Here are the answers (to the best of my knowledge) to the questions you raised.

“Let’s say you perform a series of additions on unsigned integers. Does the compiler zero out the guard bits after every operation, or does it simply wait until the end of the series and then perform the mask?”
This particular compiler (for Cirrus Logic DSP) performs the mask only in two places: before doing comparison and before shifting right. If I’m not mistaking, those are the only places where it is important. Of course, memory load/store instructions that do not perform saturation just ignore the guard part, so no problem there, and the same thing is happening when performing multiplication, etc.
So, I believe that in a way it is different, i.e. simpler, than the case when you have, e.g. 16 bit arithmetic hardware, but you are using 8 bit data type. The case in DSP is that, for example, you use 16 bit data type, your hardware supports 16 bit arithmetic, but your register has additional special purpose bits on the left.

“What happens if you do the same thing with signed integers?”
With sign integers nothing is done with the guard bits. Since signed overflow is undefined in C standard, DSP hardware and compiler define it in a way that it produces the best code. But, it is not explained too much in the manual of the DSP I’m currently working with, rather they took a position that “overflow is bad” and programmer should avoid it.

“Also if you actually get an overflow with signed integers, do you get the ‘expected’ result, or do you get garbage?”
If by “expected” you mean “always the same”, or “determinable”, result, than you do get “expected” result But it is definitely different that what you would get if overflow is handled as wrap around. I call the behavior “extended wrap around” or “delayed wrap around” because wrap around does happen but only after guard part is filled up.

Here is another interesting thing.
Luís Fernando says:
“My ideal solution would be leaving unsigned overflow unspecified and adding a modular modifier. Or you could add a type attribute to the compiler.”
The DSP compiler I’m working with supports C language extension called “C – Extensions to support embedded processors” (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf). It targets mostly DSP related issues. The main thing the extension introduced are fixed-point types. When defining fixed-point types overflow behavior they did something similar to what Luís Fernando proposed. If type has “sat” word (e.g. “sat fract”) then saturation has to happen on overflow, otherwise the behavior is undefined, that is, it should be done in the most efficient manner on the target processor. There is also a pragma that can force saturation on all fixed-point types. Similar thing might be done for signed integers.

I come from DSP embedded world, which is slightly different than what is in focus here, but I must say that all the tips (13 so far) apply to that domain as well — except this one

The reason why signed int is producing better code in DSP processors is explained well in comments of Luís Fernando Schultz Xavier da Silveira. He was considering the case when size of type is less than size of register (supported arithmetic), e.g. 8 bit int in 16 bit register. Well, this is the case practically all the time in DSP. The fact is that accumulator registers in DSPs almost always have some kind of guard bits, which are to catch overflow and subsequently perform saturation. Therefore for unsigned integers guard bits must be zeroed by compiler either before every comparison, or after every add/sub and shift left operations.

However, in your example with index boundary check, I think the second code would still be better in most of the cases, because one comparison and bits zeroing beats two comparisons
(Just tried with, not commonly used, Cirrus Logic DSP and the result is 4 against 5 instructions for second version)
On the other hand, in case of, for example, a simple comparison unsigned integers will introduce two extra instructions (one guard zeroing for every operand).

Anyhow, I just wanted to share my experience regarding this tip, because, as I said, all other tips perfectly apply to DSP world as well.

\ 0000000A 01D1 BNE.N ??f_0
\ 0000000C 0120 MOVS R0,#+1
\ 0000000E 7047 BX LR
\ ??f_0:
\ 00000010 0020 MOVS R0,#+0
\ 00000012 7047 BX LR ;; return

could be replaced by

MOVEQ R0, 1
MOVNE R0, 0
BX R14

for a faster and smaller executable, no?

Just to clarify something, I share your view on how to use unsigned and signed types. My ideal solution would be leaving unsigned overflow unspecified and adding a modular modifier. Or you could add a type attribute to the compiler. My current solution is using different types when declaring variables that should go on registers (u8_reg_t), which is a pain.

I also have searched a lot for an answer, but found nothing, not even a concern about the problem.

By the way, is optimization turned on? I don’t see why the use of predicated opcodes was abandoned in favor of plain branching.

Well, I still believe there is a fundamental problem with C providing signed types without overflow semantics but not doing the same with unsigned types. Maybe there should be signed, unsigned and modular types. However, since other languages (such as ada) do the same, maybe I am wrong, but I can’t grasp why.