Hello,
I am a computer science student and currently I am preparing my master
degree final work on "Compiler optimization on IA64 platforms". So
could you provide some information to me what is the the current
situation with gcc and IA64 platfrom - I mean what are open
optimization issues and so o
i386.h has
#define VALID_SSE2_REG_MODE(MODE) \
((MODE) == V16QImode || (MODE) == V8HImode || (MODE) == V2DFmode \
|| (MODE) == V2DImode || (MODE) == DFmode)
#define VALID_SSE_REG_MODE(MODE) \
((MODE) == TImode || (MODE) == V4SFmode || (MODE) == V4SImode \
|| (MODE) == SFmode || (MODE) =
Hello, All
Now when porting gcc I met a problem, which can
cause compiler internal error in emit_move_insn
function when I use structure pointer to assign a
value to structure member like below:
typedef struct MV
{
int m_I;
short m_J;
}MV;
void main(void)
{
MV mv1;
MV* pmv = &mv1;
I came across this odd issue with testsuite test Wconversion-5.c and AVR
target.
I should get warning going from a unsigned value that is wider than
signed result.
As I am not skilled in the art of the all conversions rules. I would
appreciate some guidance before I report this as bug.
FYI
Richard Sandiford wrote:
> "Omar Torres" <[EMAIL PROTECTED]> writes:
> More importantly:
>
>>operands[4] = simplify_gen_subreg(QImode,operands[1],HImode,0);
>>operands[5] = simplify_gen_subreg(QImode,operands[1],HImode,1);
>
> ..this code is designed to handle REGs and CONST_INTs co
Richard Sandiford wrote:
>
> You might as well make the first operand a register_operand and
> avoid the REG_P check.
I agree. I implemented this change and it works as expected.
>More importantly:
>
>>operands[4] = simplify_gen_subreg(QImode,operands[1],HImode,0);
>>operands[5]
Just a few suggestions for simplfying this...
"Omar Torres" <[EMAIL PROTECTED]> writes:
> (define_split
>[(set (match_operand:HI 0 "nonimmediate_operand" "")
> (match_operand:HI 1 "general_operand" ""))]
>"reload_completed
> && REG_P (operands[0])"
You might as well make
Snapshot gcc-4.1-20080519 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080519/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> Any suggestions on how to fix this issue?
gen_int_mode
--
Eric Botcazou
Just correcting a typo...
Omar Torres wrote:
> I split it into:
(set (reg:QI 1 %r3)
(const_int 127 [0x7f])
(set (reg:QI 2 %r2)
(const_int 255 [0xFF])
Hi All,
Since the architecture I am working with only support byte size moves,
I created a define_split break HI-move insn's into two QI-moves.
For example, the following insn:
(insn 84 5 9 (set (reg:HI 1 %r3)
(const_int 32767 [0x7fff])) 3 {*movhi} (nil)
(nil))
I split it into:
(
On Mon, May 19, 2008 at 08:45:32PM +, Joseph S. Myers wrote:
> Status
> ==
>
> GCC 4.2.4 is now available to download from gcc.gnu.org and
> ftp.gnu.org, and the 4.2 branch is open for commits under the normal
> release branch rules. The announcement of the 4.2.4 release will go
> out in
Status
==
GCC 4.2.4 is now available to download from gcc.gnu.org and
ftp.gnu.org, and the 4.2 branch is open for commits under the normal
release branch rules. The announcement of the 4.2.4 release will go
out in a few days' time after mirrors have had time to update.
There are no current p
On Wed, May 14, 2008 at 10:18:56AM +0530, Mohamed Shafi wrote:
> Hello all,
>
> Will it be possible to write a pattern in the md file to support
> setting/clearing a bit of a particular register?
> The instructions are as follows:
>
> clrb Rx, bitNo
> setb Rx, bitNo
>
> Could you point me to the
Hi,
The GCC Compile Farm project is pleased to announce that two bi-quad
core machines with the latest Opteron 8354 "Barcelona B3" processor and
16GB of RAM donated by AMD are now available online in datacenter space
kindly donated by INRIA Saclay.
All in all, gcc11 to gcc17 provide 38 64-bits c
Hello!
GCC 4.3.1 is still not ready for release as the x86 direction flag
issue (36079) needs to be resolved. We have reached consensus to
add a new flag -mcld to allow to work around the kernel bug and to
add a configure option to enable/disable this by default.
The patch from Uros is impleme
Status
==
The GCC 4.3 branch is open for commits under normal release branch
rules.
GCC 4.3.1 is still not ready for release as the x86 direction flag
issue (36079) needs to be resolved. We have reached consensus to
add a new flag -mcld to allow to work around the kernel bug and to
add a co
FX wrote:
I think the best thing to do is to have a langhook then.
It seems a bit weird to have a langhook for a one-character
difference, but if there's a consensus on it, I'll go along.
To me too, but I still maintain that it's better to print in UTF-8
(which would make the langhook more u
> I think the best thing to do is to have a langhook then.
It seems a bit weird to have a langhook for a one-character
difference, but if there's a consensus on it, I'll go along.
> Endianness issues may also appear. Maybe you should call iconv in the
> langhook to get back to UTF-8, and print t
Notice the added final '\0' in the C case; I don't know if it's bad to
have it there, but I don't see a way to not output it and still have
the correct output for Fortran (whose strings are not NUL-terminated).
I think the best thing to do is to have a langhook then. I'm actually
not sure th
> Yes, it is bad to have it there for C/C++, please make sure the final
> \0 isn't printed.
The question is: how? If we limit the tree dumps to C/C++ semantics,
then there's no way they can express Fortran code (ie a string
litteral not terminated by a NUL), is there? Or do we make the
semantics o
On Mon, May 19, 2008 at 02:59:16PM +0100, FX wrote:
> return (unsigned char *) "look\0here\0";
>
>
> Notice the added final '\0' in the C case; I don't know if it's bad to
> have it there, but I don't see a way to not output it and still have
> the correct output for Fortran (whose strings are
Hi there,
On Mon, 19 May 2008, 15:59:16 +0200, FX wrote:
> [...]
> Any comments? Is it OK to commit as is?
this may sound like nit-picking, but the length of a string cannot be
negative, so, I'd rather make the new parameter `len' an "unsigned int"
or even size_t.
HTH, cheers.
l8er
manfred
2008/5/19 <[EMAIL PROTECTED]>:
> Hi,
>
> I am Raja, I need a favor on understand how the gmon.out file is created.
> Please help me.
>
> 1. gmon.c is available in both gcc and glibc. Which is the one used to
> create gmon.out ?
I don't think gcc has gmon.c. Only glibc has it. You can also find
g
Hi all,
The Fortran front-end now handles wide character strings
(UCS-4/UTF-32); for these, the string literals are emitted as strings
with the type of an array of unsigned 32-bit integers. The issue is
that tree-pretty-print.c, in pretty_print_string() assumes strings are
composed of chars and NU
Hi,
I am Raja, I need a favor on understand how the gmon.out file is created.
Please help me.
1. gmon.c is available in both gcc and glibc. Which is the one used to
create gmon.out ?
2. Can you brief how profile information required to create gmon.out is
captured?¡¡Which are the functions are r
On Mon, May 19, 2008 at 4:24 AM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Can anyone give me a pointer to how TLS is supposed to work on powerpc-darwin?
It is non existent so it works via the emulation layer which Richard
Henderson added.
-- Pinski
Hi,
Can anyone give me a pointer to how TLS is supposed to work on powerpc-darwin?
I can't find any references, and I am trying to figure out whether I
need to do something special for it when I change the rs6000 backend
TLS support (e.g. should I expect any target to maybe require branch
islands
Hi,
My function is working properly for the below case -
for (i = 1; i < N ; i++)
{
a[i] = 1;
}
for (i = 1; i < N ; i++)
{
j = a[i];
}
But I am required to add additional phi node for j in the following case -
for (i = 1; i < N ; i++)
{
a[i] = 1;
}
29 matches
Mail list logo