androm3da wrote: > @androm3da my main concern with this change is that the header file changes > could introduce an ABI break which we do not want to do. To me it looks like > the header file changes just define additional macros on some versions of the > architecture that previously did not. Is that correct?
That is correct. Further: the macros are defining architecture-specific intrinsics. And in this case, the header file changes are making > And can you confirm that this is not introducing an ABI break? I ... don't think so. Is there even an ABI for architecture-specific intrinsics? But let me try and speculate on how things could go wrong here. A program being incorrectly built with the 22.1.0 clang via `--target hexagon-linux-musl -mv73 -mhvx` but leveraging IEEE FP opcodes via intrinsics would previously get compiled successfully. That same program again built with 22.1.3 clang via `--target hexagon-linux-musl -mv73 -mhvx` (incorrectly omitting `-mhvx-ieee-fp`) would get an error. I guess this is the kind of breakage you might be concerned about, but I see it not as ABI conformance/non-conformance but instead the compiler correctly diagnosing where it previously did not. Do we have a precedent for/against making the compiler stricter in a patch release? https://github.com/llvm/llvm-project/pull/185014 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
