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
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
"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_
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
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
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
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
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
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
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 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
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 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
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 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
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...
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
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
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
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
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
Ok thanks for the clear explanation!
Not being able to threat char[] as a string is rather shocking to me though.
Regards,
Michel
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
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;
>
> 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';
>
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(){
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
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
> 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.
30 matches
Mail list logo
