arm-elf-gcc 4.0.3: ICE when compiling crtstuff.c
Compiling crtstuff.c with arm-elf-gcc 4.0.3 for -mthumb -fPIC -msingle-pic-base fails. I had no trouble compiling GCC 4.1.1. Cheers, Shaun make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make GCC_FOR_TARGET="/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc -B/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/ -B/usr/local/arm-elf/bin/ -B/usr/local/arm-elf/lib/ -isystem /usr/local/arm-elf/include -isystem /usr/local/arm-elf/sys-include" \ AR_FOR_TARGET="arm-elf-ar" \ AR_CREATE_FOR_TARGET="arm-elf-ar rc" \ AR_EXTRACT_FOR_TARGET="arm-elf-ar x" \ AR_FLAGS_FOR_TARGET="" \ CC="gcc" CFLAGS="-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition " \ BUILD_PREFIX="" \ BUILD_PREFIX_1="loser-" \ LANGUAGES="" \ LIBGCC2_CFLAGS="-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -mthumb -fPIC -msingle-pic-base " \ MULTILIB_CFLAGS=" -mthumb -fPIC -msingle-pic-base" T=thumb/pic/xip/ thumb/pic/xip/crtbegin.o thumb/pic/xip/crtend.o thumb/pic/xip/crti.o thumb/pic/xip/crtn.o make[3]: Entering directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' /home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc -B/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/ -B/usr/local/arm-elf/bin/ -B/usr/local/arm-elf/lib/-isystem /usr/local/arm-elf/include -isystem /usr/local/arm-elf/sys-include -O2-DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -Ithumb/pic/xip -I../../gcc -I../../gcc/thumb/pic/xip -I../../gcc/../include -I../../gcc/../libcpp/include -mthumb -fPIC -msingle-pic-base -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time \ -Dinhibit_libc -c ../../gcc/crtstuff.c -DCRT_BEGIN \ -o thumb/pic/xip/crtbegin.o ../../gcc/crtstuff.c: In function 'frame_dummy': ../../gcc/crtstuff.c:325: internal compiler error: in thumb_find_work_register,at config/arm/arm.c:3140 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [thumb/pic/xip/crtbegin.o] Error 1 make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make[2]: *** [extrathumb_pic_xip] Error 2 make[2]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make: *** [all-gcc] Error 2
Re: arm-elf-nm --print-size fails on static variables
2005/11/3, Daniel Jacobowitz <[EMAIL PROTECTED]>: > On Thu, Nov 03, 2005 at 02:15:27PM -0700, Shaun Jackman wrote: > > When an object file is compiled by arm-elf-gcc 4.0.2, nm -S 2.16.* > > isn't printing the size of static variables. I'd very much appreciate > > a fix or workaround, if one is out there. > > Check what the file really says, using readelf. If the sizes are > unset, check a CVS version of GCC or report the bug to GCC's bugzilla. > That's more likely than an nm bug. It certainly appears to be a GCC bug. Cheers, Shaun $ cat foo.c int foo; static int static_foo; $ arm-elf-gcc -c foo.c $ arm-elf-readelf -s foo.o | grep foo 1: 0 FILELOCAL DEFAULT ABS foo.c 6: 0 NOTYPE LOCAL DEFAULT3 static_foo 8: 0004 4 OBJECT GLOBAL DEFAULT COM foo $ gcc -c foo.c $ readelf -s foo.o | grep foo 1: 0 FILELOCAL DEFAULT ABS foo.c 5: 4 OBJECT LOCAL DEFAULT3 static_foo 8: 0004 4 OBJECT GLOBAL DEFAULT COM foo $ arm-elf-gcc --version | head -1 arm-elf-gcc (GCC) 4.0.2 $ arm-elf-readelf --version | head -1 GNU readelf 2.16.91 20051103 $ gcc --version | head -1 gcc (GCC) 4.0.2 (Debian 4.0.2-2) $ readelf --version | head -1 GNU readelf 2.16.1-multiarch Debian GNU/Linux
r122342 ICE tree check at tree-cfg.c:2042
$ avr-gcc -mmcu=atmega64 -g -O2 -Wall -Wextra -Werror -Os -I.. -I. -MMD -DBOOTLOADER -DF_CPU=1600 -c -o fs.o ../fs.c ../fs.c: In function 'fs_exec': ../fs.c:35: internal compiler error: tree check: expected class 'expression', have 'constant' (integer_cst) in find_taken_edge, at tree-cfg.c:2042 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. $ avr-gcc --version |head -1 avr-gcc (GCC) 4.3.0 20070226 (experimental) Thanks, Shaun fs.i Description: Binary data
Re: r122342 ICE tree check at tree-cfg.c:2042
On 2/27/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: On 2/27/07, Shaun Jackman <[EMAIL PROTECTED]> wrote: > $ avr-gcc -mmcu=atmega64 -g -O2 -Wall -Wextra -Werror -Os -I.. -I. I submitted http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984 for this bug. It is a generic issue. Thanks, Andrew! I'd like to know the revision where this bug was created, if someone happens to discover it. Cheers, Shaun
libgloss psignal declaration [PATCH]
I found the following patch necessary to build libiberty with newlib
headers. Although, glibc seems to use the same signature now.
Cheers,
Shaun
2005-10-26 Shaun Jackman <[EMAIL PROTECTED]>
* libiberty/strsignal.c (psignal): Change the signo parameter from
unsigned to int, and message from char * to const char*.
Index: libiberty/strsignal.c
===
RCS file: /cvs/src/src/libiberty/strsignal.c,v
retrieving revision 1.9
diff -u -r1.9 strsignal.c
--- libiberty/strsignal.c 28 Mar 2005 02:09:01 - 1.9
+++ libiberty/strsignal.c 26 Oct 2005 21:56:29 -
@@ -549,7 +549,7 @@
#ifndef HAVE_PSIGNAL
void
-psignal (unsigned signo, char *message)
+psignal (int signo, const char *message)
{
if (signal_names == NULL)
{
arm-elf-nm --print-size fails on static variables
When an object file is compiled by arm-elf-gcc 4.0.2, nm -S 2.16.* isn't printing the size of static variables. I'd very much appreciate a fix or workaround, if one is out there. Thanks, Shaun $ cat foo.c int foo; static int static_foo; $ arm-elf-gcc -c foo.c $ arm-elf-nm -S foo.o 0004 0004 C foo b static_foo $ nm -S foo.o 0004 0004 C foo b static_foo $ gcc -c foo.c $ nm -S foo.o 0004 0004 C foo 0004 b static_foo $ arm-elf-gcc --version | head -1 arm-elf-gcc (GCC) 4.0.2 $ arm-elf-nm --version | head -1 GNU nm 2.16.91 20051103 $ gcc --version | head -1 gcc (GCC) 4.0.2 (Debian 4.0.2-2) $ nm --version | head -1 GNU nm 2.16.1-multiarch Debian GNU/Linux
AVR function inlining cutoff
With GCC r130284 --target=avr, a 116 byte static function that is called twice is inlined even with -Os, effectively doubling the function's footprint. I'd argue a function this large shouldn't even be inlined with -O2. What is the size cutoff for inlining functions? Can I modify it? If a code snippet would help troubleshoot this matter, I can certainly send one along. Cheers, Shaun
Re: AVR function inlining cutoff
Answering my own question: The `-finline-limit=N' option allows you to adjust the inline threshold. The documentation says the default is 600. A value of <= 35 ensured that my 116 byte function was not inlined, which suggests that a more reasonable default value on the AVR might be around 20. I still want functions that are only called once to always be inlined. How does the -finline-limit option affect this case? Cheers, Shaun On Nov 22, 2007 1:28 PM, Shaun Jackman <[EMAIL PROTECTED]> wrote: > With GCC r130284 --target=avr, a 116 byte static function that is > called twice is inlined even with -Os, effectively doubling the > function's footprint. I'd argue a function this large shouldn't even > be inlined with -O2. What is the size cutoff for inlining functions? > Can I modify it? If a code snippet would help troubleshoot this > matter, I can certainly send one along. > > Cheers, > Shaun
GCC feature request: attribute((noreturn)) on asm
I want to declare that the following function does not return, but GCC
complains.
__attribute__((noreturn))
void exec_application(void)
{
asm("rcall application");
}
bootloader.c: In function 'exec_application':
bootloader.c:154: error: 'noreturn' function does return
Is there any way to hint that we're never coming back from the asm instruction?
Cheers,
Shaun
gcj: ICE on gcj -c seda.jar
$ gcj -c /usr/share/java/seda.jar
seda/sandStorm/internal/AggTPSThreadManager.java: In class
'seda.sandStorm.internal.AggTPSThreadManager$governorThread':
seda/sandStorm/internal/AggTPSThreadManager.java: In method
'seda.sandStorm.internal.AggTPSThreadManager$governorThread.run()':
seda/sandStorm/internal/AggTPSThreadManager.java:328: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
The line the compiler mentions is...
$ cat -n ./seda/src/seda/sandStorm/internal/ATTIC/AggTPSThreadManager.java
...
25 package seda.sandStorm.internal;
...
44 class AggTPSThreadManager implements ThreadManagerIF, sandStormConst {
45
46 private static final boolean DEBUG = true;
47 private static final boolean DEBUG_VERBOSE = false;
...
327 public void run() {
328 if (DEBUG) System.err.println("AggTPSTM Governor: starting");
329
...
$ gcj --version |head -1
gcj (GCC) 4.1.2 20061020 (prerelease) (Debian 4.1.1-17)
The binary and source files in question may be downloaded from a Debian archive:
http://packages.debian.org/testing/libs/libseda-java
Cheers,
Shaun
Re: gcj: ICE on gcj -c seda.jar
On 12/4/06, Andrew Haley <[EMAIL PROTECTED]> wrote: Thanks. This is caused because seda.sandStorm.internal.AggTPSThreadManager$governorThread is in the file seda/sandStorm/internal/ATTIC/AggTPSThreadManager$governorThread.class (In other words, it's not where gcj expects to find it.) This is a bug in gcj. We probably shouldn't even attempt to generate code when a class is not in the right place in an archive, and exit with a compiler error. zip -d usr/share/java/seda.jar seda/sandStorm/internal/ATTIC/\* solves the problem. Thanks, Andrew. I thought that ATTIC directory looked a little suspicious. Cheers, Shaun
Bizarre inlining type promotion effect
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
mul_16_8, each call generates three `mul' instructions! Why does
inlining mul_8_8 cause each 8x8 multiplication to be promoted to a
16x16 multiplication?
It seems that the inlining mechanism has a real bug if inlining can
cause such a major change in the code generated for a given function.
Cheers,
Shaun
$ avr-gcc --version |head -1
avr-gcc (GCC) 4.1.0
$ cat mul.c
#include
static uint16_t mul_8_8(uint8_t a, uint8_t b)
{
return a * b;
}
uint32_t mul_16_8(uint16_t a, uint8_t b)
{
uint8_t a0 = a, a1 = a >> 8;
return ((uint32_t)mul_8_8(a1, b) << 8) + mul_8_8(a0, b);
}
$ avr-gcc -c -g -O2 -mmcu=avr4 mul.c
$ avr-objdump -d mul.o
mul.o: file format elf32-avr
Disassembly of section .text:
:
0:86 9f mul r24, r22
2:c0 01 movwr24, r0
4:11 24 eor r1, r1
6:08 95 ret
0008 :
8:bf 92 pushr11
a:cf 92 pushr12
c:df 92 pushr13
e:ef 92 pushr14
10:ff 92 pushr15
12:0f 93 pushr16
14:1f 93 pushr17
16:6c 01 movwr12, r24
18:b6 2e mov r11, r22
1a:8d 2d mov r24, r13
1c:99 27 eor r25, r25
1e:f0 df rcall .-32; 0x0
20:7c 01 movwr14, r24
22:00 27 eor r16, r16
24:11 27 eor r17, r17
26:10 2f mov r17, r16
28:0f 2d mov r16, r15
2a:fe 2c mov r15, r14
2c:ee 24 eor r14, r14
2e:6b 2d mov r22, r11
30:8c 2d mov r24, r12
32:e6 df rcall .-52; 0x0
34:aa 27 eor r26, r26
36:bb 27 eor r27, r27
38:e8 0e add r14, r24
3a:f9 1e adc r15, r25
3c:0a 1f adc r16, r26
3e:1b 1f adc r17, r27
40:c8 01 movwr24, r16
42:b7 01 movwr22, r14
44:1f 91 pop r17
46:0f 91 pop r16
48:ff 90 pop r15
4a:ef 90 pop r14
4c:df 90 pop r13
4e:cf 90 pop r12
50:bf 90 pop r11
52:08 95 ret
$ sed -i 's/static/& inline/' mul.c
$ avr-gcc -c -g -O2 -mmcu=avr4 mul.c
$ avr-objdump -d mul.o
mul.o: file format elf32-avr
Disassembly of section .text:
:
0:ac 01 movwr20, r24
2:26 2f mov r18, r22
4:33 27 eor r19, r19
6:89 2f mov r24, r25
8:99 27 eor r25, r25
a:82 9f mul r24, r18
c:b0 01 movwr22, r0
e:83 9f mul r24, r19
10:70 0d add r23, r0
12:92 9f mul r25, r18
14:70 0d add r23, r0
16:11 24 eor r1, r1
18:88 27 eor r24, r24
1a:99 27 eor r25, r25
1c:98 2f mov r25, r24
1e:87 2f mov r24, r23
20:76 2f mov r23, r22
22:66 27 eor r22, r22
24:55 27 eor r21, r21
26:f9 01 movwr30, r18
28:e4 9f mul r30, r20
2a:90 01 movwr18, r0
2c:e5 9f mul r30, r21
2e:30 0d add r19, r0
30:f4 9f mul r31, r20
32:30 0d add r19, r0
34:11 24 eor r1, r1
36:44 27 eor r20, r20
38:55 27 eor r21, r21
3a:62 0f add r22, r18
3c:73 1f adc r23, r19
3e:84 1f adc r24, r20
40:95 1f adc r25, r21
42:08 95 ret
Re: Bizarre inlining type promotion effect
On 12/4/06, Shaun Jackman <[EMAIL PROTECTED]> wrote: In the code snippet below, the function mul_8_8 compiles to use exactly one `mul' instruction on the AVR. The function mul_16_8 calls mul_8_8 twice. If mul_8_8 is a static inline function and inlined in ... For comparison, a hand-coded 16x8 multiply function requires 11 instructions. Cheers, Shaun mul_16_8: mul r25, r22 mov r23, r0 mov r25, r1 mul r24, r22 eor r24, r24 mov r22, r0 add r23, r1 adc r24, r25 eor r25, r25 eor r1, r1 ret
