Reenable `-Wall`

[fenhl]

This issue tracks the revert of #2489, which in turn reverted #2474. The reason for the original revert was to fix #2486, but @rrealmuto has investigated that bug and has some ideas for how to fix it properly, which would allow us to upgrade the C toolchain and reintroduce the additional lints. We want to delay this until after the upcoming release, though, to give it more time on Dev to find anything else that might be broken by the toolchain upgrade.

[fenhl]

Note to self: try the ideas posted at https://discord.com/channels/274180765816848384/442752285312024606/1441491874090320003 (private channel) after 9.0 is released

[mracsys]

The scarecrow song problem in #2486 happens due to failing to save the destination address prior to copying from the song buffer to save context. The store_scarecrow_fix C function overwrites the a0 register value depending on compiler optimizations (both with and without -Wall).

From decomp, this call is replaced by an ASM hook to save_scarecrow_song
https://github.com/zeldaret/oot/blob/eb5dac74d6435baf85ced9158d3ff915ba8872ca/src/code/z_message.c#L3744-L3745

MemCpy(gSaveContext.save.info.scarecrowSpawnSong, gScarecrowSpawnSongPtr,
                           sizeof(gSaveContext.save.info.scarecrowSpawnSong));

save_scarecrow_song source for reference:

OoT-Randomizer/ASM/src/scarecrow.asm

Lines 22 to 49 in d0b31d9

	save_scarecrow_song:
	; 80057030
	; A0 = Scarecrow Song save address (copy to)
	; A1 = Scarecrow Song live location (copy from)
	; A2 = 0x80
	addiu sp, sp, -0x18
	sw a1, 0x0(sp)
	sw a2, 0x4(sp)
	sw a3, 0x8(sp)
	sw ra, 0x10(sp)
	lb t0, 0x0000(a1)
	addiu t1, t0, 1
	bne t1, zero, @@copy_song ; if scarecrow song doesn't begin with a rest, copy it to the save data
	nop
	or a0, zero, a1
	addiu a1, a1, 8
	jal 0x57030 ; shift scarecrow song over by 1 note
	addiu a2, a2, -8
	@@copy_song:
	jal store_scarecrow_fix
	nop
	lw ra, 0x10(sp)
	lw a3, 0x8(sp)
	lw a2, 0x4(sp)
	lw a1, 0x0(sp)
	j 0x57030
	addiu sp,sp,0x18

save_scarecrow_song saves a1 through a3 prior to calling MemCpy (j 0x57030, VROM address), instead of a0 through a2. On v9.0 encryption branch, the store_scarecrow_fix function call inserted before going back to MemCpy overwrites a0 in the second instruction:

On v9.0 normal branch, the function does not touch a0, and as a result the problem does not manifest on non-race seeds:

Enabling -Wall happened to cause the compiler to use the first register layout leading to the problem. Minimum fix for the problem is to save/restore a0 in save_scarecrow_song. @GSKirox has a better fix converting the entire hack to C at https://github.com/GSKirox/OoT-Randomizer/tree/scarecrow_c_rewrite.

[mracsys]

Also, some useful RAM addresses for watches:

0x801029FC - sOcarinaSongNotes[OCARINA_SONG_SCARECROW_SPAWN]
0x80102B80 - sScarecrowsLongSongNotes
0x8011B896 - gSaveContext.save.info.scarecrowSpawnSong

These should never be touched, but just in case:
0x80102EE0 - gScarecrowLongSongPtr = 0x80102B80
0x80102EE4 - gScarecrowSpawnSongPtr = 0x801029FC