Completely broken, will not compile on Clear Linux or other distros I've tried #177
Comments
|
@rlavaee @shenhanc78 The sync to internal version last week broke |
|
No gravy: |
|
(Yes I also tried with git checkout --recurse-submodules 1f9133a) -- no dice. |
|
Ok, please use the previous commit (-2 from HEAD). That one definitely builds. |
|
Welp, same issue so I figured out it was a problem with glog being removed and git not wanting to recurse if it was removed since HEAD. Fixed with Have you considered submitting just the converter to gcc themselves to integrate into gcc to "natively" read the prof file? Would eliminate a lot of this extraneous maintenance and compilation and dependencies etc. |
|
Not sure if due to failed build, but that one is crashing with segfault on a simple profile from a simple program: Should I open a new ticket or is this just a build failure? |
|
@GabeAl If you can share |
Yes, separating the stuff that's needed for |
|
Sure I can share -- but first, anything amiss with what I'm using to invoke things? AMD Zen 4 processor (so no intel-locked "br_inst_retired:near_taken" garbledigook). I used a bunch of the standard options instead. If everything looks good, I have a large ~200MB perf.data to upload.
I see -- it would probably save time in the long term with all the debugging and code cleaning and separate tree maintenence, so perhaps the argument could be made re: amortized time savings. |
|
Your steps look fine. You are probably running into a bug in DWARF5 support. Try using |
|
One more thing: please add |
|
I'm building from 61b25e4 (HEAD -2 at the time of writing) but am running into compile failures. E.g. quipper/huge_page_deducer.cc is missing an include for <unordered_map>. Are there compatibility issues with the third-party libraries? Will reverting to a given autofdo commit (like 61b25e4) also pick up matching commits of the third-party libraries? I wanted to revert to a stable release or a "last known good" release, but it looks like the latest release (and tag) was 0.19 in 2019. |
|
Hi, sorry for breaking create_gcov. To preclude such incidences, we are thinking of forking off create_gcov or making it into another create_llvm_prof branch. Because create_gcov is only in maintenance mode and it does not depends on llvm, whereas the main create_llvm_prof part is actively developed inside google and will be synced here from time to time. I'll talk to @rlavaee who is syncing some internal code here. I'll also looking into @algr building issue during the weekend. |
|
gdwarf-4 and --gcov_version=2 still crash. |
|
BTW why all the llvm business? GCC is generally a more performant compiler for most vectorized hpc code with intrinsics etc (as long as you avoid corner cases or coding specifically to llvm's idiosyncracies). Seems like some redundant effort in the open source compiler community. |
|
I am sorry about the breakage as well. We'll soon decide what to do about
create_gcov. The easiest solution would be forking from an earlier version
of the repo and then making a standalone repo for create_gcov.
As you may know, Google has switched to the LLVM compiler for several years
now. We just weren't fully aware that there are gcc users out there.
…On Thu, Oct 12, 2023 at 5:36 PM Gabriel Al-Ghalith ***@***.***> wrote:
BTW why all the llvm business? GCC is generally a more performant compiler
for hpc code (as long as you avoid corner cases or coding specifically to
llvm's idiosyncracies). Seems like wasted effort in the open source space.
—
Reply to this email directly, view it on GitHub
<#177 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABHP3N34CSL5JCD5U6IBUIDX7CEIRANCNFSM6AAAAAA53DBH3A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I reverted the culprit patch. Please resync to head (7a005a5) and rebuild.
…On Thu, Oct 12, 2023 at 8:03 PM Rahman Lavaee ***@***.***> wrote:
I am sorry about the breakage as well. We'll soon decide what to do about
create_gcov. The easiest solution would be forking from an earlier version
of the repo and then making a standalone repo for create_gcov.
As you may know, Google has switched to the LLVM compiler for several
years now. We just weren't fully aware that there are gcc users out there.
On Thu, Oct 12, 2023 at 5:36 PM Gabriel Al-Ghalith <
***@***.***> wrote:
> BTW why all the llvm business? GCC is generally a more performant
> compiler for hpc code (as long as you avoid corner cases or coding
> specifically to llvm's idiosyncracies). Seems like wasted effort in the
> open source space.
>
> —
> Reply to this email directly, view it on GitHub
> <#177 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABHP3N34CSL5JCD5U6IBUIDX7CEIRANCNFSM6AAAAAA53DBH3A>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
Thanks @rlavaee -- would this change be expected to fix compilation, or to fix the bug I posted previously in the thread (repro requested by @erozenfeld )? Happy to give it a try but would like to align expectations first. |
|
Yes. I have tried this with gcc (Debian 13.2.0-4) 13.2.0 and all gcc-based
builds and tests succeed. Please give it a try.
…On Fri, Oct 13, 2023 at 1:06 PM Gabriel Al-Ghalith ***@***.***> wrote:
Thanks @rlavaee <https://github.com/rlavaee> -- would this change be
expected to fix compilation, or to fix the bug I posted previously in the
thread (repro requested by @erozenfeld <https://github.com/erozenfeld> )?
Happy to give it a try but would like to align expectations first.
—
Reply to this email directly, view it on GitHub
<#177 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABHP3N5GGT3ZGFWHOUKYMQ3X7GNM5ANCNFSM6AAAAAA53DBH3A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@rlavaee Thank you for fixing the break! |
|
@GabeAl I reproduced your failure and, as I suspected, you ran into a missing DWARF5 feature: BTW, double check your steps when you compile |
This code is messy. Very, unbelievably messy.
I don't understand why GCC references it in its documentation, when GCC itself compiles brilliantly across dozens of very different environments I've tried it on, and this doesn't compile anywhere for me...
GCC mentions the need to use one little utility function:
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fauto-profile
("Then use the create_gcov tool to convert the raw profile data to a format that can be used by GCC.")
I don't know why they ever merged support of this less-than-research grade codebase, and why it persists into GCC13.
Why did you merge this into GCC in a partial frankenstenian way? Why not merge the ability to support the perf output directly? Nobody I've ever talked to whose heard of AutoFDO has gotten this hot mess to compile.
GCC 13.1. No LLVM. I am not using the LLVM compiler, and am only interested in using auto-profile with GCC. I just need that one utility, "create_gcov", and nothing else in this 1.7GB code morass that gets pulled in from git clone. (Why so huge and messy?).
garbage.log
Here's the log showing the extent of the failure. It's not pretty.
The text was updated successfully, but these errors were encountered: