> As I have no window overflow trap handler the space reserved on the
> stack for saving in and local registers is just wasted memory. Is there
> any way I can reclaim this space by forcing the compiler to not honour
> the standard SPARC ABI?
No, there isn't, unless you want to hack the compiler.
Chandra Prakash Garg writes:
> checking for
> i686-pc-linux-gnu-gcc...
> /home/abhijitd/gcc/gcc-4.3.2/host-i686-pc-linux-gnu/gcc/xgcc
> -B/home/abhijitd/gcc/gcc-4.3.2/host-i686-pc-linux-gnu/gcc/
> -B/home/abhijitd/gcc/gcc-4.3.2/i686-pc-linux-gnu/bin/
> -B/home/abhijitd/gcc/gcc-4.3.2/i686-pc-linu
Hi,
The following program segfaults when compiled with gcc
but runs fine when compiled with g++ or icc (the intel C compiler)
#include
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
r.world[0]='H';
r.world[1]='\0';
return r;
}
int main(){
> Hi,
>
> The following program segfaults when compiled with gcc
> but runs fine when compiled with g++ or icc (the intel C compiler)
>
> #include
> struct Hello {
> char world[20];
> };
> struct Hello s(){
> struct Hello r;
> r.world[0]='H';
> r.world[1]='\0';
>
On Tuesday 2008-12-16 17:05, Michel Van den Bergh wrote:
> Hi,
>
> The following program segfaults when compiled with gcc
> but runs fine when compiled with g++ or icc (the intel C compiler)
>
> #include
> struct Hello {
> char world[20];
> };
> struct Hello s(){
> struct Hello r;
>
2008/12/16 Dennis Clarke :
>
>> Hi,
>>
>> The following program segfaults when compiled with gcc
>> but runs fine when compiled with g++ or icc (the intel C compiler)
>>
>> #include
>> struct Hello {
>> char world[20];
>> };
>> struct Hello s(){
>> struct Hello r;
>> r.worl
That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10
(Intel core2 duo)
I get
stest.c: In function ‘main’:
stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
has type ‘char[20]’
The resulting binary does not segfault but prints garbage (probably
uniniti
Ok thanks for the clear explanation!
Not being able to threat char[] as a string is rather shocking to me though.
Regards,
Michel
Michel Van den Bergh wrote:
That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu
8.10 (Intel core2 duo)
I get
stest.c: In function ‘main’:
stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
has type ‘char[20]’
The resulting binary does not segfault but prin
C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
arrays in C++98. Also this code is still undefined C99 but will most
likely become valid C1x.
Sent from my iPhone
On Dec 16, 2008, at 8:45 AM, Jan Engelhardt wrote:
On Tuesday 2008-12-16 17:05, Michel Van den Bergh wr
On Tuesday 2008-12-16 18:01, Sebastian Redl wrote:
> Michel Van den Bergh wrote:
>> That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10
>> (Intel core2 duo)
>> I get
>>
>> stest.c: In function ‘main’:
>> stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2 ha
The C standard says no such thing; only integer promotions are
performed. (See 6.5.2.2 of the C99 final draft.)
Ok one more question. Why does this not give a warning then (and runs fine)?
#include
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
r.wor
Sebastian Redl wrote:
> Michel Van den Bergh wrote:
>> That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu
>> 8.10 (Intel core2 duo)
>> I get
>>
>> stest.c: In function ‘main’:
>> stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
>> has type ‘char[20]’
>>
>> The
Andrew Thomas Pinski wrote:
> C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
> arrays in C++98. Also this code is still undefined C99 but will most
> likely become valid C1x.
Ah, it's an rvalue array. Good point.
> Sent from my iPhone
Advertising on gcc list. Dear me...
>
> On Tuesday 2008-12-16 17:05, Michel Van den Bergh wrote:
>
>> Hi,
>>
>> The following program segfaults when compiled with gcc
>> but runs fine when compiled with g++ or icc (the intel C compiler)
>>
>> #include
>> struct Hello {
>> char world[20];
>> };
>> struct Hello s(){
>> st
On Tue, Dec 16, 2008 at 12:28:10PM +0700, Ha Luong wrote:
> I used gcc-4.3.2 to compile the c source(*) and it generated
> "vmhraddshs" instruction when I compiled with -mcpu=8540.
> 000103A4: 11EB0321 vmhraddshs vr15,vr11,vr0,vr12
You are running into the problem that the Altivec and SPE opcode
Andrew Haley wrote:
Andrew Thomas Pinski wrote:
C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
arrays in C++98. Also this code is still undefined C99 but will most
likely become valid C1x.
Ah, it's an rvalue array. Good point.
Ok now I understand. I assume t
On Tue, Dec 16, 2008 at 9:43 AM, Michel Van den Bergh
wrote:
> Andrew Haley wrote:
>>
>> Andrew Thomas Pinski wrote:
>>
>>>
>>> C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
>>> arrays in C++98. Also this code is still undefined C99 but will most
>>> likely become valid C1
On Tuesday 2008-12-16 18:43, Michel Van den Bergh wrote:
> Andrew Haley wrote:
>> Andrew Thomas Pinski wrote:
>>
>> > C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
>> > arrays in C++98. Also this code is still undefined C99 but will most
>> > likely become valid C1x.
>>
On Tue, Dec 16, 2008 at 10:41 AM, Jan Engelhardt wrote:
> Is not this a use of an rvalue array too?:
>printf("%p\n", (struct { char x[20]; }){{"Hello"}}.x);
No, compound literals are always lvalues in C99.
Thanks,
Andrew Pinski
Hi,
./gcc/config/avr/avr.md
defines andsi3 as follows:
(define_insn "andsi3"
[(set (match_operand:SI 0 "register_operand" "=r,d")
(and:SI (match_operand:SI 1 "register_operand" "%0,0")
(match_operand:SI 2 "nonmemory_operand" "r,i")))]
""
"*{
if (which_alternative
On Mon, Dec 15, 2008 at 04:17:34PM -0500, gobaan_raveend...@amis.com wrote:
>
> Hello Everyone,
>
> I am working on an architecture with multiple types of memory and I am
> wondering about memory allocation. For the purpose of this explaination,
> we'll assume I am working with an embedded proces
I've been studying the x86 compiled form of the following function:
void function()
{
char buffer[X];
}
where X = 0, 1, 2 .. 100
Naively, I would expect to see:
pushl %ebp
movl%esp, %ebp
subl$X, %esp
leave
ret
Instead, the stack appears to b
Andrew Tomazos wrote:
I've been studying the x86 compiled form of the following function:
void function()
{
char buffer[X];
}
where X = 0, 1, 2 .. 100
Naively, I would expect to see:
pushl %ebp
movl%esp, %ebp
subl$X, %esp
leave
ret
Instead
Hello Everyone,
I am working on an optimization which happens at split2 stage. I need to
determine whether the destination operand of the current RTL (which is a
register operand) will be referred by other RTL through MEM within a basic
block. I see there is a function named reg_mentioned_p (co
Hi Nathan,
Thanks for your guide. When I debugged the exe file or make it ran on
8548 board, the vmhaddshs makes the exe file hang out. Could I compile
the source for 8540 (e500v1 instructions) only?
Thanks for your help,
Ha Luong
On Tue, Dec 16, 2008 at 9:45 PM, Nathan Froyd wrote:
> On Tue, D
Greetings,
In my efforts to build C++-0X library components I've noticed that
constexpr member variables are used in several places. I was unable to
implement these as intended and reverted to const accessors.
It seems like the intent is sort of a static const function except that
it binds
"Guo, Xuepeng" writes:
> I am working on an optimization which happens at split2 stage. I
> need to determine whether the destination operand of the current RTL
> (which is a register operand) will be referred by other RTL through
> MEM within a basic block. I see there is a function named
> reg_
Hi Ian,
Thanks for your comments. It's not exactly the entire basic block. It should be
from the current RTL to the end of the current basic block. As you know GCC
will optimize "addl %ebx, %eax" to "leal (%ebx, %eax), %eax" to avoid the flag
register dependency through a splitter in i386.md at
2008/12/16 Georg-Johann Lay :
> Hi,
>
> ./gcc/config/avr/avr.md
>
> defines andsi3 as follows:
[...]
>
> For alternative 1 "d,0,i" the effect on cc_status is described as set_n.
> However, if the high byte of [2] is 0xff, then the PSW (i.e. SREG.N)
> does not contain the MSB of the result.
>
> I di
30 matches
Mail list logo
