I am starting a review of the changes I made on the mem-ref2 branch
in preparation for a merge to trunk. This is a request for testing.
I have personally bootstrapped and tested on x86_64-unknown-linux
and powerpc64-linux (both with 32bit multilibs included and for
all languages). I also regula
Hi,
In my port I get to gen_reload to the lines
/* If IN is a simple operand, use gen_move_insn. */
else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
{
static int xxx;
xxx = OBJECT_P (in);
tem = emit_insn (gen_move_insn (out, in));
/* IN may contain a LABEL_R
Hi,
In the context of bug 31230, I have a question about the if_marked
construct.
[DOC http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html]
if_marked ("expression")
Suppose you want some kinds of object to be unique, and so you
put them in a hash table. If garbage collection marks the
On Tue, Jun 08, 2010 at 10:27:03PM +0930, Alan Modra wrote:
> PowerPC64 gcc support for a larger TOC via -mcmodel option.
[snip]
I'm having second thoughts about the optimization I added to PowerPC64
gcc with the patch hunk below. Its effect is to use a more efficient
TOC/GOT pointer relative add
roy rosen writes:
> In my port I get to gen_reload to the lines
>
> /* If IN is a simple operand, use gen_move_insn. */
> else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
> {
> static int xxx;
> xxx = OBJECT_P (in);
> tem = emit_insn (gen_move_insn (out, in));
>
roy rosen writes:
> In my port I get to gen_reload to the lines
>
> /* If IN is a simple operand, use gen_move_insn. */
> else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
> {
> static int xxx;
> xxx = OBJECT_P (in);
> tem = emit_insn (gen_move_insn (out, in));
>
Tom de Vries writes:
> static int prop(const_tree type)
> {
> return type == A;
> }
>
> static int type_hash_marked_p (const void *p) {
> const_tree const type = ((const struct type_hash *) p)->type;
> return ggc_marked_p (type) || prop (type);
> }
I would like to question your premise. The
> Can we similarly promise or say something for accesses of the
> containing struct as a whole?
I hadn't considered those cases (when would you want to copy a
*peripheral* ?) Should be the same as before, I would think.
On Jun 23, 2010, at 16:49, Ian Lance Taylor wrote:
Tom de Vries writes:
static int prop(const_tree type)
{
return type == A;
}
static int type_hash_marked_p (const void *p) {
const_tree const type = ((const struct type_hash *) p)->type;
return ggc_marked_p (type) || prop (type);
}
I wo
On Wed, Jun 23, 2010 at 11:34:04AM -0400, DJ Delorie wrote:
>
> > Can we similarly promise or say something for accesses of the
> > containing struct as a whole?
>
> I hadn't considered those cases (when would you want to copy a
> *peripheral* ?) Should be the same as before, I would think.
Not
Tom de Vries writes:
> What I am really trying to do, is a bootstrap debug build of 4.3.5.
> However, I ran into bug 31230. I minimized the testcase, did an
> analysis, created a naive patch to test my hypothesis, tested the
> patch and put it in the bug report. Now I'm looking for feedback.
>
>
On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
> Tom de Vries writes:
>
> > What I am really trying to do, is a bootstrap debug build of 4.3.5.
> > However, I ran into bug 31230. I minimized the testcase, did an
> > analysis, created a naive patch to test my hypothesis, tested the
> >
Hi,
My port supports hardware loops generated by the following (do_end) pattern:
(set (pc) (if_then_else (ne (match_operand:HI 0 "general_register_operand" "d")
(const_int 0))
(label_ref (match_operand 1 "" ""))
(pc)))
On 06/23/10 11:22, Alex Turjan wrote:
Hi,
My port supports hardware loops generated by the following (do_end) pattern:
(set (pc) (if_then_else (ne (match_operand:HI 0 "general_register_operand" "d")
(const_int 0))
(label_ref (match_operand 1 ""
Basile Starynkevitch writes:
> On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
>> Tom de Vries writes:
>>
>> > What I am really trying to do, is a bootstrap debug build of 4.3.5.
>> > However, I ran into bug 31230. I minimized the testcase, did an
>> > analysis, created a naive patch
> insns which branch are not allowed to have output
> reloads. You must
> support any kind of register as well as memory operands in
> your insn for
> the loop counter.
Thanks for answer but what do you suggest to do, as my architecture done not
support HW loops with memory operands?
Alex
On 06/23/10 12:29, Alex Turjan wrote:
insns which branch are not allowed to have output
reloads. You must
support any kind of register as well as memory operands in
your insn for
the loop counter.
Thanks for answer but what do you suggest to do, as my architecture done not
support HW
On 06/23/2010 06:03 AM, Alan Modra wrote:
> On Tue, Jun 08, 2010 at 10:27:03PM +0930, Alan Modra wrote:
>> PowerPC64 gcc support for a larger TOC via -mcmodel option.
> [snip]
>
> I'm having second thoughts about the optimization I added to PowerPC64
> gcc with the patch hunk below. Its effect is
> Date: Wed, 23 Jun 2010 11:53:31 -0400
> From: Daniel Jacobowitz
> On Wed, Jun 23, 2010 at 11:34:04AM -0400, DJ Delorie wrote:
> > > Can we similarly promise or say something for accesses of the
> > > containing struct as a whole?
> > I hadn't considered those cases (when would you want to copy a
On Jun 23, 2010, at 19:40, Ian Lance Taylor wrote:
Basile Starynkevitch writes:
On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
Tom de Vries writes:
What I am really trying to do, is a bootstrap debug build of 4.3.5.
However, I ran into bug 31230. I minimized the testcase, did
There are some target-specific types that are embedded in otherwise
target-independent types, namely struct machine_function and
CUMULATIVE_ARGS (which is the type of the info member of struct
incoming_args).
For the multi-target configurations as per PR44566 to work, these types
have to be en
Quoting Alex Turjan :
When Im compiling a loop with high register pressure the register
allocator does not allocate a register for the loop counter (i.e.,
operand 0) as it has a long life range. Thus operand 0 has to be
reloaded but then I get a failure in the reload:
...
Can anybody g
Hi everyone,
I'm starting to dig a little bit in what gcc does to protect the stack
from overflows and attacks of that kind. I've found some docs and
patches, but they aren't really up to date. I thought I could get some
diffs for the parts that manage these features, to see exactly what
they do a
On Jun 23, 2010, at 22:53, Tomás Touceda wrote:
> I'm starting to dig a little bit in what gcc does to protect the stack
> from overflows and attacks of that kind. I've found some docs and
> patches, but they aren't really up to date. I thought I could get some
> diffs for the parts that manage t
Joern Rennecke writes:
> Would patches to introduce these accessor macros be considered separately,
> or should I only submit them as part of the big patch for PR44566?
> Would patches for this be considered separately?
I would always prefer to see smaller patches. I can't imagine any
case whe
Tomás Touceda writes:
> I'm starting to dig a little bit in what gcc does to protect the stack
> from overflows and attacks of that kind. I've found some docs and
> patches, but they aren't really up to date.
See the -fstack-protector and -fstack-check options.
Ian
26 matches
Mail list logo
