support llvm 17

[5c4lar]

No description provided.

[vtjnash]

That is quite a large diff. Is that all necessary, or are there formatting changes that can be separated?

[5c4lar]

That is quite a large diff. Is that all necessary, or are there formatting changes that can be separated?

Yeah, formatting changes can be separated, there are only few necessary changes.

[vtjnash]

That would be helpful then, as this is too big to open and will conflict with everyone's open work, so we probably do not want to merge any unnecessary format changes

[5c4lar]

That would be helpful then, as this is too big to open and will conflict with everyone's open work, so we probably do not want to merge any unnecessary format changes

Thanks for your reply, I format it with clang-format again and the diff is much smaller now.

[vtjnash]

Seems like more clang-format fixes are still needed?

[5c4lar]

Linux and windows tests are passed now. The macos tests failed due to the warnings introduced during compilation of some test cases. Maybe more flags should be introduced here.

[vtjnash]

Looks like it used to be disabled in the distant past:

llvm-cbe/tools/llvm-cbe/llvm-cbe.cpp

Lines 306 to 314 in 2ca604e

	// Disable .loc support for older OS X versions.
	if (TheTriple.isMacOSX() && TheTriple.isMacOSXVersionLT(10, 6)) {
	}
	// TODO: Find a replacement to this function
	/* Greg Simpson 6-09-13
	no member named setMCUseLoc
	removed statement
	Target.setMCUseLoc(false); */

I don't know what might be wrong about the current output:

llvm-cbe/lib/Target/CBackend/CBackend.cpp

Lines 3878 to 3880 in b1efd16

	Out << "#line " << Loc->getLine() << " \"" << Directory << Filename
	<< "\""
	<< "\n";

Do you think you could update the test so that it dumps the contents of the generated file to stderr if the test fails?

[5c4lar]

I dump the generated code for the failure case and play with it on my mac. It seems that the warning is introduced by -g option, and there is nothing wrong with llvm-cbe output.

To reproduce the warning, you can compile try compile the following simple example.

// /opt/homebrew/bin/gcc-13 -g -O1 test.c
#include <stdint.h>
struct l_array_10_uint32_t
{
    uint32_t array[10];
};

int main() {
  struct l_array_10_uint32_t example;
  int i;
  for (i = 0; i < 10; ++i) {
    example.array[i] = i;
  }
  return example.array[6];
}

I think it would be safe to remove the -g option and make the test pass.

Having the above warning fixed, there are still two warnings regarding uninitialized variables, which is introduced by phi node.

[5c4lar]

Having the above warning fixed, there are still two warnings regarding uninitialized variables, which is introduced by phi node.

Tests passed, the version of gcc is different in the github actions :)