This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] implement support for "enum class"


>>>>> "Mark" == Mark Wielaard <mjw@redhat.com> writes:

>> +gdb_test "ptype E1" \
>> +    "type = enum class E1 {E1::HI = 7, E1::THERE}"

Mark> This FAILs for me with gcc plus
Mark> http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01448.html

Thanks Mark.

Mark> (gdb) ptype E1
Mark> type = enum class E1 : int {E1::HI = 7, E1::THERE}
Mark> Note the : int.
[...]
Mark> If the test is right then I think you don't want to print the underlying
Mark> type if DW_AT_enum_class is set and the enum has type safe semantics?

I'm not totally sure what to do.  It seems that without extra
information there is no perfect answer.

At least this code should (most likely) only print the ": type" part for
C++, not for C.  That was an oversight in the original patch.  This may
omit some information from the C case, but on the other hand at least
the output won't be gratuitously non-C.

I was anticipating that GCC would emit an unnamed type for the
underlying type in the case where the underlying type is not specified
in the source.  However I can see why it would not necessarily do this,
and certainly there's no requirement in DWARF along these lines.

One option might be to have the DWARF reader omit the underlying type
when the type it guessed from the enum values agreed with the type
specified in DW_AT_type.  Of course that's just a heuristic.  It's
perhaps better, I think, to just always emit the bits even if they are
in some sense redundant.

In C++11, whether an underlying type is specified is orthogonal to
whether the enum is an "enum class".  "enum x : short" is perfectly ok.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]