--- Comment #8 from hubicka at gcc dot gnu dot org 2005-11-03 22:54 ---
Actually the code 4.1 in comment #5 should execute faster on true i686. It is
longer and will trigger partial memory stalls on later chips.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:12
---
Leaving as P2.
I've seen reports of similar bitfield problems on a variety of problems. This
kind of code doesn't show up much in scientific computing, but it does show up
in network applications,
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-27 00:20 ---
Hmm, this is truely all bit-field issues.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
What|Removed |Added
Target Milestone|4.0.2 |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-25 02:49 ---
This message:
http://gcc.gnu.org/ml/gcc/2005-08/msg00208.html
was asking for the reason for the slowdown for S05e
AFAICT the inner loop for the benchmark (in s05e_test) gets compiled to:
--- Additional Comments From danalis at cis dot udel dot edu 2005-08-04
19:16 ---
For the record the reduced test case was derived from h07.cpp of bench++
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-22
21:12 ---
Moving to 4.0.2 pre Mark.
--
What|Removed |Added
Target Milestone|3.4.5
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-19
19:53 ---
There are a couple problems here, first we don't move the store to b_rec out
side of the loop. Doing
that on the mainline, we remove the loop as it is now unswitchable and really
just empty.
In fact
