"gcc -o hello helloworld.c", creates an x86_64 elf file on my x86_64 system as expected however, "setarch i386 gcc -o hello helloworld.c" also creates an x86_64 elf file instead of an i386 one, to get an i386 one I must do: "gcc -m32 -o hello helloworld.c". This is unfortunate, because even though rpmbuild adds -m32 to the *FLAGS environment variables compiling i386 packages on an x86_64 system still doesn't work for many packages, because they for example often ignore LDFLAGS, thus not specifying -m32 when linking, causing things to fail. This is one of the last problems building i386 binaries on an x86_64 system and should really be fixed now that most of the work has already been done by making x86_64 and i386 -devel packages parallel installable. A work around is to create shell script wrappers for gcc, g++ and ld which always add -m32, put these somewhere outside the standard $PATH and add the location to PATH when you want to build i386 binaries.
That's intentional, you really should use proper CFLAGS and LDFLAGS. Basing -m32/-m64 default based on environment would be very confusing e.g. when reporting bugs, would make reproducibility more difficult. Propagating $RPM_OPT_FLAGS down to all C*FLAGS is desirable for many other reasons, e.g. buffer overflow protection etc.
I already was afraid this was going to get closed in this way and I understand, however fixing all circa 3000 packages in FE + FC for this is not really doable. Well I guess I'll just keep using the shell wrappers in dir not normally in PATH and add dir to PATH when building i386 binaries approach then.
It is doable and very much desirable, we really shouldn't be unintentionally shipping programs built without -D_FORTIFY_SOURCE=2, -fstack-protector etc. I'm not aware of anything in FC that doesn't honor these unless it has a reason for it (e.g. in glibc and gcc itself), if you know about anything, feel free to file a bugreport.
The problem isn't as much in CFLAGS as it is in LDFLAGS, I maintain 80 packages in FE and where nescesarry have patched them to honor RPM_OPT_FLAGS during the compile fase, but I've been doing some experimenting with building i386 only packages (lots of asm bah) on x86_64 and on many cases LDFLAGS doesn't get properly propegated. I fully agree with you that RPM_OPT_FLAGS should always be used.