--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-17 12:31 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from jakub at gcc dot gnu dot org 2006-02-17 08:58 ---
Subject: Bug 26300
Author: jakub
Date: Fri Feb 17 08:58:46 2006
New Revision: 76
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=76
Log:
PR middle-end/26300
* combine.c (make_extraction)
--- Comment #5 from jakub at gcc dot gnu dot org 2006-02-15 20:41 ---
Subject: Bug 26300
Author: jakub
Date: Wed Feb 15 20:41:03 2006
New Revision: 16
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=16
Log:
PR middle-end/26300
* combine.c (make_extraction)
--- Comment #4 from jakub at gcc dot gnu dot org 2006-02-15 14:55 ---
Well, undefined behavior only if you reach it.
The original code looked like:
if (((type) == (Qnothing)))
return IMAGE_NOTHING;
if (((type) == (Qtext)))
return IMAGE_TEXT;
if (((type) == (Qmono_pixmap)))
retur
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-15 14:47 ---
Anyways patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01222.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26300
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-15 14:47 ---
Confirmed, this is undefined behavior anyways so I don't think we should block
4.1 for this code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from jakub at gcc dot gnu dot org 2006-02-15 11:25 ---
What happens is that first dom1 splits the 1 << (f4 (...) - 1) shift into
1 << (3 - 1) and 1 << (0 - 1) branches depending on if fn3 (r)->e == u or not.
The latter triggers undefined behavior, but if the 1 << (3 - 1) b
