2016-04-18 11:53 GMT+03:00 Senthil Kumar Selvaraj
:
> Hi,
>
> While tracking down a performance regression for the AVR target from
> 4.9.x to trunk, I noticed that failing the SHRINK_WRAPPING_ENABLED
> check in ira.c led to noticeably worse code for the following
> case. That check prevents
2015-04-18 22:15 GMT+03:00 Ralph Doncaster :
> On a x86_64 linux box I successfully built a gcc RC-20150418 toolchain
> including binutils-2.25 and avr-libc r2473(svn).
>
> I noticed some warnings in the logs:
> ../../../source/gcc-5.0.1-RC-20150418/gcc/vec.h:1048: warning: invalid
> access to non-
2014-10-21 21:18 GMT+04:00 Joern Rennecke :
> In __do_global_dtors, I ended up changing the order of execution
> in order to get back to the forwards/backwards order as found in
> crtstuff.c
> The patch I attached to target/63223 is actually an extract from this patch.
Approved.
Denis.
2014-04-30 1:29 GMT+04:00 Tom de Vries :
> Denis,
>
> when building gcc for avr with --enable-checking=yes,rtl , I run into the
> following error:
> ...
> /home/vries/gcc_versions/devel/src/libgcc/unwind-c.c: In function
> ‘__gcc_personality_sj0’:
> /home/vries/gcc_versions/devel/src/libgcc/unwind-
2014-03-03 21:01 GMT+04:00 David Edelsohn :
> On Mon, Mar 3, 2014 at 7:04 AM, Denis Chertykov wrote:
>> 2014-03-03 15:35 GMT+04:00 David Brown :
>>> On 02/03/14 19:24, Denis Chertykov wrote:
>>>> I would remove two maintainers for AVR port:
>>>> 1
2014-03-03 15:35 GMT+04:00 David Brown :
> On 02/03/14 19:24, Denis Chertykov wrote:
>> I would remove two maintainers for AVR port:
>> 1. Anatoly Sokolov
>> 2. Eric Weddington
>>
>> I have discussed the removal with Anatoly Sokolov and he is agree with it.
&g
I would remove two maintainers for AVR port:
1. Anatoly Sokolov
2. Eric Weddington
I have discussed the removal with Anatoly Sokolov and he is agree with it.
I can't discuss the removal with Eric Weddington because his mail
address invalid.
Must somebody approve the removal ? (Or I can just ap
2013/7/5 Paulo Matos
>
> Hi,
>
> I am convinced that what I am about to ask is not possible but I would like
> someone to confirm this.
>
> Can I define in an insn a register constraint that depends on another
> register value?
> So, for
> (set (match_operand:SI 0 "register_operand" "r")
>
2011/12/13 Joel Sherrill :
> Hi,
>
> From an RTEMS perspective, the head has multiple regressions from the 4.6
> branch. avr, bfin, lm32 and m68k have regressions such that they are
> incapable of compiling a complete tool chain. This means they fail to
> compile gcc, newlib, or RTEMS. These are th
2011/11/29 Georg-Johann Lay :
> Ian Lance Taylor wrote:
>> Georg-Johann Lay writes:
>>
>>> So if a frontend can define address spaces and it is a generic feature, the
>>> question is how to get the name of an address space in a generic, language
>>> independent way.
>>
>> We could decide that all
2011/10/25 Georg-Johann Lay :
> With the following, small C test program
>
>
> typedef struct
> {
> unsigned char a, b, c, d;
> } s_t;
>
> unsigned char func1 (s_t *x, s_t *y, s_t *z)
> {
> unsigned char s = 0;
> s += x->a;
> s += y->a;
> s += z->a;
>
> s += x->b;
> s += y->b;
2011/9/28 Georg-Johann Lay :
> Georg-Johann Lay schrieb:
>> This is a tentative patch for better support of logging information for avr
>> BE
>> developers.
>>
>> [...]
>>
>> * config/avr/avr-protos.h (avr_edump, avr_fdump): New macros.
>> (avr__set_caller_e, avr__set_caller_f): New pr
2011/8/4 Xinliang David Li :
> +Mark who has done size optimization tuning with FDO.
>
> On Thu, Aug 4, 2011 at 7:05 AM, Mike Hommey wrote:
>> Hi,
>>
>> We (Mozilla) are trying to get the best of the ARM toolchain for our
>> Android build. I recently built an Android Native-code Development Kit
>>
2011/7/8 Georg-Johann Lay :
> Denis Chertykov wrote:
>> 2011/7/7 Georg-Johann Lay:
>>> Hi Denis.
>>
>> I think that it's a good question to discuss inside gcc mailing list.
>> May be somebody more qualified person give a better suggestion than me.
>
2011/4/4 Georg-Johann Lay :
>
> avr-gcc bar.c -da -S -Os -dp
>
> == configuration
>
> Target: avr
> Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
> --prefix=some-prefix --enable-languages=c,c++ --disable-libssp
> --disable-libada --disable-nls --disable-shared
> Thread model: sing
2011/3/21 Georg-Johann Lay :
> Denis Chertykov schrieb:
>> 2011/3/20 Georg-Johann Lay :
>>> The AVR controller basically has two kinds of hard registers:
>>>
>>> * LD_REGS (constraint "d") that can move immediates
>>> * NO_LD_REGS (constraint
2011/3/20 Georg-Johann Lay :
> The AVR controller basically has two kinds of hard registers:
>
> * LD_REGS (constraint "d") that can move immediates
> * NO_LD_REGS (constraint "l") that cannot move immediates
>
> movsi insn of avr backend does not supply an "l,i" constraint alternative,
> so that r
2011/2/28 Georg-Johann Lay :
> Denis Chertykov schrieb:
>>
>> 2011/2/26 Georg-Johann Lay :
>>
>>> Ok, this is the patch I meant:
>>>
>>> http://gcc.gnu.org/viewcvs?view=revision&revision=86842
>>>
>>> it allows just Pmod
2011/2/26 Georg-Johann Lay :
> Georg-Johann Lay schrieb:
>>
>> Denis Chertykov schrieb:
>>
>>> 2011/2/26 Georg Johann Lay
>>>
>>>> Eric Botcazou schrieb:
>>>>
>>>>>> What does "word" mean here?
2011/2/26 Georg Johann Lay
>
> Eric Botcazou schrieb:
>>>
>>> What does "word" mean here? Is it a 32-bit entity or is it according to
>>> word_mode which is QImode for avr?
>>
>> The latter, it is machine-dependent.
>>
>>
>>> So the same should be true for QI-subregs of scalar modes if
>>> UNITS_P
2011/2/7 Joel Sherrill :
>
> There are two targets which cannot build C -- avr and lm32:
>
> + avr - http://gcc.gnu.org/PR47534
I have committed the fix r169896
Please somebody close the bug.
I can't login to bugzilla. (Probably I forgot my login and password)
Denis.
2010/8/1 redriver jiang :
> Hi Denis,
>
> I read the "out_movqi_r_mr" code of the AVR port. I see that following
> exception are
>
> handled:
>
> 1. "REG_X+offset", which is not supported by AVR.
> 2. "REGY+offset", with offset larger than 63, which is not supported by AVR.
>
> Seems reload can not
2010/7/31 redriver jiang :
> Hi,
>
> Seems there are still some exceptions.
>
> During my testing, the compiler complains:
>
> ./os_core.c: In function 'OS_EventTaskWait':
> ./os_core.c:747: error: unable to find a register to spill in class
> 'POINTER_REGS'
> ./os_core.c:747: error: this is the in
2009/12/31 Weddington, Eric :
>
>
>> -Original Message-
>> From: Andrew Hutchinson [mailto:andrewhutchin...@cox.net]
>> Sent: Wednesday, December 30, 2009 4:34 PM
>> To: Richard Guenther
>> Cc: Dave Korn; Rafael Espindola; GCC Development; Weddington,
2009/6/16 Ian Lance Taylor :
> Tomasz Francuz writes:
>
>> I would like to change gcc so AVR C++ port will use FLASH memory
>> instead of SRAM to store virtual function pointers. Does anyone try to
>> do it? I have no experience as gcc developer, so can you head me to
>> appropriate files/literatu
2009/3/13 Paolo Bonzini :
> These are all the !SHIFT_COUNT_TRUNCATED targets.
>
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
>
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact.
2009/2/17 Ian Lance Taylor :
>
> The problem with reload is that it interferes with register allocation.
> Even if gcc had a perfect register allocator, we would still generate
> suboptimal code because reload would mess up the allocation. The key to
> solving that problem is that we need to do in
2009/1/9 Sean D'Epagnier :
> 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 p
2008/12/16 Georg-Johann Lay :
> Hi,
>
> ./gcc/config/avr/avr.md
>
> defines andsi3 as follows:
[...]
>
> For alternative 1 "d,0,i" the effect on cc_status is described as set_n.
> However, if the high byte of [2] is 0xff, then the PSW (i.e. SREG.N)
> does not contain the MSB of the result.
>
> I di
2008/5/29 <[EMAIL PROTECTED]>:
> Again thank you and Denis for your comment.
>
> Here is what I deduce from code and Denis comments - I am sure he (and
> others) will correct me if wrong :-)
>
>
> The main issue is that we have one pointer register that cannot take offset
> and two base pointers
2008/5/29 Jeff Law <[EMAIL PROTECTED]>:
> Richard Sandiford wrote:
>>
>> Andy H <[EMAIL PROTECTED]> writes:
If L_R_A does nothing with it,
the normal reload handling will first try:
(const:HI (plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int 2
>>>
>>> This worke
2008/5/20 Ian Lance Taylor <[EMAIL PROTECTED]>:
> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>
>> For the 16 bit target that i am currently porting can have only
>> positive offsets less than 0x100. (unsigned 8 bit) for offset
>> addressing mode.
>
> I would expect reload to be able to handle this
Hi All.
Right now the AVR port have two maintainers Denis Chertykov
and Marek Michalkiewicz.
The AVR community ask me to add Anatoly Sokolov <[EMAIL PROTECTED]> as avr
maintainer and Marek asked to remove him.
How to do that ?
Denis.
Hi Ulrich.
Few months ago I has analyzed PR19636 (avr specific bug) and found
that it's a reload related problem. I has started the thread
http://gcc.gnu.org/ml/gcc/2006-02/msg00213.html but nobody commented the
problem.
Can you comment the problem as reload maintainer ?
Denis.
Denis Chertykov <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
>
> > Denis Chertykov <[EMAIL PROTECTED]> writes:
> >
> > > > > I think that better to call update_eliminables() somewhere after
> > > > > setup_save_areas()
>
Ian Lance Taylor writes:
> Denis Chertykov <[EMAIL PROTECTED]> writes:
>
> > > > I think that better to call update_eliminables() somewhere after
> > > > setup_save_areas()
> > >
> > > Exactly. We do that. About 15 lines after the lines
Ian Lance Taylor writes:
[...]
>
> > I think that better to call update_eliminables() somewhere after
> > setup_save_areas()
>
> Exactly. We do that. About 15 lines after the lines you quoted
> above.
>
> What am I missing?
I'm (exactly AVR port) need in call to update_eliminables() somew
Eric Christopher <[EMAIL PROTECTED]> writes:
> On Feb 13, 2006, at 7:43 AM, Denis Chertykov wrote:
>
> > Hi All.
> >
> > While I have debugging AVR target bug I found that something wrong in
> > port code or in reload.
> >
> > Is it right to us
Hi All.
While I have debugging AVR target bug I found that something wrong in
port code or in reload.
Is it right to use of get_frame_size() inside CAN_ELIMINATE macro valid ?
If yes then reload have a bug.
If no then AVR and probably MIPS ports have invalid definitions of
CAN_ELIMINATE.
Denis.
"Anatoly Sokolov" <[EMAIL PROTECTED]> writes:
> Hello.
>
> I am the member of the project 'avr-libc' (AVR C Runtime Library). As
> a result of this work there were patches with additions of support of
> new Atmel devices in gcc the toolchain. I have a desire to add them in
> official GCC sources,
Ian Lance Taylor writes:
> The current reload pass includes general heuristics to handle
> reloading memory addresses. This code knows things like "if stack
> pointer plus displacement is not a valid memory address, try loading
> the displacement into a register." Many targets currently rely on
"Joel Sherrill <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> writes:
[...]
> ../../../../../../gcc-head-test/newlib/libc/misc/init.c
> ../../../../../../gcc-head-test/newlib/libc/misc/init.c: In function
> '__libc_fini_array':
> ../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: error:
> una
Marek Michalkiewicz <[EMAIL PROTECTED]> writes:
> On Sun, Mar 20, 2005 at 04:29:01PM -0800, Richard Henderson wrote:
>
> > The easiest way is to do this in the linker instead of the compiler.
> > See the xstormy16 port and how it handles R_XSTORMY16_FPTR16. This
> > has the distinct advantage th
Paul Schlie <[EMAIL PROTECTED]> writes:
> > From: Denis Chertykov <[EMAIL PROTECTED]>
> >> - possibly something like: ?
> >>
> >> (define_insn "*addhi3"
> >> [(set (match_operand:HI 0 ...)
> >>(
Richard Henderson <[EMAIL PROTECTED]> writes:
> On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote:
> > The reload will generate addhi3 and reload will have a problem with
> > two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad
> > surprise f
Paul Schlie <[EMAIL PROTECTED]> writes:
[...]
>
> > I think that better to support
> > cmpHI, cbranch -> cmpQI1_set_CC, cmpQI2_use_CC, cbranch. because
> > AVR is a microcontroller and code size more important than code speed.
>
> - I fully agree that code-size tends to be most important, wh
Bernardo Innocenti <[EMAIL PROTECTED]> writes:
> Denis Chertykov wrote:
>
> > I have converted the AVR port from CC0 to CCmode.
>
> That's indeed very good news. Incidentally, CC0
> conversion of the AVR target was being discussed
> in an off-list thread with
Paul Schlie <[EMAIL PROTECTED]> writes:
> > From: Denis Chertykov <[EMAIL PROTECTED]>
> >> Paul Schlie <[EMAIL PROTECTED]> writes:
> >>> Denis wrote:
> >>> I have converted the AVR port from CC0 to CCmode.
> >>> But may
Paul Schlie <[EMAIL PROTECTED]> writes:
> > Denis wrote:
> > I have converted the AVR port from CC0 to CCmode.
> > But may be I have converted the port in wrong way.
> > (It's because I was interested in *this* way.)
> >
> > I have used CCmode register and havn't added the
> > '(clobber (reg:QI C
Hi All!
I have converted the AVR port from CC0 to CCmode.
But may be I have converted the port in wrong way.
(It's because I was interested in *this* way.)
I have used CCmode register and havn't added the
'(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the
CC_REGNUM just because AV
50 matches
Mail list logo
