Re: [PATCH] fix -Wsign-compare error in objc-act.c (PR objc/50743)
> (I don't have svn write access so I'll need someone else to commit it if > it's approved.) I can apply it for you. But ... do you have a copyright assignment in place for contributions to GCC ? The patch looks small and trivial enough that I think I can apply it without a signed copyright assignment form, but if you plan on contributing more, it would make sense to sign one. :-) Thanks
Expanding instructions with condition codes inter-deps
Hi,
To negate a double word (HImode) register, I used to take the
instruction all the way to assembly generation and then expand into
three assembly instructions like so:
xor %t0, # ; invert bits in top word of op0
nadd %b0, #0; negate bottom bits of op0
addc %t0, #0; add carry to top bits of op0
The interesting thing about this sequence is that the carry added to the
top bits of op0, is the carry generated by the previous instruction.
If I instead of taking the neghi rule all the way to assembly, and
instead expand it I get:
(define_expand "neghi2"
[(set (match_operand:HI 0 "register_operand")
(neg:HI (match_operand:HI 1 "general_operand")))
(clobber (reg:CC RCC))]
""
{
rtx op0_low = gen_lowpart(QImode, operands[0]);
rtx op0_high = gen_highpart(QImode, operands[0]);
emit_move_insn(operands[0], operands[1]);
emit_insn(gen_xorqi3(op0_high, op0_high, GEN_INT(-1)));
emit_insn(gen_negqi2(op0_low, op0_low));
emit_insn(gen_addc_internal(op0_high, op0_high, const0_rtx));
DONE;
})
addc_internal looks like:
(define_insn "addc_internal"
[(set (match_operand:QI 0 "nonimmediate_operand" "=c")
(plus:QI
(plus:QI
(ltu:QI (reg:CC RCC) (const_int 0))
(match_operand:QI 1 "nonimmediate_operand" "%0"))
(match_operand:QI 2 "general_operand" "cwmi")))
(clobber (reg:CC RCC))]
""
"addc\\t%0,%f2")
The problem is that GCC sometimes moves nadd and addc around. It might
swap their order or insert instructions in-between that set the carry
flag. This ends up generating code which won't work properly.
What's the best way to instruct GCC during neghi2 expansion that the
carry read by addc internal is the one generated by negqi2 and so no
instructions setting carry should be inserted between them and that
their order should not be changed? (for example, it would be ok to
output negqi2, xorqi3 and addc_internal since xorqi3 only sets N and Z,
not the Carry bit).
Cheers,
--
PMatos
Re: asm in inline function invalidating function attributes?
On Mon, Oct 17, 2011 at 02:57, Richard Guenther
> It would simply be an alternate ABI
that makes all registers callee-saved?
> I suppose that would be not too hard to add.
That would be great. There are quite a few interfaces which have a
trivial normal case and only in special situations you need something
more. These interfaces could be translated into:
retval fct(sometype arg) { return cond ? somevalue : complexfct(); }
These would be candidates for this new ABI. The compiler might have
to do minimal spilling to implement the 'cond' expression but the new
ABI would be used unwise if this is expensive.
Note that I would want registers used for passing parameters to also
be preserved (except, of course, when they are needed for the return
value). This proved really useful in the kernel syscall interface
which behaves like that.
Re: asm in inline function invalidating function attributes?
> > At least the Linux kernel has a couple such cases ("nasty inline asm to
> > hide register clobbering in calls") and it's always ugly and hard to
> > maintain.
>
> It would simply be an alternate ABI that makes all registers callee-saved?
Yes exactly that.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
RE: optimization question: mpl
I'm sorry I haven't gotten around to chasing this sooner. I needed to learn
how to use objdump and read the assembler. The code now lets you define the
depth.
It generates some pretty crappy code even with gcc-4.6.0 on O3. The code when
generating a 20 deep template inlines every 6 levels. At 50 depth it only does
2 levels at a time.
Someone mentioned taking control of this myself and implementing array lookups.
Sure, I could also do binary searches and hash tables when the data numbers
aren't continuous. The problem with doing these things is that it takes
control away from the compiler's optimizer. Theoretically an optimizer should
know best when to go from if/elses to binary lookups to hash tables. I could
do this kind of stuff at the metaprogramming level, but that could break an
optimizer in the future. It reminds me of all the "if x==0" you see in old
Fortran code which made things run faster on old machines were branching was
cheap.
Theoretically I might know which ids are most probable, but profile feedback
optimization could be used for this.
Would gcc join switch/case statements?
switch(id) { case 1: foo(); break;}
switch(id) { case 2: bar(); break;}
Another idea to revive the switch/case is to implement a utility with a N
switch cases, one for each size. I could maybe use self including headers or
generate such code.
By the way this kind of code exists. Boost::variant::apply_visitor uses
repeated switch/case statements. Changing foo() below to switch/case doesn't
seem to help.
Chris
-- improved code
#include
#include
#include
struct DecodeContext;
struct M1{
static const int id=13;
static void decode(DecodeContext& ){ std::cout<<"1\n";}
};
struct M2{
static const int id=17;
static void decode(DecodeContext& ){ std::cout<<"2\n";}
};
struct M3{
static const int id=19;
static void decode(DecodeContext& ){ std::cout<<"3\n";}
};
template
struct M{
static const int id=N*3+1024;
static void decode(DecodeContext& ){ std::cout< struct ListMember;
template <> struct ListMember<1>{ typedef M1 type; };
template <> struct ListMember<2>{ typedef M2 type; };
template <> struct ListMember<3>{ typedef M3 type; };
template struct ListMember { typedef M type; };
template
void foo(int id, DecodeContext& dc) {
typedef typename ListMember::type M;
if(M::id==id)
M::decode(dc);
else
foo(id,dc);
}
template<>
void foo<0>(int id, DecodeContext& dc) {}
int main(){
DecodeContext& dc= *(DecodeContext*)0;// junk for now
int id=std::rand(); // runtime dependent
foo<50>(id,dc);
return 0;
}
-Original Message-
From: Piotr Rak [mailto:piotr@gmail.com]
Sent: Wednesday, July 28, 2010 8:17 PM
To: Hite, Christopher
Cc: Richard Guenther; gcc@gcc.gnu.org
Subject: Re: optimization question: mpl
Hi,
2010/7/28 Hite, Christopher :
>> Generally without knowing the compiler version you are using it is
>> hard to tell.
> I'll use whatever's best. Right now I'm still on 4.4.3. I'll
> probably upgrade soon to 4.5.
>
>> The same is true without a complete compilable testcase.
> I didn't want to make a test case that depends on boost::mpl. How's
> this:
>
> struct DecodeContext;
>
> struct M1{
> static const int id=1;
> static void decode(DecodeContext& ){} };
>
> struct M2{
> static const int id=2;
> static void decode(DecodeContext& ){} };
>
> struct M3{
> static const int id=3;
> static void decode(DecodeContext& ){} };
>
>
> template struct ListMember;
>
> template <> struct ListMember<1>{ typedef M1 type; };
> template <> struct ListMember<2>{ typedef M2 type; };
> template <> struct ListMember<3>{ typedef M3 type; };
>
> template
> void foo(int id, DecodeContext& dc) {
> typedef typename ListMember::type M;
> if(M::id==id)
> M::decode(dc);
> else
> foo(id,dc);
> }
>
> template<>
> void foo<0>(int id, DecodeContext& dc) {}
>
>
>
> int main(){
> DecodeContext& dc= *(DecodeContext*)0;// junk for now
> int id=2; //sometime runtime dependent
> foo<3>(id,dc);
> return 0;
> }
>
>
>> You can use the flatten attribute to tell the compiler to inline all
>> calls in a given function, like
>>
>> void __attribute__((flatten)) foo(void)
>> {
>> ...
>> decode1();
>> ...
>> }
>
> That would cause decode1() to be inlined, which might not be what you
> want.
>
> Hmm maybe I could rewrite things so the switch case returns a function
> pointer. I'm guessing that would make things slower though.
>
Or you could just initialize static array of pointers, like that
(please note, that I never compiled code below):
typedef void (*pfn) (DeclContext&);
tempate
struct InitDispatchHelper
{
static void init(std::tr1::array& a)
{
a[I-1] = ListMemeber::foo;
InitPointersHelper::init
Re: Expanding instructions with condition codes inter-deps
On Mon, Oct 17, 2011 at 3:50 AM, Paulo J. Matos wrote: > addc_internal looks like: > (define_insn "addc_internal" > [(set (match_operand:QI 0 "nonimmediate_operand" "=c") > (plus:QI > (plus:QI > (ltu:QI (reg:CC RCC) (const_int 0)) > (match_operand:QI 1 "nonimmediate_operand" "%0")) > (match_operand:QI 2 "general_operand" "cwmi"))) > (clobber (reg:CC RCC))] > "" > "addc\\t%0,%f2") Try adding (use (reg:CC RCC)) to the pattern above. Thanks, Andrew Pinski >
FW: How to let Linux kernel Makefile generate intermediate *.i files ? It doesn't work to add "EXTRA_CFLAGS += -save-temps" in Makefile and gets "cc: warning: -pipe ignored because -wave-temps specif
-Original Message- From: Liu Wang Sent: Saturday, October 15, 2011 5:42 PM To: 'gcc-h...@gcc.gnu.org' Subject: How to let Linux kernel Makefile generate intermediate *.i files ? It doesn't work to add "EXTRA_CFLAGS += -save-temps" in Makefile and gets "cc: warning: -pipe ignored because -wave-temps specified." Sir./Madam, Appreciate your helping me with the following. How to let Linux kernel Makefile generate intermediate *.i files ? It doesn't work to add "EXTRA_CFLAGS += -save-temps" in Makefile and gets "cc: warning: -pipe ignored because -wave-temps specified." Sincerely, Liu Wang
Re: FW: How to let Linux kernel Makefile generate intermediate *.i files ? It doesn't work to add "EXTRA_CFLAGS += -save-temps" in Makefile and gets "cc: warning: -pipe ignored because -wave-temps sp
On 10/17/2011 09:27 AM, Liu Wang wrote: > > > -Original Message- > From: Liu Wang > Sent: Saturday, October 15, 2011 5:42 PM > To: 'gcc-h...@gcc.gnu.org' > Subject: How to let Linux kernel Makefile generate intermediate *.i files ? > It doesn't work to add "EXTRA_CFLAGS += -save-temps" in Makefile and gets > "cc: warning: -pipe ignored because -wave-temps specified." > > Sir./Madam, > > Appreciate your helping me with the following. > > How to let Linux kernel Makefile generate intermediate *.i files ? > It doesn't work to add "EXTRA_CFLAGS += -save-temps" in Makefile and gets > "cc: warning: -pipe ignored because -wave-temps specified." The Linux kernel Makefile already has support for generating .i files. "make help" (partial output) says: (for targets) dir/file.[oisS] - Build specified target only I have binary files built in the X64 subdirectory, so I tested like so: $ make O=X64 ARCH=x86_64 init/calibrate.i $ ls -l X64/init/*.i -rw-r--r-- 1 rddunlap users 354232 Oct 17 09:32 X64/init/calibrate.i -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
gcc auto-omit-frame-pointer vs msvc longjmp
On 10/17/2011 07:09 AM, Bob Breuer wrote:
> I don't think this is a free/g_free issue. If I use the following
> patch, then I at least get the openbios messages:
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index a9fa608..dfbd6ea 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
> /* main execution loop */
>
> volatile sig_atomic_t exit_request;
> +register void *ebp asm("ebp");
>
> int cpu_exec(CPUState *env)
> {
> @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
>
> /* prepare setjmp context for exception handling */
> for(;;) {
> +int dummy = 0;
> +ebp = &dummy;
See if
asm("" : : : "ebp");
also solves the problem.
> Google finds a mention of longjmp failing with -fomit-frame-pointer:
> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>
> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
Hmm. This is the first I've heard of a longjmp implementation
failing without a frame pointer. Presumably this is with the
mingw i.e. msvc libc?
This is something that could be worked around in gcc, I suppose.
We recognize longjmp for some things, we could force the use of
a frame pointer for msvc targets too.
For now it might be best to simply force -fno-omit-frame-pointer
for mingw host in the configure script.
r~
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
On Mon, Oct 17, 2011 at 5:22 PM, Richard Henderson wrote:
> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>> I don't think this is a free/g_free issue. If I use the following
>> patch, then I at least get the openbios messages:
>>
>> diff --git a/cpu-exec.c b/cpu-exec.c
>> index a9fa608..dfbd6ea 100644
>> --- a/cpu-exec.c
>> +++ b/cpu-exec.c
>> @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
>> /* main execution loop */
>>
>> volatile sig_atomic_t exit_request;
>> +register void *ebp asm("ebp");
>>
>> int cpu_exec(CPUState *env)
>> {
>> @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
>>
>> /* prepare setjmp context for exception handling */
>> for(;;) {
>> + int dummy = 0;
>> + ebp = &dummy;
>
> See if
>
> asm("" : : : "ebp");
>
> also solves the problem.
>
>> Google finds a mention of longjmp failing with -fomit-frame-pointer:
>> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>>
>> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
>
> Hmm. This is the first I've heard of a longjmp implementation
> failing without a frame pointer. Presumably this is with the
> mingw i.e. msvc libc?
>
> This is something that could be worked around in gcc, I suppose.
> We recognize longjmp for some things, we could force the use of
> a frame pointer for msvc targets too.
>
> For now it might be best to simply force -fno-omit-frame-pointer
> for mingw host in the configure script.
IIRC buggy versions of alloca() could also fail without a frame pointer.
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
On 10/17/2011 12:14 PM, Blue Swirl wrote: > IIRC buggy versions of alloca() could also fail without a frame pointer. (1) GCC always uses a frame pointer for alloca, (2) Unless you do -fno-builtin-alloca, we always implement it inline. r~
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
Richard Henderson wrote:
> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>> I don't think this is a free/g_free issue. If I use the following
>> patch, then I at least get the openbios messages:
>>
>> diff --git a/cpu-exec.c b/cpu-exec.c
>> index a9fa608..dfbd6ea 100644
>> --- a/cpu-exec.c
>> +++ b/cpu-exec.c
>> @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
>> /* main execution loop */
>>
>> volatile sig_atomic_t exit_request;
>> +register void *ebp asm("ebp");
>>
>> int cpu_exec(CPUState *env)
>> {
>> @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
>>
>> /* prepare setjmp context for exception handling */
>> for(;;) {
>> +int dummy = 0;
>> +ebp = &dummy;
>
> See if
>
> asm("" : : : "ebp");
>
> also solves the problem.
No, that doesn't fix it.
>
>> Google finds a mention of longjmp failing with -fomit-frame-pointer:
>> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>>
>> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
>
> Hmm. This is the first I've heard of a longjmp implementation
> failing without a frame pointer. Presumably this is with the
> mingw i.e. msvc libc?
Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
gcc-core-4.6.1-2-mingw32-bin.
> This is something that could be worked around in gcc, I suppose.
> We recognize longjmp for some things, we could force the use of
> a frame pointer for msvc targets too.
>
> For now it might be best to simply force -fno-omit-frame-pointer
> for mingw host in the configure script.
Here's a testcase that crashes on the longjmp:
#include
#include
jmp_buf env;
int test(void)
{
int i;
asm("xor %%ebp,%%ebp" ::: "ebp");
i = setjmp(env);
printf("i = %d\n", i);
if (i == 0)
longjmp(env, 2);
return i;
}
int main(void)
{
return test();
}
Remove the asm statement to make it not crash. Obviously with
omit-frame-pointer, gcc can shove anything into ebp.
Bob
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
2011/10/17 Bob Breuer :
> Richard Henderson wrote:
>> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>>> I don't think this is a free/g_free issue. If I use the following
>>> patch, then I at least get the openbios messages:
>>>
>>> diff --git a/cpu-exec.c b/cpu-exec.c
>>> index a9fa608..dfbd6ea 100644
>>> --- a/cpu-exec.c
>>> +++ b/cpu-exec.c
>>> @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
>>> /* main execution loop */
>>>
>>> volatile sig_atomic_t exit_request;
>>> +register void *ebp asm("ebp");
>>>
>>> int cpu_exec(CPUState *env)
>>> {
>>> @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
>>>
>>> /* prepare setjmp context for exception handling */
>>> for(;;) {
>>> + int dummy = 0;
>>> + ebp = &dummy;
>>
>> See if
>>
>> asm("" : : : "ebp");
>>
>> also solves the problem.
>
> No, that doesn't fix it.
>
>>
>>> Google finds a mention of longjmp failing with -fomit-frame-pointer:
>>> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>>>
>>> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
>>
>> Hmm. This is the first I've heard of a longjmp implementation
>> failing without a frame pointer. Presumably this is with the
>> mingw i.e. msvc libc?
>
> Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
> gcc-core-4.6.1-2-mingw32-bin.
>
>> This is something that could be worked around in gcc, I suppose.
>> We recognize longjmp for some things, we could force the use of
>> a frame pointer for msvc targets too.
>>
>> For now it might be best to simply force -fno-omit-frame-pointer
>> for mingw host in the configure script.
>
> Here's a testcase that crashes on the longjmp:
>
> #include
> #include
>
> jmp_buf env;
>
> int test(void)
> {
> int i;
>
> asm("xor %%ebp,%%ebp" ::: "ebp");
>
> i = setjmp(env);
> printf("i = %d\n", i);
>
> if (i == 0)
> longjmp(env, 2);
>
> return i;
> }
>
> int main(void)
> {
> return test();
> }
>
> Remove the asm statement to make it not crash. Obviously with
> omit-frame-pointer, gcc can shove anything into ebp.
>
> Bob
This crash isn'r related to ebp existing, or not. The issue is the
hidden argument of setjmp, which is missing. If you can try the
following at top of file after include section.
#define setjmp(BUF) _setjmpex((BUF), NULL)
int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
_setjmp3(jmp_buf _Buf, void *_Ctx);
...
This will work as expected with or without omit-frame-pointer.
The issue is that setjmp has a second (undocumented as usual)
argument, which has a meaning.
Regards,
Kai
PS: _setjmp3 is an export from msvcrt.dll. So if symbol is missing
on link, simply specify msvcrt.dll as argument to link-line.
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
Kai Tietz wrote:
> 2011/10/17 Bob Breuer :
>> Richard Henderson wrote:
>>> On 10/17/2011 07:09 AM, Bob Breuer wrote:
I don't think this is a free/g_free issue. If I use the following
patch, then I at least get the openbios messages:
diff --git a/cpu-exec.c b/cpu-exec.c
index a9fa608..dfbd6ea 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
/* main execution loop */
volatile sig_atomic_t exit_request;
+register void *ebp asm("ebp");
int cpu_exec(CPUState *env)
{
@@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
/* prepare setjmp context for exception handling */
for(;;) {
+int dummy = 0;
+ebp = &dummy;
>>> See if
>>>
>>> asm("" : : : "ebp");
>>>
>>> also solves the problem.
>> No, that doesn't fix it.
>>
Google finds a mention of longjmp failing with -fomit-frame-pointer:
http://lua-users.org/lists/lua-l/2005-02/msg00158.html
Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
>>> Hmm. This is the first I've heard of a longjmp implementation
>>> failing without a frame pointer. Presumably this is with the
>>> mingw i.e. msvc libc?
>> Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
>> gcc-core-4.6.1-2-mingw32-bin.
>>
>>> This is something that could be worked around in gcc, I suppose.
>>> We recognize longjmp for some things, we could force the use of
>>> a frame pointer for msvc targets too.
>>>
>>> For now it might be best to simply force -fno-omit-frame-pointer
>>> for mingw host in the configure script.
>> Here's a testcase that crashes on the longjmp:
>>
>> #include
>> #include
>>
>> jmp_buf env;
>>
>> int test(void)
>> {
>> int i;
>>
>> asm("xor %%ebp,%%ebp" ::: "ebp");
>>
>> i = setjmp(env);
>> printf("i = %d\n", i);
>>
>> if (i == 0)
>>longjmp(env, 2);
>>
>> return i;
>> }
>>
>> int main(void)
>> {
>> return test();
>> }
>>
>> Remove the asm statement to make it not crash. Obviously with
>> omit-frame-pointer, gcc can shove anything into ebp.
>>
>> Bob
>
> This crash isn'r related to ebp existing, or not. The issue is the
> hidden argument of setjmp, which is missing. If you can try the
> following at top of file after include section.
>
> #define setjmp(BUF) _setjmpex((BUF), NULL)
> int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
> _setjmp3(jmp_buf _Buf, void *_Ctx);
> ...
Did you mean _setjmp3 instead of _setjmpex? With _setjmp3, it works
without the asm, but still crashes if I zero out ebp before the setjmp.
Aren't the function arguments on the stack anyway?
>
> This will work as expected with or without omit-frame-pointer.
>
> The issue is that setjmp has a second (undocumented as usual)
> argument, which has a meaning.
So why does my testcase above fail with the asm, but work without the
asm statement? Compile it with gcc -O2 and try it yourself.
>
> Regards,
> Kai
>
> PS: _setjmp3 is an export from msvcrt.dll. So if symbol is missing
> on link, simply specify msvcrt.dll as argument to link-line.
Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
2011/10/18 Bob Breuer :
> Kai Tietz wrote:
>> 2011/10/17 Bob Breuer :
>>> Richard Henderson wrote:
On 10/17/2011 07:09 AM, Bob Breuer wrote:
> I don't think this is a free/g_free issue. If I use the following
> patch, then I at least get the openbios messages:
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index a9fa608..dfbd6ea 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
> /* main execution loop */
>
> volatile sig_atomic_t exit_request;
> +register void *ebp asm("ebp");
>
> int cpu_exec(CPUState *env)
> {
> @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)
>
> /* prepare setjmp context for exception handling */
> for(;;) {
> + int dummy = 0;
> + ebp = &dummy;
See if
asm("" : : : "ebp");
also solves the problem.
>>> No, that doesn't fix it.
>>>
> Google finds a mention of longjmp failing with -fomit-frame-pointer:
> http://lua-users.org/lists/lua-l/2005-02/msg00158.html
>
> Looks like gcc 4.6 turns on -fomit-frame-pointer by default.
Hmm. This is the first I've heard of a longjmp implementation
failing without a frame pointer. Presumably this is with the
mingw i.e. msvc libc?
>>> Yeah, mingw from www.mingw.org which I believe uses msvcrt.dll, package
>>> gcc-core-4.6.1-2-mingw32-bin.
>>>
This is something that could be worked around in gcc, I suppose.
We recognize longjmp for some things, we could force the use of
a frame pointer for msvc targets too.
For now it might be best to simply force -fno-omit-frame-pointer
for mingw host in the configure script.
>>> Here's a testcase that crashes on the longjmp:
>>>
>>> #include
>>> #include
>>>
>>> jmp_buf env;
>>>
>>> int test(void)
>>> {
>>> int i;
>>>
>>> asm("xor %%ebp,%%ebp" ::: "ebp");
>>>
>>> i = setjmp(env);
>>> printf("i = %d\n", i);
>>>
>>> if (i == 0)
>>> longjmp(env, 2);
>>>
>>> return i;
>>> }
>>>
>>> int main(void)
>>> {
>>> return test();
>>> }
>>>
>>> Remove the asm statement to make it not crash. Obviously with
>>> omit-frame-pointer, gcc can shove anything into ebp.
>>>
>>> Bob
>>
>> This crash isn'r related to ebp existing, or not. The issue is the
>> hidden argument of setjmp, which is missing. If you can try the
>> following at top of file after include section.
>>
>> #define setjmp(BUF) _setjmpex((BUF), NULL)
>> int __cdecl __attribute__ ((__nothrow__,__returns_twice__))
>> _setjmp3(jmp_buf _Buf, void *_Ctx);
>> ...
>
> Did you mean _setjmp3 instead of _setjmpex? With _setjmp3, it works
> without the asm, but still crashes if I zero out ebp before the setjmp.
> Aren't the function arguments on the stack anyway?
Yes, I mean _setjmp3 (pasto from headers and missed the second line
prototyping _setjmp3).
I repeat myself here. setjmp() has an hidden arguement, which is
passed on x86 on stack. By not passing this required argument, setjmp
will take a random-value from stack. In your case 'i'. btw if you
would pre-initialize 'i' with zero, I would assume you won't see a
crash, but anyway this is just by chance.
For this I suggest to use here _setjmp3 instead, as here
second-argument is documented as being present.
Btw I tested your code with i686-pc-mingw32 version 4.6.x and 4.7.x
gcc version. With my suggested pattern, I don't see a crash for your
provide test-code with, or without zero-ing ebp.
Kai
AIX library issues
I've discovered an issue which I can't believe I'm the first to bump in to. But I've checked older gcc installs and find the same issue. I did a brief internet search and found sorta similar issues but I'm not sure if they explained it as I see it. I bumped into this while trying to build lzma. What follows is from a gcc 4.5.2 build using gcc 4.5.2 to compile it running AIX 6.1 TL05 SP06. But, as I said, I've compared this to output produced by a gcc 4.3.1 running on AIX 5.3 with the same results. On AIX, there is a tool called dump. dump -H dumps out the header of the loader section. When I link lzma and try to run it, it dies with a long error (that I won't post). In essence it boils down to this: lzma needs libstdc++. In that archive is one shared object. The loader can find lzma and can find the libstdc++ object but it can not load either because libstc++ depends upon another library that the loader can not find. Here is why: dump -H libstdc++.so.6 ./powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs/libstdc++.so.6.orig: ***Loader Section*** Loader Header Information VERSION# #SYMtableENT #RELOCentLENidSTR 0x0001 0x0fe0 0x33b6 0x00da #IMPfilIDOFFidSTR LENstrTBLOFFstrTBL 0x0003 0x0003e9a8 0x0002dec7 0x0003ea82 ***Import File Strings*** INDEX PATH BASEMEMBER 0 /usr/work/build/gcc-4.5.2/powerpc-ibm-aix6.1.0.0/libstdc++-v3/src:/usr/work/build/gcc-4.5.2/powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs:/usr/work/build/gcc-4.5.2/./gcc:/usr/lib:/lib 1libc.a shr.o 2libgcc_s.a shr.o What this is telling us is that libstdc++.so.6 needs libc.a(shr.o) and libgcc_s.a(shr.o) and it is also telling us that when libc.a(shr.o) and libgcc_s.a(shr.o) is needed at run time, the list of places searched is the list of directories listed in entry 0. But the list is the list of where the library is built -- not where it (or more importantly where libgcc_s.a) will be installed. When I configured and built this gcc, prefix path was set to /gsa/ausgsa/projects/r/ruby. Here are the first few lines of my config.log: /usr/work/src/gcc-4.5.2/configure --prefix=/gsa/ausgsa/projects/r/ruby --with-gmp=/gsa/ausgsa/projects/r/ruby --with-mpfr=/gsa/ausgsa/projects/r/ruby --with-mpc=/gsa/ausgsa/projects/r/ruby --disable-nls --enable-threads=aix --with-libiconv-prefix=/usr --enable-languages=c,c++ I have told configure that /gsa/ausgsa/projects/r/ruby is the place I plan to install this compiler. Yet its search path does not include this path at all. For most (perhaps all) of the other shared objects, the path doesn't make THAT much difference because the only library needed is libc.a and it will be found in /usr/lib. The executables suffer from the same thing. Again, it doesn't seem to matter since they only include libc.a. I've been told but I do not know for sure that libtool understands AIX's peculiarities. In particular, what needs to happen is a relink needs to be done. The executables and libraries are correct for testing the results in the current directory. But they are not correct when the final result is moved into the place it was designed to go in to. The good news is that a program compiled with gcc produces an object file with the proper path so all the programs produced from the final gcc are correct. I'm fairly sure that this isn't a pilot error (I somehow botched the call to configure or something like that) but I sure would be happy to find out it was my fault. This seems like a rather hard nut to crack. I hope all this is clear. I'm more than happy to help out in solving this. Thank you, pedz
Re: RFC: Add --plugin-gcc option to ar/nm
On 15/10/2011 23:44, H.J. Lu wrote: > Hi, > > ---plugin option for ar/nm is very long. I am proposing to add > a --plugin-gcc option. It can be implemented with > > 1. Move LTOPLUGINSONAME from gcc to config/plugins.m4. > 2. Define LTOPLUGINSONAME for ar/nm. > 3. For --plugin-gcc, ar/nm call popen using environment variable GCC if set, > or gcc with -print-prog-name=$LTOPLUGINSONAM to get > plugin name. > > Any comments? > Given the general "environment variables are bad and to be avoided where possible" rule we tend to follow, and the fact that it might often be more useful to check $CC rather than $GCC, how about letting --plugin-gcc take an optional argument, which is used in preference to both $GCC and plain "gcc" when provided? i.e. 3. For --plugin-gcc, ar/nm calls popen using - the optional argument to --plugin-gcc, if provided, or - environment variable GCC if set, or - "gcc" as the executable to launch, and with "-print-prog-name=$LTOPLUGINSONAME" as the sole command-line argument, to get the full path to the plugin. cheers, DaveK
Function Name from CALL_INSN RTX
Hello Everyone, Is it possible to extract the function name (as a tree or char *) from a CALL_INSN RTX? Is there a #define or a series of #defines that can accomplish this? The tried to find this information by stepping through the print_rtx function using gdb and the information (as a char *) is currently stored in the following location of a CALL_INSN: "insn->u.fld[4]->rt_rtx->u.fld[1]->rt_rtx->u.fld[0]->rt_rtx->u.fld[0]->rt_rtx->u.fld[0]->rt_str " Does anyone know of a #define or a function I can call to retrieve this information? I would prefer to use functions or #defines rather than absolute locations for future compatibility. Any help is greatly appreciated! Thanks, Balaji V. Iyer.
Re: Function Name from CALL_INSN RTX
"Iyer, Balaji V" writes: >Is it possible to extract the function name (as a tree or char *) > from a CALL_INSN RTX? Is there a #define or a series of #defines that can > accomplish this? Not always, of course. A call through a function pointer has no name. The function get_callee_fndecl will do its best to get the function decl from a CALL_EXPR. Ian
register allocation in gcc
In my .md file there is an insn (define_insn abssf2 (clobber (match_scratch 2 "")) the %2 register is allocated as r0 in the real code. My problem is that i want other than r0 to be allocated for operand 2. Please help how to do that. -- View this message in context: http://old.nabble.com/register-allocation-in-gcc-tp32672242p32672242.html Sent from the gcc - Dev mailing list archive at Nabble.com.
