[gcc r15-637] Use DW_TAG_module for Ada

2024-05-17 Thread Tom Tromey via Gcc-cvs
https://gcc.gnu.org/g:9b6acf5357818ce7ff234c504ed79078a06d0e0f

commit r15-637-g9b6acf5357818ce7ff234c504ed79078a06d0e0f
Author: Tom Tromey 
Date:   Thu Apr 18 09:08:23 2024 -0600

Use DW_TAG_module for Ada

DWARF is not especially clear on the distinction between
DW_TAG_namespace and DW_TAG_module, but I think that DW_TAG_module is
more appropriate for Ada.  This patch changes the compiler to do this.
Note that the Ada compiler does not yet create NAMESPACE_DECLs.

gcc

* dwarf2out.cc (gen_namespace_die): Use DW_TAG_module for Ada.

Diff:
---
 gcc/dwarf2out.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 70b7f5f42cd7..5b064ffd78ad 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -27003,7 +27003,7 @@ gen_namespace_die (tree decl, dw_die_ref context_die)
 {
   /* Output a real namespace or module.  */
   context_die = setup_namespace_context (decl, comp_unit_die ());
-  namespace_die = new_die (is_fortran () || is_dlang ()
+  namespace_die = new_die (is_fortran () || is_dlang () || is_ada ()
   ? DW_TAG_module : DW_TAG_namespace,
   context_die, decl);
   /* For Fortran modules defined in different CU don't add src coords.  */


[gcc r15-3458] Check DECL_NAMELESS in modified_type_die

2024-09-04 Thread Tom Tromey via Gcc-cvs
https://gcc.gnu.org/g:5326306e7d9d36eccc2c2f02e1357818625f057b

commit r15-3458-g5326306e7d9d36eccc2c2f02e1357818625f057b
Author: Tom Tromey 
Date:   Thu Aug 29 13:23:18 2024 -0600

Check DECL_NAMELESS in modified_type_die

While working on a patch to the Ada compiler, I found a spot in
dwarf2out.cc that calls add_name_attribute without respecting
DECL_NAMELESS.

gcc

* dwarf2out.cc (modified_type_die): Check DECL_NAMELESS.

Diff:
---
 gcc/dwarf2out.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 89c2fd02649..a7ec359bd0c 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -14019,6 +14019,7 @@ modified_type_die (tree type, int cv_quals, bool 
reverse,
   || (cv_quals == TYPE_UNQUALIFIED)))
  || (TREE_CODE (name) == TYPE_DECL
  && DECL_NAME (name)
+ && !DECL_NAMELESS (name)
  && (TREE_TYPE (name) == qualified_type
  || (lang_hooks.types.get_debug_type
  && (lang_hooks.types.get_debug_type (TREE_TYPE (name))


[gcc r14-9754] Prettify output of debug_dwarf_die

2024-04-02 Thread Tom Tromey via Gcc-cvs
https://gcc.gnu.org/g:1e459e6625ff86babc461f8ceada0a63aee5b7a5

commit r14-9754-g1e459e6625ff86babc461f8ceada0a63aee5b7a5
Author: Tom Tromey 
Date:   Thu Mar 28 13:22:34 2024 -0600

Prettify output of debug_dwarf_die

When debugging gcc, I tried calling debug_dwarf_die and I saw this
output:

  DW_AT_location: location descriptor:
(0x7fffe9c2e870) DW_OP_dup 0, 0
(0x7fffe9c2e8c0) DW_OP_bra location descriptor (0x7fffe9c2e640)
, 0
(0x7fffe9c2e820) DW_OP_lit4 4, 0
(0x7fffe9c2e910) DW_OP_skip location descriptor (0x7fffe9c2e9b0)
, 0
(0x7fffe9c2e640) DW_OP_dup 0, 0

I think those ", 0" should not appear on their own lines.  The issue
seems to be that print_dw_val should not generally emit a newline,
except when recursing.

gcc/ChangeLog

* dwarf2out.cc (print_dw_val) : Don't
print newline when not recursing.

Diff:
---
 gcc/dwarf2out.cc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 8f18bc4fe64..1b0e8b5a5b2 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -6651,7 +6651,7 @@ print_dw_val (dw_val_node *val, bool recurse, FILE 
*outfile)
 case dw_val_class_loc:
   fprintf (outfile, "location descriptor");
   if (val->v.val_loc == NULL)
-   fprintf (outfile, " -> \n");
+   fprintf (outfile, " -> ");
   else if (recurse)
{
  fprintf (outfile, ":\n");
@@ -6662,9 +6662,9 @@ print_dw_val (dw_val_node *val, bool recurse, FILE 
*outfile)
   else
{
  if (flag_dump_noaddr || flag_dump_unnumbered)
-   fprintf (outfile, " #\n");
+   fprintf (outfile, " #");
  else
-   fprintf (outfile, " (%p)\n", (void *) val->v.val_loc);
+   fprintf (outfile, " (%p)", (void *) val->v.val_loc);
}
   break;
 case dw_val_class_loc_list:


[gcc r14-9760] libiberty: Invoke D demangler when --format=auto

2024-04-02 Thread Tom Tromey via Gcc-cvs
https://gcc.gnu.org/g:ca2f7c84927f85b95f0f48f82b93f1460c372db4

commit r14-9760-gca2f7c84927f85b95f0f48f82b93f1460c372db4
Author: Tom Tromey 
Date:   Sat Mar 30 13:48:30 2024 -0600

libiberty: Invoke D demangler when --format=auto

Investigating GDB PR d/31580 showed that the libiberty demangler
doesn't automatically demangle D mangled names.  However, I think it
should -- like C++ and Rust (new-style), D mangled names are readily
distinguished by the leading "_D", and so the likelihood of confusion
is low.  The other non-"auto" cases in this code are Ada (where the
encoded form could more easily be confused by ordinary programs) and
Java (which is long gone, but which also shared the C++ mangling and
thus was just an output style preference).

This patch also fixed another GDB bug, though of course that part
won't apply to the GCC repository.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276

libiberty
* cplus-dem.c (cplus_demangle): Try the D demangler with
"auto" format.
* testsuite/d-demangle-expected: Add --format=auto test.

Diff:
---
 libiberty/cplus-dem.c   | 2 +-
 libiberty/testsuite/d-demangle-expected | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/libiberty/cplus-dem.c b/libiberty/cplus-dem.c
index 8b92946981f..ee9e84f5d6b 100644
--- a/libiberty/cplus-dem.c
+++ b/libiberty/cplus-dem.c
@@ -186,7 +186,7 @@ cplus_demangle (const char *mangled, int options)
   if (GNAT_DEMANGLING)
 return ada_demangle (mangled, options);
 
-  if (DLANG_DEMANGLING)
+  if (DLANG_DEMANGLING || AUTO_DEMANGLING)
 {
   ret = dlang_demangle (mangled, options);
   if (ret)
diff --git a/libiberty/testsuite/d-demangle-expected 
b/libiberty/testsuite/d-demangle-expected
index 47b059c4298..cfbdf2a52cb 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -1470,3 +1470,8 @@ demangle.anonymous
 --format=dlang
 _D8demangle9anonymous03fooZ
 demangle.anonymous.foo
+#
+# Test that 'auto' works.
+--format=auto
+_D8demangle9anonymous03fooZ
+demangle.anonymous.foo


[gcc r15-9133] Further use of mod_scope in modified_type_die

2025-04-01 Thread Tom Tromey via Gcc-cvs
https://gcc.gnu.org/g:2fd74c790556a3de6c42efa564781aa2ac0e3596

commit r15-9133-g2fd74c790556a3de6c42efa564781aa2ac0e3596
Author: Tom Tromey 
Date:   Wed Aug 21 11:46:52 2024 -0600

Further use of mod_scope in modified_type_die

I am working on some changes to GNAT to emit hierarchical DWARF --
i.e., where entities will have simple names nested in a DW_TAG_module.

While working on this I found a couple of paths in modified_type_die
where "mod_scope" should be used, but is not.  I suspect these cases
are only reachable by Ada code, as in both spots (subrange types and
base types), I believe that other languages don't generally have named
types in a non-top-level scope, and in these other situations,
mod_scope will still be correct.

gcc

* dwarf2out.cc (modified_type_die): Use mod_scope for
ranged types, base types, and array types.

Diff:
---
 gcc/dwarf2out.cc | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index a2acfd1d3565..69e9d775d0d2 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -13926,7 +13926,7 @@ modified_type_die (tree type, int cv_quals, bool 
reverse,
   || (lang_hooks.types.get_array_descr_info
   && lang_hooks.types.get_array_descr_info (type, &info)))
 {
-  gen_type_die (type, context_die);
+  gen_type_die (type, mod_scope);
   return lookup_type_die (type);
 }
   else if (code == INTEGER_TYPE
@@ -13936,7 +13936,7 @@ modified_type_die (tree type, int cv_quals, bool 
reverse,
   tree bias = NULL_TREE;
   if (lang_hooks.types.get_type_bias)
bias = lang_hooks.types.get_type_bias (type);
-  mod_type_die = subrange_type_die (type, low, high, bias, context_die);
+  mod_type_die = subrange_type_die (type, low, high, bias, mod_scope);
   item_type = TREE_TYPE (type);
 }
   else if (is_base_type (type))
@@ -13973,10 +13973,10 @@ modified_type_die (tree type, int cv_quals, bool 
reverse,
{
  dw_die_ref after_die
= modified_type_die (type, cv_quals, false, context_die);
- add_child_die_after (comp_unit_die (), mod_type_die, after_die);
+ add_child_die_after (mod_scope, mod_type_die, after_die);
}
   else
-   add_child_die (comp_unit_die (), mod_type_die);
+   add_child_die (mod_scope, mod_type_die);
 
   add_pubtype (type, mod_type_die);
 }