--- Comment #15 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
22:12 ---
(In reply to comment #13)
> (In reply to comment #11)
> > The main concern on the recent LKML thread appeared to be code size rather
> > than
> > speed.
> One should note th
--- Comment #14 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
22:08 ---
(In reply to comment #7)
> One should note this is actually hard to do without changing the code for 3506
> also.
And of course if the volatile variable in the 3506 example code was an MMIO
re
--- Comment #12 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:23 ---
(In reply to comment #9)
> s/debian/Ubuntu/
Please accept my apologies for skipping that step -- I wasn't aware of this.
Should I replicate this bug at Ubuntu, or is this strictly advice fo
--- Comment #11 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:21 ---
(In reply to comment #10)
> Actually as I understand it, the expanded version is slightly faster under
> newer x86's anyways as they don't have an extra decode stage.
The main conce
--- Comment #6 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:04 ---
(In reply to comment #4)
> It is still the same issue.
Perhaps I am missing something, but I don't know of any hardware that would
react differently to this two-instruction sequence:
m
--- Comment #2 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
00:11 ---
Hmmm... I wasn't asking for volatile to be atomic, just for it to avoid
generating unnecessary code.
--
paulmck at linux dot vnet dot ibm dot com changed:
What|Re
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paulmck at linux dot vnet dot ibm dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
