Senthil Kumar Selvaraj schrieb:
On a 64 bit machine, executing
$ make check RUNTESTFLAGS=avr-torture.exp=builtins-1.c
--target_board=atxmega128a1
causes virtual memory allocation failure and/or large scale machine
slowdown, with cc1 using up gobs (35G) virtual memory.
I tracked this down to
David Daney wrote:
Mike Stump wrote:
David Daney wrote:
Ian Lance Taylor wrote:
Mike Stump wrote:
Where in the manual are the machine specific print operand
modifiers documented? I've looked around, and just can seem to
find them; surely, I can't be the first to document such a modifier.
Ian Lance Taylor wrote:
Mike Stump wrote:
Where in the manual are the machine specific print operand
modifiers documented? I've looked around, and just can seem to
find them; surely, I can't be the first to document such a
modifier.
To the best of my knowledge they are not documented in the
Senthil Kumar Selvaraj wrote:
Some tests in gcc/testsuite/gcc.target/avr/torture (builtins-2.c, for
e.g.) have -Tavr51-flash1.x specified in dg-options. The tests currently
fail with an unable to open linker script error for that file.
Is that linker script supposed to be checked into source
Paulo Matos schrieb:
Hi,
Is there any good way to define TARGET_CANNOT_MODIFY_JUMPS_P such
that jumps are not modified after sched2?
Or in other words, is there a way to recognize if sched2 has already
been ran (sched2_completed, maybe)?
Such flags would be really helpful, but unfortunately
Joseph S. Myers a écrit:
On Wed, 10 Oct 2012, Robert Dewar wrote:
On 10/10/2012 10:48 AM, Joseph S. Myers wrote:
On Wed, 10 Oct 2012, Gabor Loki wrote:
2) repeat all the compilation commands related to the previous list in
the proper environment. The only thing which I have added to the
Sharad Singhai schrieb:
I have enhanced the dump infrastructure in r191883, r191884. These
patches updated the tree/rtl dump facility so that passes do not
reference the dump file directly, but instead use a different (and
hopefully cleaner) API.
Instead of this
if (dump_file)
Jonathan Wakely schrieb:
On 18 October 2012 13:43, Jonathan Wakely wrote:
On 18 October 2012 13:32, Frédéric Buclin wrote:
Le 18. 10. 12 14:27, Jonathan Wakely a écrit :
I'll prepare some mockups for people to look at and see if they like it.
Please file a bug and CC me. It's much easier to
Richard Biener schrieb:
Joseph S. Myers wrote:
I think the fix should be to give an early error message for compiling
from stdin with -save-temps, and then stop the compilation because there's
nowhere to save the intermediate files (given the lack of an input file
name).
Alternatively, inform
Diego Novillo wrote:
=== Approach: Move GTY to cc1plus.
Instead of a separate weak parser, we would make cc1plus understand GTY
attributes. The compiler would emit IL in the object files instead of
generating source.
Does this mean GTY is implemented as a C++ language extension and the
DJ Delorie schrieb:
Ian Lance Taylor writes:
Also the fact that GCC is now written in C++ seems to me to be
deserving of a bump to 5.0.
I see no reason why an internal design change that has no user visible
effects should have any impact on the version number.
Changing the implementation
Hi, suppose the following C code:
static __inline__ __attribute__((__always_inline__))
_Fract rbits (const int i)
{
_Fract f;
__builtin_memcpy (f, i, sizeof (_Fract));
return f;
}
_Fract func (void)
{
#if B == 1
return rbits (0x1234);
#elif B == 2
return 0.14222r;
#endif
}
Richard Biener wrote:
On Thu, Jan 17, 2013 at 12:20 PM, Georg-Johann Lay wrote:
Hi, suppose the following C code:
static __inline__ __attribute__((__always_inline__))
_Fract rbits (const int i)
{
_Fract f;
__builtin_memcpy (f, i, sizeof (_Fract));
return f;
}
_Fract func
Richard Biener wrote:
On Thu, Jan 17, 2013 at 6:04 PM, Georg-Johann Lay wrote:
Richard Biener wrote:
On Thu, Jan 17, 2013 at 12:20 PM, Georg-Johann Lay wrote:
Hi, suppose the following C code:
static __inline__ __attribute__((__always_inline__))
_Fract rbits (const int i)
{
_Fract f
Robert Dewar wrote:
About the time Clang does because GCC now has to compete.
How about that? Clang is currently slightly ahead and GCC really needs
to change if it is to continue to be the best.
Best is measured by many metrics, and it is unrealistic to expect
any product to be best in all
Richard Biener schrieb:
On Thu, Jan 17, 2013 at 6:04 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Biener wrote:
On Thu, Jan 17, 2013 at 12:20 PM, Georg-Johann Lay wrote:
Hi, suppose the following C code:
static __inline__ __attribute__((__always_inline__))
_Fract rbits (const int i
[Removing avr-gcc-list from CC because there is no need to cross-post]
S, Pitchumani wrote:
I was analyzing an issue for avr target (gcc-4.7.2).
Issue is that already clobbered register is used after the transformation
in post reload pass.
insns after reload pass:
set (reg:HI r24
S, Pitchumani schrieb:
From: Georg-Johann Lay
S, Pitchumani wrote:
I was analyzing an issue for avr target (gcc-4.7.2).
Issue is that already clobbered register is used after the
transformation in post reload pass.
insns after reload pass:
set (reg:HI r24
(const:HI (plus:HI
While implementing PR56263 (Strict address-space checking for AVR), I
encountered the problem that pointer casts with address spaces are always
expanded as const_int 0.
The problem occurs if the attached patch that implements PR56263 and the
following code is compiled as
$ avr-gcc -Os
Richard Biener wrote:
On Fri, Mar 8, 2013 at 3:19 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Mar 8, 2013 at 2:57 PM, Georg-Johann Lay wrote:
While implementing PR56263 (Strict address-space checking for AVR), I
encountered the problem that pointer casts with address spaces
Richard Biener wrote:
On Fri, Mar 8, 2013 at 5:03 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Biener wrote:
On Fri, Mar 8, 2013 at 3:19 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Mar 8, 2013 at 2:57 PM, Georg-Johann Lay wrote:
While implementing PR56263 (Strict
Paulo Matos schrieb:
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)
(match_operand:SI 1
Ondrej Bilka schrieb:
http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch
This is wrong:
@@ -10834,7 +10834,7 @@ avr_convert_to_type (tree type, tree expr)
XOP[2] # Bytes to copy
Return TRUE if the expansion is accomplished.
- Return FALSE if the operand compination is not
Yury Gribov schrieb:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a good starting
Am 02/27/2014 06:03 PM, schrieb Richard Sandiford:
Yury Gribov y.gri...@samsung.com writes:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive
Am 02/27/2014 03:34 PM, schrieb Richard Biener:
I've been hacking on a prototype that generates matching and
simplification code from a meta-description. The goal is
to provide a single source of transforms currently spread
over the compiler, mostly fold-const.c, gimple-fold.c and
Am 03/25/2014 01:28 PM, schrieb Jeff Law:
On 03/25/14 06:23, Umesh Kalappa wrote:
Dear All,
The GCC source reference 4.8.1 will synthesized some of the double
word operations(SI mode) like add /sub in the below case from the word
size (HI) patterns,
(code snippet)
expand_binop_directly
Am 05/07/2014 04:20 PM, schrieb Umesh Kalappa:
Hi All ,
We are porting GCC 4.8.1 for the customized hardware, where the
current calling convention used as arguments are passed by stack and
return value by register.
But we do have some intrinsic functions(that are supplied by hardware
folks )
Am 05/16/2014 07:16 PM, schrieb Carlos O'Donell:
On 05/12/2014 11:13 PM, David Wohlferd wrote:
After updating gcc's docs about inline asm, I'm trying to improve
some of the related sections. One that I feel has problems with
clarity is __attribute__ naked.
I have attached my proposed update.
Am 05/20/2014 06:04 PM, schrieb Paulo Matos:
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of Basile Starynkevitch
Sent: 20 May 2014 16:29
To: Bruce Adams
Cc: gcc@gcc.gnu.org
Subject: Re: Roadmap for 4.9.1, 4.10.0 and onwards?
On Tue, 2014-05-20 at 11:09 +0100, Bruce
Am 05/20/2014 03:31 PM, schrieb Carlos O'Donell:
On 05/20/2014 03:59 AM, Georg-Johann Lay wrote:
Am 05/16/2014 07:16 PM, schrieb Carlos O'Donell:
On 05/12/2014 11:13 PM, David Wohlferd wrote:
After updating gcc's docs about inline asm, I'm trying to
improve some of the related sections. One
Investigating PR63633 turned out that the middle-end calls insn expanders with
hard registers, namely mulsi3 from avr back-end:
(define_expand mulsi3
[(parallel [(set (match_operand:SI 0 register_operand )
(mult:SI (match_operand:SI 1 register_operand )
Jeff Law schrieb:
On 10/24/14 10:29, Jakub Jelinek wrote:
But I'd say, if you can't handle hard regs in the operands (either
general,
or some specific ones), you should
force the hard regs into pseudos (all hard regs, or just the problematic
ones) in the expander.
So in this case, check if
Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek:
On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
Yes, that's the straight forward approach which works so far. Bit tedious,
but well...
In one case expmed generated different code, though: divmodhi instead of
mulhi_highpart
Am 10/27/2014 08:43 PM, schrieb Jeff Law:
On 10/27/14 13:33, Georg-Johann Lay wrote:
Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek:
On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
Yes, that's the straight forward approach which works so far. Bit
tedious,
but well...
In one
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 small, I already thought about complaining, too.
Johann
Could
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-gcc -O1 -S
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 inline f1(int
Richard Guenther wrote:
On Tue, Aug 2, 2011 at 10:48 AM, Mikael Pettersson mi...@it.uu.se 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 mi...@it.uu.se 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:
addi sp,
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 i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
I suggest to amend the documentation for local call-clobbered register
variables to say that the only valid sequence using
Richard Guenther wrote:
On Wed, Aug 3, 2011 at 3:27 PM, Michael Matz m...@suse.de 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 r1);
}
there is
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
addr_space_convert_expr 0xb74cdfc0
type pointer_type 0xb74c7f60
type integer_type
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
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 user writes a line like
const __pgm char * pallo = pallo;
he wants
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.
For the new __pgm AS, only Z is available without offset
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 AS support
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 needed, this effort never really went
anywhere. I'll append
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 literals
in non
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 different code
base than you were using ...)
But I still see
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
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)
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
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 macros, or new
Richard Sandiford schrieb:
Georg-Johann Lay a...@gjlay.de 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 a...@gjlay.de 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 to *insn* costs i.e. cost of the
whole pattern
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
Peter Bigot wrote:
On Sun, Aug 21, 2011 at 12:01 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Sandiford schrieb:
Georg-Johann Lay a...@gjlay.de 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
Ian Lance Taylor wrote:
Georg-Johann Lay a...@gjlay.de 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 final.c I would
conclude
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:
http
David Brown schrieb:
On 21/09/2011 15:57, Ian Lance Taylor wrote:
David Brownda...@westcontrol.com 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
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
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.
* config/avr/avr.c: Include
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*movqi/2[length = 1]
ldi r30,lo8(-64) ; 34
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
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_insn depends
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 += z-c;
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
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
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. which is also needed by the functions
that like
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
terminology, LTO counts as a language
Ian Lance Taylor wrote:
Georg-Johann Lay a...@gjlay.de 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 frontends that use address spaces
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 thus
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
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)))
how can low_io_mem ever match?
Oh, I see
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_predicate general_operand
(ior (match_operand 0 memory_operand)
(match_operand 0 register_operand
Denis Chertykov wrote:
2011/11/29 Georg-Johann Lay a...@gjlay.de:
Ian Lance Taylor wrote:
Georg-Johann Lay a...@gjlay.de 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
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)
Guess it operates the same because the drag-volatile-over-volatile
happens not in recog(_for_combine
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 the
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
Andrew Pinski schrieb:
On Sun, Dec 11, 2011 at 3:13 PM, Georg-Johann Lay a...@gjlay.de 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
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
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
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))]
{
return
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)
Konstantin Vladimirov schrieb:
Hi,
This problem is backend independent, so I build reproduction in x86
backend. Consider code:
int func(int x);
int test(int x, int *data)
{
int retval;
register int *buffer asm (eax);
buffer = data;
retval = func(x);
__asm__ __volatile__
Joseph S. Myers wrote:
On Fri, 20 Jan 2012, Georg-Johann Lay wrote:
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
Joseph S. Myers wrote:
On Wed, 25 Jan 2012, Georg-Johann Lay wrote:
You mean that thread?
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00064.html
and
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00079.html
Yes, the whole thread (with particular reference to my comments about what
Richard Henderson schrieb:
On 01/21/2012 01:48 AM, Georg-Johann Lay wrote:
FRACTIONAL_INT_MODE (PSI, 24, 3);
Unrelated to everything else, I'm not sure you want a *fractional* mode.
You're using all bits of the 3 bytes of storage. Fractional modes are
those where there are unused bits
Alan Lehotsky schrieb:
I'm working on a port to a Harvard architecture where the data memory
addresses are only 14 bits wide (e.g. 16kb) and the instruction
address space is 21 bits wide.
I do not want to define Pmode as PSImode; the machine has separate
address registers for data memory AND
Hi,
may I propose to change this message to a more user-friendly one?
In most cases, the message is triggered by a typo like here:
Int foo (void)
{
return 1;
}
A message like
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
is just pain to the eyes, and apart from
This patchlet fixes length computation of std %0,%1 and st %0,%1 that
reported 2 instead of 1. The reason is that the insn length was accumulated and
added to the length of 1 already set in the caller.
These length are unconditionally set to 1 now because there is no code emit
before these
Miles Bader wrote:
Chris Lattner clatt...@apple.com writes:
Int foo (void) { return 1; }
A message like
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
is just pain to the eyes, and apart from that it is not more helpful
than a simple syntax error before 'foo':
FWIW,
Zoltán Kócsi schrieb:
paul_kon...@dell.com wrote:
I would prefer this to generate a warning. The C language standard change
you refer to is a classic example of a misguided change, and any code whose
behavior depends on this deserves a warning message, NOT an option to work
one way or the
This is a question on SUBREGs generated by lower-subreg.c and whether register
allocator is supposed to handle them efficiently.
Suppose the following small function compiled for AVR.
Remember AVR is 8-bit machine with int = HImode and UNITS_PER_WORD = 1.
int add (int val)
{
return val + 1;
1 - 100 of 1308 matches
Mail list logo
