[Bug target/58695] New: MSP430 zero-initialized array remains uninitialized with -nostartfiles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58695 Bug ID: 58695 Summary: MSP430 zero-initialized array remains uninitialized with -nostartfiles Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: quandary at remstate dot com Created attachment 30986 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30986&action=edit Should initialize a 16-byte array to all zeroes When initializing (non-constant) arrays with a list of constants, an all-zero array is left uninitialized when -nostartfiles is specified. Arrays with any non-zero elements are still initialized properly. At the assembly level, the difference in behavior seems to be that the compiler puts all-zero arrays into .bss, whereas the compiler puts arrays with non-zero elements into .data. I would suggest that in the case where -nostartfiles is specified, an explicit all-zero array should be placed into .data so that initialization/programming takes place per the programmer's intent. msp430-elf-gcc -v: Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/msp430-elf/gcc-bin//msp430-elf-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/msp430-elf//lto-wrapper Target: msp430-elf Configured with: /var/tmp/portage/cross-msp430-elf/gcc-/work/gcc-/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/msp430-elf/gcc-bin/ --includedir=/usr/lib/gcc/msp430-elf//include --datadir=/usr/share/gcc-data/msp430-elf/ --mandir=/usr/share/gcc-data/msp430-elf//man --infodir=/usr/share/gcc-data/msp430-elf//info --with-gxx-include-dir=/usr/lib/gcc/msp430-elf//include/g++-v --host=x86_64-pc-linux-gnu --target=msp430-elf --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --with-python-dir=/share/gcc-data/msp430-elf//python --enable-poison-system-directories --enable-checking=release --disable-libgcj --disable-build-with-cxx --disable-build-poststage1-with-cxx --disable-libquadmath --enable-languages=c --disable-shared --disable-libatomic --disable-threads --without-headers --disable-bootstrap --with-newlib --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo SVN' Thread model: single gcc version 20131011 (experimental) rev. 203465 (Gentoo SVN) Command line that triggers the bug: msp430-elf-gcc -save-temps -nostartfiles -o bug.elf zero_init.c
[Bug target/58695] MSP430 zero-initialized array remains uninitialized with -nostartfiles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58695 --- Comment #2 from Travis Snoozy --- (In reply to Andrew Pinski from comment #1) > I think you should do either -fno-zero-initialized-in-bss or even better use > a linker script which forces the bss to be allocated in memory. Thanks; I didn't know about -fno-zero-initialized-in-bss for now, and it neatly works around this problem for now. I don't see how the linker script can be the problem here -- perhaps I'm missing a point? Looking at my output, .bss and its variables *are* allocated in memory -- the symbol shows up, the space is blocked out for use. The problem is that an initialized value shouldn't be going into .bss in the first place, because .bss (by definition) *uninitialized* memory. Because I have -nostartfiles, the uninitialized memory is remaining uninitialized, instead of being cleared. Would it be possible to have -nostartfiles automatically imply -fno-zero-initialized-in-bss, because the former changes how .bss will effectively behave?
[Bug target/58716] New: [PATCH] MSP430X check is inverted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58716
Bug ID: 58716
Summary: [PATCH] MSP430X check is inverted
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: quandary at remstate dot com
CC: dj at redhat dot com, nickc at redhat dot com
Target: msp430-elf
Created attachment 30996
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30996&action=edit
Use !strcasecmp() to detect when a string is matched (instead of strcasecmp())
r203026 added a check for MSP430X arch MCUs based on a complete listing of
supported chips. If a chip is in the list, then the msp430x flag should be set.
The change uses strcasecmp() to accomplish the check, and this function returns
zero on success (match). The "if" statement checking the result of strcasecmp()
is expecting a non-zero value ("true") to trigger the branch.
Fix is to NOT strcasecmp's output. Trivial patch against trunk (head) attached.
Symptom was that code generated for the msp430g2412 chip (non-CPUX) contained
pushm. Verified that the attached patch resolves that issue.
