[Bug middle-end/92170] Incorrect function names output when using -fstack-usage on C++

[boite.pour.spam at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170

X Ryl  changed:

   What|Removed |Added

 CC||boite.pour.spam at gmail dot 
com

--- Comment #8 from X Ryl  ---
Is there a reason why -fstack-usage doesn't output mangled name ?
It's very easy to run the output through c++filt.

Wouldn't it better if it was consistent with other tools and as such could be
compared ?

Typically, there is a tool (https://www.dlbeer.co.nz/oss/avstack.html) that's
used to compute the minimum stack size required for a program, and the fact
that -fstack-usage breaks for C++ (either with wrong names, or it outputs non
mangled name), it's not possible to link the reported stack usage with the
functions in the produced binary (for example, with objdump)

Even when the C++ item does not contain fancy dot, this is still a real pain
because if you demangle objdump's output, you'll get:

unsigned char * MyClass::foo(unsigned long)

while fstack-usage will return (with typedef):

uint8_t * MyClass::foo(uint64_t)



The patch is very simple, just bypass any demangling here since I don't think
it's the role of this method to demangle for you.






Index: gcc-7.3.0/gcc/toplev.c
===
--- gcc-7.3.0.orig/gcc/toplev.c
+++ gcc-7.3.0/gcc/toplev.c
@@ -996,28 +996,8 @@ output_stack_usage (void)
 {
   expanded_location loc
= expand_location (DECL_SOURCE_LOCATION (current_function_decl));
-  /* We don't want to print the full qualified name because it can be
long,
-so we strip the scope prefix, but we may need to deal with the suffix
-created by the compiler.  */
-  const char *suffix
-   = strchr (IDENTIFIER_POINTER (DECL_NAME (current_function_decl)), '.');
-  const char *name
-   = lang_hooks.decl_printable_name (current_function_decl, 2);
-  if (suffix)
-   {
- const char *dot = strchr (name, '.');
- while (dot && strcasecmp (dot, suffix) != 0)
-   {
- name = dot + 1;
- dot = strchr (name, '.');
-   }
-   }
-  else
-   {
- const char *dot = strrchr (name, '.');
- if (dot)
-   name = dot + 1;
-   }
+  const char *name = IDENTIFIER_POINTER
+   (DECL_ASSEMBLER_NAME (current_function_decl));

   fprintf (stack_usage_file,
   "%s:%d:%d:%s\t" HOST_WIDE_INT_PRINT_DEC"\t%s\n",

[Bug c++/81102] New: G++ wrong error report for partial template specialization

[boite.pour.spam at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81102

Bug ID: 81102
   Summary: G++ wrong error report for partial template
specialization
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boite.pour.spam at gmail dot com
  Target Milestone: ---

Hi,

 This code used to work fine with G++ version < 7.0:


template 
struct HelperWrapper;

// [...]

// Zero-ary
template 
struct HelperWrapper
{
static inline void* WrapFuncT(const int)
{
return (void*)Func; // Changed for the bug report, normally I capture
the function pointer, and make a list of its arguments type here, and return an
object that's callable and perform argument convertion via variant types.
}
};

// Unary
template 
struct HelperWrapper
{
static inline void * WrapFuncT(const int)
{
return (void*)Func; // Changed
}
};

// Binary
template 
struct HelperWrapper
{
static inline void * WrapFuncT(const int)
{
return (void*)Func; // Changed
}
};

[...]





Here's a godbolt that shows it starts failing since GCC v7.0.0 :
godbolt.org/g/uW3D7O


The diagnostic is:
:20:8: error: partial specialization 'struct HelperWrapper' is not more specialized than [-fpermissive]
 struct HelperWrapper
^~~~
:5:8: note: primary template 'template struct HelperWrapper'
 struct HelperWrapper;


IIUC, in the zero-ary case, the primary template argument FuncSig (which should
be matched to "Ret (&)()" does not match the specialized version "Ret" argument
which only match the return type of the function argument.
Thus, there does not exist any type that could lead to ambiguity here.

For the other arity case,  the diagnostic seems wrong too since there is an
additional template argument for the function argument type. That is: it does
not exist a type T that could match the specialized version while matching the
primary template directly, since the type T must "embed" 2 different types:
it's a function + a template  argument type.

Moreover, replacing the (&) part and (&Func) part by (*) and (*Func) makes G++
happy with the code.

The C++ standard allows taking reference on function as it decays to function
pointer, so the initial writing should be allowed without diagnostic.

However this code is used on Microsoft C++ compiler too, and it only accept
(&Func) version and fails compiling (*Func) version (this has been the case
since 2007 IIRC). It's also accepted on Intel C++ compiler too, and on Clang
(check the godbolt.org)

Thus, since G++7.0, I have to make 2 version (one with function pointers and
one with reference to support all compilers) and it's not very clean.
It also fails on G++8.0 beta.

Can you explain if it's a feature (and if yes, what is the reason for making a
difference between function pointer and function reference, and the extract of
the C++ standard that supports this claim) or a bug, please ?

Thank you very much.