(cc'ing gcc@gcc.gnu.org)
On Nov 21, 2007 2:38 AM, Wouter van Gulik [EMAIL PROTECTED] wrote:
Also consider the fuse bit get routine. This scheme gives more knowledge
to the compiler, unfortunately gcc fails to see the loading of r31 can
done once:
using this:
Is it possible to disable the heuristic inline function logic? I would
like to select the following behaviour:
* all static inline functions are always inlined
* all static functions that are called once are inlined
(-finline-functions-called-once)
* no other functions are inlined
I'm using -Os
Is there a switch to never inline a non-static function?
Thanks,
Shaun
On Dec 19, 2007 6:25 PM, Shaun Jackman [EMAIL PROTECTED] wrote:
Is it possible to disable the heuristic inline function logic? I would
like to select the following behaviour:
* all static inline functions are always
2008/12/1 K.J. Kuan-Jau Lin(林寬釗) [EMAIL PROTECTED]:
Hi Shaun,
I have trouble in uClinux world.
After long and painful debugging, i found it is due to the R_ARM_GOTOFF32
relocation type.
By google, i found you got the same problem before.
GCC reports an error for this snippet:
int main()
{
foo:
int x;
}
foo.c:4: error: expected expression before 'int'
... but not this snippet:
int main()
{
foo:
(void)0;
int x;
}
Is this expected behaviour? At the very least, it seems like an
unusual distinction.
Please
What optimisation option is needed to prod arm-elf-gcc -mthumb to
generate a tail call? ARM works as expected.
Please cc me in your reply. Thanks!
Shaun
arm-elf-gcc (GCC) 4.1.0
$ cat EOF tail.c
int tail(void);
int main()
{
return tail();
}
EOF
$ arm-elf-gcc -mthumb -S -O2 tail.c
$ sed
The default -mpic-register (on ARM/Thumb) is r10. In -mthumb mode, r10
is not available to the math instructions as a direct argument. On top
of that, preserving r10 complicates the function prologue. Does it
make more sense to use a directly accessible register, r7 for example,
as the default
On 6/26/06, Richard Earnshaw [EMAIL PROTECTED] wrote:
As of gcc-4.2 it isn't fixed, it's just like any other pseudo generated
by the compiler.
Glad to hear it!
Thanks,
Shaun
After I've modified the MULTILIB options in t-arm-elf, what's the
fastest way to test the new configuration without rebuilding the
entire toolchain? Right now the best method I have is `make clean-gcc
all-gcc', which is admittedly quite slow.
Please cc me in your reply. Thanks!
Shaun
On 26 Jun 2006 14:04:36 -0700, Ian Lance Taylor [EMAIL PROTECTED]
The usual hacked up way is to MULTILIB_EXCEPTIONS to remove
-msingle-pic-base without -fPIC. Something like
MULTILIB_EXCEPTIONS = -msingle-pic-base
might do it.
I tried your suggestion, but it didn't seem to have the desired
On 26 Jun 2006 14:42:20 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
No, that wouldn't work. MULTILIB_EXCEPTIONS takes a shell glob
pattern. It is invoked for each option set which is going to be
generated. I would expect that one of the option sets would be simply
-msingle-pic-base. So
On 6/26/06, Shaun Jackman [EMAIL PROTECTED] wrote:
Reading through gcc/genmultilib, it looks as though
MULTILIB_EXCLUSIONS can take a '!' parameter, but MULTILIB_EXCEPTIONS
cannot.
The solutions was to use MULTILIB_EXCLUSIONS!
MULTILIB_EXCLUSIONS += !fPIC/msingle-pic-base
Yeeha!
Cheers
On 6/26/06, Shaun Jackman [EMAIL PROTECTED] wrote:
After I've modified the MULTILIB options in t-arm-elf, what's the
fastest way to test the new configuration without rebuilding the
entire toolchain? Right now the best method I have is `make clean-gcc
all-gcc', which is admittedly quite slow
I'm attempting to build an XIP Hello, world! application for the ARM
processor. I'm compiling with -fPIC -msingle-pic-base with the default
-mpic-register=r10. The layout of the memory map is such that the
.text and .rodata are in flash memory, and the .got, .data and so
forth are loaded into
On 6/27/06, Erwin Authried [EMAIL PROTECTED] wrote:
Hi,
which compiler/binutil version did you use? Could you post the source
that you used?
One other thing (although that doesn't seem to have to do with your
problem): It is important that you use -fpic (not -fPIC) so that the
correct multilib
On 6/27/06, Shaun Jackman [EMAIL PROTECTED] wrote:
I'm attempting to build an XIP Hello, world! application for the ARM
processor. I'm compiling with -fPIC -msingle-pic-base with the default
-mpic-register=r10. The layout of the memory map is such that the
.text and .rodata are in flash memory
On 6/27/06, David McCullough [EMAIL PROTECTED] wrote:
Are you using the ld-elf2flt/elf2flt.ld combo ?
It lays things out in a known way and has a '-move-rodata' option which
will put the rodata in with the .text if it contains no relocation info
needed at runtime.
Something like this on the
On 6/27/06, David McCullough [EMAIL PROTECTED] wrote:
AFAIK, you need to drop the -FPIC in favour of -fpic everywhere.
From the GCC manual, -fpic vs. -fPIC `makes a difference on the m68k,
PowerPC and SPARC.' For my purposes, it makes no difference on the
ARM.
You could try some
On 6/28/06, Shaun Jackman [EMAIL PROTECTED] wrote:
I have experimented with GCC 4.0.3, 4.1.0, and 4.1.1. I found that
4.1.x behave the same; however, GCC 4.0.3 does not emit GOTOFF32
relocations. Apparently these are a new feature and preferable in some
instances since they do reduce the number
Hello Richard, Dan,
I'm trying to track down which part of the GCC source tree makes the
decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation.
A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a
reference to a static function. I thought there was a good chance one
of
On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
GOTOFF support has been there for a long while. Only use of it for
static functions is recent. It should be easy to find. But this is
not at all the only problem. GCC's PIC model assumes a fixed
displacement between segments.
Even if a
On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote:
I'm not terribly familiar with the GCC source tree. I scanned
config/arm/arm.c and its SVN log for changes that might affect
GOTOFF32, but came up empty. Do you know where
On 6/29/06, Richard Earnshaw [EMAIL PROTECTED] wrote:
No, it was PhilB, but it must have been two or three years ago now.
Thanks, Richard. I suspect svn r71881 is responsible. I'll start
testing and hopefully put a patch together. I would suspect r49871,
but this patch is in 4.0.3, which
-29 Shaun Jackman [EMAIL PROTECTED]
* config/arm/arm.c (local_symbol_p): New function.
(legitimize_pic_address, arm_assemble_integer): Use it to prevent
GOTOFF relocations to the .text segment in execute-in-place code.
Index: config/arm/arm.c
Any comments on this patch? This patch, or something like it, is
absolutely necessary to support execute-in-place (XIP) on uClinux.
Please cc me in your reply. Cheers,
Shaun
On 6/29/06, Shaun Jackman [EMAIL PROTECTED] wrote:
This patch forces the use of GOT relocations instead of GOTOFF when
Is it possible to disable the heuristic inline function logic? I would
like the following behaviour:
* static inline functions are always inlined
* non-static functions are never inlined
* static functions that are called once are inlined
* static functions that are called more than once are not
2009/11/18 Shaun Jackman sjack...@gmail.com:
Is it possible to disable the heuristic inline function logic? I would
like the following behaviour:
* static inline functions are always inlined
* non-static functions are never inlined
* static functions that are called once are inlined
When assigning a bool to a single bit of a bitfield located in the
bit-addressable region of memory, better code is produced by
if (flag)
bitfield.bit = true;
else
bitfield.bit = false;
than
bitfield.bit = flag;
I've included a short test
2009/11/28 Richard Guenther richard.guent...@gmail.com:
On Sat, Nov 28, 2009 at 11:43 PM, Shaun Jackman sjack...@gmail.com wrote:
When assigning a bool to a single bit of a bitfield located in the
bit-addressable region of memory, better code is produced by
if (flag
The following macro expands to some rather frightful code on the AVR:
#define BSWAP_16(x) \
x) 8) 0xff) | (((x) 0xff) 8))
uint16_t bswap_16(uint16_t x)
{
0:9c 01 movwr18, r24
2:89 2f mov r24, r25
4:99 27 eor r25, r25
6:
The GCC build (svn revision 118976) is not finding the target as,
although it appears to be in the right place.
Thanks,
Shaun
$ ../configure --target=avr --enable-languages=c --prefix=/usr
...
$ cat gcc/as
#!/bin/sh
exec $@
$ /usr/bin/avr-as --version | head -1
GNU assembler 2.16.1
$ make
...
I would like to multiply a 16-bit number by an 8-bit number and
produce a 24-bit result on the AVR. The AVR has a hardware 8-bit *
8-bit - 16-bit multiplier.
If I multiply a 16-bit number by a 16-bit number, it produces a 16-bit
result, which isn't wide enough to hold the result.
If I cast one
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
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
On 11/26/06, Denis Vlasenko [EMAIL PROTECTED] wrote:
On Saturday 18 November 2006 00:30, Shaun Jackman wrote:
The following macro expands to some rather frightful code on the AVR:
#define BSWAP_16(x) \
x) 8) 0xff) | (((x) 0xff) 8))
Sometimes gcc is generating better code if you
On 12/18/06, Anton Erasmus [EMAIL PROTECTED] wrote:
Hi,
Not a macro, but the following seems to generate reasonable code.
...
Thanks Anton,
I came to the same conclusion.
Cheers,
Shaun
static inline uint16_t bswap_16_inline(uint16_t x)
{
union {
uint16_t x;
On 12/18/06, David VanHorn [EMAIL PROTECTED] wrote:
Am I missing something here?
Why not pop to assembler, push the high, push the low, pop the high, pop the
low?
* Inline assembler cannot be used at compile time, for example to
initialize a static variable.
* If the swap function is called
On 12/18/06, Nils Springob [EMAIL PROTECTED] wrote:
Hi,
and it is possible to use an anonymous struct:
True. However, unnamed struct/union fields are an extension of the C
language provided by GCC and not strictly portable. It is a nice
feature though. It would be nice if it crept its way
Can the GCC C Extension of Generalized Lvalues be enabled with a
switch in gcc-4.0?
Cheers,
Shaun
On Mar 22, 2005 12:29 PM, Andreas Jochens [EMAIL PROTECTED] wrote:
Package: romeo
Severity: normal
Tags: patch
When building 'romeo' on amd64 with gcc-4.0,
I get the following error:
On 6/29/05, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Wed, Jun 29, 2005 at 10:34:20AM -0700, Shaun Jackman wrote:
the statement expression macro? My best idea was to use alloca, but it
wouldn't look pretty. Can someone confirm that memory allocated with
alloca would last the lifetime
On 6/29/05, Russell Shaw [EMAIL PROTECTED] wrote:
Alloca is like creating a stack variable, except it just gives you some
generic bytes that don't mean anything. Exiting the local scope will
trash the local variables and anything done with alloca(). You'll need
to store some information in a
On 8/2/05, Paul Koning [EMAIL PROTECTED] wrote:
One of the things that continues to baffle me (and my colleagues) is
the bizarre way in which attributes such as packed work when applied
to structs.
It would be natural to assume, as Shaun did, that marking a struct
packed (or, for that
On 8/2/05, Dave Korn [EMAIL PROTECTED] wrote:
There are two separate issues here:
1) Is the base of the struct aligned to the natural alignment, or can the
struct be based at any address
The base of the struct is aligned to the natural alignment, four bytes
in this case.
2) Is there
On 8/2/05, Joe Buck [EMAIL PROTECTED] wrote:
I suppose we could make on an unaligned project return a void*. That
isn't really right, but it would at least prevent the cases that we know
don't work from compiling.
That sounds like a dangerous idea only because I'd expect...
int *p =
On 8/4/05, Carl Whitwell [EMAIL PROTECTED] wrote:
Hi,
thought I'd drop you a mail, would put it on gcc mailing list but
haven't got time to work out how to send it there at this moment.
The gcc mailing list is [EMAIL PROTECTED]
All testing here is done on x86 processors using gcc
On 8/5/05, Carl Whitwell [EMAIL PROTECTED] wrote:
On 8/4/05, Shaun Jackman [EMAIL PROTECTED] wrote:
Are you using an x86 host and an arm target?
Actually no, my major concern at the time was the large quantity of
legacy code with packed structures that we have on an embedded linux
x86
The Debian HPPA buildd is failing with an ICE when building SwingWT
for the HPPA.
Here's the full build log:
http://buildd.debian.org/fetch.php?pkg=swingwtver=0.87-2arch=hppastamp=1126289145file=logas=raw
Here's the interesting line:
swingwtx/swing/JOptionPane.java:325: internal compiler error:
The following code snippet produces code that loads a register, r5,
from memory, but never uses the value. The code is correct though, so
not a major issue. In addition, it never uses r3 or r12, which are
free registers, in that they don't have to be saved by the callee.
For a one line function
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
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
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
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
$ 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()':
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
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
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
$ 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
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
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
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
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
61 matches
Mail list logo
