Re: [Qemu-devel] Patch for compiling with GCC 4

2008-02-19 Thread Christian Roue
Thanks Thiemo.
I'll look at TCG, some more doc reading ahead apparently.

Bye
Chris

On Feb 18, 2008 9:49 PM, Thiemo Seufer [EMAIL PROTECTED] wrote:
 Alexander Graf wrote:
 
  On Feb 17, 2008, at 9:22 PM, Christian Roue wrote:
 
  Well, I somehow felt like it was a bit brutal and probably fixing the
  symptoms which is apparently the case.
  Looking more carefully, compile fails in :
  sh4-linux-user for function op_cmp_str_T0_T1
  gcc optimization leads to a ret followed by a last assignement with a
  jump back.
  I guess dyngen hopes to find function epilogue as the last bytes.
  It's apparently the only function where it happens.
 
  I found that adding gcc option -fno-tree-dominator-opts for sh4
  target avoids this (I suppose) unwanted optimization.
  It may be a bit brutal again ( disabling too many optims or wrong
  ones).
  May be the op_cmp_str_T0_T1 function can be rewritten to something
  that avoids this optimization.
  Am I on a better track ?
 
  This looks like the right approach to the symptoms. The real fix would
  be to move the sh4 target to TCG,

 The migration to tcg can be done gradually, fixing the immediate problem
 shouldn't get too involved.

  but for the meantime I believe this is
  the way to go. You can already find a lot of these unoptimization flags
  autodetected in the configure script, so I guess that'd be the right
  place for a patch.

 I added those as workarounds, they should rather go away than expand to
 cover even more flags.


 Thiemo







Re: [Qemu-devel] Patch for compiling with GCC 4

2008-02-18 Thread Christian Roue
Alex,
thanks for the hint.
I'll have a look at TCG.

Bye
Chris.


On Feb 18, 2008 1:07 PM, Alexander Graf [EMAIL PROTECTED] wrote:

 On Feb 17, 2008, at 9:22 PM, Christian Roue wrote:

  Well, I somehow felt like it was a bit brutal and probably fixing the
  symptoms which is apparently the case.
  Looking more carefully, compile fails in :
  sh4-linux-user for function op_cmp_str_T0_T1
  gcc optimization leads to a ret followed by a last assignement with
  a jump back.
  I guess dyngen hopes to find function epilogue as the last bytes.
  It's apparently the only function where it happens.
 
  I found that adding gcc option -fno-tree-dominator-opts for sh4
  target avoids this (I suppose) unwanted optimization.
  It may be a bit brutal again ( disabling too many optims or wrong
  ones).
  May be the op_cmp_str_T0_T1 function can be rewritten to something
  that avoids this optimization.
  Am I on a better track ?

 This looks like the right approach to the symptoms. The real fix
 would be to move the sh4 target to TCG, but for the meantime I believe
 this is the way to go. You can already find a lot of these
 unoptimization flags autodetected in the configure script, so I guess
 that'd be the right place for a patch.

 I am not sure if anybody with commit right listens, though.

 Regards,

 Alex


 
 
  Bye
  Chris.
 
 
  On Feb 16, 2008 9:01 PM, Paul Brook [EMAIL PROTECTED] wrote:
  On Saturday 16 February 2008, Christian Roue wrote:
  Hi all,
  I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2
  using
  --disable-gcc-check, I found compile fails as stated in configure
  before i
  disabled gcc check..
  Error message, points to a problem of dyngen not correctly detecting
  function ends on i386 when last instruction is a jump. I applied
  following
  change and successfully compiled/run qemu i386.  This extra test
  check for
  a relative backward jump  to function exit ret,
  gcc 4 apparently generates a few of these.
 
  You patch is wrong. The dyngen error is correct.
 
  Paul
 
 
 








Re: [Qemu-devel] Patch for compiling with GCC 4

2008-02-17 Thread Christian Roue
Well, I somehow felt like it was a bit brutal and probably fixing the
symptoms which is apparently the case.
Looking more carefully, compile fails in :
sh4-linux-user for function op_cmp_str_T0_T1
gcc optimization leads to a ret followed by a last assignement with a jump back.
I guess dyngen hopes to find function epilogue as the last bytes.
It's apparently the only function where it happens.

I found that adding gcc option -fno-tree-dominator-opts for sh4
target avoids this (I suppose) unwanted optimization.
It may be a bit brutal again ( disabling too many optims or wrong ones).
May be the op_cmp_str_T0_T1 function can be rewritten to something
that avoids this optimization.
Am I on a better track ?

Bye
Chris.


On Feb 16, 2008 9:01 PM, Paul Brook [EMAIL PROTECTED] wrote:
 On Saturday 16 February 2008, Christian Roue wrote:
  Hi all,
  I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2 using
  --disable-gcc-check, I found compile fails as stated in configure before i
  disabled gcc check..
  Error message, points to a problem of dyngen not correctly detecting
  function ends on i386 when last instruction is a jump. I applied following
  change and successfully compiled/run qemu i386.  This extra test check for
  a relative backward jump  to function exit ret,
  gcc 4 apparently generates a few of these.

 You patch is wrong. The dyngen error is correct.

 Paul





[Qemu-devel] Patch for compiling with GCC 4

2008-02-16 Thread Christian Roue
Hi all,
I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2 using
--disable-gcc-check, I found compile fails as stated in configure before i
disabled gcc check..
Error message, points to a problem of dyngen not correctly detecting
function ends on i386 when last instruction is a jump. I applied following
change and successfully compiled/run qemu i386.  This extra test check for
a relative backward jump  to function exit ret,
gcc 4 apparently generates a few of these.

My small change to cvs head is :

--- dyngen.c   2008-02-13 18:54:36.0 +0100
+++ dyngen.c2008-02-13 19:10:14.0 +0100
@@ -1474,7 +1474,7 @@
 len = p_end - p_start;
 if (len == 0)
 error(empty code for %s, name);
-if (p_end[-1] == 0xc3) {
+if (p_end[-1] == 0xc3 || p_end[-2] == 0xeb) {
 len--;
 } else {
 error(ret or jmp expected at the end of %s, name);

Bye
Chris.