Hello,
My problem is quite simple, the PPC has few conditions registers and some are
assumed to be saved over function calls (in my test case NU_Sleep()), but the
hard real time kernel do not save those (partial flags) registers.
This behaviour is perfectly documented in gcc-4.1.1/gcc/config/rs6
ped on cygwin:
$ gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc-4.1.1/configure
Thread model: single
gcc version 4.1.1
Etienne.
- Message d'origine
De : Ian Lance Taylor <[EMAIL PROTECTED]>
À : Etienne Lorrain <[EMAIL PROTECTED]>
Cc : gcc
Hello,
[EMAIL PROTECTED] /cygdrive/x
$ cat tmp.c
typedef unsigned size_t;
char *strncpy (char *pDest, const char *pSrc, size_t n)
{
return pDest;
}
[EMAIL PROTECTED] /cygdrive/x
$ powerpc-eabi-gcc -v
Using built-in specs.
Target: powerpc-eabi
Configured with: ../gcc-4.1.1/configure --ta
Sorry please ignore, not enough coffee...
Etienne.
___
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expér
--- Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> I don't actually understand the question. gcc is compiling the
> function as you wrote it. What do you want it to do differently?
This has been resolved today by:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30785
I was adding code to test a
Hi,
Just a minor thing, but I hit this problem times to times, I know
the CPP preprocessor has no warning like "end of line ignored"...
GCC-3.3.5 and 3.4.3.
[EMAIL PROTECTED]:~/projet$ cat > tmp.c
#define OPTION1 0x0001
#define OPTION2 0x0002
#define OPTION3 0x0004
#define OPTION4 0x0008
#
Paul Schlie wrote:
> My impression is that there are 3 fundamental types of memory references:
>
> - literal-code (call/goto code-label/ptr)
> - literal-data (mem static-const-symbol/ptr)
> - runtime-data (mem non-static-const-symbol/ptr)
>
> As such it seems likely sufficient to simply enable the
> GCC 3.4.4 RC1 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050510/
I downloaded and rebuild for ia32 with latest pre binutils on
my project and noticed an increase of size. I am compiling with -Os
because size is very important in my case - so I invertigated by
lookin
> Etienne Lorrain <[EMAIL PROTECTED]> wrote:
>
>> Some of those problem may also exist in GCC-4.0 because this
>> version (and the 4.1 I tested) gives me an increase of 60% of the
>> code size compared to 3.4.3.
>
>
> This is a serious regression which
> Etienne Lorrain <[EMAIL PROTECTED]> wrote:
>
>> If I compile that with GCC-3.4, I get:
>>
>> $ size tmp.o
>> textdata bss dec hex filename
>> 243 0 0 243 f3 tmp.o
>>
>> With GCC-4.0:
>>
>
> Etienne Lorrain <[EMAIL PROTECTED]> wrote:
>
>> If I compile that with GCC-3.4, I get:
>>
>> $ size tmp.o
>> textdata bss dec hex filename
>> 243 0 0 243 f3 tmp.o
>>
>> With GCC-4.0:
>>
>
> GCC 3.4.4 RC2 is now available here:
> ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050512
> There are just a few changes from RC1 to fix critical problems people
experienced with RC1.
Work for me, thanks.
Etienne.
Hello,
This stripped down extract of a real file (main.c of Gujin-1.1) gives:
[EMAIL PROTECTED]:~/projet/gujin$ gcc -Os tst.c -c -o tst.o && size tst.o
textdata bss dec hex filename
261 0 0 261 105 tst.o
[EMAIL PROTECTED]:~/projet/gujin$ ../toolchain/
--- Falk Hueffner <[EMAIL PROTECTED]> wrote:
> You should always enter it on bugzilla, if you cannot find this out
> for yourself. We have highly trained professionals who will swiftly
> close duplicate bug reports, and that way the report cannot get lost.
So it is:
http://gcc.gnu.org/bugzilla/s
The result of this funtion is 1, is there a C lawyer around?
$ cat tmp.c
unsigned fct (unsigned array[10])
{
return sizeof(array) / sizeof(array[0]);
}
$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/m
Hello,
Subject says it all - I do not know if that is new. I just have a bug
in Gujin-1.2 with this new compiler, because function:
__attribute__ ((section (".xcode_start"), noreturn))
void xcodeseg_never_call_address_zero (void)
calls xcodeseg_BOOT1_putstr() generated by macro:
#define GE
--- Richard Guenther <[EMAIL PROTECTED]> wrote:
> Please explain the problem you're seeing. I can see nothing wrong with
> inlining functions within different sections in general. If you're
> trying to do things behind the compilers back, though, be prepared to
> change workarounds with compiler
Hello,
Investigated again a big increase of size going from GCC-3.4 to 4.x
(gcc (GCC) 4.0.2 20050811 (prerelease)) on my Gujin-v1.2, quickly way
to reproduce:
Download and untar gujin, then build "fs.s" :
url_get http://prdownloads.sourceforge.net/gujin/gujin-1.2.tar.gz?download
tar -xvzf
Thanks James,
Shall I create a new bug report or re-open:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21626
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478
Etienne.
--- James E Wilson <[EMAIL PROTECTED]> wrote:
> Etienne Lorrain wrote:
> > Investigated again a big i
I do not know if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477
should be fixed in this release, but I am sure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
which was marked as duplicate is not fixed:
[EMAIL PROTECTED]:~/projet/gujin$ cat > tmp.c
int
sub (int i)
{
int array[100]
The bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
was filled against 4.0.2-pre and is concerning C; the bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477
is in C++ and filled against 4.1, it was marked duplicate,
but it would be nice to have 4.0.2 fixed before release.
Etienne.
Hello,
You really do not want to get a correction for:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
before release?
I checked again with 4.0.2 20050917, and nothing
has changed since:
http://gcc.gnu.org/ml/gcc/2005-09/msg00251.html
Etienne.
_
--- Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Etienne Lorrain wrote:
> > Hello,
> >
> > You really do not want to get a correction for:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
> > before release?
> >
> > I checked agai
Hello,
A lot of people (me too) write this kind of code:
struct param1_str *param1;
struct param2_str *param2;
struct param3_str *param3;
error = treat_alpha (param1, param2, param3);
if (error)
printf ("treat_alpha failed error %d, param1 = %p, "
"param2 = %p, param3 = %p
Hello,
I am trying to rebuild gcc, for my target (ia32/amd64 bootloader) I will
not use any library whatsoever, target is ia32.
If I do:
rm -f -r ../toolchain
mkdir ../toolchain ../toolchain/source ../toolchain/build
tar --directory ../toolchain -xjf ../binutils-2.19.1.tar.bz2
mv ../toolchain
Hello,
I did not find any documentation of a "rep ret" instruction, at
http://www.intel.com/design/processor/manuals/253667.pdf
they just say: "The behavior of the REP prefix is undefined when used with
non-strings instructions".
Any pointers?
Thanks,
Etienne.
etienne:~$ gcc --version
gcc
Manuel López-Ibáñez wrote:
> Anything not documented there is likely to change or be removed in the
> future, so you should not rely on it. On the other hand, if you find
> some behaviour that you feel should be documented and it is not,
> please submit a documentation patch (or at least open a b
--- Mer 11.3.09, Ian Lance Taylor wrote:
> But they aren't documented in the user manual. I think
> they should be, just as we document the machine specific
> constraint characters in the user manual.
> I think it would be appropriate to open a bug report about this.
>
> Ian
http://gcc.gnu.org
Hello,
the docs for "-fno-function-cse" says:
`-fno-function-cse'
Do not put function addresses in registers; make each instruction
that calls a constant function contain the function's address
explicitly.
This option results in less efficient code, but some strange hacks
> Looking at assembly listings of the Linux kernel I see thousands of
> places where function returns are checked to be non-zero to indicate
> errors. For example something like this:
>
> mov bx, 0
> .L1
>call foo
>test ax,ax
>jnz .Lerror
Another calling convention could be to no
--- Andrew Pinski wrote:
> On May 24, 2006, at 2:54 AM, Etienne Lorrain wrote:
> > Another calling convention could be to not only return the "return
> > value" in %eax (or %edx:%eax for long long returns) but also its
> > comparisson to zero in the flags, so
Was just looking again at the assembly file generated by GCC, and noted
this pattern I have already seen - maybe beginning with 4.0.
In short:
[EMAIL PROTECTED]:~/projet/gujin$ /home/etienne/projet/toolchain/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configu
> The correct version is I think,
>
> void longcpy(long* _dst, long* _src, unsigned _numwords)
> {
> asm volatile (
> "cld \n\t"
> "rep \n\t"
> "movsl \n\t"
> // Outputs (read/write)
> : "=S" (_src), "=D" (_dst), "=c" (_numwords)
>
--- Andrew Haley <[EMAIL PROTECTED]> wrote:
> Etienne Lorrain writes:
> > > The correct version is I think,
> > >
> > > void longcpy(long* _dst, long* _src, unsigned _numwords)
> > > {
> > > asm volatile (
> > &
DJ Delorie wrote:
> I strongly request we continue supporting the use of attribute((mode))
> to create pointers of different sizes, at least for copying and
> passing. The m32c reset vector and interrupt table really want to be
> set up like this example:
>
> typedef void (*ifunc)() __attribute__(
You write you needs 6 assembly instructions to check a pointer on x86,
I am using the "bound" ia32 instruction (1 byte opcode 0x62, invalid in ia64)
to check the stack pointer for few years now in Gujin (http://gujin.org)
without
problem.
I am doing this kind of thing to guard against stack
--- Robert Dewar <[EMAIL PROTECTED]> wrote:
> Tzi-cker Chiueh wrote:
> > We have considered the bound instruction in the CASH project. But
> > we found that bound instruction is slower than the six normal
> > instructions it is meant to replace for range checking. For example, the
> > bound instruc
> I ponder about writing a "i386 16bit realmode" gcc backend as my master
> thesis - which would be usefull for generating 16-bit bios code needed
> by the virtual machine developed at my university.
I do not know the virtual machine at your university, but there is
two different project you ma
> What is the proper way to tell gcc that a inline assembly statement either
> modifies
> a particular area of memory or needs it to be updated/in-sync because the
> assembly
> reads from it.
Maybe also related to:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32642
i.e. "=m" works for variables
> You forgot to look at PowerPC :
>
> http://cvs.opensolaris.org/source/xref/ppc-dev/ppc-dev/usr/src/lib/libc/ppc/gen/memcpy.s
>
> is that nice and small ?
I had to clear/check the whole 256 Mbytes SDRAM on a PPC system,
and the fastest way I got (excluding DMA access) is by playing with the
laye
---Andrew Pinski <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote:
> > The PPC has a very fast dcbz (data cache block zero) to clear memory,
> > and also dcbi (data cache block invalidate) which permit to have a
> > cached line caching an address without reading first the memory (when
> > yo
If you build and install binutils (for instance in $HOME), I think
GCC build will use them when using --prefix to build GCC.
But for GMP and MPFR, you need to set --with-gmp to the same path as
--prefix.
Would it be simpler to use the same --prefix to build binutils, GMP,
MPFR and GCC - so defau
Hello,
On C structures, for attributes like "const", it is enough to consider
that each field inherit the attribute of the structure.
But for the volatile attribute, is it valid to treat each field as
volatile like GCC does it now?
I mean:
volatile struct { unsigned char a,b,c,d; } volstruct;
voi
> > On C structures, for attributes like "const", it is enough to
> > consider that each field inherit the attribute of the structure.
> > But for the volatile attribute, is it valid to treat each field as
> > volatile like GCC does it now?
>
> "An object that has volatile-qualified type may be
>
Hello,
On GCC: gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0, Binutils: GNU ld (GNU Binutils for
Ubuntu) 2.29.1,I get such error messages:
boot.c: In function ‘dummy_do_not_call’:
boot.c:1656:3: error: invalid 'asm': operand is not a condition code, invalid
operand code 'c'
asm volatile (" bootbefore_part
45 matches
Mail list logo
