2009/11/28 Richard Guenther :
> On Sat, Nov 28, 2009 at 11:43 PM, Shaun Jackman 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)
>> bitfield
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 and
2009/11/18 Shaun Jackman :
> 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
&g
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 i
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.
> (http://mailman.uclinux.org/pipermail/uclin
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 fu
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 a
(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:
>
> ===
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 in
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, 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 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
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
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
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
...
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
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 GOTOF
Shaun
2006-06-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.
In
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 does
On 6/28/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
It was probably me. But why can't you do this yourself? Look at the
assembly. See what the output string is. Search for it in
config/arm/. Use svn blame, as already suggested.
I did search the assembler text and found the constant an
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 u
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
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, 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 redu
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 experime
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 l
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
.tex
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
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 RA
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
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
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".
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 desir
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
I'm using MULTILIB_OPTIONS and MULTILIB_DIRNAMES to compile a PIC/XIP
toolchain. I'm familiar with the MULTILIB_EXCEPTIONS mechanism to
specify incompatible configurations. How, though, do I indicate that
msingle-pic-base depends on fPIC?
MULTILIB_OPTIONS+= fPIC
MULTILIB_DIRNAMES += pic
MUL
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
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 -mp
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
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
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 t
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=swingwt&ver=0.87-2&arch=hppa&stamp=1126289145&file=log&as=raw
Here's the interesting line:
swingwtx/swing/JOptionPane.java:325: internal compiler er
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 tha
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 g
On 8/3/05, Richard Henderson <[EMAIL PROTECTED]> wrote:
> It is nevertheless correct. Examine all of the parts of the expression.
>
> In particular, "&s->b". What type does it have? In an ideal world, it
> would be "pointer to unaligned integer". But we have no such type in
> our type system,
On 8/2/05, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> operator. None of these examples produce an unaligned load:
I should clarify the wording I'm using here. By "an unaligned load" I
mean code to safely load from an unaligned pointer.
Cheers,
Shaun
On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
> It sounds like the workaround is to avoid memcpy, and just use
> variable assignment. Alternatively, cast the pointers to char*, which
> should force memcpy to do the right thing. Ugh.
Casting to void* does not work either. gcc keeps the alignm
On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
> It sounds like the workaround is to avoid memcpy, and just use
> variable assignment. Alternatively, cast the pointers to char*, which
> should force memcpy to do the right thing. Ugh.
I swear originally, back in the gcc 2.95 days, I used memcp
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
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 t
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
On 8/2/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> In order for anyone to answer your questions about the alignment of
> various types in a struct, don't you think you should perhaps have told us a
> little about what those types actually are and how the struct is laid out?
Of course, my apologie
In a typical Ethernet/IP ARP header the source IP address is
unaligned. Instead of using...
out->srcIPAddr = in->dstIPAddr;
... I used...
memcpy(&out->srcIPAddr, &in->dstIPAddr, sizeof(uint32_t));
... to account for the unaligned destination. This worked until gcc 4,
which now gener
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 i
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
Hello,
I'm implementing a tiny vfork/exit implementation using setjmp and
longjmp. Since the function calling setjmp can't return (if you still
want to longjmp to its jmp_buf) I implemented vfork using a statement
expression macro. Here's my implementation of vfork.
jmp_buf *vfork_jmp_buf;
#defin
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 erro
> I did fix at least one bug, such that -Ttext does something useful with
> ELF toolchains, if your linker script it set up to use it. I think the
> ARM BPABI script may be the only one set up that way, though.
That would be excellent. I dislike having to read / modify / write
(read: fork) an exi
I have had no trouble specifiying the linker script using the -T
switch to gcc. I am now trying to specify the linker script from a
specs file like so:
%rename link old_link
*link:
-Thello.ld%s %(old_link)
gcc complains though about linking Thumb code against ARM libraries --
I've specified -mthu
When -Ttext is used in combination with -mthumb it causes a relocation
truncated to fit message. What does this mean, and how do I fix it?
Please cc me in your reply. Thanks,
Shaun
$ arm-elf-gcc --version | head -1
arm-elf-gcc (GCC) 3.4.0
$ cat hello.c
int main() { return 0; }
$ arm-elf-gcc -Ttex
Is it possible by hacking the specs file to change the target for
arm-elf-gcc from -marm to -mthumb? I tried a few obvious things like
changing marm in *multilib_defaults to mthumb, but this did not have
the desired effect.
Please cc me in your reply. Thanks!
Shaun
61 matches
Mail list logo
