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
d 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
> cal
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 snip
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.
$ 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:20
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
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 8x
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
$ 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/
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
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
> &g
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 00
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 in
13 matches
Mail list logo
