[compiler-rt] lots of "warning: unknown warning option '-Werror=builtin-declaration-mismatch'" messages #72413
Comments
EugeneZelenko
added
cmake
|
|
|
That's what I don't understand, neither my llvm-git PKGBUILD nor the |
|
For reference, I am attaching the build config which is inside the PKGBUILD: PKGBUILD.txt And these flags are set in |
|
@thesamesam it is, since dc298fe |
|
@arichardson @thesamesam Ping. Could you please take a look, this issue still reproduces on latest main. |
|
Steps to reproduce:
|
|
You might need to adjust the build_stage1.bash script manually, as I use a local PGO-profile with it. |
|
Well that flag is only passed if the CMake configure command detects it as supported, so I have no idea why this is failing unless you are somehow overriding the compiler manually? |
|
I set the compiler flags via cmake within the scripts. And before the mentioned change, there were no such warnings. |
|
I don't understand why this would be going wrong since cmake tests if the flag is supported before using it. The cmake log should be helpful for figuring this out. Could be an issue with using DLLVM_ENABLE_PROJECTS=compiler-rt. This is no longer supported on main and should be using runtimes instead. |
|
Here are the logs from the ENABLE_PROJECTS build. With a ENABLE_RUNTIMES build, I don't get these warnings. |
|
It might be the same thing as #124623. Please try to minimise the steps required to reproduce it rather than producing large scripts with options that definitely won't work for me. |
|
Sorry, I've already provided a script that reproduces the problem (which I've updated today to workaround this issue, hence you'd need to undo that change). If that script doesn't suit you, you should be able to reproduce the problem when building compiler-rt via the The following is what AI came up as a summary. This is all I - as an unpaid non-programmer - can possibly add to this discussion. I'll leave it to you programmers to get to the bottomn of this if that is still a reasonable request, as I was told that the ENABLE_PROJECTS route is deprecated for compiler-rt anyway which should make this issue obsolete soon. |
|
No, you provided a script which you even admitted would need adaptation (in two ways!). No AI sludge, please. Bugs require collaboration, I'm afraid, it's not a matter of throwing things over the wall. You pinged and said it's still happening, and I told you what I'd need to work on it. You're free to propose a patch yourself instead. I'll unsubscribe from this bug now. |
Sorry, but I am not just throwing things over the wall here. If adapting a script in two obvious ways is too much to ask for you, it is too much to ask for me to sink any more time into this soon-to-be-obsolete issue. My time is limited and also valuable. I can also work on other more meaningful issues. And I consider the hints that were given here good enough and actionable for you guys to actually do your job instead of letting laymen solve it for you. |
So you paid good money for a program to "repeat, in your own words, [...]" without adding any useful or usable novel information, but...
With the implicit suggestion that the time of LLVM developers is neither one. Very nice. I suppose the contrast with you as "unpaid" means that LLVM developers are paid, hence why their time is unlimited.
And here you are, again, claiming that this is a "job". Can you show me your paid support contract? People like you are why OSS developers give up on OSS. That's true without you running a stochastic parrot designed to produce lies instead of actionable information -- though the stochastic parrot usage certainly doesn't help. |
|
Let's not go this route of further escalation (you are arguing with a law professional who also happens to be a tech enthusiast). I also refuse to fight strawman arguments. Blaming me for not having a degree in software engineering to give you a better analysis (or even better, a mergable MR) is not helpful either. At least I put effort into providing you constructive analysis and feedback to the best of my abilities. That is all what you can hope for from a end user like me. I also question the professionalism of you and Sam in dealing with my criticism. Yes, I might have overreacted emotionally as I would have hoped for a more forthcoming approach from the start. But the issue got ignored for two years even though the change that introduced it was identified in the meantime by a third party and could have been reverted or fixed in due time with some effort. Thankfully Alexander was more constructive without making unreasonable demands or blaming me and could identify a defect in the meantime. From the discussions of the proposed fix in #125602, I take away that my report and my insistance was of some value for the LLVM community after all. Why CI and the build bots didn't catch it back then would be another interesting question for another day and poits to a lack in coverage. |
You are welcome to escalate and sue me for defamation of character, if you like. It's very easy to claim anything on the internet. But I am not blaming you for not having a degree in software engineering. And I'm not expecting or demanding an analysis of the underlying cause, nor a mergeable PR. I'm quite happy for end users to report the best they can and very understanding of when they cannot provide more info (even if that does mean sometimes that we will never be able to figure out the problem, it is easy to be polite about my sadness that I'm unable to figure out the problem!). I'm blaming you for being massively rude about it by demanding things from open source developers and claiming an entitlement. I'm blaming you for insinuating that your time is more valuable than the time of others. I'm blaming you for making it difficult to be sad about being unable to solve your problem. Really, I don't know why this wasn't clear to you from the very start. At no point did I comment on your lack of a degree in software engineering, I commented on your hyperfixation on being "paid" and your demands that LLVM developers need to
which is actually, provably, a common cause of OSS developers quitting their unpaid tech enthusiast hobby which turns out to not actually be a job.
From the discussion of the proposed fix in #125602, I take away that nobody has any clue how your report occurred and the attempted analysis and fix was an incorrect diagnosis. You even reported there that it does NOT fix anything for you. That means the LLVM community is now back at square one in trying to figure out whether there even is a defect to begin with, let alone what the defect is. Sometimes issues are hard to understand, which is why they take a long time to fix. That's not the same thing as being "ignored".
Nobody has been able to figure out how to manually reproduce it either. It is, on the face of it, impossible to get wrong. Again, if we're back at square one in trying to figure out why it happens in the first place (or even whether it is possible to happen in the first place, report notwithstanding), then we can't expect CI and build bots to catch it either. |
|
Eli, While I appreciate your and Sam's engagement, I'm not interested in further personal attacks, baseless accusations or misinterpretations of my choice of words. Let's stick to the issue at hand. I stand by my initial report and the effort I put into providing information, even if the proposed fix in #125602 ultimately proved ineffective, as I reported there. My comments about "doing your job" and time constraints, were rooted in genuine frustration with Sam's remarks, given the identification of the causative commit and his remarks that I interpreted as provocative and not helpful. I understand the situation is more complex than initially perceived. However, dismissing my contributions and resorting to insults is unproductive. Regarding the "AI summary," it was an attempt to bridge the communication gap given my lack of programming expertise and shows the effort I am willing to invest to solve this issue. If that was unhelpful, I won't use it again. Frankly, the energy spent on dissecting our choice of words would be better spent on investigating the issue itself, assuming it is still relevant given the deprecation of the ENABLE_PROJECTS route. I've provided detailed information, a reproducible script (which, yes, requires minor adaptation which won't burn out any OSS developer), and we've got the confirmation from @mati865 already. My time is limited, as is everyone's, but I've invested a considerable amount in this already and hoped Sam and you would be more constructive and forthcoming in the future. If there's anything specific I can do to assist further, within my technical limitations, please let me know. I'm willing to test new revisions of that MR. Otherwise, I suggest we either focus on concrete steps towards a solution or acknowledge that the issue may be moot due to the deprecation of ENABLE_PROJECTS. I expect a professional and constructive dialogue going forward from both of you and Sam that complies with LLVM's Code of Conduct. |
You are more than welcome to interpret people's remarks, such as "Please try to minimise the steps required to reproduce it rather than producing large scripts with options that definitely won't work for me.", as provocative and unhelpful. As long as you're okay with those people then interpreting your comments about people's paid jobs, as provocative and unhelpful on your part. Personally, I don't see how
is provocative or unhelpful. It's pretty standard OSS interaction to expect users to aid in the investigation process, for example by testing their own build process incrementally through seeing which settings can be removed while still reproducing the problem, and not at all astonishing if an OSS developer therefore cordially requests you to do so. (And you admitted that the large scripts in question contain hardcoded information such as your personal computer's login username, clearly those scripts won't work out of the box on someone else's machine, which is precisely why it is helpful for the reporter to, if they can, "please try" to minimize the size of the reproducer script.) You may think you're frustrated, but I promise you, there are other people in the world who occasionally feel frustrated too.
I am sorry to have to confirm this :( but AI is a hugely divisive topic that many, many, many people regard as a hoax produced by scammers and con artists grifting for venture capitalist money. There is a significant body of work around AI (in)accuracy, both scientific papers and bloggers. For an example of what some people think about it, see e.g. https://softwarecrisis.dev/letters/llmentalist/ On top of this, AI bots are behind the world's largest DDoS attack on the entirety of the open web, with great emphasis on the "distributed" part of "distributed denial of service". Additionally, AI is incredibly damaging to the environment in precisely the same way that cryptocurrency mining is. Attempting to use AI to "bridge the communication gap" runs the risk of upsetting a subset of people who feel that you're insulting both their intelligence and their dayjob. The reasoning would be something like "this person thinks I'm not worth the effort of communicating with, and is instead helping destroy the planet in order to tell me information I already know". Of course, your mileage may vary. Plenty of people seem to like AI a lot. But personally, I'd ask, why risk it?
You seem to be under the impression that people haven't investigated the issue itself, though I'm not sure why you believe that. Note as well that @mati865 did NOT confirm your issue, only corrected Sam, who said:
by pointing out that a reference had been added within the LLVM repository that very day. No claim was made that "I have reproduced the bug report."
If you're accusing people of violating the LLVM Code of Conduct please communicate directly to the Code of Conduct committee. Note that this is a double-edged sword -- one could easily argue that language such as demanding people "actually do your job" is a Code of Conduct violation. Threatening and browbeating people over Code of Conduct accusations is also a potential Code of Conduct violation, depending on whether or not the accusation turns out to be accurate or at least qualifies for the subjective "reasonable person would feel cause for concern" threshold. I personally would say that e.g.
is not something that the average person would be worried is a Code of Conduct violation to the extent one would have to publicly announce a belief that it was in violation. As you've claimed:
I can only conclude that you believe it is a Code of Conduct violating level of "unprofessionalism" to make what you believe are "unreasonable demands" and then "blame" you for not having enough information to provide to merit further investigation. |
I should have been more elaborate on my part. I'm 90% sure I have somehow hit this issue but the details are lost to the time now. Probably my reproducer was so complicated I decided to only confirm this issue might come from LLVM's own code. |
Eli, this will be my last comment on our personal dispute. I've filed a Code of Conduct violation where I've presented my side of the story with the concerned committee. From your lengthy comment that I still consider to be hostile in tone, I can see that you show no signs of any wrongdoing on your or Sam's part. That is unacceptable in my opinion. This is not my first interaction with OSS developers, hence a "standard OSS interaction" looks different from my experience and already had the pleasure to work with many other engineers that were more understanding and forthcoming to me as a non-programmer. They could keep a professional tone despite some of my reported problems originated from user error. Yet they didn't make unreasonable demands or came up with false accusations that I found to be highly discouraging of future contributions. The adjusted script - even without the PGO-file that I use on my local machine (which can be easily deleted even under heavy time constraints by any developer willing to help within thirty seconds) should reproduce the problem. Yet I haven't seen any efforts of you or Sam trying to reproduce the issue with that provided script. Here is the adjusted script, I've tested it without the local PGO profile and it still reproduces the reported issue reliably. You need to run the setup-repo script (as linked above) first, though. |
|
Which version of clang and cmake are you using when running this script? |
I've tested Clang 19.1.7 (CachyOS default toolchain) and Clang-21git (7ef636e, built using my llvm-bolt-scripts), both of which reproduce this issue. Cmake: 3.31.5 (CachyOS default) |
|
I'm trying to build AOSP clang-r530567 on an aarch64 machine using tc-build, which is basically a set of scripts to build LLVM and binutils, and I encountered the same error. Environment details |
|
Ah I just noticed that the warnings appear to be for assembly files only. Are any C source files affected? I wonder if the problem is that cmake uses a different compiler for assembly sources here? I don't see CMAKE_ASM_COMPILER being overridden in the script above so it probably defaults to a different one? |
|
@arichardson I've provided that information in: #72413 (comment) in the part after I usually set As I don't know the differences under the hood between the ways ENABLE_PROJECTS and ENABLE_RUNTIMES build compiler-rt, this might be indeed another angle for further investigation. |
|
This is what Google Gemini 2.0 EXP (edited by me) has to say when analyzing the issue: The Problem: The issue stems from this line in append_list_if(COMPILER_RT_HAS_WBUILTIN_DECLARATION_MISMATCH_FLAG -Werror=builtin-declaration-mismatch BUILTIN_CFLAGS)This unconditionally adds This occurs specifically with The affected assembly files are:
Proposed Solution: The fix is to modify Here's the proposed change (assuming the builtins library target is named # ... (previous CMake code) ...
# Assuming your source files are in a variable called BUILTIN_SOURCES
foreach (SOURCE_FILE ${BUILTIN_SOURCES})
get_source_file_property(SOURCE_LANGUAGE ${SOURCE_FILE} LANGUAGE)
if (SOURCE_LANGUAGE STREQUAL "C" OR SOURCE_LANGUAGE STREQUAL "CXX")
# Apply the flag to the specific source file:
set_source_files_properties(${SOURCE_FILE} PROPERTIES COMPILE_FLAGS "-Werror=builtin-declaration-mismatch")
endif()
endforeach()
# ... (rest of the CMake code, including add_library) ...
add_library(clang_rt.builtins ${BUILTIN_SOURCES})
# ... (and you might still use BUILTIN_CFLAGS for other flags,
# but NOT for -Werror=builtin-declaration-mismatch) ...
target_compile_options(clang_rt.builtins PRIVATE ${BUILTIN_CFLAGS})Explanation:
Advantages of this approach:
I believe this solution addresses the root cause of the build failure while preserving the intended behavior of checking for builtin declaration mismatches in C/C++ code. Could you please review this analysis and proposed fix? I'm happy to provide a patch if this looks good. Thanks! |
|
@arichardson Good news, I've tested this AI proposed approach which gets rid of the warnings, just exchange line 786 to line 926 of Edit: It doesn't seem to be the correct fix according to Sam, I've also seen a huge compile time regression with it in subsequent builds. |
|
I've proposed a patch in: #125602 (comment) |
This comment has been minimized.
This comment has been minimized.
Compiling llvm-git with 0a0e06f leads to the following new warnings in compiler-rt:
CachyOS also ships with a brand new gcc-version 13.2.1 20231110.
The text was updated successfully, but these errors were encountered: