Re: [PATCH v3] emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack [PR70536]

2023-05-17 Thread Ed Catmur
Ping.

On Sat, 4 Feb 2023, at 10:50, Ed Catmur wrote:
> Per 
> http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Variadic_templates 
> DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:
>
> 17$:  DW_TAG_formal_parameter_pack
>   DW_AT_name("args")
> 18$:  DW_TAG_formal_parameter
>   ! no DW_AT_name attribute
>   DW_AT_type(reference to 13$)
> (...)
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536
> ---
>  gcc/dwarf2out.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
> index 1f39df3b1e2..462328acd9f 100644
> --- a/gcc/dwarf2out.cc
> +++ b/gcc/dwarf2out.cc
> @@ -23041,7 +23041,7 @@ gen_formal_parameter_pack_die  (tree parm_pack,
> && subr_die);
> 
>parm_pack_die = new_die (DW_TAG_GNU_formal_parameter_pack, subr_die, 
> parm_pack);
> -  add_src_coords_attributes (parm_pack_die, parm_pack);
> +  add_name_and_src_coords_attributes (parm_pack_die, parm_pack);
> 
>for (arg = pack_arg; arg; arg = DECL_CHAIN (arg))
>  {
> -- 
> 2.34.1


[PATCH v3] emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack [PR70536]

2023-02-04 Thread Ed Catmur
Per http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Variadic_templates 
DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:

17$:  DW_TAG_formal_parameter_pack
  DW_AT_name("args")
18$:  DW_TAG_formal_parameter
  ! no DW_AT_name attribute
  DW_AT_type(reference to 13$)
(...)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536
---
 gcc/dwarf2out.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 1f39df3b1e2..462328acd9f 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -23041,7 +23041,7 @@ gen_formal_parameter_pack_die  (tree parm_pack,
  && subr_die);
 
   parm_pack_die = new_die (DW_TAG_GNU_formal_parameter_pack, subr_die, 
parm_pack);
-  add_src_coords_attributes (parm_pack_die, parm_pack);
+  add_name_and_src_coords_attributes (parm_pack_die, parm_pack);
 
   for (arg = pack_arg; arg; arg = DECL_CHAIN (arg))
 {
-- 
2.34.1



[PATCH] gcc: emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack [PR70536]

2023-01-10 Thread Ed Catmur
Per http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Variadic_templates 
DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:

17$:  DW_TAG_formal_parameter_pack
  DW_AT_name("args")
18$:  DW_TAG_formal_parameter
  ! no DW_AT_name attribute
  DW_AT_type(reference to 13$)
(...)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536From 2c50fbbfdd42c9ecb6d6b8e4c53bb3029ef1ee25 Mon Sep 17 00:00:00 2001
From: Ed Catmur 
Date: Sat, 12 Mar 2022 17:38:33 +
Subject: [PATCH] emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack

Per http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Variadic_templates 
DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:

17$:  DW_TAG_formal_parameter_pack
  DW_AT_name("args")
18$:  DW_TAG_formal_parameter
  ! no DW_AT_name attribute
  DW_AT_type(reference to 13$)
(...)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536
---
 gcc/dwarf2out.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 5681b01749ad..ef3bc6f88e07 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -23006,7 +23006,7 @@ gen_formal_parameter_pack_die  (tree parm_pack,
  && subr_die);
 
   parm_pack_die = new_die (DW_TAG_GNU_formal_parameter_pack, subr_die, 
parm_pack);
-  add_src_coords_attributes (parm_pack_die, parm_pack);
+  add_name_and_src_coords_attributes (parm_pack_die, parm_pack);
 
   for (arg = pack_arg; arg; arg = DECL_CHAIN (arg))
 {


[PATCH v2] c++: Fall through for arrays of T vs T cv [PR104996]

2022-04-18 Thread Ed Catmur
If two arrays do not have the exact same element type including qualification, 
this could be e.g. f(int (&&)[]) vs. f(int const (&)[]), which can still be 
distinguished by the lvalue-rvalue tiebreaker.

By tightening this branch (in accordance with the letter of the Standard) we 
fall through to the next branch, which tests whether they have different 
element type ignoring qualification and returns 0 in that case; thus we only 
actually fall through in the T[...] vs. T cv[...] case, eventually considering 
the lvalue-rvalue tiebreaker at the end of compare_ics.

Bootstrapped and tested on x86_64-pc-linux-gnu.

Signed-off-by: Ed Catmur 

PR c++/104996

gcc/cp/ChangeLog:

* call.cc (compare_ics): When comparing list-initialization sequences, 
do not return early.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist129.C: New test.
---
 gcc/cp/call.cc   | 7 ++-
 gcc/testsuite/g++.dg/cpp0x/initlist129.C | 6 ++
 2 files changed, 8 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist129.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 51d8f6c3fb1..fa18d7f8f9d 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -11546,12 +11546,9 @@ compare_ics (conversion *ics1, conversion *ics2)
 P0388R4.)  */
   else if (t1->kind == ck_aggr
   && TREE_CODE (t1->type) == ARRAY_TYPE
-  && TREE_CODE (t2->type) == ARRAY_TYPE)
+  && TREE_CODE (t2->type) == ARRAY_TYPE
+  && same_type_p (TREE_TYPE (t1->type), TREE_TYPE (t2->type)))
{
- /* The type of the array elements must be the same.  */
- if (!same_type_p (TREE_TYPE (t1->type), TREE_TYPE (t2->type)))
-   return 0;
-
  tree n1 = nelts_initialized_by_list_init (t1);
  tree n2 = nelts_initialized_by_list_init (t2);
  if (tree_int_cst_lt (n1, n2))
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist129.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist129.C
new file mode 100644
index 000..4d4faa9e08d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist129.C
@@ -0,0 +1,6 @@
+// PR c++/104996
+// { dg-do compile { target c++11 } }
+
+template char f(int (&&)[size]);
+template int f(int const (&)[size]);
+static_assert(sizeof(f({1, 2, 3})) == 1, "");
-- 
2.30.2



[PATCH] c++: Fall through for arrays of T vs T cv [PR104996]

2022-03-22 Thread Ed Catmur
If two arrays do not have the exact same element type including qualification, 
this could be e.g. f(int (&&)[]) vs. f(int const (&)[]), which can still be 
distinguished by the lvalue-rvalue tiebreaker.

By tightening this branch (in accordance with the letter of the Standard) we 
fall through to the next branch, which tests whether they have different 
element type ignoring qualification and returns 0 in that case; thus we only 
actually fall through in the T[...] vs. T cv[...] case, eventually considering 
the lvalue-rvalue tiebreaker at the end of compare_ics.

Add test.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104996
---
 gcc/cp/call.cc  | 7 ++-
 gcc/testsuite/g++.dg/pr104996.C | 5 +
 2 files changed, 7 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr104996.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 23d3fc496b822..28589ab3459ea 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -11535,12 +11535,9 @@ compare_ics (conversion *ics1, conversion *ics2)
 P0388R4.)  */
   else if (t1->kind == ck_aggr
   && TREE_CODE (t1->type) == ARRAY_TYPE
-  && TREE_CODE (t2->type) == ARRAY_TYPE)
+  && TREE_CODE (t2->type) == ARRAY_TYPE
+  && same_type_p (TREE_TYPE (t1->type), TREE_TYPE (t2->type)))
{
- /* The type of the array elements must be the same.  */
- if (!same_type_p (TREE_TYPE (t1->type), TREE_TYPE (t2->type)))
-   return 0;
-
  tree n1 = nelts_initialized_by_list_init (t1);
  tree n2 = nelts_initialized_by_list_init (t2);
  if (tree_int_cst_lt (n1, n2))
diff --git a/gcc/testsuite/g++.dg/pr104996.C b/gcc/testsuite/g++.dg/pr104996.C
new file mode 100644
index 0..2e7558c7b9c77
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr104996.C
@@ -0,0 +1,5 @@
+// { dg-do compile { target c++11 } }
+
+template char f(int (&&)[size]);
+template int f(int const (&)[size]);
+static_assert(sizeof(f({1, 2, 3})) == 1, "");


[PATCH] gcc: emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack [PR70536]

2022-03-13 Thread Ed Catmur
Per http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Variadic_templates 
DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:

17$:  DW_TAG_formal_parameter_pack
  DW_AT_name("args")
18$:  DW_TAG_formal_parameter
  ! no DW_AT_name attribute
  DW_AT_type(reference to 13$)
(...)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536
From 2c50fbbfdd42c9ecb6d6b8e4c53bb3029ef1ee25 Mon Sep 17 00:00:00 2001
From: Ed Catmur 
Date: Sat, 12 Mar 2022 17:38:33 +
Subject: [PATCH] emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack

Per http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Variadic_templates 
DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:

17$:  DW_TAG_formal_parameter_pack
  DW_AT_name("args")
18$:  DW_TAG_formal_parameter
  ! no DW_AT_name attribute
  DW_AT_type(reference to 13$)
(...)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536
---
 gcc/dwarf2out.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 5681b01749add..ef3bc6f88e070 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -23006,7 +23006,7 @@ gen_formal_parameter_pack_die  (tree parm_pack,
  && subr_die);
 
   parm_pack_die = new_die (DW_TAG_GNU_formal_parameter_pack, subr_die, 
parm_pack);
-  add_src_coords_attributes (parm_pack_die, parm_pack);
+  add_name_and_src_coords_attributes (parm_pack_die, parm_pack);
 
   for (arg = pack_arg; arg; arg = DECL_CHAIN (arg))
 {


[PATCH 3/3] c++: expr-cast - C-style cast conformance [PR77465]

2021-12-30 Thread Ed Catmur
gcc/testsuite/ChangeLog:

* g++.dg/conversion/explicit2.C: New test.
* g++.dg/conversion/explicit3.C: New test.


0003-Add-tests-verifying-conformance-to-explicit.patch
Description: Binary data


[PATCH 2/3] c++: expr-cast - C-style cast conformance [PR77465]

2021-12-30 Thread Ed Catmur
gcc/cp/ChangeLog:

* call.c (reference_binding):

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-union.C:
* g++.dg/warn/Wstrict-aliasing-5.C:
* g++.old-deja/g++.jason/rvalue3.C:
* g++.dg/conversion/explicit1.C: New test.

0002-Add-const-qualification-to-static_cast-stage-of-C-st.patch
Description: Binary data


[PATCH 1/3] c++: expr-cast - C-style cast conformance [PR77465]

2021-12-30 Thread Ed Catmur
PR c++/77465 - [DR909] rejected C-style cast involving casting away constness 
from result of conversion operator

PR c++/77465

gcc/cp/ChangeLog:

* call.c (tourney):
(joust):
(build_user_type_conversion_1):
(reference_binding):
(implicit_conversion_1):
(build_user_type_conversion):
(perform_overload_resolution):
(build_op_call):
(build_conditional_expr):
(build_new_op):
(build_op_subscript):
(convert_like_internal):
(build_over_call):
(build_new_method_call):
* cp-tree.h (build_user_type_conversion):

gcc/testsuite/ChangeLog:

* g++.old-deja/g++.brendan/misc17.C:
* g++.old-deja/g++.mike/p2855.C:
* g++.dg/conversion/cwg909.C: New test.


0001-Apply-C-style-cast-rules-for-user-defined-conversion.patch
Description: Binary data


[PATCH 0/3] c++: expr-cast - C-style cast conformance [PR77465]

2021-12-30 Thread Ed Catmur
This patch series improves conformance to the C++ standard for C-style casts 
(explicit cast notation, [expr.cast]) in two scenarios.

First, as discussed in CWG 909 [1], a C-style cast may invoke a user-defined 
conversion (as a static_cast) followed by a const_cast; currently this is 
erroneously rejected, tracked in PR77465 [2].

Second, a C-style cast to non-const reference to arithmetic type can and thus 
should be interpreted as a static_cast reference binding to temporary followed 
by a const_cast; currently it is interpreted as a reinterpret_cast (possibly 
followed by const_cast). To the best of my knowledge this has not been reported 
as a defect; credit to Turtlefight on Stack Overflow [3] for analyzing the 
situation, drawing my attention to the above issues, and convincing me that my 
interpretation was correct. Note that C-style cast to /const/ arithmetic 
reference will already introduce a temporary; this patch only changes the 
behavior where the reference is to non-const.

Clearly there is the potential for miscompilation of existing code that assumes 
an incorrect interpretation (reinterpret_cast); a number of existing test cases 
are amended in this patch series. In consideration of this, I have checked 
bootstrap (on x86_64) with no new errors, and add a warning (to Wconversion) 
where a C-style cast to arithmetic reference introduces a temporary in a 
situation where the user may expect a reinterpret_cast (type-punning); this 
affects both the const (existing) and non-const case. Note that this change 
will not affect C code compiled as C++, since that code cannot contain 
user-defined conversions or references.

In this patch series,
* 1/3 - allow C-style cast to invoke user-defined conversion followed by 
const_cast, resolving PR77465; adds a test case and fixes existing test cases 
which expect this to be rejected
* 2/3 - allow C-style cast to non-const reference to arithmetic type to invoke 
static_cast reference binding to temporary followed by const_cast; adds a test 
case and fixes existing test cases which expect reinterpret_cast semantics
* 3/3 - add comprehensive test suite covering expr.cast scenarios, positive and 
negative.

1. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#909
2. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77465
3. https://stackoverflow.com/a/70400230/567292