[Bug c++/42576] GCC miscompiles switch statement (omits case label/block)

2010-01-01 Thread kgardas at objectsecurity dot com


--- Comment #1 from kgardas at objectsecurity dot com  2010-01-01 19:20 
---
Created an attachment (id=19438)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19438action=view)
MICO's head preprocessed typecode.cc file


-- 


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



[Bug c++/42576] GCC miscompiles switch statement (omits case label/block)

2010-01-01 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2010-01-01 19:21 ---
If tckind is really an enum, then the behavior of gcc is correct.


-- 


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



[Bug c++/42576] GCC miscompiles switch statement (omits case label/block)

2010-01-01 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2010-01-01 19:23 ---
And it is. ((int)0x) is ouside the range of the enum is gcc's behavior
is correct.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug c++/42576] GCC miscompiles switch statement (omits case label/block)

2010-01-01 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-01 19:43 ---
new TypeCode(TK_RECURSIVE); is undefined and TK_RECURSIVE will
be truncated to fit the enum.  That might be the issue that actually
breaks this.


-- 


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



[Bug c++/42576] GCC miscompiles switch statement (omits case label/block)

2010-01-01 Thread kgardas at objectsecurity dot com


--- Comment #5 from kgardas at objectsecurity dot com  2010-01-01 20:34 
---
yes, tckind is enum. Thanks for pointing out that this is MICO code issue. If
you also could be so kind and cite some C++/C language specification point
which GCC follows here and which all older GCC releases overlooked (or does
not implement support for) as does Sun's C++ and Intel C++ that would be great.
I find somehow silly that while using GCC 4.4.x (1) I'm able to assign
arbitrary value to enum type variable w/o any warning, (2) I'm able to use
arbitrary int for comparison with enum and (3) if I set enum variable value to
arbitrary integer I'm able to use this arbitrary integer in `if/else'
comparison successfully so the assignment nor comparison is not truncated to
enum value IMHO, yet still it does omit my arbitrary integer from switch/case.
Isn't this kind of strange? Thanks!


-- 


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