Generally speaking, you propose the fix to whichever group created the code that caused the issue. So in your case, if the possible bug you're trying to fix is caused by some code in the upstream project (e.g. PulseAudio), you should file a bug report and propose your fix in the upstream project. If the bug is caused by code in Gentoo, such as a patch applied by an ebuild, then you should file your report and propose the fix in the Gentoo bug tracker.
In the former case, if the bug is caused by upstream code, generally it should be possible to confirm it by reproducing the bug without any Gentoo-specific infrastructure. Download and compile the upstream project's source code manually, following the instructions they give, and tweak compiler options or whatever you need to do to get the bug to occur. Ideally, you would even do it on a non-Gentoo system or two. This has two benefits: first, it proves that the bug has nothing to do with any customizations applied by Gentoo or anyone else, and second, it lets you work out a clear procedure for reproducing the bug, which will be tremendously valuable to the upstream project's developers when they are evaluating your bug report.
If you're quite confident that the bug does not exist in the upstream code, but it was introduced by some Gentoo-specific customization, then you can propose to the Gentoo people that they change that customization. Again, it's tremendously valuable if you can make it happen on a clean Gentoo system configured in the standard way. That proves that the bug has nothing to do with any customizations you may have applied, and it also allows the developers to reproduce it.
Of course, you may run into a situation where it's not possible to reproduce the bug on a clean Gentoo system, and in that case you have to consider the option that it's your specific environment that causes the bug. In that case, you're on your own. The "group" that created the code that caused the issue is you, and therefore the only person you can really report the issue to is yourself.
/bin/truemy builds will fail. If I then log bug reports asking for build mechanisms to support renaming the gcc binary, I may find at least some get closed NOTABUG or WONTFIX, and that decision rests entirely with the project.