Richard Sandiford schrieb:
> Georg-Johann Lay writes:
>> 1) The internals just mention TARGET_SECONDARY_RELOAD for REG-MEM and
>> for REG-REG moves, no word about REG-CONST moves. So is using
>> secondary reloads for CONST_INT (or other consts) like outlined
>&
Richard Sandiford schrieb:
Georg-Johann Lay writes:
2) The secondary reload hook is always called with
regclass = GENERAL_REGS, even in cases where the class
is known to be NO_LD_REGS like, e.g. when preparing arguments
for a function call. Why this? I would expect to get the
With the changed IRA there occurs assertion failure of some inline
asm, find precompiled source attached. Seem as if something goes wrong
with FP elimination. The precompiled source is from avr-libc and
compiled fine with older versions/revisions.
avr-gcc 4.7.0 as of SVN 171824, configured
../../g
With new versions of gcc from trunk (like last snapshot SVN 171894), I
observe very bad code from register allocator.
As a test case assume
bar.c:
int a (void);
int b (void)
{
return a()+1;
}
which, on avr, could be compiled as
b:
.L__stack_usage = 0
rcall a ; 6 *call_value_in
Richard Sandiford schrieb:
> Georg-Johann Lay writes:
>> With new versions of gcc from trunk (like last snapshot SVN 171894), I
>> observe very bad code from register allocator.
>
> Could you check whether:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02053.
Added myself to MAINTAINERS.
Please update your MAINTAINERS file.
Johann
Index: ChangeLog
===
--- ChangeLog (Revision 172381)
+++ ChangeLog (Revision 172382)
@@ -1,3 +1,7 @@
+2011-04-13 Georg-Johann Lay
The following code is a testcase for avr where reload generates wrong
code:
struct S
{
unsigned char a, b;
} ab = {12, 34};
void yoo (struct S y)
{
__asm volatile ("ldi %B0, 56" : "+y" (y));
y.a = 0;
__asm volatile ("; y = %0" : "+y" (y));
ab = y;
}
The asm just serves to dir
In viewvc's colored diff views, there is no CSS class defined for
changed lines
One example:
http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/libgcc.S?r1=172384&r2=172383&pathrev=172384&diff_format=h
The "removed" lines have a red background and can be seen easily.
But the "changed" lines have
H.J. Lu schrieb:
My target needs a scratch register to store a register in one register class
and it needs to use memory to copy from one register class to another.
I have store and reload_out patterns for those registers. When reload
tries to copy data from one register class to another, it jus
H.J. Lu schrieb:
> On Sat, Apr 30, 2011 at 6:18 AM, Georg-Johann Lay wrote:
>> H.J. Lu schrieb:
>>> My target needs a scratch register to store a register in one register
>>> class
>>> and it needs to use memory to copy from one register class to another.
>
Pat Haugen schrieb:
I'm seeing some odd behavior in ira for PowerPC, starting with the big
ira merge best I can tell (r171649).
void foo(float *f1, float*f2) {
*f1 = *f2;
}
If I compile with gcc -S -m64 -O3 -mcpu=power7 and look at the ira dump,
I see that the pseudo used to copy the data,
Trying to track faulty code generation because of a missing input
reload, I got lost in reload and need some help.
The insn to reload (insn 7) is
(set (subreg:QI (reg:HI 28) 0)
(const_int 0))
This insn generates one output reload (.ira dump)
Reloads for insn # 7
Reload 0: reload_out (HI) =
Georg-Johann Lay wrote:
> so there is a missing input reload, i.e. prior to insn 7 there must be
> something like
>
> (set (reg:HI 28)
> (reg:HI 24))
>
Typo, that should read:
(set (reg:HI 24)
(reg:HI 28))
prior to insn 7.
Eric Botcazou schrieb:
Perhaps the original subreg shouldn't have been there?
Yes, I'd think that everything in the RTL middle-end expects word-mode subregs
of double-word-mode hard regs to be simplifiable.
You are right, I was staring at the wrong place. subreg of hardreg
should not be th
Eric Botcazou schrieb:
>> You are right, I was staring at the wrong place. subreg of hardreg
>> should not be there.
>
> You can take a look at PR target/48830, this is a related problem for the
> SPARC where reload generates:
>
> (set (reg:SI 708 [ D.2989+4 ])
> (subreg:SI (reg:DI 72 %f40)
Bernd Schmidt schrieb:
> On 06/01/2011 04:00 PM, Georg-Johann Lay wrote:
>> Eric Botcazou schrieb:
>>>> You are right, I was staring at the wrong place. subreg of hardreg
>>>> should not be there.
>>> You can take a look at PR target/48830, this is a relat
Bernd Schmidt schrieb:
> On 06/01/2011 05:35 PM, Georg-Johann Lay wrote:
>
>> The reason for why a subreg of hardreg is there during reload is that
>> on avr, r29:r28 is the frame pointer (word_mode is QI and Pmode is
>> HI). Because in many places of the compiler,
Hi, I intend to add some assembler sources to libgcc build.
Using the straight forward way in ./gcc/config/avr/t-avr
@ -52,7 +50,30 @@ LIB1ASMFUNCS = \
...
+ _ffssi2 \
+ _ffshi2 \
+ _loop_ffsqi2 \
+ _ctzsi2 \
+ _ctzhi2 \
+ _clzdi2 \
+ _clzsi2 \
+ _c
Georg-Johann Lay schrieb:
> Hi, I intend to add some assembler sources to libgcc build.
>
> Using the straight forward way in ./gcc/config/avr/t-avr
>
> @ -52,7 +50,30 @@ LIB1ASMFUNCS = \
> ...
> + _ffssi2 \
> + _ffshi2 \
> + _loop_ffsqi2 \
> +
Ian Lance Taylor schrieb:
> Georg-Johann Lay writes:
>
>> Am I something missing? Adding fragments to LIB1ASMFUNCS should filter
>> them out in filter-out.
>
> I think the problem is that libgcc/config/avr/t-avr does not filter
> LIB1ASMFUNCS out of the lists it g
Ian Lance Taylor schrieb:
> Georg-Johann Lay writes:
>
>> Ian Lance Taylor schrieb:
>>> Georg-Johann Lay writes:
>>>
>> Wondering why there is now just another t-target, both t-targets
>> containing snips of libgcc.
>
> There is a very slo
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.dg/unroll_1.c?view=markup&pathrev=174762
Since several days now I observe Python exceptions in viewcvs ike that:
An Exception Has Occurred
Python Traceback
Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/viewvc/lib/v
As I don't know where to report and viewcvs still breaks, CCing overseers.
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.dg/unroll_1.c?view=markup&pathrev=174762
> http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.dg/unroll_1.c?view=markup&pathrev=174762
>
> Since several days now I observ
Vincent Legoll wrote:
> On Fri, Jun 24, 2011 at 12:01 PM, Georg-Johann Lay <...@...> wrote:
Would you please avoid quoting email addresses in mailing lists?
Thanks, Johann.
Lu, John schrieb:
Hi,
I'm trying to utilize the clz pattern:
(define_insn "clzhi2"
[(set (match_operand:HI 0 "register_operand" "=r")
(clz:HI (match_operand:HI 1 "register_operand" "r")))]
""
"cntlz %0 %1")
I can build a compiler successfully with this pattern, but I
can'
Ian Lance Taylor schrieb:
Vincent Legoll writes:
This may be the changeset that broke pygments running on older
pythons (< 2.4):
https://bitbucket.org/birkenfeld/pygments-main/changeset/8d3fbbf1ffdb
Thanks for identifying the patch. I applied the reverse patch manually
to gcc.gnu.org, and t
Hi,
I am on 4.7 trunk (175991)
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared
--enable-languages=c,c++ --with-dwarf2 --disable-lto
Suppose the following source from gcc.c-torture/compile/pr30338.c:
extern char *
Jakub Jelinek wrote:
> On Fri, Jul 08, 2011 at 02:36:23PM +0200, Georg-Johann Lay wrote:
>> I am on 4.7 trunk (175991)
>>
>> Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
>> --prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared
>>
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.
...bringing this over to gcc mailing list
>> I thin
Jeff Law wrote:
> On 07/08/11 11:07, DJ Delorie wrote:
>> Is there an unwritten rule that the frame pointer must be a single
>> hard register? I'm working on a port where $fp is a register pair,
>> and I've seen gcc allocate the second register to other things
>> (causing all sorts of problems).
>
Andrew Pinski wrote:
> On Fri, Jul 8, 2011 at 10:50 AM, Jon Grant wrote:
>> Hello
>>
>> I'm using latest Firefox looking at the onlinedocs with a default
>> Firefox install, default font sizes, no change in zoom level.
>
> Are you sure that this is not a bug in Firefox? I think it is the
> corre
The following pattern shall be generated by insn combine
and then be split by pre-reload split:
(define_insn_and_split "*mulsqihi3.const"
[(set (match_operand:HI 0 "register_operand"
"=&r")
(mult:HI (sign_extend:HI (match_operand:QI 1
"register_operand" "a"))
(match_ope
Georg-Johann Lay wrote:
> The following pattern shall be generated by insn combine
> and then be split by pre-reload split:
>
> (define_insn_and_split "*mulsqihi3.const"
> [(set (match_operand:HI 0 "register_operand"
> "=&r")
&g
Georg-Johann Lay wrote:
> Georg-Johann Lay wrote:
>> The following pattern shall be generated by insn combine
>> and then be split by pre-reload split:
>>
>> (define_insn_and_split "*mulsqihi3.const"
>> [(set (match_operand:HI 0 "register_operand
and regards,
> Sameera D
>
>
> **-Original Message-
> **From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> **Georg-Johann Lay
> **Sent: 11 July 2011 12:28
> **To: gcc@gcc.gnu.org
> **Subject: Re: IRA: matches insn even though !reload_in
Bernd Schmidt wrote:
> On 07/11/11 13:27, Georg-Johann Lay wrote:
>>>> IRA now propagates insn 7 into insn 8 so that in insn-output gcc runs
>>>> into the gcc_unreachable() even though !reload_in_progress etc should
>>>> keep IRA/reload from generating
Bernd Schmidt wrote:
> On 07/11/11 13:27, Georg-Johann Lay wrote:
>>>> IRA now propagates insn 7 into insn 8 so that in insn-output gcc runs
>>>> into the gcc_unreachable() even though !reload_in_progress etc should
>>>> keep IRA/reload from generating
Bernd Schmidt wrote:
> On 07/11/11 18:42, Bernd Schmidt wrote:
>> On 07/11/11 18:12, Georg-Johann Lay wrote:
>>> The reason is that IRA (or reload, don't see it from the dumps)
>>> combines the insns again to:
>>>
>>> (insn 29 31 24 2 (
Not familiar with combine inerts, I'd like to know if
it's low hanging fruit to teach insn combine to perform
optimizations like the following.
Suppose following C code, int = HI
int y15;
int x15;
void qmul8_xy (char c, int x, int y)
{
y15 = y * c;
x15 = x * c;
}
and that the target has
Bernd Schmidt wrote:
> On 07/12/11 13:11, Georg-Johann Lay wrote:
>> Not familiar with combine inerts, I'd like to know if
>> it's low hanging fruit to teach insn combine to perform
>> optimizations like the following.
>>
>> Suppose following C code, int
Michael Meissner wrote:
> On Mon, Jul 11, 2011 at 12:38:34PM +0200, Georg-Johann Lay wrote:
>> How do I write a pre-reload combine + pre-reload split correctly?
>> I'd like to avoid clobber reg.
>>
>> Thanks much for any hint.
>
> The move patterns are alw
In the internals, there is no description of a backend
can add a new pass. And no backend uses
passes.c:register_pass (4.5 and 4.7), so here is the question:
How can a backend add a pass?
I tried this code in OVERRIDE_OPTIONS (simply because I
found no canonical place to put it).
struct regi
Romain Geissler schrieb:
> Hi
>
> Le 19 juil. 2011 à 18:13, Georg-Johann Lay a écrit :
>> How can a backend add a pass?
>
> I've never seen any warning about adding a backend pass in
> the plugin documentation, which may also register passes thanks
> to register_p
DJ Delorie wrote:
> Ian Lance Taylor writes:
>> I don't think anybody has ever done this. At the moment only plugins
>> add new passes. But I agree that backends clearly need to be able to do
>> this, and some passes need to move into the appropriate backends. I
>> would encourage you to fix th
DJ Delorie schrieb:
I just call register_pass() with a suitable struct.
Which hook did you use to add/move the pass?
I used register_pass().
That's clear, sorry for the confision. From where in the
backend do you call register_pass?
Jon Grant wrote:
> Hello
>
> Georg-Johann Lay wrote, On 08/07/11 19:08:
> [.]
>> I can confirm that it's hardly readable on some systems.
>> I use Opera and several FF versions, some worse, some a bit less worse.
>>
>> IMO it's definitely to s
Michael Walle schrieb:
Hi list,
consider the following test code:
static void inline f1(int arg)
{
register int a1 asm("r8") = 10;
register int a2 asm("r1") = arg;
asm("scall" : : "r"(a1), "r"(a2));
}
void f2(int arg)
{
f1(arg >> 10);
}
If you compile this code with 'lm32-g
Michael Walle wrote:
> Hi,
>
> That was quick :)
>
>> Your asm has no output operands and no side effects, with more
>> aggressive optimization the whole ask would disappear.
> Sorry, that was just a small test file, the original code has output operands.
>
> The new test code:
> static int inl
Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 10:48 AM, Mikael Pettersson wrote:
>> Hans-Peter Nilsson writes:
>> > On Mon, 1 Aug 2011, Richard Henderson wrote:
>> >
>> > > On 08/01/2011 01:30 PM, Michael Walle wrote:
>> > > > 1) function inlining
>> > > > 2) deferred argument evaluation
Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
>> Michael Walle writes:
>> >
>> > Hi,
>> >
>> > > To confirm that try -fno-tree-ter.
>> >
>> > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
>> > assembly code:
>> >
>> > f2:
>>
Richard Guenther schrieb:
I suggest to amend the documentation for local call-clobbered register
variables to say that the only valid sequence using them is from a
non-inlinable function that contains only direct initializations of the
register variables from constants or parameters.
Richard.
Ulrich Weigand wrote:
> Richard Guenther wrote:
>> On Tue, Aug 2, 2011 at 3:23 PM, Ian Lance Taylor wrote:
>>> Richard Guenther writes:
I suggest to amend the documentation for local call-clobbered register
variables to say that the only valid sequence using them is from a
non-inli
Richard Guenther wrote:
> On Wed, Aug 3, 2011 at 3:27 PM, Michael Matz wrote:
>> Hi,
>>
>> On Wed, 3 Aug 2011, Richard Guenther wrote:
>>
Yes, that's reasonable. As I understand the docs, in code like
void foo ()
{
register int var asm ("r1") = 10;
asm (";; use r
For the following 1-liner I get an error with current trunk r177267:
const __pgm char * pallo = "pallo";
__pgm as a named address space qualifier.
>$TV/xgcc -B$TV pgm.c -c -save-temps -dp -mmcu=atmega8
unit size
align 8 symtab 0 alias set -1 canonical type 0xb74c7f00
Trying to make named address space support work for target AVR,
I am facing the following problem:
For generic AS, there are three valid base pointer registers
X , Y and Z.
For the new __pgm AS, only Z is available without offset.
The problem is now that addresses.h:base_reg_class() does not
pas
Ulrich Weigand wrote:
> Georg-Johann Lay wrote:
>
>> For the following 1-liner I get an error with current trunk r177267:
>>
>> const __pgm char * pallo = "pallo";
>>
>> __pgm as a named address space qualifier.
> [snip]
>> Moreover, if a
Ulrich Weigand wrote:
> Georg-Johann Lay wrote:
>
>> Trying to make named address space support work for target AVR,
>> I am facing the following problem:
>>
>> For generic AS, there are three valid base pointer registers
>> X , Y and Z.
>>
>> F
Ulrich Weigand schrieb:
Georg-Johann Lay wrote:
Ulrich Weigand wrote:
I'd be happy to bring this up to date if you're willing to work with
me to get this tested on a target that needs this support ...
Just attached a patch to bugzilla because an AVR user wanted to play
with the
Ulrich Weigand wrote:
> Georg-Johann Lay wrote:
>> Ulrich Weigand wrote:
>>> This means that problems like the one you're seeing have been hidden
>>> so far. I've started looking into fixing this, but since I don't
>>> have a target where this is
Ulrich Weigand schrieb:
Georg-Johann Lay wrote:
Ulrich Weigand wrote:
This is pretty much working as expected. "pallo" is a string literal
which (always) resides in the default address space. According to the
named address space specification (TR 18037) there are no string liter
Ulrich Weigand wrote:
> Georg-Johann Lay wrote:
>
>> Thanks, it works.
>
> OK, thanks for testing!
>
>> std Y+2,r31 ; 30 *movphi/3 [length = 7]
>> std Y+1,r30
>
> I'm actually not seeing those (maybe I'm using a differen
Hi, I'm getting the following error in viewvc for several days now:
http://gcc.gnu.org/viewcvs/trunk/gcc/dse.c?view=markup
An Exception Has Occurred
Python Traceback
Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/viewvc/lib/viewvc.py", line
4463, in main
reque
Richard Sandiford schrieb:
I've been working on some patches to make insn_rtx_cost take account
of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly beginning
to realise that I don't understand what rtx costs are supposed to represent.
AIUI the rules have historically been:
1) Regist
http://gcc.gnu.org/ml/gcc/2011-08/msg00131.html
Georg-Johann Lay a écrit:
Ulrich Weigand wrote:
Georg-Johann Lay wrote:
Thanks, it works.
OK, thanks for testing!
[...]
Bye,
Ulrich
Are you going to install that patch? Or maybe you already installed it?
Then, I wonder how the
Ulrich Weigand schrieb:
Georg-Johann Lay wrote:
http://gcc.gnu.org/ml/gcc/2011-08/msg00131.html
Are you going to install that patch? Or maybe you already installed it?
No, it isn't approved yet (in fact, it isn't even posted for approval).
Usually, patches that add new target macr
Richard Sandiford schrieb:
Georg-Johann Lay writes:
Richard Sandiford schrieb:
I've been working on some patches to make insn_rtx_cost take account
of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly beginning
to realise that I don't understand what rtx costs
Richard Sandiford wrote:
> Georg-Johann Lay writes:
>>>> IMO a clean approach would be to query the costs of a whole insn (resp.
>>>> it's pattern) rather than the cost of an RTX. COSTS_N_INSNS already
>>>> indicates that the costs are compared
Implementing TARGET_ASM_FUNCTION_RODATA_SECTION hook I wonder that will go into
these sections an I
am a but unsure as the internals don't say a word about that. From the only
two uses of that hook
in final.c I would conclude that it's only used for jump tables generated by
switch/case statemen
Peter Bigot wrote:
> On Sun, Aug 21, 2011 at 12:01 PM, Georg-Johann Lay wrote:
>> Richard Sandiford schrieb:
>>> Georg-Johann Lay writes:
>>>
>>>> Richard Sandiford schrieb:
>>>>
>>>>> I've been working on some patches to
Ian Lance Taylor wrote:
> Georg-Johann Lay writes:
>
>> Implementing TARGET_ASM_FUNCTION_RODATA_SECTION hook I wonder that will go
>> into these sections an I am a but unsure as the internals don't say a word
>> about that. From the only two uses of that hook in fin
This problem still persists.
viewcvs works, e.g. for gcc.h but fails for gcc.c:
http://gcc.gnu.org/viewcvs/trunk/gcc/gcc.c?view=markup
http://gcc.gnu.org/viewcvs/trunk/gcc/gcc.h?view=markup
Georg-Johann Lay wrote:
Hi, I'm getting the following error in viewvc for several days now:
David Brown schrieb:
On 21/09/2011 15:57, Ian Lance Taylor wrote:
David Brown writes:
On 21/09/2011 10:21, Paulo J. Matos wrote:
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change the nature of "foo" - the compiler can still implement it as a
compi
Hi, looking into PR50448 there is the following C code:
typedef struct
{
unsigned char a,b,c,d;
} SPI_t;
#define SPIE (*(SPI_t volatile*) 0x0AC0)
void foo (void)
{
SPIE.d = 0xAA;
while (!(SPIE.c & 0x80));
SPIE.d = 0xBB;
while (!(SPIE.c & 0x80));
}
At .optimized, the .c and
This is a tentative patch for better support of logging information for avr BE
developers.
There are situations where it is more convenient to let the compiler produce
information than to debug into the compiler. One example are -da dumps.
This patch proposes a better support to print information
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 prototypes.
>
Paolo Bonzini schrieb:
> On 09/28/2011 02:14 PM, Georg-Johann Lay wrote:
>> This leads to unpleasant code. The machine can access all RAM
>> locations by
>> direct addressing. However, the resulting code is:
>>
>> foo:
>> ldi r24,lo8(-86) ; 6*mov
In rtl.h there is
/* Predicate yielding nonzero iff X is a real insn. */
#define INSN_P(X) \
(NONJUMP_INSN_P (X) || DEBUG_INSN_P (X) || JUMP_P (X) || CALL_P (X))
and in emit-rtl:
/* Return the last INSN, CALL_INSN or JUMP_INSN before INSN;
or 0, if there is none. This routine does not lo
Eric Botcazou schrieb:
>> From my understanding a "real" insn is an insn that leads to code that will
>> be executed like INSN, CALL_INSN or JUMP_INSN but not DEBUG_INSN that's
>> used for location tracking or shipping debug information or CODE_LABEL or
>> whatever.
>>
>> This means that next_real_
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;
s += z->b;
s += x->c;
s += y->c;
s +
This error occurs if you configure GCC as cross compiler and
$ make
$ make clean-target-libgcc
$ make all-target-libgcc
./libgcc/libgcc2.c:32:23: fatal error: libgcc_tm.h: No such file or directory
Removing the $target directory altogether works:
$ make
$ rm -rf $target
$ make # rebuilds libgc
Sean D'Epagnier schrieb:
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-pro
Steven Bosscher schrieb:
In avr.c there is:
...
#include "c-family/c-common.h"
...
That is the problem: avr.c should be language independent. Here you
are trying to link code calling C-family functions in a non-C language
(lto1 is just another front end for gcc, just like
cc1/cc1plus/etc...).
Ian Lance Taylor wrote:
> Georg-Johann Lay writes:
>
>> Suppose avr.c:avr_out_lpm which is used to print insns in final,
>> e.g. ADJUST_INSN_LENGTH.
>>
>> Should avr_out_lpm be moved to avr-c.c? And avr-c.c include all the
>> rtl.h, tree.h, output.h etc. w
Ian Lance Taylor wrote:
> Georg-Johann Lay writes:
>> Ian Lance Taylor wrote:
>>> Georg-Johann Lay writes:
>>> The point is that functions that are C/C++ specific need to not be in
>>> avr.c, because they will break for languages other than C/C++. In this
>&
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 fro
Hi, I have a question concerning the following C code
typedef unsigned char uint8_t;
#define SEARCHING (-2)
#define UCSR0A (*(volatile uint8_t *)((0x0B) + 0x20))
#define UDR0 (*(volatile uint8_t *)((0x0C) + 0x20))
void __vector_18(void)
{
unsigned char status = UCSR0A;
unsigned char data
Ian Lance Taylor wrote:
Georg-Johann Lay writes:
Is insn combine allowed to match the insn because from combine's
perspective just a CONST_INT (i.e. low_io_address_operand) is moved
across the access of UDR0?
Yes.
Or is this a bug in insn combine?
No.
If combine is right -- and
Denis Chertykov wrote:
2011/11/29 Georg-Johann Lay:
I attached a patch but I fail to find the right configure options for
gcc/binutils as the testsuite complains
./avr/bin/ld: bad -plugin option
Configured gcc with --enable-lto and binutils 2.21 with --enable-plugin.
Maybe the patch can be
Ian Lance Taylor wrote:
Georg-Johann Lay writes:
If general_operand can be perceived as
(define_predicate "general_operand"
(ior (match_operand 0 "memory_operand")
(match_operand 0 "register_operand")
(match_operand 0 "immediate_operand
Richard Guenther wrote:
> On Thu, Dec 1, 2011 at 10:40 PM, Georg-Johann Lay wrote:
>> Ian Lance Taylor wrote:
>>
>>> Georg-Johann Lay writes:
>>>
>>>> If general_operand can be perceived as
>>>>
>>>> (define_pr
Denis Chertykov wrote:
> 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 addres
Ian Lance Taylor wrote:
> Georg-Johann Lay:
>>
>> What about that predicate?
>>
>> (define_predicate "low_io_mem"
>>(and (match_code "mem")
>> (match_test "low_io_address_operand (XEXP (op, 0))")))
>>
>>
BELBACHIR Selim wrote:
> Hi,
>
> I'm still working on a new gcc-4.5.2 backend for a private processor.
> I encountered a strange behavior and I'm unable to find what causes this
> behavior.
> As an overview, it seems that dse2 pass removes insn where it should not
> (optim -O2, -O3)
>
> Here is
Bringing this over from gcc-patches@
Jakub Jelinek wrote:
On Fri, Dec 09, 2011 at 01:50:37PM +0100, Georg-Johann Lay wrote:
No, not OK.
This leads to unacceptable code for devices that cannot shift easily like,
e.g.AVR. This target can only shift by 1 and shifts with big offsets have
to be
Andrew Pinski schrieb:
On Sun, Dec 11, 2011 at 3:13 PM, Georg-Johann Lay wrote:
If there was a canonical representation of these operations, a backend
wouldn't even notice if the tree passes chose a different, more convenient
canonicalization.
The problem is not just the canonicaliz
BELBACHIR Selim schrieb:
Hi,
I'm still developping a new private target backend (gcc4.5.2) and I
noticed something strange in the assembler generated for conditionnal
jump.
Maybe unfortunate defnition of branch costs or rtx costs?
How can I tell GCC to perform the best conditionnal jump by s
This is a tentative patch to fix combine.c so that it no more reorders volatile
memory accesses.
Even reading volatile memory can change other (volatile) memory as explained
in the patch. This also applies to volatile memory that is not wired to
hardware that changes by magic when reading: An ISR
Trying to document some new options/name spaces, I ran into following problem
with hyperlinking inside the document.
It's best explained with an example from documentation:
Start at
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html
and scroll to the end of the page to section "PowerPC
Hi, in avr.md there is
(define_insn "map_bitsqi"
[(set (match_operand:QI 0 "register_operand" "=d")
(unspec:QI [(match_operand:SI 1 "const_int_operand" "n")
(match_operand:QI 2 "register_operand" "r")]
UNSPEC_MAP_BITS))]
""
{
re
Hi.
avr-gcc implements a 24-bit scalar integer types __int24 and __uint24 in
avr.c:TARGET_INIT_BUILTINS like so:
tree int24_type = make_signed_type (GET_MODE_BITSIZE (PSImode));
tree uint24_type = make_unsigned_type (GET_MODE_BITSIZE (PSImode));
(*lang_hooks.types.register_builtin_type) (
101 - 200 of 366 matches
Mail list logo
