the combined build is using GCC 13.2.0 and binutils 2.41

these are committed to GCC trunk, not yet to the gcc-13 branch

How exactly did you combine the sources?  This is hardly a problem with gprofng.

I cannot reproduce the problem.

I cloned http://gcc.gnu.org/git/gcc.git and copied all directories from binutils-gdb. 
 I see an error in the libctf build:
 ../../libctf/ctf-hash.c: In function ‘ctf_dynhash_create’:
 ../../libctf/ctf-hash.c:169:13: error: allocation of insufficient size ‘8’ for type ‘ctf_dynhash_t’ {aka ‘struct ctf_dynhash’} with size ‘24’ [-Werror=alloc-size]
  169 |     dynhash = malloc (offsetof (ctf_dynhash_t, key_free));
 ../../libctf/ctf-hash.c: In function ‘ctf_hashtab_insert’:
 ../../libctf/ctf-hash.c:222:15: error: allocation of insufficient size ‘16’ for type ‘ctf_helem_t’ {aka ‘struct ctf_helem’} with size ‘24’ [-Werror=alloc-size]

After fixing these errors, my build and installation no longer have any other errors.

(would you mind sending a patch for those to the ML btw? those have been on my list to report/fix...)

I removed only compiler errors to continue my build.
Like this:
% diff $old_binutils/libctf/ctf-hash.c libctf/ctf-hash.c
168,169c168,169
<   else
<     dynhash = malloc (offsetof (ctf_dynhash_t, key_free));
---
>   else    dynhash = malloc (sizeof (ctf_dynhash_t));
> 
222c222
< 	*slot = malloc (offsetof (ctf_helem_t, owner));
---
> 	*slot = malloc (sizeof (ctf_helem_t));



The correct fix is needed.

I configured my gcc trank build:
   <src>/configure --prefix=`pwd`/INSTALL --enable-gprofng
I see the binutils-gdb targets in Makefile.
For example:
% grep gprof Makefile 
    maybe-configure-gprof \
    maybe-configure-gprofng \
all-host: maybe-all-gprof
all-host: maybe-all-gprofng
info-host: maybe-info-gprof
info-host: maybe-info-gprofng


But after `make -j 40`, there are no gprofng, gprof, libctf, etc in build.
How should I configure my build to reproduce errors ?

Oops. I forgot to create links to binutils-2_41-branch.
Now I can build, install and run gprofng without warnings/errors.
I use gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-16.0.2)
I built on an x86_64/OL8 machine.

What errors are you seeing in your gprofng build?

I think it is about backporting this patch from master to releases/gcc-13:

commit 24552056fd5fc677c0d032f54a5cad1c4303d312
Author:     Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
AuthorDate: Fri Mar 11 08:58:31 2022 +0000
Commit:     Arsen Arsenović <arsen@gcc.gnu.org>
CommitDate: Mon Aug 7 22:59:38 2023 +0200

    gprofng: a new GNU profiler

    ChangeLog:

            * Makefile.def: Add gprofng module.
            * configure.ac: Add --enable-gprofng option.
            * Makefile.in: Regenerate.
            * configure: Regenerate.

    include/ChangeLog:

            * collectorAPI.h: New file.
            * libcollector.h: New file.
            * libfcollector.h: New file.

I don't have permissions for `git push`.
I fixed the problem after:

% git branch
  master
* releases/gcc-13
  trunk

% git cherry-pick 24552056fd5fc677c0d032f54a5cad1c4303d312
Performing inexact rename detection: 100% (322524/322524), done.
Auto-merging configure.ac
Auto-merging configure
Auto-merging Makefile.in
Auto-merging Makefile.def
[releases/gcc-13 d7f1ea5edb2] gprofng: a new GNU profiler
 Date: Fri Mar 11 08:58:31 2022 +0000
 7 files changed, 744 insertions(+)
 create mode 100644 include/collectorAPI.h
 create mode 100644 include/libcollector.h
 create mode 100644 include/libfcollector.h

I prepared a patch for the releases/gcc-13 branch.
Richard Biener <richard.guenther@gmail.com> rejected my patch for this branch.
Which branch should I use? master, trunk or something else?

On 1/31/24 00:56, Richard Biener wrote:
> On Wed, Jan 31, 2024 at 4:46 AM Vladimir Mezentsev
> <vladimir.mezentsev@oracle.com> wrote:
>>   may I close 31109 ?
>
> So yes, I'd say that's an INVALID bug since it doesn't use master
> branches on both sides.
>
> Richard.