On 13/04/2010 16:06, Sean D'Epagnier wrote:
> Would the patch I have be ok if I get the same results?
Yes, absolutely; we insist only on no regressions, i.e. the patch mustn't
increase the number of fails. Most targets have the odd outstanding failure
or two. So there's no reason not to go
On 3/19/10, Dave Korn wrote:
> On 16/03/2010 09:15, Sean D'Epagnier wrote:
>
> Do you have a copyright assignment on file for GCC? For a non-trivial
> contribution of this size, it's a requirement before the patch can be
> accepted.
>
Yes this should be fine.
> Once that is established, you
On 16/03/2010 09:15, Sean D'Epagnier wrote:
> I went through the c++ parser and added support for fixed point there.
> Everything seems to be working, and I am able to use fixed-point
> numbers in c++.
>
> The c++ parser is kind of complex and it is possible I missed
> something. I would love t
> The problem is that it won't be as simple as that. You'll have to extend
> the C++ parser to accept those new RID_ values that it was previously never
> expecting to see in those contexts, I would think (but haven't verified
> against the source yet). The C++ parser is a hand-coded recursive-
On 15/03/2010 22:03, Sean D'Epagnier wrote:
> - { "_Fract", RID_FRACT, D_CONLY | D_EXT },
> - { "_Accum", RID_ACCUM, D_CONLY | D_EXT },
> - { "_Sat", RID_SAT, D_CONLY | D_EXT },
> + { "_Fract", RID_FRACT, D_EXT },
> + { "_Accum",
It looks like my patches for avr target to get native fixed-point
support may be included soon. I realized that many users use avr-g++
for their projects, and I cannot get the fixed point types working in
c++. The question is generic and should apply to all targets.
Compiling a simple test prog
