Unfortunately those two are linked together. C compilers produce insecure C code because the semantics of the C language limit the options that the C compiler has for generating secure code. You could make a C compiler that generated more secure code, but doing so would make it non-compatible with the C standard and would most likely break a large swath of programs that compile and run on the other non-secure compilers. Worse still it would still generate insecure code even if less of it because things like address aliasing, and being able to cast ints to pointers are fundamentally insecure.

For an idea of what it would take to make C actually secure (and even then only in so much as you reasonably can) take a look at all the things Rust has had to do. Nearly everything that exists in Rust is there because they started with a C feature and asked themselves "what do we need to change to make this safe/secure?". Most other languages as a minimal first step towards improving security remove direct access to pointers, they're simply too powerful to do securely in the manner C does. Rust has (mostly) secure pointers, but only after putting an insane amount of work into bolting a massively complicated ownership and lifetime tracking system on top of it, and even then it's still not perfectly secure since they had to include unsafe blocks to provide a trap door for certain edge cases (also for C interop).

So yes, you could make a secure C compiler, it just wouldn't compile C code anymore, it would compile some "safe" subset of C which would probably end up looking like either Rust or C# (or maybe ObjectiveC).