I found an obnoxious bug in the C compiler. I would like to help the community by reporting it.

I don't have much familiarity with the CE toolchain or with github, so I don't know quite where to go to report the issue. I did come across a page on the LLVM site for reporting bugs, but to follow the procedure I saw there, apparently I would have to spend hours learning new tools that I've never heard of before. Um, no, after a long day debugging, I don't have time for that!

Is there another way? If I narrow down the bug so that I have source code of a small program that very obviously doesn't compile as it should, does anyone know of an easy way to report the issue?

(I'm including below some details of the compiler bug, in case anyone is curious.)

***

I am using clang version 14.0.0 (https://github.com/jacobly0/llvm-project a139def90d26173f771eb1eca797633d1fbb2797.

When my program runs the following code, it says "Made it through":


Code:


But if I comment out the second line, my program says "WHAT THE @$%&*?":


Code:


That obviously shouldn't be able to happen under any circumstances!

(Yes, index is a local uint8_t that equals 2 when it his this portion of code, and cycle is a pointer that points to a byte that's immediately after a 2. However, other portions of the code may somehow matter; I couldn't quickly duplicate this bug in a much smaller program. If there's a reasonably easy way for me to report this bug, then I will try to narrow it down.)

The general response to the question in the topic title is: just create an issue in the repo: https://github.com/jacobly0/llvm-project/issues
Be sure to provide a zip with the source code (as minimal as possible if you can) and the makefile you used or at least the full clang command line invocation.
Also, you can try the to use the very latest version of the code from that repo instead of the build from the latest CE toolchain release, which would be quite outdated now.

Now, if we're being specific to your case right now, it might not be wrong, just optimizing things out and avoiding UB - I haven't taken a deep look.

Thank you!

Are you sure it isn't just because you aren't using volatile. Pretty sure your code is wrong, not a compiler bug.

2 cents from general C experience:
- Have you checked the assembler code? It usually tells a much clearer story.
- What is cycle exactly and what does it point to?
- volatile shouldn't be an issue unless the values pointed to be cycle change asynchronously. But still have you tried to read cycle[-1] only once?
- There is no guarantee that uint8_t is a character type, so there's a slight chance that your access to cycle[-1] is breaking strict aliasing and getting optimized away by UB. A language lawyer might suggest unsigned char instead.

Hope it helps, debugging this kind of issues can be hard sometimes...

Cycle is an array of pointers-to-structs, which is immediately preceded in memory by a byte that's the array length. Index tracks a particular position in the cycle. The relevant code is supposed to move to the next element in the cycle, thusly:

#define QuantityOf(array) (*(((uint8_t*)(array))-1))

index++;
if (index == QuantityOf(cycle)) index = 0;

Hmm, so maybe the compiler is neglecting the (uint8_t*) typecast and so the -1 is actually subtracting three (because pointer arithmetic in C). Either that or it's optimizing out relevant code entirely. The "QuantityOf" macro does work as expected in nearly 100 other places in my code. Switching to unsigned char did not help.

Okay, so as of now, my production code is:
void List_IncrementIndexWrappingAround(List this, int* index)
{
(*index)++;
if (*index == QuantityOf(this)) *index = 0;
else ReturnFalse(); // As of 3/26/22 this line, which does nothing, must be included!
}

(I note that replacing "ReturnFalse()" with something like "index = index" that the compiler can optimize away causes the code to fail again.)

My plan is:
1. Take a break from this obnoxious issue.
2. Check whether a more recent version of the compiler fixes the issue.
3. Compare the assembler code generated with and without the "else" statement. I don't much care _what_ the compiler is doing wrong, but once I learn to identify _whether_ the compiler has done something wrong, I can more effectively:
4. Reduce the mistake-containing program to the minimum possible size.
5. Report the error.

Or just give me code and I can auto reduce it...

Provide a zip of your currently broken program, source, makefile, and all. That's what the documentation literally tells you to do - or you can keep wasting time

Oh, you guys are great! Well, reducing the program turned out to be trivial once I had a good night's sleep and a better attitude.

Here's my new problem:
I have a zip with a reduced program, complete with all the .exe files needed to build and run it under Windows 7.
I go to https://github.com/jacobly0/llvm-project/issues/new
I click where it says "Attach files by..." and I open the zip, or maybe instead I drag the zip there.
Either way, the place that says "Attach files by..." changes to say in red letters:
"is not included in the list"

Nothing else. Thank you Github for such a helpful error message.

*sigh* I'm such a newbie. So, what do I need to do? Do I need to remove the .exe files from the zip or something?

You should be able to drag n drop the zip file directly into the text field where you type the issue description. It'll take a little while during the upload the transform into the appropriate markdown (format) for an internal link to your zip file, that we can access.

Trust me, you didn't actually "reduce" the program lol - making it smaller and less code is not "reduction". Provide a zip somewhere on the internet where we can access it - but you can just drag/drop the zip onto the comment box in the GitHub issue you create and it will automatically handle everything for you.

I still get the same error drag/dropping the zip even when I clear the Firefox cache for Github or I try Chrome.

Let me know if this link works for you:
(Removed by admin for ROM image)

First of all it don't distribute roms as it is illegal and therefore against the rules of this forum. Also, none of the toolchain developers use windows so use a cross platform project format such as this if you want help.

Yikes! I forgot that an obviously-illegal-to-distribute file was in there. It's gone now.

Since those Windows .exe files were no use, let me mention verbally that I found the error using
clang version 14.0.0 (https://github.com/jacobly0/llvm-project a139def90d26173f771eb1eca797633d1fbb2797) and fasmg version g.jdp2. I assume the cemu and rom versions don't matter.

Yeah the bug is reproducible and hopefully there will be a fix soon

Great, thanks!

Thanks for the bug report, the compiler confused itself about the comparison and managed to convince itself that it was actually compiling *index == 0 which caused it to promptly attempt to use the flags from the increment instead of comparing the two values.

was this actually a bug in clang, or something specific to your z80 codegen?

Ah, I see. Thank you so much for the quick turnaround! It's a big relief knowing that this particular issue won't pop up again if someday I happen to write similar code.

Oh, incidentally, I just noticed in my code this line:

Print(va_arg(additionalParameters, Byte) != 0 ? "yes" : "no"); // The compiler crashes if it encounters va_arg(additionalParameters, bool).

Apparently that issue was so easy to identify and work around that it didn't occur to me to report it.