On 08/06/06, Jie Zhang <[EMAIL PROTECTED]> wrote:
On 6/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Our Co. have a new 32b embedded processor, and we have ported the gcc
> backend for it(support c/c++), now we want add its backend code into gcc
> packages. i read the "Contributing to GCC
Properly enforcing access rules in libgcj causes problems in that
compiler-generated code sometimes wants to access private methods.
This patch uses a single bit in the signature pointer to indicate that
this is a compiler-generated access, so we should not perform any
access checks. Encoding the
Geoff,
I noticed PR 26792 last night. After reading that it became clear what
was causing the massive c++ regressions when I built gcc trunk under fink.
Fink sets MACOSX_DEPLOYMENT_TARGET to 10.4 when a package is built in
fink 10.4 branch. They also were applying the rejected patch from...
ht
On Wed, Jun 07, 2006 at 06:38:52PM -0500, Menezes, Evandro wrote:
> > > > > > We have several choices for stack alignment requirement
> > > > > >
> > > > > > 1. Leave it unchanged. Gcc can do
> > > > > > a. Nothing. Let the program crash.
> > > > > > b. Align stack to 16byte if XMM registe
Hi,
One of the SoC requirements is to have public development. So I should
I create a branch of my current Boehm's GC experiments and commit my
code there? I'm not sure, because there exists a posibility that this
branch will be thrown away, if we don't go the Boehm's GC route. And
the current co
On Jun 7, 2006, at 11:13 PM, Uros Bizjak wrote:
Hello!
Current mainline gcc can efficiently disable x87 instruction when
-mno-80387 switch is used. In this case, MMX registers can be used for
the autovectorisation even without emms or femms instructions to
switch back to x87 mode.
I don't th
On 08 June 2006 16:34, Laurynas Biveinis wrote:
> One of the SoC requirements is to have public development. So I should
> I create a branch of my current Boehm's GC experiments and commit my
> code there? I'm not sure, because there exists a posibility that this
> branch will be thrown away, if w
When I originally thought of flattening the data structures for
representing GIMPLE, I had not really contemplated the idea of totally
lowering the memory expressions represented by ARRAY_REF and COMPONENT_REF.
However, as Kenny pointed out today, it may be useful for us to
completely simplify th
On 6/8/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
When I originally thought of flattening the data structures for
representing GIMPLE, I had not really contemplated the idea of totally
lowering the memory expressions represented by ARRAY_REF and COMPONENT_REF.
However, as Kenny pointed out to
[EMAIL PROTECTED] writes:
> There is a __COUNTER__ macro, supported by Microsoft C++ compiler which
> can help me a lot in the thesis implementation. This macro expands to
> an integer starting with 0 and incrementing by 1 every time it is
> used Would you consider it adding it to the offici
On 6/8/06, Dave Korn <[EMAIL PROTECTED]> wrote:
On 08 June 2006 16:34, Laurynas Biveinis wrote:
> One of the SoC requirements is to have public development. So I should
> I create a branch of my current Boehm's GC experiments and commit my
> code there? I'm not sure, because there exists a posib
Richard Guenther wrote:
> On 6/8/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> When I originally thought of flattening the data structures for
>> representing GIMPLE, I had not really contemplated the idea of totally
>> lowering the memory expressions represented by ARRAY_REF and COMPONENT_REF.
>
Hi,
On Thu, 8 Jun 2006, Richard Guenther wrote:
> > Please don't get too fixated on the above pseudo-code. I have not
> > thought about this through in detail. I just want to bring this up,
> > particularly for folks doing data dependency. Perhaps we need
> > different
> > expressions altoget
I would appreciate any help in this reload problem
that I have been struggling with for some time:
I completed a gcc back end port to a processor that
supports both displaced and indexed addressing modes
for load, but only displaced for store. For example:
ld.w Rd Rb imm(load from Rb+imm)
On 6/8/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> We (me and Matz) thought over this as well and concluded it would be
> nice to have
>
> - MEM_REF ( base, offset, alias_tag )
>
> with base being either some memory object or an INDIRECT_REF of a pointer and
> be done
Hi,
On Thu, 8 Jun 2006, Daniel Berlin wrote:
> >>> with base being either some memory object or an INDIRECT_REF of a
> >>> pointer and be done with that tree code.
> >> So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done
> >> any better in removing recursion :)
> >
> > What type
Michael Matz wrote:
> Hi,
>
> On Thu, 8 Jun 2006, Daniel Berlin wrote:
>
Thoughts?
>>> We (me and Matz) thought over this as well and concluded it would be
>>> nice to have
>>>
>>> - MEM_REF ( base, offset, alias_tag )
>>>
>>> with base being either some memory object or an INDIRECT_REF of
On 08 June 2006 17:44, Juul Vanderspek wrote:
> Tracing all this in find_reloads (reload.c), I see a
> call to find_reloads_address, indeed with reload type
> RELOAD_FOR_OUTPUT_ADDRESS, but this function
> immediately discovers that the address is a
> strict_memory_address, and decides to do noth
Um, this just is a collapse of some large macro.
The original compiles into a compiler that refuses to
reload.
> >
> > #define GO_IF_LEGITIMATE_ADDRESS ... \
> > -- recognizes register, displaced, and indexed --
>
>
> Oh, yes. That's not valid C at all.
>
>
> cheers,
> DaveK
>
Hello,
> > >>> with base being either some memory object or an INDIRECT_REF of a
> > >>> pointer and be done with that tree code.
> > >> So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done
> > >> any better in removing recursion :)
> > >
> > > What type the first operand would be
Zdenek Dvorak wrote:
> Hello,
>
>> with base being either some memory object or an INDIRECT_REF of a
>> pointer and be done with that tree code.
> So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done
> any better in removing recursion :)
What type the first ope
On Tue, Jun 06, 2006 at 08:27:10PM +0200, Rask Ingemann Lambertsen wrote:
> On Tue, Jun 06, 2006 at 10:39:46AM +0100, Richard Sandiford wrote:
> > This is just a guess, but the insn above might be an output reload.
>
> It is, in a peculiar (and not useful) way. Diffing the greg dump against
> the
On 08 June 2006 18:54, Juul Vanderspek wrote:
> Um, this just is a collapse of some large macro.
> The original compiles into a compiler that refuses to
> reload.
The point I was making was that if you think there's a problem with that
macro, and you've posted to the list to ask if anyone can
I collapsed the macro exactly because I am pretty sure
that this macro is ok (I have extensively verified
that it works), and to keep the
initial message small. I have attached my complete
configuration file this time.
--- Dave Korn <[EMAIL PROTECTED]> wrote:
> On 08 June 2006 18:54, Juul Vander
Hi,
On Thu, 8 Jun 2006, Daniel Berlin wrote:
> >> Thoughts?
> >
> > We (me and Matz) thought over this as well and concluded it would be
> > nice to have
> >
> > - MEM_REF ( base, offset, alias_tag )
> >
> > with base being either some memory object or an INDIRECT_REF of a
> > pointer and be
Laurynas Biveinis wrote:
> Hi,
>
> One of the SoC requirements is to have public development. So I should
> I create a branch of my current Boehm's GC experiments and commit my
> code there?
Sure, if you like (you have a copyright assignment and are write after
approval, so you can create branch
On Thu, Jun 08, 2006 at 12:13:50PM -0400, Diego Novillo wrote:
> However, as Kenny pointed out today, it may be useful for us to
> completely simplify these expressions to remove their recursive
> structure. Something like:
>
> ARRAY_REF : ID [ VAL ]
>
> COMPONENT_REF : ID . ID
>
Richard Henderson wrote on 06/08/06 16:36:
> As folks have pointed out down-thread wrt multi-dimensional arrays,
> I think this is a rather poor idea. Both for components and arrays.
>
Yeah, multi-dimensional arrays are a problem. I'm not sure I see the
flattening of components as a problem. B
Rask,
On Thursday 08 June 2006 20:12, Rask Ingemann Lambertsen wrote:
> Also, undo the change to arm_legitimate_address_p() arm.c.
Hmmm
> arm-elf-gcc -g -mswp-byte-writes -Wall -O2 -fomit-frame-pointer
> -ffast-math -mthumb-interwork -isystem
> /usr/lib/devkitpro/libnds/include -mcpu=arm9td
Juul Vanderspek wrote:
In order to enable indexed loads, I extended
GO_IF_LEGITIMATE_ADDRESS to also match indexed
addresses, added a memory constraint 'R' to match
nonindexed addresses, and used R for stores in the
'mov' rule (see below).
This may be easier if you do it the other way. I.e. re
On Sun, Jun 04, 2006 at 02:03:05PM +0200, Piotr Wyderski wrote:
> fs:[0x14] is a per-thread 32-bit word available for applications,
> so you can store a pointer to your own TLS array there.
I don't think we can hijack this.
> fs:[0x2c] points to a Windows-specific TLS array, so you can
> make us
On Sun, Jun 04, 2006 at 07:05:55AM -0400, Ross Ridge wrote:
> FX Coudert wrote:
> > Now, for an idea of how much work it represents... perhaps someone
> >here can tell us?
>
> It's not too hard but it requires changing GCC and binutils, plus a
> bit of library support. In my implementation (more
On 08/06/2006, at 7:48 AM, Jack Howarth wrote:
Geoff,
I noticed PR 26792 last night. After reading that it became
clear what
was causing the massive c++ regressions when I built gcc trunk
under fink.
Fink sets MACOSX_DEPLOYMENT_TARGET to 10.4 when a package is built in
fink 10.4 branch
> > I see. Provided a local is passed in a register to a
> non-vararg function, it is still OK to align the stack.
>
> Given that we don't support 4 byte aligned stack at all with XMM
> regisrers, I would prefer to increase Linux/x86 stack alignment to
> 16 byte. People can use 4 byte alignment
Snapshot gcc-4.0-20060608 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060608/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi all,
Short version:
I have to choose between:
(a) keep Wconversion only for warnings about prototypes causing a type
conversion different from what would happen to the same argument in
the absence of a prototype, which was its original purpose, and move
everything else to a new option (Wcoer
Ross Ridge wrote:
> Actually, the last one I haven't done yet. I've just been using a linker
> script to do that, but it should be in a library so the TLS directory
> entry isn't created if the executable doesn't use TLS.
Richard Henderson wrote:
> You can also create this in the linker, without
On Thu, Jun 08, 2006 at 05:25:32PM -0500, Menezes, Evandro wrote:
> > > I see. Provided a local is passed in a register to a
> > non-vararg function, it is still OK to align the stack.
> >
> > Given that we don't support 4 byte aligned stack at all with XMM
> > regisrers, I would prefer to incre
hi,
Following is a c code .
int a;
main()
{
a=a+1;
}
This RTL generated for this programe for mips processor is
/***/
; Function main
(note 2 0 3 NOTE_INSN_DELETED)
(note 3 2 4 NOTE_INSN_FUNCTION_BEG)
(note 4 3 5 NOTE_INSN_DELETED)
(note 5
"kernel coder" <[EMAIL PROTECTED]> writes:
This is all just boilerplate which is put at the end of every function
during RTL expansion.
> (insn 15 11 16 (nil) (clobber (reg/i:SI 2 v0)) -1 (nil)
>(nil))
Clobber the hard return register.
> (insn 16 15 13 (nil) (clobber (reg:SI 181)) -1 (nil)
40 matches
Mail list logo
