[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 Martin Liška changed: What|Removed |Added Host|powerpcle-*-linux-gnu* |powerpc64le-linux-gnu Build|powerpcle-*-linux-gnu* |powerpc64le-linux-gnu Target|powerpcle-*-linux-gnu* |powerpc64le-linux-gnu --- Comment #6 from Martin Liška --- Fixed target, it's ppc64le and I can reproduce it on gcc112.fsffrance.org machine. It contains valgrind 3.15 which is pretty new.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #13 from Richard Biener ---
(In reply to Xi Ruoyao from comment #9)
> (In reply to rguent...@suse.de from comment #8)
>
> > I guess it is because -mxgot is supposed to be handled by the assembler?
> > I see
> >
> > %{mgp32} %{mgp64} %{march=*} %{mxgot:-xgot} \
> >
> > in ASM_SPEC. I guess this doesn't make it to COLLECT_AS_OPTIONS
> > and eventually makes it dropped from COLLECT_GCC_OPTIONS as well.
>
> I don't think so.
>
> I can reproduce this issue compiling spidermonkey (js interpreter) from
> firefox-78 ESR. I'm using "-pipe" so I can easily find the parameters
> passed to "as", using "ps -aux". "-xgot" is passed correctly.
>
> > Can you attach the full output of compiling & linking with -v added?
^^^ (output aka output on the console)
I think the issue should be visible from a simple hello world compiled
with LTO and -mxgot (aka not using -xgot in the approproate places in the
end, not failing the link in the end).
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #11 from Martin Liška ---
(In reply to Segher Boessenkool from comment #10)
> (And that new test case is full of obvious invalid code as well, fwiw.)
Wait here. Changing the code to:
long compress_n_blocks = 0;
void GOST_34_11::compress_n() {
for (long i = 0; i < compress_n_blocks; ++i) {
unsigned char S[32], S2[32];
the function GOST_34_11::compress_n now does not execute at all. Thus it should
not consider an invalid code. Can you please prove where the invalid code?
Moreover, the test-case comes from the original Botan benchmark:
https://github.com/randombit/botan
I'm able to run the benchmark with Sanitizers enabled, so I really don't think
it contains an invalid code.
[Bug c++/98719] New: [modules] translating importable standard headers causes various ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98719
Bug ID: 98719
Summary: [modules] translating importable standard headers
causes various ICEs
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at kolpackov dot net
Target Milestone: ---
Created attachment 49989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49989&action=edit
build transcript
An attempt to enable include translation for all the importable standard
headers (http://eel.is/c++draft/library#headers-4) causes various internal
compiler errors. Here are a few examples:
Trying to translate from a top-level include:
c++ ../../gcc-install/include/c++/11.0.0/h{type_traits}
c++ ../../gcc-install/include/c++/11.0.0/h{concepts}
c++ ../../gcc-install/include/c++/11.0.0/h{compare}
In file included from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/stl_iterator_base_types.h:71,
from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/stl_algobase.h:65,
from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/char_traits.h:39,
from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/string:40:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/iterator_concepts.h:34:
internal compiler error: in set_filename, at cp/module.cc:19081
34 |
|
0xc69be8 module_state::set_filename(Cody::Packet const&)
../../gcc/gcc/cp/module.cc:19081
0xc69e4f maybe_translate_include
../../gcc/gcc/cp/module.cc:19124
0x2bfcda7 _cpp_stack_file
../../gcc/libcpp/files.c:912
0x2bfd420 _cpp_stack_include
../../gcc/libcpp/files.c:1104
0x2bf15ea do_include_common
../../gcc/libcpp/directives.c:853
0x2bf1642 do_include
../../gcc/libcpp/directives.c:865
0x2bf0bc0 _cpp_handle_directive
../../gcc/libcpp/directives.c:541
0x2c094d1 cpp_directive_only_process(cpp_reader*, void*, void (*)(cpp_reader*,
CPP_DO_task, void*, ...))
../../gcc/libcpp/lex.c:4393
0xf11c8e scan_translation_unit_directives_only
../../gcc/gcc/c-family/c-ppoutput.c:402
0xf11158 preprocess_file(cpp_reader*)
../../gcc/gcc/c-family/c-ppoutput.c:100
0xf0b6e4 c_common_init()
../../gcc/gcc/c-family/c-opts.c:1188
0xbe4d7b cxx_init()
../../gcc/gcc/cp/lex.c:332
0x1805e47 lang_dependent_init
../../gcc/gcc/toplev.c:1881
0x18066f9 do_compile
../../gcc/gcc/toplev.c:2178
Trying to translate from a top-level include:
c++ ../../gcc-install/include/c++/11.0.0/h{iosfwd}
c++ ../../gcc-install/include/c++/11.0.0/h{typeinfo}
c++ ../../gcc-install/include/c++/11.0.0/h{new}
c++ ../../gcc-install/include/c++/11.0.0/h{type_traits}
c++ ../../gcc-install/include/c++/11.0.0/h{exception}
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/exception:
internal compiler error: in write_cluster, at cp/module.cc:14563
0xc5b52c module_state::write_cluster(elf_out*, depset**, unsigned int,
depset::hash&, unsigned int*, unsigned int*)
../../gcc/gcc/cp/module.cc:14562
0xc65808 module_state::write(elf_out*, cpp_reader*)
../../gcc/gcc/cp/module.cc:17691
0xc6bbfd finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:19747
0xb8a7a1 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:5178
0xf0b805 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1233
The build transcripts for these two cases are attached.
[Bug fortran/64290] [F03] No finalization at deallocation of LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64290 --- Comment #5 from Ev Drikos --- Created attachment 49990 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49990&action=edit realloc_class_8.f95 Hello, Having seen a Note in F2018 draft, specifically 10.2.1.3 Interpretation of intrinsic assignments, I wrote a test case that I thought should be ok, but I face this: $ gfortran8 realloc_class_8.f95 && ./a.out DEFERRED LENGTH NAME NAME=NONE [LEN= 4 ] USER=NONE [LEN= 4 ] NAME=Mr. John Richard Doe [LEN= 20 ] USER=Mr. John RichardMr. [LEN= 20 ] STOP 6 Of course, there are no finalizers in this case, yet I think that is closely related because they have the same bug fix (class reallocations). Hope this helps, Ev. Drikos
[Bug c++/98719] [modules] translating importable standard headers causes various ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98719 --- Comment #1 from Boris Kolpackov --- Created attachment 49991 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49991&action=edit build transcript
[Bug c++/98707] ICE using std::string in a module partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98707 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-18
[Bug c++/98720] New: [modules] update __cpp_modules value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98720 Bug ID: 98720 Summary: [modules] update __cpp_modules value Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: boris at kolpackov dot net Target Milestone: --- It is currently 201810 while it should be 201907.
[Bug c++/98718] [modules] use of partitions causes ICE in write_macro_maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98718 --- Comment #1 from Boris Kolpackov --- Perhaps this is the same bug but with a simpler reproducer (it points to the same location): cat
[Bug middle-end/98713] Failure to generate branch version of abs if user requested it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-18 CC||marxin at gcc dot gnu.org, ||sayle at gcc dot gnu.org, ||uros at gcc dot gnu.org --- Comment #1 from Martin Liška --- I think it's fixed since r11-2588-gc072fd236dc08f99. @Roger, Uros: Can you please verify that?
[Bug middle-end/98715] ICE in make_decl_rtl with double variable length array (VLA)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98715 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Last reconfirmed||2021-01-18 Ever confirmed|0 |1
[Bug tree-optimization/98721] New: [11 Regression] ICE in c_tree_printer at /gcc/c/c-objc-common.c:314 since r11-5523-geafe8ee7af13c398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98721
Bug ID: 98721
Summary: [11 Regression] ICE in c_tree_printer at
/gcc/c/c-objc-common.c:314 since
r11-5523-geafe8ee7af13c398
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: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
Since the revision, I see the following ICE:
$ cat strlen.i
long unsigned int strlen(const char *);
void test_char_vla_local(int n) {
char vla[n];
if (1 == strlen(vla)) {
char vla[n];
}
}
$ gcc strlen.i -c -fsanitize=undefined -fno-code-hoisting -O3
strlen.i: In function ‘test_char_vla_local’:
strlen.i:5:12: warning: ‘strlen’ reading 1 or more bytes from a region of size
0 [-Wstringop-overread]
5 | if (1 == strlen(vla)) {
|^~~
‘
during RTL pass: expand
Segmentation fault
0xe6e37a crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:327
0x8a9ee8 c_tree_printer
/home/marxin/Programming/gcc/gcc/c/c-objc-common.c:314
0x8a9ee8 c_tree_printer
/home/marxin/Programming/gcc/gcc/c/c-objc-common.c:254
0x1a43872 pp_format(pretty_printer*, text_info*)
/home/marxin/Programming/gcc/gcc/pretty-print.c:1475
0x1a288a0 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/marxin/Programming/gcc/gcc/diagnostic.c:1244
0x1a2bb87 diagnostic_impl
/home/marxin/Programming/gcc/gcc/diagnostic.c:1406
0x1a2bb87 inform(unsigned int, char const*, ...)
/home/marxin/Programming/gcc/gcc/diagnostic.c:1485
0x994e06 access_ref::inform_access(access_mode) const
/home/marxin/Programming/gcc/gcc/builtins.c:4576
0x998aab check_access(tree_node*, tree_node*, tree_node*, tree_node*,
tree_node*, access_mode, access_data const*)
/home/marxin/Programming/gcc/gcc/builtins.c:4889
0x9998c4 check_read_access
/home/marxin/Programming/gcc/gcc/builtins.c:4909
0xc1 check_read_access
/home/marxin/Programming/gcc/gcc/expr.h:282
0xc1 expand_builtin_strlen
/home/marxin/Programming/gcc/gcc/builtins.c:3701
0x99ef2c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/marxin/Programming/gcc/gcc/builtins.c:9818
0xaf2c8d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:11275
0xafe0b0 store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/marxin/Programming/gcc/gcc/expr.c:5885
0xaff8cf expand_assignment(tree_node*, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/expr.c:5621
0x9c9046 expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2837
0x9c9046 expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3843
0x9c9046 expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:4007
0x9cef5a expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6044
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/98721] [11 Regression] ICE in c_tree_printer at /gcc/c/c-objc-common.c:314 since r11-5523-geafe8ee7af13c398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98721 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-18 Known to work||10.2.0 Ever confirmed|0 |1 Target Milestone|--- |11.0 Known to fail||11.0
[Bug tree-optimization/98721] [11 Regression] ICE in c_tree_printer at /gcc/c/c-objc-common.c:314 since r11-5523-geafe8ee7af13c398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98721 --- Comment #1 from Martin Liška --- Where both these 2 objects are null: (gdb) p sizestr $7 = "0", '\000' , "\060\316\377\377\377\177\000\000P\316\377\377\377\177\000\000\210#\000\000\000\000\000\000\230\373;\367\377\177\000\000\000wF\367\377\177\000\000\340-;\367\377\177\000\000\340\267<\367\377\177\000\000\361̖\000\000\000\000" (gdb) p allocfn $8 = in access_ref::inform_access (access_mode mode) const function.
[Bug middle-end/98713] Failure to generate branch version of abs if user requested it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #2 from Roger Sayle --- My first impression is that this isn't a bug, it's a feature. In an optimizing compiler, the user specifies the computation to be performed and the compiler selects the implementation. Hence "x+0" isn't a user request to perform an addition. Perhaps David could provide more information on why a branch implementation is required/preferred (for example on which target)? On generic x86_64, I believe the code currently generated is both smaller and faster. Assuming "neg eax" takes about the same time as "test edi,edi", and that "cmovs" takes about the same time as (either branch) of "js". As a workaround a branch version can be implemented in inline assembly using __asm, but I'm still hazy as to why this would be desirable.
[Bug tree-optimization/98703] Failure to optimize out non-zero check after multiplication overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98703 Richard Biener changed: What|Removed |Added Blocks||85316 --- Comment #1 from Richard Biener --- Guess VRP should infer a range for x then after __builtin_mul_overflow is true? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug middle-end/98713] Failure to generate branch version of abs if user requested it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713 --- Comment #3 from Richard Biener --- A well-predicted branch will be faster than the cmov because of the shorter data dependence path.
[Bug tree-optimization/98703] Failure to optimize out non-zero check after multiplication overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98703 Jakub Jelinek changed: What|Removed |Added CC||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I guess so, and even for the case where it returned false. If it returned true, we can at least infer that both operands are non-zero (and for operands with the same type and same as the return type's element type also not 1, 1 * x won't overflow either, but e.g. 1 * x might overflow if stored into unsigned and x is negative), if it returns false and say one argument is constant, we can easily compute range of the other one. Perhaps from range of one operand we could also infer the range of the other operand, but perhaps that might be too dangerous.
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Priority|P3 |P1
[Bug tree-optimization/98721] [11 Regression] ICE in c_tree_printer at /gcc/c/c-objc-common.c:314 since r11-5523-geafe8ee7af13c398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98721 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/98694] [11 Regression] GCC produces incorrect code for loops with -O3 for skylake-avx512 and icelake-server
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98694
--- Comment #7 from Hongtao.liu ---
Another testcase reproduce the same issue.
#include
typedef short v4hi __attribute__ ((vector_size (8)));
typedef int v2si __attribute__ ((vector_size (8)));
v4hi b;
__attribute__ ((noipa))
v2si
foo (__m512i src1, __m512i src2)
{
__mmask64 m = _mm512_cmpeq_epu8_mask (src1, src2);
short s = (short) m;
int i = (int)m;
b = __extension__ (v4hi) {s, s, s, s};
return __extension__ (v2si) {i, i};
}
int main ()
{
__m512i src1 = _mm512_setzero_si512 ();
__m512i src2 = _mm512_set_epi8 (0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1);
__mmask64 m = _mm512_cmpeq_epu8_mask (src1, src2);
v2si a = foo (src1, src2);
if (a[0] != (int)m)
__builtin_abort ();
return 0;
}
[Bug rtl-optimization/98722] New: [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-6615-gcf2ac1c30af0fa783c8d72e527904dda5d8cc330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722
Bug ID: 98722
Summary: [11 Regression] ICE in lra_set_insn_recog_data, at
lra.c:1004 since
r11-6615-gcf2ac1c30af0fa783c8d72e527904dda5d8cc330
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: s390x-linux-gnu
Since the revision I see the following ICE:
$ cat reint.cpp
struct B {
virtual void Method();
};
typedef void (B::*fn_type_a)();
int main() {
fn_type_a f(&B::Method);
B b;
(b.*f)();
}
$ ./xgcc -B. -Og -fno-tree-fre -fno-split-wide-types -c reint.cpp
during RTL pass: reload
reint.cpp: In function ‘int main()’:
reint.cpp:10:1: internal compiler error: in lra_set_insn_recog_data, at
lra.c:1004
10 | }
| ^
0x138dc84 lra_set_insn_recog_data(rtx_insn*)
/home/marxin/Programming/gcc2/gcc/lra.c:1004
0x138b9e1 lra_get_insn_recog_data
/home/marxin/Programming/gcc2/gcc/lra-int.h:486
0x138f87d lra_update_insn_regno_info(rtx_insn*)
/home/marxin/Programming/gcc2/gcc/lra.c:1625
0x138fd86 lra_push_insn_1
/home/marxin/Programming/gcc2/gcc/lra.c:1780
0x138fdb9 lra_push_insn(rtx_insn*)
/home/marxin/Programming/gcc2/gcc/lra.c:1788
0x138fec1 push_insns
/home/marxin/Programming/gcc2/gcc/lra.c:1831
0x13900ae lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char const*)
/home/marxin/Programming/gcc2/gcc/lra.c:1871
0x13a73ac curr_insn_transform
/home/marxin/Programming/gcc2/gcc/lra-constraints.c:4644
0x13a8a02 lra_constraints(bool)
/home/marxin/Programming/gcc2/gcc/lra-constraints.c:5138
0x139119c lra(_IO_FILE*)
/home/marxin/Programming/gcc2/gcc/lra.c:2332
0x1339df4 do_reload
/home/marxin/Programming/gcc2/gcc/ira.c:5811
0x133a2d6 execute
/home/marxin/Programming/gcc2/gcc/ira.c:5997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/98722] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-6615-gcf2ac1c30af0fa783c8d72e527904dda5d8cc330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-01-18 Known to fail||11.0 Known to work||10.2.0 Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug middle-end/98713] Failure to generate branch version of abs if user requested it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713 --- Comment #4 from Uroš Bizjak --- Please see PR 56309 (and PR 85559 meta bug). Quote from Honza: The decision on whether to use cmov or jmp was always tricky on x86 architectures. Cmov increase dependency chains, register pressure (both values needs to be loaded in) and has long opcode. So jump sequence, if well predicted, flows better through the out-of-order core. If badly predicted it is, of course, a disaster. I think more modern CPUs solved the problems with long latency of cmov, but the dependency chains are still there. We don't know how to drive the decision, as this is a deep architectural issue.
[Bug tree-optimization/98673] pass fre4 inhibit pass dom3 to create much more optimized code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98673
Richard Biener changed:
What|Removed |Added
Known to work||8.4.0
--- Comment #4 from Richard Biener ---
Please try simplifying the testcase, I've tried
long loadValue;
const long *engLoad;
float engLoadDelta1;
void foo()
{
long i1, numXEntries = 50;
for( i1 = 0 ; i1 < ( numXEntries - 1 ) ; i1++ )
{
if( ( loadValue < engLoad[i1+1] ) && ( loadValue >= engLoad[i1] ) )
{
break ;
}
}
if( i1 == ( numXEntries - 1 ) )
{
loadValue = engLoad[i1] ;
}
engLoadDelta1 = (float)( loadValue - engLoad[i1] ) /
(float)( engLoad[i1 + 1] - engLoad[i1] ) ;
}
which on x86 doesn't exhibit the issue (same code with GCC 8 and GCC 10).
[Bug tree-optimization/98268] ICE: verify_gimple failed with LTO and SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98268 --- Comment #3 from Alex Coplan --- Adding --param=aarch64-autovec-preference=3 I can reproduce the ICE on trunk.
[Bug tree-optimization/98095] Optimize __builtin_unordered (...) || __builtin_is{less,greater}{,equal}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98095 Roger Sayle changed: What|Removed |Added Last reconfirmed||2021-01-18 CC||roger at nextmovesoftware dot com Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 --- Comment #3 from Stam Markianos-Wright --- Just started looking at this. I've narrowed it as the bug appearing with commit 9b75f56d4b7951c60a6563964a65787b95bc. I have yet to fire this up in gdb to see what's happening, but one test I did do was to try commenting out the assert that is causing the ICE and it then ran to completion. So one _total speculation_ would be that with these latest changes that enable groups of different sizes, this condition in the assert is now too strict: multiple_p (TYPE_VECTOR_SUBPARTS (nunits_vectype), TYPE_VECTOR_SUBPARTS (*stmt_vectype_out)))
[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98708
--- Comment #17 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2e43880dbd4cb9722ae99708c01c399f985dc7c3
commit r11-6765-g2e43880dbd4cb9722ae99708c01c399f985dc7c3
Author: Jakub Jelinek
Date: Mon Jan 18 11:28:17 2021 +0100
libstd++: : Add workaround for as Error: file number less than one error
[PR98708]
As mentioned in the PR, since the switch to DWARF5 by default instead of
DWARF4, gcc fails to build when configured against recent binutils.
The problem is that cxx11-ios_failure* is built in separate steps,
-S compilation (with -g -O2) followed by some sed and followed by
-c -g -O2 -g0 assembly. When gcc is configured against recent binutils
and DWARF5 is the default, we emit .file 0 "..." directive on which the
assembler then fails (unless --gdwarf-5 is passed to it, but we don't want
that generally because on the other side older assemblers don't like -g*
passed to it when invoked on *.s file with compiler generated debug info.
I hope the bug will be fixed soon on the binutils side, but it would be
nice
to have a workaround.
The following patch is one of the possibilities, another one is to do that
but add configure check for whether it is needed,
essentially
echo 'int main () { return 0; }' > conftest.c
${CXX} ${CXXFLAGS} -g -O2 -S conftest.c -o conftest.s
${CXX} ${CXXFLAGS} -g -O2 -g0 -c conftest.s -o conftest.o
and if the last command fails, we need that -gno-as-loc-support.
Or yet another option would be I think do a different check, whether
${CXX} ${CXXFLAGS} -g -O2 -S conftest.c -o conftest.s
${CXX} ${CXXFLAGS} -g -O2 -c conftest.s -o conftest.o
works and if yes, don't add the -g0 to cxx11-ios_failure*.s assembly.
2021-01-18 Jakub Jelinek
PR debug/98708
* src/c++11/Makefile.am (cxx11-ios_failure-lt.s,
cxx11-ios_failure.s):
Compile with -gno-as-loc-support.
* src/c++11/Makefile.in: Regenerated.
[Bug middle-end/98713] Failure to generate branch version of abs if user requested it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713 --- Comment #5 from Dávid Bolvanský --- User knows the data better, so he/she may prefer abs with branch. Also PGO may say that branch for abs is better based on profile data.
[Bug middle-end/98713] Failure to generate branch version of abs if user requested it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Guess we should punt on the various phiopt detections if the branch probabilities are substantially different.
[Bug libstdc++/98723] New: On Windows with CP936 encoding, regex compiles very slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723
Bug ID: 98723
Summary: On Windows with CP936 encoding, regex compiles very
slow.
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: goughostt at gmail dot com
Target Milestone: ---
example code:
#include
#include
#include
int main() {
std::setlocale(LC_ALL, "");
std::regex rgx{"[a-z][a-z][a-z]"};
std::cerr<::do_transform() is made;
do_transform() will use the result of strxfrm() to allocate buffer;
on Windows, strxfrm() returns INT_MAX to indicate error;
if char > 0x7f, and the system encoding is CP936, strxfrm() will fail;
thus, compiling '[a-z]' will repeatedly allocate large buffers.
issues:
1. the regex compilation will be affected by current locale even if
std::regex::collate is not set, by calling strxfrm.
2. code in bits/locale_classes.tcc should handle documented return conditions
of strxfrm() on Windows:
size_t __res = _M_transform(__c, __p, __len); //*** calls strxfrm()
// If the buffer was not large enough, try again with the
// correct size.
if (__res >= __len)
{
__len = __res + 1;
delete [] __c, __c = 0;
__c = new _CharT[__len];
__res = _M_transform(__c, __p, __len);
}
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 --- Comment #4 from rsandifo at gcc dot gnu.org --- (In reply to Stam Markianos-Wright from comment #3) > Just started looking at this. I've narrowed it as the bug appearing with > commit 9b75f56d4b7951c60a6563964a65787b95bc. > > I have yet to fire this up in gdb to see what's happening, but one test I > did do was to try commenting out the assert that is causing the ICE and it > then ran to completion. > > So one _total speculation_ would be that with these latest changes that > enable groups of different sizes, this condition in the assert is now too > strict: > > > multiple_p (TYPE_VECTOR_SUBPARTS (nunits_vectype), > TYPE_VECTOR_SUBPARTS (*stmt_vectype_out))) What are nunits_vectype and *stmt_vectype_out at the point that the assert fails?
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 --- Comment #2 from Jakub Jelinek --- The failed asan tests are all with -flto, and the changes in the output are from: WRITE of size 1 at 0x7ffeab2b5d8a thread T0 #0 0x401288 in foo /home/jakub/src/gcc/gcc/testsuite/c-c++-common/asan/alloca_big_alignment.c:11 #1 0x4010c4 in main /home/jakub/src/gcc/gcc/testsuite/c-c++-common/asan/alloca_big_alignment.c:15 #2 0x7f9c719311a1 in __libc_start_main (/lib64/libc.so.6+0x281a1) #3 0x40112d in _start (/home/jakub/src/gcc/obj66/gcc/testsuite/gcc6/alloca_big_alignment.exe+0x40112d) like output to: WRITE of size 1 at 0x7ffe337c4b0a thread T0 #0 0x401288 in foo gcc/obj2/gcc/testsuite/gcc3/:11 #1 0x4010c4 in main gcc/obj2/gcc/testsuite/gcc3/:15 #2 0x7efe2df801a1 in __libc_start_main (/lib64/libc.so.6+0x281a1) #3 0x40112d in _start (gcc/obj2/gcc/testsuite/gcc3/alloca_big_alignment.exe+0x40112d)
[Bug ada/98724] New: [11 Regression] gnat build failure on alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98724 Bug ID: 98724 Summary: [11 Regression] gnat build failure on alpha-linux-gnu Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- trunk fails to build gnat on alpha-linux-gnu. Although it only prints warnings ... /packages/cross/11/p/gcc-cross-ports/gcc/build/./gcc/xgcc -B/packages/cross/11/p/gcc-cross-ports/gcc/build/./gcc/ -B/usr/alpha-linux-gnu/bin/ -B/usr/alpha-linux-gnu/lib/ -isystem /usr/alpha-linux-gnu/include -isystem /usr/alph a-linux-gnu/sys-include -isystem /packages/cross/11/p/gcc-cross-ports/gcc/build/sys-include-c -g -O2 -W -Wa ll -gnatpg -nostdinc -gnatn a-nallfl.ads -o a-nallfl.o a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:48:13: warning: profile of "Sin" doesn't match the builtin it binds a-nallfl.ads:51:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:51:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:51:13: warning: profile of "Cos" doesn't match the builtin it binds a-nallfl.ads:54:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:54:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:54:13: warning: profile of "Tan" doesn't match the builtin it binds a-nallfl.ads:57:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:57:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:57:13: warning: profile of "Exp" doesn't match the builtin it binds a-nallfl.ads:60:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:60:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:60:13: warning: profile of "Sqrt" doesn't match the builtin it binds a-nallfl.ads:63:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:63:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:63:13: warning: profile of "Log" doesn't match the builtin it binds a-nallfl.ads:66:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:66:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:66:13: warning: profile of "Acos" doesn't match the builtin it binds a-nallfl.ads:69:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:69:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:69:13: warning: profile of "Asin" doesn't match the builtin it binds a-nallfl.ads:72:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:72:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:72:13: warning: profile of "Atan" doesn't match the builtin it binds a-nallfl.ads:75:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:75:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:75:13: warning: profile of "Sinh" doesn't match the builtin it binds a-nallfl.ads:78:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:78:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:78:13: warning: profile of "Cosh" doesn't match the builtin it binds a-nallfl.ads:81:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:81:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:81:13: warning: profile of "Tanh" doesn't match the builtin it binds a-nallfl.ads:84:13: warning: intrinsic binding type mismatch on return value a-nallfl.ads:84:13: warning: intrinsic binding type mismatch on argument 1 a-nallfl.ads:84:13: warning: profile of "Pow" doesn't match the builtin it binds make[9]: *** [../gcc-interface/Makefile:302: a-nallfl.o] Error 1 make[9]: Leaving directory '/packages/cross/11/p/gcc-cross-ports/gcc/build/gcc/ada/rts' make[8]: *** [gcc-interface/Makefile:634: gnatlib] Error 2 make[8]: Leaving directory '/packages/cross/11/p/gcc-cross-ports/gcc/build/gcc/ada' make[7]: *** [gcc-interface/Makefile:727: gnatlib-shared-dual] Error 2 make[7]: Leaving directory '/packages/cross/11/p/gcc-cross-ports/gcc/build/gcc/ada' make[6]: *** [gcc-interface/Makefile:830: gnatlib-shared] Error 2 make[6]: Leaving directory '/packages/cross/11/p/gcc-cross-ports/gcc/build/gcc/ada' make[5]: *** [Makefile:108: gnatlib-shared] Error 2 make[5]: Leaving directory '/packages/cross/11/p/gcc-cross-ports/gcc/build/alpha-linux-gnu/libada' make[4]: *** [Makefile:16641: all-target-libada] Error 2 make[4]: Leaving directory '/packages/cross/11/p/gcc-cross-ports/gcc/build' make[3]: *** [Makefile:979: all] Error 2 GCC configured with --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-
[Bug tree-optimization/98268] [10 Regression] ICE: verify_gimple failed with LTO and SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98268 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Priority|P3 |P2 Target Milestone|--- |10.3 CC||ktkachov at gcc dot gnu.org Last reconfirmed||2021-01-18 Known to work||9.3.1 Known to fail||10.2.1 Ever confirmed|0 |1 Summary|ICE: verify_gimple failed |[10 Regression] ICE: |with LTO and SVE|verify_gimple failed with ||LTO and SVE --- Comment #4 from ktkachov at gcc dot gnu.org --- I can't reproduce on trunk even with the param, but it does trigger on GCC 10 branch. Does it need some extra checking in the configuration?
[Bug rtl-optimization/98722] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-6615-gcf2ac1c30af0fa783c8d72e527904dda5d8cc330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Keywords||ra
[Bug tree-optimization/98268] [10 Regression] ICE: verify_gimple failed with LTO and SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98268 --- Comment #5 from Alex Coplan --- Ah, sorry, I hit this with a VLA compile on trunk, so the full command line is: $ aarch64-elf-gcc a.c b.c -flto -O1 -ftree-vectorize -march=armv8.2-a+sve --param=aarch64-autovec-preference=3 with the above source files. It doesn't ICE with the -msve-vector-bits=128 flag as above.
[Bug tree-optimization/98268] [10/11 Regression] ICE: verify_gimple failed with LTO and SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98268 ktkachov at gcc dot gnu.org changed: What|Removed |Added Summary|[10 Regression] ICE:|[10/11 Regression] ICE: |verify_gimple failed with |verify_gimple failed with |LTO and SVE |LTO and SVE Known to fail||11.0 --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to Alex Coplan from comment #5) > Ah, sorry, I hit this with a VLA compile on trunk, so the full command line > is: > > $ aarch64-elf-gcc a.c b.c -flto -O1 -ftree-vectorize -march=armv8.2-a+sve > --param=aarch64-autovec-preference=3 > > with the above source files. It doesn't ICE with the -msve-vector-bits=128 > flag as above. Indeed, reproduced now, thanks.
[Bug libstdc++/98723] On Windows with CP936 encoding, regex compiles very slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-01-18
[Bug libstdc++/98725] New: Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 Bug ID: 98725 Summary: Review what is disabled in libstdc++ by --disable-wchar_t Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Currently libstdc++ guards *any* use of wchar_t with a check for _GLIBCXX_USE_WCHAR_T. This has unfortunate consequences such as std::wstring_convert being unusable to convert between char and char16_t (which doesn't use wchar_t at all). That's because we do this in : #ifdef _GLIBCXX_USE_WCHAR_T _GLIBCXX_BEGIN_NAMESPACE_CXX11 /// String conversions template, typename _Byte_alloc = allocator> class wstring_convert The wchar_t type exists unconditionally for C++, so traits like std::is_integral_v are already always defined as true. std::char_traits also works, by using the primary template (which works for any character-like type). That means that even std::wstring works, albeit slower than if we had optimized support for in libc. The consequences of --disable-wchar_t (whether implicit or explicit) should to disable explicit instantiations for std::wstring, std::wifstream etc. and to disable wchar_t support in locales and std::filesystem. It doesn't need to disable everything that refers to wchar_t.
[Bug ada/98724] [11 Regression] gnat build failure on alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98724 --- Comment #1 from Uroš Bizjak --- Sorry, I don't have access to alpha anymore. (And I'm surprised that gnat even builds, because I've never tried.)
[Bug libstdc++/98723] On Windows with CP936 encoding, regex compiles very slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #1 from Jonathan Wakely --- The Windows behaviour fails to conform to the C and C++ standards. I think _M_transform should check errno and throw an exception on error (which means removing the non-throwing exceptions specification from that function).
[Bug tree-optimization/98726] New: aarch64: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
Bug ID: 98726
Summary: aarch64: tree check: expected integer_cst, have
poly_int_cst in to_wide, at tree.h:5984
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat test.c
int a, c;
char b;
int d() {
a = 0;
for (; a <= 21; a = (short)a + 1)
b &= c;
}
$ aarch64-elf-gcc -c test.c -O3 -march=armv8.2-a+sve
during GIMPLE pass: forwprop
test.c: In function 'd':
test.c:3:5: internal compiler error: tree check: expected integer_cst, have
poly_int_cst in to_wide, at tree.h:5984
3 | int d() {
| ^
0x1161f66 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/alecop01/toolchain/src/gcc/gcc/tree.c:9812
0x7393c1 tree_check(tree_node const*, char const*, int, char const*, tree_code)
/home/alecop01/toolchain/src/gcc/gcc/tree.h:3594
0x7393c1 wi::to_wide(tree_node const*)
/home/alecop01/toolchain/src/gcc/gcc/tree.h:5984
0x1177e1d vector_cst_int_elt(tree_node const*, unsigned int)
/home/alecop01/toolchain/src/gcc/gcc/tree.c:11104
0x11935a3 vector_cst_elt(tree_node const*, unsigned int)
/home/alecop01/toolchain/src/gcc/gcc/tree.c:11131
0xa35b48 const_binop(tree_code, tree_node*, tree_node*, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/fold-const.c:1644
0x1484144 gimple_resimplify2
/home/alecop01/toolchain/src/gcc/gcc/gimple-match-head.c:276
0x14b3ca2 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
/home/alecop01/toolchain/src/gcc/gcc/gimple-match-head.c:957
0xa9c5d1 fold_stmt_1
/home/alecop01/toolchain/src/gcc/gcc/gimple-fold.c:6016
0xa9ef9b fold_stmt(gimple_stmt_iterator*, tree_node* (*)(tree_node*))
/home/alecop01/toolchain/src/gcc/gcc/gimple-fold.c:6254
0xf73a2a execute
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-forwprop.c:3108
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/98726] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726 Alex Coplan changed: What|Removed |Added Target Milestone|--- |11.0 Known to fail||11.0 Keywords||ice-checking, ||ice-on-valid-code Target||aarch64 Summary|aarch64: tree check:|SVE: tree check: expected |expected integer_cst, have |integer_cst, have |poly_int_cst in to_wide, at |poly_int_cst in to_wide, at |tree.h:5984 |tree.h:5984
[Bug middle-end/98713] Failure to generate branch version of abs if user requested it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713 --- Comment #7 from Roger Sayle --- I agree in the general case, a conditional jump (that depends only on the condition flags) potentially has a shorter dependence chain than a cmov (which depends on the condition flags and two registers). But in this case, the condition codes can't be determined any faster than the register operands. I believe the branch prediction argument is a red herring. Yes, with clever hardware and luck, the CPU can predict which instruction will be executed next after a conditional jump, but it can always know which instruction is executed next after a cmov. A cmov (and multiple cmovs) can be scheduled and executed out-of-order without speculation. Hence branch prediction is only a factor when dependency chain lengths are an issue/unequal (or the cmov is slower than a correctly predicted branch). An understanding the data distribution is also irrelevant if the best/fastest (correctly predicted) branch implementation is no better/faster than the cmov. But I can also imagine microarchitectures where predicted conditional jumps are free (requiring zero cycles) and where the condition code "test" is eliminated having been set/forwarded from an earier instruction, in which case a zero-latency abs is about as good as you can get. Are we assuming a target with "predicted_branch_cost < conditional_move_cost"? I wouldn't be surprised if GCC internally assumes these are both always COSTS_N_INSNS(1). If conditional_move_cost <= predicted_branch_cost <= mispredicted_branch_cost then the cmov should always preferred (independent of branch probabilities or __builtin_expect hints). If predicted_branch_cost <= mispredicted_branch_cost <= conditional_move_cost, the branch should always be preferred, and the cmov shouldn't be part of the ISA. The interesting domain of trade-offs is where/when predicted_branch_cost < conditional_move_cost <= mispredicted_branch_cost (which I'm not yet convinced is the case here). Do we have any numbers that show the branch is better (for this case) on real hardware, than can't be explained by other factors? For example, on ABS where the inputs are always positive.
[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||9.3.1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-18 Known to fail||10.2.1 Ever confirmed|0 |1 Target Milestone|11.0|10.3 CC||ktkachov at gcc dot gnu.org Priority|P3 |P2 Summary|SVE: tree check: expected |[10/11 Regression] SVE: |integer_cst, have |tree check: expected |poly_int_cst in to_wide, at |integer_cst, have |tree.h:5984 |poly_int_cst in to_wide, at ||tree.h:5984 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/98727] New: [11 Regression] Miscompiled signed overflow check since r11-6580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98727
Bug ID: 98727
Summary: [11 Regression] Miscompiled signed overflow check
since r11-6580
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
__attribute__((noipa)) long int
foo (long int x, long int y)
{
long int z = (unsigned long) x * y;
if (x != z / y)
return -1;
return z;
}
int
main ()
{
if (foo (4, 24) != 96
|| foo (124, 126) != 124L * 126
|| foo (__LONG_MAX__ / 16, 17) != -1)
__builtin_abort ();
return 0;
}
is miscompiled at -O2 since r11-6580-g9febe9e4be7812519258ea3ed4f38bbc1a61624b
[Bug tree-optimization/98727] [11 Regression] Miscompiled signed overflow check since r11-6580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98727 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-01-18 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |11.0 Priority|P3 |P1 Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/98727] [11 Regression] Miscompiled signed overflow check since r11-6580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98727 --- Comment #1 from Jakub Jelinek --- Created attachment 49992 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49992&action=edit gcc11-pr98727.patch Untested fix.
[Bug ada/98724] [11 Regression] gnat build failure on alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98724 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug debug/98728] New: [11 regression] Several debug tests FAIL with DWARF-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 Bug ID: 98728 Summary: [11 regression] Several debug tests FAIL with DWARF-5 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: mark at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-pc-linux-gnu With the switch to DWARF-5, two debug tests have started to FAIL: +FAIL: g++.dg/debug/dwarf2/constexpr-var-1.C scan-assembler-times DW_AT_const_expr 2 32 and 64-bit Solaris/SPARC and x86, Linux/x86_64 +FAIL: gcc.dg/debug/dwarf2/dwarf-float.c scan-assembler 0x10.*DW_AT_byte_size 32-bit Solaris/x86 and Linux/x86_64 Besides, there were many changes to guality tests on Linux/x86_64, both tests previously XPASSing now XFAIL again, as well as several new FAILs.
[Bug tree-optimization/98727] [11 Regression] Miscompiled signed overflow check since r11-6580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98727 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Heh, how did you come with the test-case?
[Bug debug/98728] [11 regression] Several debug tests FAIL with DWARF-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jan Hubicka --- Mine. Note that the initialized warning was not really related to this problem, just to the assumption that parameters declared "const" are read by the callee which was proved false by modref and triggered false positive in the warning.
[Bug target/79437] Redundant move instruction when getting sign bit of double on 32-bit architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79437 --- Comment #5 from Matheus Izvekov --- Issue is still present on 10.2 and trunk. Workspace for reference: https://godbolt.org/z/EYhaaW I believe this issue should have already been transitioned to CONFIRMED.
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 --- Comment #3 from Jakub Jelinek --- So, seems when asan alloca_big_alignment test is built with -gdwarf-4 -flto, we have: Offset: 0x57 Length: 214 DWARF Version: 4 Prologue Length: 105 Minimum Instruction Length: 1 Maximum Ops per Instruction: 1 Initial value of 'is_stmt': 1 Line Base: -5 Line Range: 14 Opcode Base: 13 Opcodes: Opcode 1 has 0 args Opcode 2 has 1 arg Opcode 3 has 1 arg Opcode 4 has 1 arg Opcode 5 has 1 arg Opcode 6 has 0 args Opcode 7 has 0 args Opcode 8 has 0 args Opcode 9 has 1 arg Opcode 10 has 0 args Opcode 11 has 0 args Opcode 12 has 1 arg The Directory Table (offset 0x73): 1 /usr/src/gcc/gcc/testsuite/c-c++-common/asan The File Name Table (offset 0xa1): Entry Dir TimeSizeName 1 1 0 0 alloca_big_alignment.c 2 0 0 0 Line Number Statements: [0x00ca] Set column to 56 [0x00cc] Extended opcode 2: set Address to 0x4011f0 [0x00d7] Special opcode 12: advance Address by 0 to 0x4011f0 and Line by 7 to 8 [0x00d8] Set is_stmt to 0 [0x00d9] Copy (view 1) [0x00da] Set column to 17 [0x00dc] Special opcode 20: advance Address by 1 to 0x4011f1 and Line by 1 to 9 [0x00dd] Special opcode 89: advance Address by 6 to 0x4011f7 and Line by 0 to 9 [0x00de] Set column to 56 [0x00e0] Special opcode 130: advance Address by 9 to 0x401200 and Line by -1 to 8 [0x00e1] Advance PC by constant 17 to 0x401211 [0x00e2] Special opcode 47: advance Address by 3 to 0x401214 and Line by 0 to 8 [0x00e3] Set column to 3 [0x00e5] Set is_stmt to 1 [0x00e6] Special opcode 90: advance Address by 6 to 0x40121a and Line by 1 to 9 [0x00e7] Set is_stmt to 0 This is for a TU created by LTO, which in .debug_info has: <565> DW_AT_name: (indirect string, offset: 0x676): <569> DW_AT_comp_dir: (indirect string, offset: 0x652): /usr/src/gcc/obj2/gcc/testsuite/gcc Now, with -gdwarf-5 -flto, is still has: <566> DW_AT_name: (indirect line string, offset: 0x11d): <56a> DW_AT_comp_dir: (indirect line string, offset: 0x12a): /usr/src/gcc/obj2/gcc/testsuite/gcc but the .debug_lines part starts with: Offset: 0x57 Length: 162 DWARF Version: 5 Address size (bytes):8 Segment selector (bytes):0 Prologue Length: 51 Minimum Instruction Length: 1 Maximum Ops per Instruction: 1 Initial value of 'is_stmt': 1 Line Base: -5 Line Range: 14 Opcode Base: 13 Opcodes: Opcode 1 has 0 args Opcode 2 has 1 arg Opcode 3 has 1 arg Opcode 4 has 1 arg Opcode 5 has 1 arg Opcode 6 has 0 args Opcode 7 has 0 args Opcode 8 has 0 args Opcode 9 has 1 arg Opcode 10 has 0 args Opcode 11 has 0 args Opcode 12 has 1 arg The Directory Table (offset 0x79, lines 2, columns 1): Entry Name 0 (indirect line string, offset: 0x12a): /usr/src/gcc/obj2/gcc/testsuite/gcc 1 (indirect line string, offset: 0x14e): /usr/src/gcc/gcc/testsuite/c-c++-common/asan The File Name Table (offset 0x87, lines 3, columns 2): Entry Dir Name 0 0 (indirect line string, offset: 0x11d): 1 1 (indirect line string, offset: 0x1b3): alloca_big_alignment.c 2 0 (indirect line string, offset: 0x17b): Line Number Statements: [0x0096] Set column to 56 [0x0098] Extended opcode 2: set Address to 0x4011f0 [0x00a3] Special opcode 12: advance Address by 0 to 0x4011f0 and Line by 7 to 8 [0x00a4] Set is_stmt to 0 [0x00a5] Copy (view 1) [0x00a6] Set column to 17 [0x00a8] Special opcode 20: advance Address by 1 to 0x4011f1 and Line by 1 to 9 [0x00a9] Special opcode 89: advance Address by 6 to 0x4011f7 and Line by 0 to 9 [0x00aa] Set column to 56 [0x00ac] Special opcode 130: advance Address by 9 to 0x401200 and Line by -1 to 8 [0x00ad] Advance PC by constant 17 to 0x401211 [0x00ae] Special opcode 47: advance Address by 3 to 0x401214 and Line by 0 to 8 [0x00af] Set column to 3 [0x00b1] Set is_stmt to 1 [0x00b2] Special opcode 90: advance Address by 6 to 0x40121a and Line by 1 to 9 [0x00b3] Set is_stmt to 0 So the important difference is in that DWARF5 has the 0 entry in the filename table while DWARF4 does not. DWARF5 Table 6.4: Line number program initial state says that the initial file is 1, which means I think read_line_program in libbacktrace is incorrect for DWARF5.
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
--- Comment #5 from Stam Markianos-Wright ---
(In reply to rsand...@gcc.gnu.org from comment #4)
> (In reply to Stam Markianos-Wright from comment #3)
> > Just started looking at this. I've narrowed it as the bug appearing with
> > commit 9b75f56d4b7951c60a6563964a65787b95bc.
> >
> > I have yet to fire this up in gdb to see what's happening, but one test I
> > did do was to try commenting out the assert that is causing the ICE and it
> > then ran to completion.
> >
> > So one _total speculation_ would be that with these latest changes that
> > enable groups of different sizes, this condition in the assert is now too
> > strict:
> >
> >
> > multiple_p (TYPE_VECTOR_SUBPARTS (nunits_vectype),
> > TYPE_VECTOR_SUBPARTS (*stmt_vectype_out)))
> What are nunits_vectype and *stmt_vectype_out at the point
> that the assert fails?
Hmm so looking at this on commit 9b75f56d4b7951c60a6563964a65787b95bc,
we have:
nunits_vectype is a: vector(SUBPARTS {coeffs = {4, 0}}) float
*stmt_vectype_out is a: vector(SUBPARTS {coeffs = {8, 0}}) long int
In this case we are checking multiple_p (4, 8) == false
(and also group_size == 9 here which is expected)
Before the commit we'd get here with:
nunits_vectype is a: vector(SUBPARTS {coeffs = {4, 0}}) float
*stmt_vectype_out is a: vector(SUBPARTS {coeffs = {2, 0}}) long int
And here we were checking multiple_p (4, 2) == true
I'm tempted to try and add a reverse:
|| multiple_p (*stmt_vectype_out, nunits_vectype)
And then regtest, but I probably need to do more reading around to figure out
what we really should be expecting each case!
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-01-18 Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- Created attachment 49993 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49993&action=edit gcc11-pr98716.patch Untested fix.
[Bug testsuite/97299] [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299 --- Comment #2 from Richard Biener --- Just noting that while gcc-testresults has almost daily results of GCC 8,9,10 branches for ppc64le-linux trunk is only daily tested on ppc64-aix
[Bug tree-optimization/98727] [11 Regression] Miscompiled signed overflow check since r11-6580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98727
--- Comment #3 from Jakub Jelinek ---
Serge noticed LLVM miscompilation and bisected to my change and then with
instrumented GCC found two possible compilation units, and I've eyeballed the
differences on one of those and spotted the bug in the .MUL_OVERFLOW arguments
in the widening_mul dump.
The original LLVM code is like:
// Check each interesting stride.
for (int64_t Factor : Factors) {
// Check that the multiplication doesn't overflow.
if (Base.BaseOffset == std::numeric_limits::min() && Factor == -1)
continue;
int64_t NewBaseOffset = (uint64_t)Base.BaseOffset * Factor;
if (NewBaseOffset / Factor != Base.BaseOffset)
continue;
(and another very similar a few lines below).
Note, as I said in the PR for which the change has been made, the case where
one of the arguments is signed min and the other -1 can cause UB in the
division, so one needs to either do what LLVM does or conditionalize the
divisor and != other arg on what operand is -1 (choose the other one).
GCC isn't able to figure out such comparisons are part of the overflow check...
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 --- Comment #6 from rsandifo at gcc dot gnu.org --- (In reply to Stam Markianos-Wright from comment #5) > I'm tempted to try and add a reverse: > > || multiple_p (*stmt_vectype_out, nunits_vectype) > > And then regtest, but I probably need to do more reading around to figure out > what we really should be expecting each case! I don't think that's right. If nunits_vectype is not a multiple of stmt_vectype then the stmt_vectype contains (or might contain) unused elements. The vectoriser isn't set up to work like that: all operations are currently supposed to be full-vector operations (possibly predicated, on SVE and AVX). AFAICT the assert is correct and it's showing up a problem elsewhere.
[Bug testsuite/97299] [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299
--- Comment #3 from Richard Biener ---
OK, so this is a bad interaction of pattern detection and SLP reduction
vectorization. We're detecting
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/slp-reduc-3.c:26:14: note:
widen_sum pattern recognized: patt_47 = prod_24 w+ res2_31;
which in turn empties LOOP_VINFO_REDUCTIONS via
/* Patterns cannot be vectorized using SLP, because they change the order of
computation. */
if (loop_vinfo)
{
unsigned ix, ix2;
stmt_vec_info *elem_ptr;
VEC_ORDERED_REMOVE_IF (LOOP_VINFO_REDUCTIONS (loop_vinfo), ix, ix2,
elem_ptr, *elem_ptr == stmt_info);
}
which means we're ending up with interleaving (and worse code).
The sentence above should only apply to reduction ops performing lane
reduction (SAD_EXPR, but also WIDEN_SUM_EXPR).
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 --- Comment #7 from Stam Markianos-Wright --- (In reply to rsand...@gcc.gnu.org from comment #6) > (In reply to Stam Markianos-Wright from comment #5) > > I'm tempted to try and add a reverse: > > > > || multiple_p (*stmt_vectype_out, nunits_vectype) > > > > And then regtest, but I probably need to do more reading around to figure > > out > > what we really should be expecting each case! > I don't think that's right. If nunits_vectype is not a multiple > of stmt_vectype then the stmt_vectype contains (or might contain) > unused elements. The vectoriser isn't set up to work like that: > all operations are currently supposed to be full-vector operations > (possibly predicated, on SVE and AVX). > > AFAICT the assert is correct and it's showing up a problem elsewhere. Cool, thank you for the info and the confirmation! I will carry on investigating to try and find the actual problem
[Bug testsuite/97299] [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:104304cd246e9e8cd874f6cef7e2a5cd4bb0114d commit r11-6767-g104304cd246e9e8cd874f6cef7e2a5cd4bb0114d Author: Richard Biener Date: Mon Jan 18 14:51:00 2021 +0100 testsuite/97299 - fix test condition of gcc.dg/vect/slp-reduc-3.c This avoids looking for permute optimization when SLP cannot be applied. 2021-01-18 Richard Biener PR testsuite/97299 * gcc.dg/vect/slp-reduc-3.c: Guard VEC_PERM_EXPR scan.
[Bug testsuite/97299] [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97494
--- Comment #4 from Richard Biener ---
OK, so for gcc.dg/vect/slp-11b.c we're now doing hybrid vectorization if a { 0
2 1 } load permute is supported. The reason this is needed is that
out[i*4] = (in[i*4] + 2) * 3;
out[i*4 + 1] = (in[i*4 + 2] + 2) * 7;
out[i*4 + 2] = (in[i*4 + 1] + 7) * 3;
out[i*4 + 3] = (in[i*4 + 3] + 3) * 4;
is "inconsistently" folded like
out[i*4] = (in[i*4] * 3 + 6);
out[i*4 + 1] = (in[i*4 + 2] * 7 + 14);
out[i*4 + 2] = (in[i*4 + 1] * 3 + 21);
out[i*4 + 3] = (in[i*4 + 3] + 3) * 4;
so for (x + 3) * 4 we're _not_ associating. That breaks SLP discovery
but with splitting we're now using SLP for the first three lane and
interleaving for the last.
[Bug middle-end/98713] Failure to generate branch version of abs if user requested it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713 --- Comment #8 from Jakub Jelinek --- This is specific to x86, where if the inputs are inpredictable and results aren't consumed too early that the cmov latency kills performance cmov sometimes improves performance a lot, on the other side, if the inputs are predictable, branches are often much faster than cmov. I'm not aware of other architectures where the conditional moves are such a mixed bag, e.g. on arm/aarch64 I think using cmov is generally always better.
[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97494
--- Comment #5 from Richard Biener ---
I guess this folding detail wasn't what the original testcase was supposed to
test. Doing
out[i*4] = (in[i*4] + 2) * 3;
out[i*4 + 1] = (in[i*4 + 2] + 2) * 7;
out[i*4 + 2] = (in[i*4 + 1] + 7) * 3;
out[i*4 + 3] = (in[i*4 + 3] + 3) * 7;
will fix that but then we still need some good target selector given likely
not all targets can do this permute but we do not have "good" target-supports
for specific permutes. Maybe
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { {
vect_strided4 || vect_perm} && vect_int_mult } } } } */
/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" {
target { vect_perm && vect_int_mult } } } } */
will do though. I will try that.
[it would be nice to have separate PRs for different test fails]
[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97494 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e393f03b1a73d75901d1bc49c99123bdf534e120 commit r11-6770-ge393f03b1a73d75901d1bc49c99123bdf534e120 Author: Richard Biener Date: Mon Jan 18 15:18:15 2021 +0100 testsuite/97494 - adjust gcc.dg/vect/slp-11b.c Support for loop SLP splitting exposed that slp-11b.c has folding that breaks SLP discovery which isn't what was intended when the testcase was written. The following makes it SLP-able and "only" run into the issue that a load permutation is required. And tries to adjust the target selectors accordingly. 2021-01-18 Richard Biener PR testsuite/97494 * gcc.dg/vect/slp-11b.c: Adjust.
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ec153f96f8943f1d2418d2248ed219358990bb5f commit r11-6771-gec153f96f8943f1d2418d2248ed219358990bb5f Author: Jonathan Wakely Date: Mon Jan 18 14:23:13 2021 + libstdc++: Only test writing to wostream if supported [PR 98725] libstdc++-v3/ChangeLog: PR libstdc++/98725 * testsuite/20_util/unique_ptr/io/lwg2948.cc: Do not try to write to a wide character stream if wide character support is disabled in the library.
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-01-18 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |12.0 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug c/98729] New: GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
Bug ID: 98729
Summary: GCC 11 MinGW Windows build doesn't generate working PE
executables
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: brechtsanders at users dot sourceforge.net
Target Milestone: ---
Created attachment 49994
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49994&action=edit
Invalid Windows .exe PE file
When I try to build GCC 11 for MinGW (using MinGW-w64 8.0.0) configure fails
(on both 32-bit and 64-bit) when it's trying to test if it can run a compiled
.exe file.
When I replicate this command with:
`echo "int main () { return 0; }" |
/R/winlibs64_stage/gcc-11-20210117/build_mingw/./gcc/xgcc
-B/R/winlibs64_stage/gcc-11-20210117/build_mingw/./gcc/
-L/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/lib
-L/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/mingw/lib -isystem
/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/include
-isystem /R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/mingw/include
-B/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/bin/
-B/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/lib/
-isystem
/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/include
-isystem
/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/sys-include
--sysroot=/R/winlibs64_stage/gcc-11-20210117/build_mingw/mingw-w64 -o
conftest.exe -g -O2 -xc -`
it builds `conftest.exe`, but running it (fro MSYS2 bash shell) with
`conftest.exe` fails with error `bash: ./conftest.exe: cannot execute binary
file: Exec format error`, or when I run it from Windows or Command prompt it
pops up a message saying `This app can't run on your PC`.
The command `file conftest.exe` does return `conftest.exe: PE32+ executable
(console) x86-64, for MS Windows`.
I have attached this file.
[Bug libstdc++/98723] On Windows with CP936 encoding, regex compiles very slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723 --- Comment #2 from goughost --- That may be acceptable for issue 2. But additional fixes are need; otherwise, users cannot use regex after calling setlocale(LC_ALL,"") in such a situation. Can regex compilers work without calling _M_transform? (at least when std::regex::collate is not set) On the other hand, maybe the error condition can be handled by regex compiler code. To some extent, the bug is in the regex compiler. Building cache for '\xee' calls strxfrm() with "\xee\x00", which is not a valid string if current encoding is utf8. Also, in GNU/Linux, resulting strings of such (successful) calls might not help building the cache. Examples calling strxfrom in GNU/Linux with various locales. (Note that, in cases when Windows fails, Linux gives trivial results.) // C input 61 00, errno 0, res 1, outbuf: 61 input 62 00, errno 0, res 1, outbuf: 62 input aa 00, errno 0, res 1, outbuf: aa input bb 00, errno 0, res 1, outbuf: bb // C.UTF-8 input 61 00, errno 0, res 1, outbuf: 63 input 62 00, errno 0, res 1, outbuf: 64 input aa 00, errno 0, res 1, outbuf: 03 input bb 00, errno 0, res 1, outbuf: 03 // en_US.UTF-8 input 61 00, errno 0, res 10, outbuf: 51 01 02 01 02 01 00 00 00 00 input 62 00, errno 0, res 10, outbuf: 5e 01 02 01 02 01 00 00 00 00 input aa 00, errno 0, res 5, outbuf: 01 01 01 01 03 input bb 00, errno 0, res 5, outbuf: 01 01 01 01 03 // zh_CN.GB2312 input 61 00, errno 0, res 11, outbuf: e1 a9 bd 01 02 01 02 01 00 00 61 input 62 00, errno 0, res 11, outbuf: e1 a9 be 01 02 01 02 01 00 00 62 input aa 00, errno 0, res 5, outbuf: 01 01 01 01 03 input bb 00, errno 0, res 5, outbuf: 01 01 01 01 03
[Bug target/98730] New: vceqzq_p64 does not generate vceq with immediate 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98730
Bug ID: 98730
Summary: vceqzq_p64 does not generate vceq with immediate 0
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
vceqzq_p64 intrinsic was introduced with commit r11-6719
(g:63999d751df9bcde4ab9107edb4c635d274b248d)
defined as:
vceqzq_p64 (poly64x2_t __a)
{
poly64x2_t __b = vreinterpretq_p64_u32 (vdupq_n_u32 (0));
return vceqq_p64 (__a, __b);
}
which is similar to what vceqz_p64 does:
vceqz_p64 (poly64x1_t __a)
{
poly64x1_t __b = vreinterpret_p64_u32 (vdup_n_u32 (0));
return vceq_p64 (__a, __b);
}
vceqzq_p64 uses vceqq_p64 which is defined as:
vceqq_p64 (poly64x2_t __a, poly64x2_t __b)
{
poly64_t __high_a = vget_high_p64 (__a);
poly64_t __high_b = vget_high_p64 (__b);
uint64x1_t __high = vceq_p64 (__high_a, __high_b);
poly64_t __low_a = vget_low_p64 (__a);
poly64_t __low_b = vget_low_p64 (__b);
uint64x1_t __low = vceq_p64 (__low_a, __low_b);
return vcombine_u64 (__low, __high);
}
Unlike vceqz_p64, vceqzq_p64 does not use the vceq alternative with an
immediate, as is shown by the vceqzq_p64.c testcase, which generates:
ldr r3, .L3
vmov.i32q10, #0 @ v4si
vld1.64 {d16-d17}, [r3:64]
vceq.i32d18, d17, d21
vceq.i32d16, d16, d21
vpmin.u32 d18, d18, d18
vpmin.u32 d16, d16, d16
vmov.f64d17, d18@ int
vstrd16, [r3, #16]
vstrd17, [r3, #24]
bx lr
By comparison, vceqz_p64 generates:
ldr r3, .L3
vldr.64 d16, [r3] @ int
vceq.i32d16, d16, #0
vpmin.u32 d16, d16, d16
vstr.64 d16, [r3, #8] @ int
bx lr
The reload trace for vceqzq_p64 say:
Choosing alt 0 in insn 19: (0) =w (1) w (2) w {neon_vceqv2si_insn}
alt=0,overall=0,losers=0,rld_nregs=0
Choosing alt 0 in insn 15: (0) =w (1) w (2) w {neon_vceqv2si_insn}
alt=0,overall=0,losers=0,rld_nregs=0
(insn 19 8 15 2 (set (reg:V2SI 48 d16 [orig:128 _18 ] [128])
(neg:V2SI (eq:V2SI (reg:V2SI 48 d16 [orig:139 v1 ] [139])
(reg:V2SI 54 d19 [ _5+8 ]
"/home/christophe.lyon/src/GCC/builds/gcc-fsf-git-neon-intrinsics/tools/lib/gcc/arm-none-linux-gnueabihf/11.0.0/include/arm_neon.h":2404:22
1650 {neon_vceqv2si_insn}
(expr_list:REG_EQUAL (neg:V2SI (eq:V2SI (subreg:V2SI (reg:DI 48 d16
[orig:139 v1 ] [139]) 0)
(const_vector:V2SI [
(const_int 0 [0]) repeated x2
])))
(nil)))
(insn 15 19 20 2 (set (reg:V2SI 50 d17 [orig:121 _11 ] [121])
(neg:V2SI (eq:V2SI (reg:V2SI 50 d17 [orig:141 v2 ] [141])
(reg:V2SI 54 d19 [ _5+8 ]
"/home/christophe.lyon/src/GCC/builds/gcc-fsf-git-neon-intrinsics/tools/lib/gcc/arm-none-linux-gnueabihf/11.0.0/include/arm_neon.h":2404:22
1650 {neon_vceqv2si_insn}
(expr_list:REG_EQUAL (neg:V2SI (eq:V2SI (subreg:V2SI (reg:DI 50 d17
[orig:141 v2 ] [141]) 0)
(const_vector:V2SI [
(const_int 0 [0]) repeated x2
])))
(nil)))
[Bug c/98729] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #1 from Brecht Sanders --- I have discovered that adding `-s` to the above build command or stripping the .exe file with `strip` does allow it to run. So probably something is messed up in the debugging symbols section.
[Bug debug/98728] [11 regression] Several debug tests FAIL with DWARF-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 Mark Wielaard changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- Hi, Maybe this bug should be split in two (or three) for each specific FAIL? (In reply to Rainer Orth from comment #0) > With the switch to DWARF-5, two debug tests have started to FAIL: > > +FAIL: g++.dg/debug/dwarf2/constexpr-var-1.C scan-assembler-times > DW_AT_const_expr 2 > > 32 and 64-bit Solaris/SPARC and x86, Linux/x86_64 This is https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552474.html There is a suggested fix, but no consensus on whether that is a good one: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553102.html > +FAIL: gcc.dg/debug/dwarf2/dwarf-float.c scan-assembler 0x10.*DW_AT_byte_size > > 32-bit Solaris/x86 and Linux/x86_64 So this fails in 32bit mode, but not in 64bit mode. In 64bit mode gcc generates: .uleb128 0x2# (DIE (0x7d) DW_TAG_base_type) .byte 0x10# DW_AT_byte_size # DW_AT_encoding (0x4) .long .LASF4 # DW_AT_name: "long double" But in 32bit mode it generates: .uleb128 0x2# (DIE (0x6d) DW_TAG_base_type) .byte 0xc # DW_AT_byte_size # DW_AT_encoding (0x4) .long .LASF4 # DW_AT_name: "long double" > Besides, there were many changes to guality tests on Linux/x86_64, both tests > previously XPASSing now XFAIL again, as well as several new FAILs. The guality tests are a little fragile, they also depend on the gdb version installed.
[Bug target/98730] vceqzq_p64 does not generate vceq with immediate 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98730 --- Comment #1 from Christophe Lyon --- Why does it choose alternative 0 instead of 1 which matches a vector of constant zeros?
[Bug target/98731] New: s390x: Large classes of std::bitset and std::vector hash the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98731
Bug ID: 98731
Summary: s390x: Large classes of std::bitset and
std::vector hash the same
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
[forwarded from https://bugs.debian.org/977638]
same behavior with GCC 8, 9 and 10.
On s390x, std::hash returns identical values for large classes of
std::bitset and std::vector:
$ cat bug.cc
#include
#include
#include
#include
int main() {
std::bitset<2> a("00"), b("01");
std::vector c = {false, true, false, true};
std::vector d = {true, false, true, false};
std::bitset<9> e("0"), f("010101010");
std::vector g = {true, true, true, true, true, true, true, true,
true};
std::vector h = {false, false, false, true, true,
false, false, false, false};
std::hash> h1;
std::hash> h2;
std::hash> h3;
std::cout << h1(a) << '\n'
<< h1(b) << '\n'
<< h3(c) << '\n'
<< h3(d) << "\n\n"
<< h2(e) << '\n'
<< h2(f) << '\n'
<< h3(g) << '\n'
<< h3(h) << '\n';
}
$ g++ -o bug bug.cc
$ ./bug
7857072875483051545
7857072875483051545
7857072875483051545
7857072875483051545
4158372090644325695
4158372090644325695
4158372090644325695
4158372090644325695
It appears that the hash value is completely dependent on the size of
the object in bytes. 1–8-bit values all hash to 7857072875483051545;
9–16-bit values all hash to 4158372090644325695; and though bug.cc
doesn’t demonstrate it, 17-bit values hash to 14756137038141193723.
[Bug libbacktrace/98732] New: libbacktrace could not find executable to open
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98732 Bug ID: 98732 Summary: libbacktrace could not find executable to open Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: jettzheng at foxmail dot com CC: ian at gcc dot gnu.org Target Milestone: --- Created attachment 49995 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49995&action=edit zip with all files needed gcc version: GNU C++20 (GCC) version 11.0.0 20210118 (experimental) (x86_64-w64-mingw32) compiled by GNU C version 10.2.1 20201125, GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22-GMP system type: Windows 10 Insider Preview Dev Channel Build 21286.1000 64-bit x86_64 gcc options: COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=c:/gcc/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/11/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../configure --target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --disable-bootstrap --enable-libstdcxx-debug --with-tune=znver1 --prefix=/mnt/c/GCC --with-sysroot=/mnt/c/GCC-Build/NewestLinux --with-build-sysroot=/mnt/c/GCC-Build/NewestLinux --disable-libstdcxx-pch --disable-multilib --enable-libgomp --with-cross-host --with-libiconv-prefix=/mnt/c/GCC-Build/NewestLinux/Libraries --disable-libstdcxx-verbose --enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-nls --disable-win32-registry --enable-shared --with-gnu-as --with-gnu-ld --enable-threads=posix --program-suffix=-11 --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-__cxa_atexit --enable-plugin --program-prefix= : (reconfigured) ../configure --target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --disable-bootstrap --enable-libstdcxx-debug --with-tune=znver1 --prefix=/mnt/c/GCC --with-sysroot=/mnt/c/GCC-Build/NewestLinux --with-build-sysroot=/mnt/c/GCC-Build/NewestLinux --disable-libstdcxx-pch --disable-multilib --enable-libgomp --with-cross-host --with-libiconv-prefix=/mnt/c/GCC-Build/NewestLinux/Libraries --disable-libstdcxx-verbose --enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-nls --disable-win32-registry --enable-shared --with-gnu-as --with-gnu-ld --enable-threads=posix --program-suffix=-11 --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-__cxa_atexit --enable-plugin --program-prefix= Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20210118 (experimental) (GCC) COLLECT_GCC_OPTIONS='-std=gnu++20' '-fmodules-ts' '-o' 'demo.exe' '-v' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-fsanitize=undefined' '-save-temps' '-shared-libgcc' '-mtune=znver1' '-march=x86-64' '-dumpdir' 'demo-' command line: g++ prime.cpp demo.cpp -std=gnu++20 -fmodules-ts -o demo.exe -v -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -fsanitize=undefined -save-temps output: prime.cpp:4:9: internal compiler error: in tree_node, at cp/module.cc:9134 4 | export module prime; | ^~ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. and In module imported at demo.cpp:1:1: prime: error: failed to read compiled module: No such file or directory prime: note: compiled module file is 'gcm.cache/prime.gcm' prime: note: imports must be built before being imported prime: fatal error: returning to the gate for a mechanical issue preprocessed files are with the attatchment anyways, my libbacktrace won't work
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #7 from acsawdey at gcc dot gnu.org --- The inline expansion should be disabled by -Os, the patterns for cmpstr[n]si both have this: if (optimize_insn_for_size_p ()) FAIL;
[Bug c++/95608] c++20 wrong code for defaulted equality comparison on array member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95608 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- This seems to be a dup of PR93480, which is now fixed on trunk. *** This bug has been marked as a duplicate of bug 93480 ***
[Bug c++/93480] Defaulted <=> doesn't expand array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93480 Patrick Palka changed: What|Removed |Added CC||vermaelen.wouter at gmail dot com --- Comment #7 from Patrick Palka --- *** Bug 95608 has been marked as a duplicate of this bug. ***
[Bug c++/88604] Initializing constexpr array consumes all memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88604 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Patrick Palka --- Indeed a dup. *** This bug has been marked as a duplicate of bug 96197 ***
[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197 Patrick Palka changed: What|Removed |Added CC||gcc-bugs at oxyware dot com --- Comment #12 from Patrick Palka --- *** Bug 88604 has been marked as a duplicate of this bug. ***
[Bug testsuite/97987] FAIL: gcc.c-torture/compile/asmgoto-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97987 --- Comment #2 from CVS Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:76c1dd15e4a056a59a13b2208af23a6bd67c2682 commit r11-6774-g76c1dd15e4a056a59a13b2208af23a6bd67c2682 Author: John David Anglin Date: Mon Jan 18 15:45:47 2021 + Skip asm goto tests on hppa*-*-*. gcc/testsuite/ChangeLog: PR testsuite/97987 * gcc.c-torture/compile/asmgoto-2.c: Skip on hppa. * gcc.c-torture/compile/asmgoto-5.c: Likewise.
[Bug testsuite/97987] FAIL: gcc.c-torture/compile/asmgoto-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97987 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from John David Anglin --- Fixed on master.
[Bug c++/95262] Taking address of function pointer doesn't do full concept overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95262 Patrick Palka changed: What|Removed |Added Target Milestone|--- |10.3 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Patrick Palka --- Fixed for GCC 10.3 and 11 by r11-2634 / r10-8627.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 68372, which changed state. Bug 68372 Summary: [concepts] invalid use of pack expansion expression in member function template declaration https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68372 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/68372] [concepts] invalid use of pack expansion expression in member function template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68372 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Target Milestone|--- |10.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Patrick Palka --- Fixed then.
[Bug other/98733] New: libiberty (v)asprintf checks do not work if asprintf() is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98733
Bug ID: 98733
Summary: libiberty (v)asprintf checks do not work if asprintf()
is a macro
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: tbaeder at redhat dot com
Target Milestone: ---
The include/libiberty.h file has a check before declaring asprintf:
#if defined(HAVE_DECL_ASPRINTF) && !HAVE_DECL_ASPRINTF
extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2;
#endif
via a ac_fn_c_check_decl call in libiberty's configure script,
HAVE_DECL_ASPRINTF is defined when the following code sample compiles without
errors:
#include
/* ... tons of includes and constant definitions ... */
int
main()
{
(void) asprintf;
return 0;
}
This compiles if asprintf is defined as a function but fails if it is a macro,
which can be tested in this godbolt.org test: https://godbolt.org/z/T5n17c
This is the case for asprintf when stdio.h includes bits/stdio2.h and the
compiler does not support va_arg_pack().
The former happens via stdio.h when the _FORTIFY_SOURCE level is > 0 and
__fortify_function is defined:
https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/stdio.h;h=144137cf67aadac3e86844e37f0fe47c45072fd3;hb=HEAD#l866
and the latter causes the definition of asprintf() as a
macro:https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/bits/stdio2.h;h=3f0cab1254b02c4348dcd961e38b9805c7cbe834;hb=HEAD#l206
Given this combination, HAVE_DECL_ASPRINTF is 0, which means libiberty will in
the end declare its own asprintf, via include/libiberty.h:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=include/libiberty.h;h=f4c0fe11d6fe3fe0e1cc44c7c6f6266c97c263e4;hb=HEAD#l655
... which will then fail:
../../libiberty/../include/libiberty.h:627:12: error: expected parameter
declarator
extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2;
^
/usr/include/bits/stdio2.h:207:24: note: expanded from macro 'asprintf'
__asprintf_chk (ptr, __USE_FORTIFY_LEVEL - 1, __VA_ARGS__)
Clang does not support va_arg_pack(), so this failure occurs when using clang.
[Bug c++/96821] [concepts] Incorrect evaluation of concept with ill-formed expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96821
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Patrick Palka ---
GCC's behaviour is correct, I think. Since the concept constant_expression
doesn't use its template parameter, the normal form of foo's associated
constraint is just 'true (with an empty parameter mapping)', so the
satisfaction value of with_value_constant for any T is trivially true and
independent of T.
Another workaround to have the with_value_constant concept work as you expect
is to make the constant_expression concept depend on its template parameter in
a trivial way, e.g. define it as:
template
concept constant_expression = requires { V; };
[Bug target/98729] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #2 from Andrew Pinski --- this sounds more like it is a bug in binutils rather than GCC.
[Bug c++/96410] A lambda with a template parameter list inside the template function using C++20 requires clauses is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96410 Patrick Palka changed: What|Removed |Added Target Milestone|10.3|11.0
[Bug c++/97402] Value of dependent partial-concept-id is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97402 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #4 from Patrick Palka --- This is essentially a dup of PR96444, I think. *** This bug has been marked as a duplicate of bug 96444 ***
[Bug c++/96444] Incorrect satisfaction value of placeholder type constraint on variable with non-dependent initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96444 Patrick Palka changed: What|Removed |Added CC||ed at catmur dot uk --- Comment #1 from Patrick Palka --- *** Bug 97402 has been marked as a duplicate of this bug. ***
[Bug c++/98687] [11 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in diagnose_name_conflict, at cp/name-lookup.c:2729 since r11-6652-g796ead19f85372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98687 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #4 from Jonathan Wakely --- This affects building Boost too.
[Bug c++/98687] [11 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in diagnose_name_conflict, at cp/name-lookup.c:2729 since r11-6652-g796ead19f85372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98687 --- Comment #5 from Jonathan Wakely --- And the patch at https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563562.html fixes the Boost build.
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #5 from Ian Lance Taylor --- I'm not seeing any failures in the Go testsuite with GNU binutils 2.35.1. Anybody know what changed in newer version of the binutils?
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 --- Comment #6 from Ian Lance Taylor --- On the other hand the libbacktrace testsuite now fails when using dwz 0.13+20201015-2. But I guess that is not a GCC problem. dwz -m b3test_dwz_common.debug b3test_dwz_1 b3test_dwz_2 dwz: b3test_dwz_1: Unknown DWARF DW_FORM_implicit_const dwz: b3test_dwz_1: Couldn't read abbrev at offset 0x0 dwz: b3test_dwz_2: Unknown DWARF DW_FORM_implicit_const dwz: b3test_dwz_2: Couldn't read abbrev at offset 0x0 dwz: Too few files for multifile optimization make[3]: *** [Makefile:2436: b3test_dwz] Error 1
