[PATCH 2/5] Make sure that static data member constexpr isn't optimized away in test.

[Mark Wielaard]

Hi,

On Mon, 2020-08-24 at 17:38 -0400, Jason Merrill wrote:
> > This looks incorrect to me, that is a workaround for a real GCC bug.
> > 
> > Shouldn't we instead do something like (untested) following patch?
> > I mean, for DWARF < 5 the static data members were using DW_TAG_member,
> > which has been always marked by the function, so IMHO we should also always
> > mark the DW_TAG_variables at the class scope that replaced those.
> 
> The earlier behavior seems like an accident, that happened because we 
> always need to emit information about non-static data members.  I don't 
> think we should take it as guidance.

Maybe the reason they got emitted this way was an accident on the GCC
side. But I don't think it is an accident on the GDB side. At least
looking at the various gdb testcases, the intention is to show a
struct/class type as defined to the user, which includes both the
static and non-static data members of a class.

> In this case one reason we don't emit debug info is because (before 
> C++17) there's no definition of 'b'.  After C++17 the in-class 
> declaration of 'b' is a definition, but we don't have to give it a 
> symbol, so there's still nothing for the debug info to describe.

But don't we describe other parts of a type that don't have a symbol as
part of the debug info?

> This issue doesn't seem specific to class members; it also affects 
> namespace-scope C++17 inline variables:
> 
> inline const int var = 42;
> int main() { return var; }
> 
> Compiling this testcase with -g doesn't emit any debug info for 'var' 
> even though it's used.

That is new in GCC11, don't have GCC10 here to compare against, but
GCC9 produces:

DWARF section [27] '.debug_info' at offset 0x30b5:
 [Offset]
 Compilation unit at offset 0:
 Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4
 Unit type: compile (1)
 [     c]  compile_unit         abbrev: 1
           producer             (strp) "GNU C++17 9.3.1 20200408 (Red Hat 9.3.1-2) -mtune=generic -march=x86-64 -gdwarf-5 -O2 -std=gnu++17"
           language             (data1) C_plus_plus_14 (33)
           name                 (strp) "p.cc"
           comp_dir             (strp) "/tmp"
           ranges               (sec_offset) range list [     c]
           low_pc               (addr) 000000000000000000
           stmt_list            (sec_offset) 0
 [    2a]    variable             abbrev: 2
             name                 (string) "var"
             decl_file            (data1) p.cc (1)
             decl_line            (data1) 1
             decl_column          (data1) 18
             type                 (ref4) [    3f]
             external             (flag_present) yes
             inline               (data1) declared_inlined (3)
             const_value          (data1) 42
 [    38]    base_type            abbrev: 3
             byte_size            (data1) 4
             encoding             (data1) signed (5)
             name                 (string) "int"
 [    3f]    const_type           abbrev: 4
             type                 (ref4) [    38]
 [    44]    subprogram           abbrev: 5
             external             (flag_present) yes
             name                 (strp) "main"
             decl_file            (data1) p.cc (1)
             decl_line            (data1) 2
             decl_column          (data1) 5
             type                 (ref4) [    38]
             low_pc               (addr) 0x0000000000401050 <main>
             high_pc              (data8) 6 (0x0000000000401056 <_start>)
             frame_base           (exprloc) 
              [ 0] call_frame_cfa
             call_all_calls       (flag_present) yes

> Should we assume that if a variable with DW_AT_const_value is TREE_USED, 
> we need to write out debug info for it?

I would say yes. If it is used a user might want to look up its value.

Cheers,

Mark