In attach you can find example program,
client and server side. And doc for the system as README file.
The newest version of the sources can be downloaded from
crpc at sf dot net.
To compile the package just 'make' and 'make install'. Tests can be
found inside the tests
directory.
There are sever
I have a question with regards to ARM interworking. The target is
ARM7TDMI-S, embedded system with no OS. The compiler is arm-elf-gcc,
4.3.1 with binutils maybe 3 months old.
It seems that when interworking is enabled then when a piece of THUMB
code calls an other piece of THUMB code in a separate
Zoltán Kócsi wrote:
> I have a question with regards to ARM interworking. The target is
> ARM7TDMI-S, embedded system with no OS. The compiler is arm-elf-gcc,
> 4.3.1 with binutils maybe 3 months old.
>
> It seems that when interworking is enabled then when a piece of THUMB
> code calls an other p
This message is really off topic for this list, please direct any
follow-ups to gcc-h...@gcc.gnu.org.
On Wed, 2009-01-21 at 19:53 +1100, Zoltán Kócsi wrote:
> I have a question with regards to ARM interworking. The target is
> ARM7TDMI-S, embedded system with no OS. The compiler is arm-elf-gcc,
>
Hello,
Eric and I discovered a discrepancy in the DWARF register numbering
on SPARC for floating point registers. The problem is more visible
on SPARC 64-bit because they are used for parameter passing, whether
i0 is used on 32-bit SPARC. Consider for instance the following code:
volatile r
Joel Brobecker writes:
> However, when I tried to find some kind of official document
> to confirm this numbering, I only found:
>
> http://wikis.sun.com/display/SunStudio/Dwarf+Register+Numbering
>
> This is a wiki page, so I'm not sure how much we can trust the contents.
> However, it doe
> Date: Wed, 21 Jan 2009 15:08:47 +0400
>
> Hello,
>
> Eric and I discovered a discrepancy in the DWARF register numbering
> on SPARC for floating point registers. The problem is more visible
> on SPARC 64-bit because they are used for parameter passing, whether
> i0 is used on 32-bit SPARC. Co
Hi,
I just wanted to see if there are others out there who get profile
information from a simulator and feed that information back for GCC's
PBO, in the .gcda format.
I had tried this on picoChip, by changing the instrumentation code in
GCC for fprofile-arcs and got edge profile working quite
> Obviously the GCC folks broke backwards compatibility with themselves.
> So unless we find evidence that contradicts the wiki page you cite, I
> think GCC needs to be fixed.
Yes, the SVR4 definition used to be masked by that of the sol2.h file on
Solaris and is not anymore. But the SVR4 defini
andrew babanin writes:
> In attach you can find example program,
> client and server side. And doc for the system as README file.
> The newest version of the sources can be downloaded from
> crpc at sf dot net.
Thanks. This does seem useful for some people. I would be interested
in hearing tho
Hi,
I am trying to write some simple builtin functions for target avr.
The buitins themselves are no proplem. The expansion works as intended.
What is unacceptable is a code bloat of +100% ... +150% during the RTL
passes.
So can anyone assist me in writing down RTL that will yield best/accepta
On Wed, 21 Jan 2009, Georg-Johann Lay wrote:
> Up to now, LPM is not implemented in the compiler because GCC does not
> allow to add new target specific qualifiers like "flash".
Note that work on ISO TR 18037 named address spaces is underway for GCC
4.5 (currently on named-addr-spaces-branch).
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Wednesday, January 21, 2009 10:05 AM
> To: gcc@gcc.gnu.org
> Subject: [target.md]: Backend passes cause code bloat of +140%.
>
> Hi,
>
> I am trying to write some simple builtin functions for target avr.
>
> 2009/1/21 Ian Lance Taylor :
> What support needs to be in gcc
> proper?
As my wrapper compiler do some job, that GCC does, so I thought,
that it would be better to add CRPC support to GCC. Maybe using some
kind of plugin.
CRPC wrapper compiler has it own automata and
reads all the C input. Yo
On Jan 20, 2009, at 11:22 PM, Jack Howarth wrote:
Are there any observations that you could make concerning
the thread...
http://gcc.gnu.org/ml/gcc/2009-01/msg00297.html
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the extr
andrew babanin wrote:
2009/1/21 Ian Lance Taylor :
You say it needs only libc, but of course it needs
more than the ISO C library functions. Is the code written in a way
that makes it easy to port to other systems?
CRPC has two main parts - C-wrapper compiler and shared library.
> 2009/1/21 Joel Sherrill :
> I think this would have been useful on at least one project
> in my history. :)
>
> Ian mentioned embedded systems in an earlier question
> and I am still unsure what you require of the OS in terms
> of services to work. Cygwin is very close to a "real UNIX"
> from a
andrew babanin wrote:
2009/1/21 Joel Sherrill :
I think this would have been useful on at least one project
in my history. :)
Ian mentioned embedded systems in an earlier question
and I am still unsure what you require of the OS in terms
of services to work. Cygwin is very close to a
Hello!
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the extra work here otherwise bits of gcc get very grumpy
when we ask for lower alignment. We could just reject values less
than 128 bits for Darwin, but it's easier to
On Jan 21, 2009, at 11:40 AM, Uros Bizjak wrote:
Hello!
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the extra work here otherwise bits of gcc get very grumpy
when we ask for lower alignment. We could just reject values le
>>> 2009/1/21 Joel Sherrill :
>
> Is the marshalling and encoding based upon anything
> standard?
>
> Does it support RPC's across heterogeneous hosts?
Data that should be send through the net is packed using my own method.
It is rather simple, but marshaling is made automatically, in C code, gene
On Jan 21, 2009, at 8:40 PM, Uros Bizjak wrote:
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the extra work here otherwise bits of gcc get very grumpy
when we ask for lower alignment. We could just reject values less
than 12
From: Eric Botcazou
Date: Wed, 21 Jan 2009 15:22:19 +0100
> > Obviously the GCC folks broke backwards compatibility with themselves.
> > So unless we find evidence that contradicts the wiki page you cite, I
> > think GCC needs to be fixed.
>
> Yes, the SVR4 definition used to be masked by that o
On Wed, Jan 21, 2009 at 11:59:09AM -0800, Mike Stump wrote:
> On Jan 21, 2009, at 8:40 PM, Uros Bizjak wrote:
>>> Sure, in i386/darwin.h we have:
>>>
>>> /* Since we'll never want a stack boundary less aligned than 128 bits
>>> we need the extra work here otherwise bits of gcc get very grumpy
>>>
2009/1/18 Dave Korn :
> Andy Scott wrote:
>
>> Again stage3 part of build, and this is what actually stops the build
>> the above issue doesn't seem to (I think it happens in stage 2), I get
>> the following:
>>
>>
>
> < a few more lines of log deleted :) >
>
>> ../../../gcc/libiberty/strsignal.c
Weddington, Eric schrieb:
Hi,
I am trying to write some simple builtin functions for target avr.
Hi Georg-Johann,
Anatoly Sokolov and I already have a patch to add builtin function capabilities
for the AVR. Could you send us your patches?
Hi Eric,
I just gave the builtin approch for pg
Hi,
I am trying to generate a cross-compiler targetting ARM wince plateform
from gcc trunk and I have an error message
when compiling mingw and regarding linker
My tree is organized like this :
src
+ binutils
+ gcc
+ mingw
+ w32api
+ build-mingw32ce
and I am using a script to build the differen
Joseph S. Myers schrieb:
On Wed, 21 Jan 2009, Georg-Johann Lay wrote:
Up to now, LPM is not implemented in the compiler because GCC does not
allow to add new target specific qualifiers like "flash".
Note that work on ISO TR 18037 named address spaces is underway for GCC
4.5 (currently on na
On Jan 21, 2009, at 3:43 PM, Jack Howarth wrote:
So that invalidates your previously proposed patch? Or should I
still test it?
No need to test, I was wrong about that being the bit that causes it.
The description I last posted should be about right however, one just
needs a bit of time i
Snapshot gcc-4.2-20090121 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090121/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Weddington, Eric schrieb:
> Anatoly Sokolov and I already have a patch to add builtin function
capabilities for the AVR. Could you send us your patches?
The patch is contained in my top post
http://gcc.gnu.org/ml/gcc/2009-01/msg00309.html
Here a verbatim copy, so it is easier to discuss wha
Hi,
for the record, today I started an rsync to get a local copy of the
repository and, at variance with the information in:
http://gcc.gnu.org/rsync.html
the size I'm seeing is already > 17G, and counting... If somebody knows
the total size and wants to update the web page, I think it would b
17,327,572 k
:)
On Wed, Jan 21, 2009 at 8:13 PM, Paolo Carlini wrote:
> Hi,
>
> for the record, today I started an rsync to get a local copy of the
> repository and, at variance with the information in:
>
> http://gcc.gnu.org/rsync.html
>
> the size I'm seeing is already > 17G, and counting...
http://www.google.com/group/assureinaldoingram?auzlmvvrjthusst
resort rests Twice By-the-way collapsed bath-sponge
fulfillment field caps
34 matches
Mail list logo
