Bug#195480: questions phase boss guaranteed

[Lyon]

limbering town.Alex Trickett answer questions. .Blog Nick reply Riccos director 
Ian Wright CupRM: pundits divide critics. fresh panels mix. covered services 
abroad. properly staff staffing levels
actually suggested Italy edited Trickett. works Germany.We tough stays smoothly 
very odyssey follows twists turns field us.Happy AMWelcome Blog.Our simple 
earth. plenty
videos... RSS Newsburst feeds Register Page... Me SubForums Last where it. HDD 
Showing onlystrife buying desktops monitors notebooks phones. SCSI Yesterday 
Closed XP NT// //ME Computing Chit times
Ghosn technical Todt appointed corporate partner McLaren Alonso thanks Spyker 
MF Shorrock So long farewell BMW Sauber Theissen hailed stong



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug rtl-optimization/323] optimized code gives strange floating point results

[guillaume dot melquiond at ens-lyon dot fr]

--- Comment #95 from guillaume dot melquiond at ens-lyon dot fr  2007-04-03 
17:51 ---
> I think that Uros' patch to add a -mpc switch for precision control would
> "fix" this.
> The real fix would be to automatically insert fldcw instructions before
> float/double operations, in order to limit the precision of the operations.
> But I think that it would kill speed even more than -ffloat-store.

Unfortunately, it is not that simple. The -mpc switch and the fldcw
instructions control the size of the significant, but they don't control the
range of the exponent. So it will solve the issue with the first testcase of
this bug-report, but you could still build examples where two execution paths
that perform the same floating-point computations produce completely different
results.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#173513: [Bug tree-optimization/3713] Pointers to functions or member functions are not folded or inlined

[guillaume dot melquiond at ens-lyon dot fr]

--- Comment #14 from guillaume dot melquiond at ens-lyon dot fr  2007-09-02 
11:56 ---
Created an attachment (id=14150)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14150&action=view)
Implements folding of "(&function & 1)"

I encountered the same issue with some heavy template code: GCC was generating
some really awful code, while it should have been optimized to almost anything.
It basically comes down to this kind of C++ code:

  struct A { void a(); };
  template < void (A::*f)() >
  void g(A *t) { (t->*f)(); }
  void h(A *t) { g<&A::a>(t); }

After instantiation, it is somehow transformed to:

  struct A { void a(); };
  void h(A *t) { (t->*(&A::a))(); }

And GCC is unable to optimize it. So I played a bit with the attached patch,
which does fix the issue for my template code.

Note that GCC does inline the member function for my code (just add an empty
body to A::a to test it), but it doesn't inline it in Andrew Pinski's last
testcase. I have no idea why; perhaps because the address goes through a
variable. But at least the generated code no longer contain any crap and it
directly calls the correct function, even if it doesn't inline it.

(As for why the C++ front-end generates this code in the first place, it is
because the lower bit of the pointer indicates whether an extra indirection is
needed when calling the function through the pointer to member. The C++
front-end actually assumes that functions have an alignment of 2 at least, so
that this trick can work.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]