[Bug c++/90947] [9 Regression] Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947
Dimitar Yordanov changed:
What|Removed |Added
CC||dimitar.yordanov at sap dot com
--- Comment #12 from Dimitar Yordanov ---
Hi,
after the fix we hit a regression with:
$ cat > main.cpp << EOF
#include
static std::atomic a[1] { {1} };
int main(void)
{
if (!a[0].load())
__builtin_abort ();
return 0;
}
EOF
$ g++ main.cpp && ./a.out
Best wishes
Dimitar
[Bug c++/92221] New: [Regression] template argument deduction/substitution failed after "Implement P0846R0, ADL and function templates"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92221
Bug ID: 92221
Summary: [Regression] template argument deduction/substitution
failed after "Implement P0846R0, ADL and function
templates"
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitar.yordanov at sap dot com
Target Milestone: ---
Hi,
we see a regression for the following example:
$cat > foo.cpp << EOF
template class a {
using b = int;
using c = int;
b d;
void e() { g(d); }
template static void g(f...);
};
EOF
$g++ -c foo.cpp
foo.cpp: In member function ‘void a< >::e()’:
foo.cpp:5:20: error: no matching function for call to ‘a<
>::g >::c>(a<
>::b&)’
5 | void e() { g(d); }
|^
foo.cpp:6:40: note: candidate: ‘template template static
void a< >::g(f ...)’
6 | template static void g(f...);
|^
foo.cpp:6:40: note: template argument deduction/substitution failed:
foo.cpp:5:20: note: mismatched types ‘f’ and ‘int’
5 | void e() { g(d); }
|^
First appears after:
2018-11-01 Marek Polacek
Implement P0846R0, ADL and function templates.
* decl.c (grokfndecl): Allow FUNCTION_DECL in assert.
...
Best wishes
Dimitar
[Bug lto/91935] Unneeded .debug_info entries in .symtab when using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91935 --- Comment #2 from Dimitar Yordanov --- Probably already clear, but to write down what I read so far and did not write with the initial report: PR lto/83452. is actually not the regression, it is just a workaround to "Make discarded global symbols hidden weak" and PR lto/91478 is a different implementation of the same workaround that instead aliases discarded global symbols to a debug_info entry, which should always be present. But in the end the dead symbols are there.
[Bug lto/91935] Unneeded .debug_info entries in .symtab when using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91935 --- Comment #3 from Dimitar Yordanov --- ld.bfd --gc-sections drops the dead symbols, at least in the example code. ld.gold --gc-sections works differently. I guess it does not even look at sections without SHF_ALLOC
[Bug lto/83452] FAIL: gfortran.dg/save_6.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83452 dimitar.yordanov at sap dot com changed: What|Removed |Added CC||dimitar.yordanov at sap dot com --- Comment #15 from dimitar.yordanov at sap dot com --- Hi, after this fix I see.debug_info entries in the .symtab, which seem unneeded to me(on Linux x86_64). If they are unnecessary should they be removed by the linker or the plugin? Is the fix in this patch only needed for HPUX, because of misbehaving linker? cat > foo.c << EOF const char *a = "a"; EOF g++ -flto -gdwarf-4 -g1 -o foo.c.o -c foo.c g++ -flto -shared -o libfoo.so foo.c.o objdump -t libfoo.so | grep debug_info Best wishes, D.
[Bug lto/83452] FAIL: gfortran.dg/save_6.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83452 --- Comment #17 from Dimitar Yordanov --- I still see the issue with the latest master branch from today[1]. 1- https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=ed76597323f2005730596f3a85583691621aa616
[Bug c++/91935] New: Unneeded .debug_info entries in .symtab when using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91935 Bug ID: 91935 Summary: Unneeded .debug_info entries in .symtab when using LTO Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dimitar.yordanov at sap dot com Target Milestone: --- Hi, I see following behavior manifesting itself first after the fix for PR lto/83452. cat > foo.c << EOF const char *a = "a"; EOF g++ -flto -gdwarf-4 -g1 -o foo.c.o -c foo.c g++ -flto -shared -o libfoo.so foo.c.o objdump -t libfoo.so | grep debug_info Best wishes Dimitar
[Bug c++/90998] New: [Regression] ICE (segfalut) in gcc/cp/call.c compare_ics() with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90998
Bug ID: 90998
Summary: [Regression] ICE (segfalut) in gcc/cp/call.c
compare_ics() with -std=c++17
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitar.yordanov at sap dot com
Target Milestone: ---
Regression appeared first with:
PR c++/86521 - C++17 copy elision in initialization by constructor.
Reproducer:
cat << EOF > a.cpp
unsigned char a[1];
struct b {};
struct c : b {
c(b);
c(b &&);
};
struct B {
operator c();
static B d(unsigned char *, short, short, bool);
};
struct e {
unsigned short f(bool) const;
};
#pragma GCC diagnostic error "-Wconversion"
short g, h;
unsigned short e::f(bool i) const {
c(B::d(a, g, h, i));
return 0;
}
EOF
$ g++ -std=c++17 a.cpp
a.cpp: In member function ‘short unsigned int e::f(bool) const’:
a.cpp:17:21: internal compiler error: Segmentation fault
17 | c(B::d(a, g, h, i));
| ^
0xde01df crash_signal
../.././gcc/toplev.c:326
0x13049c2 compare_ics
../.././gcc/cp/call.c:10083
0x1307168 joust
../.././gcc/cp/call.c:10696
0x1307beb tourney
../.././gcc/cp/call.c:11085
0x130c18e build_new_method_call_1
../.././gcc/cp/call.c:9764
0x130c18e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../.././gcc/cp/call.c:9932
0x1312853 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../.././gcc/cp/call.c:9356
0x1326db3 perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
../.././gcc/cp/call.c:11273
0x1326db3 perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
../.././gcc/cp/call.c:11252
0x11f8fa9 build_static_cast_1
../.././gcc/cp/typeck.c:7185
0x11fb217 cp_build_c_cast(tree_node*, tree_node*, int)
../.././gcc/cp/typeck.c:7981
0x11fb217 cp_build_c_cast(tree_node*, tree_node*, int)
../.././gcc/cp/typeck.c:7898
0x11fb7da build_functional_cast(tree_node*, tree_node*, int)
../.././gcc/cp/typeck2.c:2263
0x11fb7da build_functional_cast(tree_node*, tree_node*, int)
../.././gcc/cp/typeck2.c:2151
0x126c346 cp_parser_functional_cast
../.././gcc/cp/parser.c:28332
0x1265725 cp_parser_postfix_expression
../.././gcc/cp/parser.c:7098
0x12668e8 cp_parser_unary_expression
../.././gcc/cp/parser.c:8469
0x126764f cp_parser_cast_expression
../.././gcc/cp/parser.c:9355
0x1267d12 cp_parser_binary_expression
../.././gcc/cp/parser.c:9457
0x12684d7 cp_parser_assignment_expression
../.././gcc/cp/parser.c:9754
[Bug middle-end/104880] New: regression ICE in expand_expr_addr_expr_1, at expr.c:8231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104880
Bug ID: 104880
Summary: regression ICE in expand_expr_addr_expr_1, at
expr.c:8231
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitar.yordanov at sap dot com
Target Milestone: ---
Hi,
I hit an ICE with the following reduced example:
cat > foo.cc << EOF
class c {
long b;
};
class B {
public:
typedef void *d;
};
class aa {
public:
aa(B::d, char *);
};
class e : public B {
public:
e();
};
__uint128_t f;
struct g {
struct h : c {
h(__uint128_t &i) : c(reinterpret_cast(i)) {}
__uint128_t ad();
};
};
class n : g {
public:
n(int);
void j() {
__uint128_t a;
h k(a);
__atomic_compare_exchange_n(&f, &a, k.ad(), true, 3, 0);
}
};
int l;
class m : e {
void ar() {
n b(l);
b.j();
}
virtual c bd() { aa(d(&m::ar), ""); }
};
void o() { new m; }
EOF
g++ -mcx16 -O2 -c foo.cc
during RTL pass: expand
foo.cc: In member function ‘void m::ar()’:
foo.cc:29:32: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:8231
29 | __atomic_compare_exchange_n(&f, &a, k.ad(), true, 3, 0);
Regression appeared first with:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=eb72dc663e9070b281be83a80f6f838a3a878822
Best regards
Dimitar
[Bug middle-end/104880] [11 Regression] ICE in expand_expr_addr_expr_1, at expr.c:8231 since r11-165-geb72dc663e9070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104880 --- Comment #4 from Dimitar Yordanov --- Thanks, works for me!
[Bug c++/105035] New: regression ICE segmentation fault with -Wduplicated-cond
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035
Bug ID: 105035
Summary: regression ICE segmentation fault with
-Wduplicated-cond
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitar.yordanov at sap dot com
Target Milestone: ---
Hi,
we hit an ICE with the following reduced example:
cat > foo.cc << EOF
class a {
struct b {
int c;
int f;
};
template void d();
b e;
};
template void a::d() {
int g;
if (&g == &e.c)
;
else if (&g == &e.f)
;
}
EOF
g++ -Wduplicated-cond -c foo.cc
Best wishes
Dimitar
[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Dimitar Yordanov changed:
What|Removed |Added
CC||dimitar.yordanov at sap dot com
--- Comment #3 from Dimitar Yordanov ---
Hi,
what I can further add as a detail to the code below is that in the error case
"begin" is after "range[0]" as calculated by get_pc_range
-
void
__register_frame_info_bases (const void *begin, struct object *ob,
void *tbase, void *dbase)
{
.
// Register the object itself to know the base pointer on deregistration.
btree_insert (®istered_frames, (uintptr_type) begin, 1, ob);
// Register the frame in the b-tree
uintptr_type range[2];
get_pc_range (ob, range);
btree_insert (®istered_frames, range[0], range[1] - range[0], ob);
-
and pc_begin comes from the following with "((encoding & 0x70) ==
DW_EH_PE_pcrel" being true
-
static const unsigned char *
read_encoded_value_with_base (unsigned char encoding, _Unwind_Ptr base,
const unsigned char *p, _Unwind_Ptr *val)
{
case DW_EH_PE_sdata8:
result = u->s8;
p += 8;
result += ((encoding & 0x70) == DW_EH_PE_pcrel
? (_Unwind_Internal_Ptr) u : base);
-
E.g. u->s8 has a value of 0xe6f8 u 0x7fa7fc22f908 and with that
result 0x7fa7fc22e000 which is lower as the begin 0x7fa7fc22f160
[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 --- Comment #5 from Dimitar Yordanov --- > It looks like the code does not find an unwind frame when de-registering an > exception handler >From what I understand so far the issue is already there when doing the registration. There is twice a call to btree_insert: btree_insert (®istered_frames, (uintptr_type) begin, 1, ob); btree_insert (®istered_frames, range[0], range[1] - range[0], ob); for those, calls when "range[0]" is before "begin" with the same "ob" the next search for removing will return the slot where range[0] is not the one of begin. Because of the way "btree_node_find_leaf_slot" works, doing a if (n->content.entries[index].base + n->content.entries[index].size > value) which is true for the second insert call even if we want to find the slot for the first insert.
[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 --- Comment #6 from Dimitar Yordanov --- Before the fix for PR 110956 there was just one btree_insert call for the same "ob"
[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 --- Comment #8 from Dimitar Yordanov --- yes
[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 --- Comment #10 from Dimitar Yordanov --- Valid question. Seeing others hitting the same issue and looking at the backtrace I would think it is not directly in our code but comes with the usage LLVMs LLJIT
[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 --- Comment #12 from Dimitar Yordanov --- > Does this patch fix the problem for you? yes. The failing testcase is successful after the change. I'll schedule more tests.
[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 --- Comment #17 from Dimitar Yordanov --- I've executed more tests and see another one failing. This time "begin" is inside of another range, not the one that gets calculated with this "begin". So there is again an overlapping in the btree. Could we maybe use two trees, one for "begin" and one for the ranges?
[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 --- Comment #19 from Dimitar Yordanov --- I've rerun related tests and they look OK with the latest patch.
