--- Comment #21 from mikpe at it dot uu dot se 2010-06-21 11:18 ---
(In reply to comment #20)
> (In reply to comment #19)
> > Configuration options for i386-linux and x86_64-linux hosts for both
> > binutils and gcc would be very much appreciated.
>
> I don't know if you can build the c
--- Comment #20 from mikpe at it dot uu dot se 2010-06-21 10:44 ---
(In reply to comment #19)
> Configuration options for i386-linux and x86_64-linux hosts for both
> binutils and gcc would be very much appreciated.
I don't know if you can build the c++ frontend without libstdc++, but t
--- Comment #19 from jamborm at gcc dot gnu dot org 2010-06-21 08:29
---
(In reply to comment #16)
> (In reply to comment #15)
> > ... I cannot reproduce the problem.
> I can send you either the compiler binaries (hosts: cygwin/linux i386/linux
> x64/darwin x64) or the configuration opt
--- Comment #18 from mikpe at it dot uu dot se 2010-06-20 18:26 ---
(In reply to comment #5)
> Unfortunately I don't see this happening on the x86_64-linux ->
> arm-linux-gnueabi cross compiler I built for myself.
You need to build a cross to arm-eabi not arm-linux-gnueabi to see the bu
--- Comment #17 from eblot dot ml at gmail dot com 2010-06-20 17:02 ---
Created an attachment (id=20947)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20947&action=view)
File output with -fdump-tree-all option switch
Here are the requested tree dumps
--
http://gcc.gnu.org/bug
--- Comment #16 from eblot dot ml at gmail dot com 2010-06-20 16:57 ---
(In reply to comment #15)
> ... I cannot reproduce the problem.
I can send you either the compiler binaries (hosts: cygwin/linux i386/linux
x64/darwin x64) or the configuration options to build the binutils and the
c
--- Comment #15 from jamborm at gcc dot gnu dot org 2010-06-20 16:50
---
(In reply to comment #14)
>
> Let me know how to proceed if you need more dumps.
Well, at this point I'd generate all tree dumps with -fdump-tree-all
and start looking through them. You can tar-gzip them and att
--- Comment #14 from eblot dot ml at gmail dot com 2010-06-20 13:53 ---
(In reply to comment #10)
> I'd suggest generating all dumps, going through them and looking where
and why the if statement disappears and how the switch statement
evolved before being removed by switch conversion.
--- Comment #13 from eblot dot ml at gmail dot com 2010-06-17 16:41 ---
(In reply to comment #10)
> When I use -fshort-enums my dumps specifically state unsigned char.
> But I assume that char is actually unsigned here by default.
AAPCS specifies the following (7.1.1)
C/C++ type: M
--- Comment #12 from jamborm at gcc dot gnu dot org 2010-06-17 16:37
---
(In reply to comment #11)
> (In reply to comment #10)
> > > With -fno-tree-switch-conversion switch option switch, the bug does not
> > > appear.
> > Really? See below...
>
> Below is the dump WITHOUT the `-fno-
--- Comment #11 from eblot dot ml at gmail dot com 2010-06-17 16:34 ---
(In reply to comment #10)
> > With -fno-tree-switch-conversion switch option switch, the bug does not
> > appear.
> Really? See below...
Below is the dump WITHOUT the `-fno-tree-switch-conversion`
I did not unders
--- Comment #10 from jamborm at gcc dot gnu dot org 2010-06-17 15:00
---
(In reply to comment #7)
> (In reply to comment #5)
> > Could you please first try to reproduce the bug with the
> > -fno-tree-switch-conversion swithch?
>
> Using GCC 4.5.0 (tarball)
>
> With -fno-tree-switch-c
--- Comment #9 from jamborm at gcc dot gnu dot org 2010-06-17 14:02 ---
(In reply to comment #8)
> Subject: Re: switch/case optimization produces an invalid lookup table index
>
> I bet it could be reproduced on any target with -fshort-enums.
>
Unfortunately no, this switch does not
--- Comment #8 from pinskia at gmail dot com 2010-06-17 09:37 ---
Subject: Re: switch/case optimization produces an invalid lookup table index
I bet it could be reproduced on any target with -fshort-enums.
On Jun 17, 2010, at 2:20 AM, "eblot dot ml at gmail dot com"
wrote:
>
>
> ---
I bet it could be reproduced on any target with -fshort-enums.
On Jun 17, 2010, at 2:20 AM, "eblot dot ml at gmail dot com" > wrote:
--- Comment #6 from eblot dot ml at gmail dot com 2010-06-17
09:20 ---
(In reply to comment #5)
Unfortunately I don't see this happening on the x8
--- Comment #7 from eblot dot ml at gmail dot com 2010-06-17 09:34 ---
(In reply to comment #5)
> Could you please first try to reproduce the bug with the
> -fno-tree-switch-conversion swithch?
Using GCC 4.5.0 (tarball)
With -fno-tree-switch-conversion switch option switch, the bug do
--- Comment #6 from eblot dot ml at gmail dot com 2010-06-17 09:20 ---
(In reply to comment #5)
> Unfortunately I don't see this happening on the x86_64-linux ->
> arm-linux-gnueabi cross compiler I built for myself. The generated
> assembly has all four elements in the initialization o
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-06-15 15:08 ---
Unfortunately I don't see this happening on the x86_64-linux ->
arm-linux-gnueabi cross compiler I built for myself. The generated
assembly has all four elements in the initialization of CSWTCH.2 and
the intermediat
--- Comment #4 from eblot dot ml at gmail dot com 2010-06-04 23:41 ---
(fixing up description)
--
eblot dot ml at gmail dot com changed:
What|Removed |Added
Su
19 matches
Mail list logo
