error linking lto1 for target avr

I have the latest gcc from svn, and with configure --target=avr --enable-languages=c: When building with make eventually I get: gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes

Re: fixed-point support in c++

On 3/19/10, Dave Korn dave.korn.cyg...@googlemail.com 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

Re: fixed-point support in c++

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

fixed-point support in c++

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

Re: generic bug in fixed-point constant folding

Hi, I found a few more cases that still cause internal compiler errors, I managed to fix them. I have attached an updated patch. Sean On Tue, Mar 17, 2009 at 12:45 PM, Fu, Chao-Ying f...@mips.com wrote: Sean D'Epagnier wrote: I think I found a generic problem for fixed point constant

generic bug in fixed-point constant folding

Hi, I think I found a generic problem for fixed point constant folding. In fold-const.c:11872 gcc tries to apply: /* Transform (x c) c into x (-1c), or transform (x c) c into x ((unsigned)-1 c) for unsigned types. */ I attached a simple patch which fixes the problem by

type promotion for fixed point types

Hi, I just added support for printf and scanf of fixed point types to avr libc. I wanted to handle: Currently accum and fract work, but not short accum or short fract This is not a problem for integers currently since they get type promoted when passed with stdarg. There is nothing in the

putting operands in MEM even with register_operand predicate

Hi, I have a rule in machine descriptor: (define_insn fractFIXED2:modeFIXED1:mode2 [(set (match_operand:FIXED1 0 register_operand ) (fract_convert:FIXED1 (match_operand:FIXED2 1 register_operand )))] * return fract_out (insn, operands, 1, NULL); [(set_attr cc clobber)])

having trouble with define_split

Hi, I am currently working on adding native fixed-point support to the avr backend. A lot of stuff is working, but there are a few things left, one of them is conversions from fixed point to floating point. I have conversions between all integer and fixed point types working as well as SA to SF

writing md rules for fixed-point conversion

I am working toward efficient support of some of the sfixed point types on avr architecture. I started out by writing an assembly library to handle all of the conversions to and from various fixed point, integer, and floating point types. In many cases the functions are only 1 or 2 instructions,

Re: trying to fix a bug in m6812 front-end

Hi, I changed: (match_operand:HI 2 general_operand )))] to (match_operand:HI 2 splitable_operand )))] as suggested, and the problem seems to be solved! I posted a bug report the the m68hc1x site, I will post a follow up. Thanks, Sean D'Epagnier

trying to fix a bug in m6812 front-end

are much appreciated. -- Sean D'Epagnier