[Bug debug/78100] DWARF symbols for an array sometimes missing the array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78100 --- Comment #10 from Kevin Puetz --- The godbolt recipe also nails down the other end of the version range - 5.4 produced something weirder still (a single DW_TAG_variable with DW_AT_external=true, but also with DW_AT_location and DW_AT_upper_bound present - so it kind of mushed the two decls together with all the attributes of both). 6.1 starts emitting two separate DW_TAG_variable DIEs, one with DW_AT_external=true and the other with DW_AT_location, using DW_AT_specification to link them; but it lost the DW_AT_upper_bound. Then 10.1...trunk all seem fixed, emitting an incomplete `extern` and a complete definition, as it should. So "Known to fail" should be 6.1-9.5, "Known to Work" should be 10.0+ (and bug 91507 can also be marked "RESOLVED FIXED" since 10.1 is long since released). I'd update the metadata myself but don't the permission bits...
[Bug debug/78100] DWARF symbols for an array sometimes missing the array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78100 --- Comment #8 from Kevin Puetz --- Found it: this is a duplicate of bug 91507, thus fixed by r276403/31632e2c4327146ea8d21cff33adaa505b17d2bd
[Bug debug/78100] DWARF symbols for an array sometimes missing the array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78100 --- Comment #7 from Kevin Puetz --- Nope, falsified that guess - I just realized compiler explorer can do dwarfdump, which makes it easy to bisect among the releases they have (if not actually commit-by-commit). This shows that 9.5.0 (which has r263660) still produces bad DWARF, and 10.1 is fixed. So it can't be that commit... https://godbolt.org/z/jj4safe6e
[Bug debug/78100] DWARF symbols for an array sometimes missing the array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78100 Kevin Puetz changed: What|Removed |Added CC||puetzk at puetzk dot org --- Comment #6 from Kevin Puetz --- Possibly r263660/ea379c9ec3776b9d4f72d5d8c8987e2e43c7baae? add_bound_info (subrange_die, DW_AT_upper_bound) eventually calls the add_scalar_info() that was changed in that patch. And it at least seems plausible that the changes around decl_die = lookup_decl_die(decl)` could be relevant. https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/dwarf2out.c;h=b80c909e1fc6b05c35faa30a72e262a08cc7d65e;hp=236f199afcf050957639f1cce839f870a0d472c6;hb=ea379c9ec3776b9d4f72d5d8c8987e2e43c7baae;hpb=3fb558b154f795983ae6a9dd6478e18a2c846584 The new code requires that decl_die have DW_AT_location or DW_AT_const_value in order to take the early return, and the first decl (the `extern` with DW_AT_external = yes) has neither. So that would help the function *not* just reference the extern and return early, thus eventually writing the complete DW_TAG_array_type too. I don't know this code well, haven't actually bisected, and this isn't actually an LTO case that patch's comment describes... but it seems to be in the right timeframe and changing relevant parts of dwarf2out.c
[Bug c++/95222] [10/11 Regression] GCC 10.1 x86 issue with function pointers with calling convention attribute and template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95222 --- Comment #9 from Kevin Puetz --- I accidentally dropped a word, meant to say: I'm not directly arguing for (or against) a backport to (a hypothetical 9.5.0) Just noting that this issue could also manifest as wrong-code, for consideration in case there's going to be one.
[Bug c++/95222] [10/11 Regression] GCC 10.1 x86 issue with function pointers with calling convention attribute and template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95222
Kevin Puetz changed:
What|Removed |Added
CC||puetzk at puetzk dot org
--- Comment #8 from Kevin Puetz ---
This bug can also manifest as wrong-code, e.g.
>>>
template struct func_ptr_t;
template struct func_ptr_t {
using type = void(*)(T);
};
template struct func_ptr_t {
#if 1
using type = void(__attribute__((__stdcall__))*)(T);
#else
using type = void(__attribute__((__stdcall__))*)(int); // this works,
using T is important somehow
#endif
};
#if 1
using foo_stdcall_ptr = func_ptr_t::type;
using foo_cdecl_ptr = func_ptr_t::type;
#else
using foo_stdcall_ptr = void(__attribute__((__stdcall__))*)(int,int);
using foo_cdecl_ptr = void(*)(int,int);
#endif
foo_stdcall_ptr foo_stdcall;
foo_cdecl_ptr foo_cdecl;
void bar_stdcall() {
foo_stdcall(1);
}
void bar_cdecl() {
foo_cdecl(1);
}
>>>
Should compile so that the bar_stdcall versions pops fewer bytes off the stack
(as foo_stdcall already cleaned up its own arguments).
>>>
--- bar_cdecl.S 2021-03-09 00:54:58.404022904 +
+++ bar_stdcall.S 2021-03-09 00:52:07.900015002 +
@@ -1,15 +1,15 @@
-:
+:
0: f3 0f 1e fb endbr32
4: 55 push %ebp
5: 89 e5 mov%esp,%ebp
7: 83 ec 08sub$0x8,%esp
- a: e8 fc ff ff ff call 32
+ a: e8 fc ff ff ff call b
f: 05 01 00 00 00 add$0x1,%eax
14: 8b 80 00 00 00 00 mov0x0(%eax),%eax
1a: 83 ec 0csub$0xc,%esp
1d: 6a 01 push $0x1
1f: ff d0 call *%eax
- 21: 83 c4 10add$0x10,%esp
+ 21: 83 c4 0cadd$0xc,%esp
24: 90 nop
25: c9 leave
26: c3 ret
>>>
But doesn't in 9.4, 10.0, and 10.1 (seems to be fixed again in 10.2+,
presumably per this fix). I mention this only because I finally found this
relevant PR, and perhaps knowing it might affect decisions about which branches
should get fixed - e.g. 9.x is in stage 4 but this is a 9.3.0->9.4.0 regression
(presumably PR090750), and also wrong-code. But we were able to work around it,
and so I'm not directly arguing for (or against) a backport to
Ubuntu 20.04 compiler **is** affected despite claiming to be 9.3.0 - Ubuntu has
seemingly backported the gcc 9 branch through 4ad02cfb768 (git-updates.patch in
gcc-9_9.3.0-17ubuntu1~20.04.debian.tar.xz). But I'll raise that separately in
their bug tracker.
