Re: A reload inheritance bug
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used for the instruction at B looks like this:
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 9 r9 [3275])
(reg:SI 10 sl [3812]))
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), inc by 8
reload_in_reg: (plus:SI (reg/f:SI 9 r9 [3275])
(reg:SI 10 sl [3812]))
reload_reg_rtx: (reg:SI 9 r9)
where, in the notation from above, r9 is H and pseudo 3275 is reg2.
I could be missing something here, but aren't matched operands given a
reload type of RELOAD_OTHER rather than RELOAD_FOR_INPUT?
I might be tripping up on the terminology here then. The original
instruction is:
(insn:HI 5291 5282 5295 2 (set (reg:DF 4078 [ Jd+1040 ])
(mem/s:DF (plus:SI (reg/f:SI 3275)
(reg:SI 3812)) [30 Jd+1040 S8 A64])) 578 {*movdf_vfp} (nil)
(expr_list:REG_DEAD (reg/f:SI 3275)
(expr_list:REG_DEAD (reg:SI 3812)
(nil
and after reload we end up with:
(insn 6675 5282 5291 2 (set (reg:SI 9 r9)
(plus:SI (reg/f:SI 9 r9 [3275])
(reg:SI 10 sl [3812]))) 4 {*arm_addsi3} (nil)
(nil))
(insn:HI 5291 6675 5295 2 (set (reg:DF 75 s12 [orig:4078 Jd+1040 ] [4078])
(mem/s:DF (reg:SI 9 r9) [30 Jd+1040 S8 A64])) 578
{*movdf_vfp} (nil)
(nil))
Also, which register is the "inc by 8" note for? R9 or sl?
I thought the value of "inc" wasn't relevant here since we aren't
dealing with an autoincrement instruction (see the comment in
reload.h:struct reload).
Mark
Re: A reload inheritance bug
On Tue, May 15, 2007 at 09:31:10AM +0100, Mark Shinwell wrote:
> Rask Ingemann Lambertsen wrote:
> >On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
> >
> >[snip]
> >>- the last use of reg2 (in B) is inside a matched input operand;
> >[snip]
> >>The reload used for the instruction at B looks like this:
[snip]
> >>GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), inc by 8
[snip]
> > I could be missing something here, but aren't matched operands given a
> >reload type of RELOAD_OTHER rather than RELOAD_FOR_INPUT?
>
> I might be tripping up on the terminology here then. The original
> instruction is:
>
> (insn:HI 5291 5282 5295 2 (set (reg:DF 4078 [ Jd+1040 ])
> (mem/s:DF (plus:SI (reg/f:SI 3275)
> (reg:SI 3812)) [30 Jd+1040 S8 A64])) 578 {*movdf_vfp} (nil)
> (expr_list:REG_DEAD (reg/f:SI 3275)
> (expr_list:REG_DEAD (reg:SI 3812)
> (nil
Where is the matched input operand you're referring to? I don't see any
in the *movdf_vfp pattern.
> > Also, which register is the "inc by 8" note for? R9 or sl?
>
> I thought the value of "inc" wasn't relevant here since we aren't
> dealing with an autoincrement instruction (see the comment in
> reload.h:struct reload).
True, there's a bug in the pretty-printer. Quoting reload1.c:
/* AUTO_INC reloads need to be handled even if inherited. We got an
AUTO_INC reload if reload_out is set but reload_out_reg isn't. */
--
Rask Ingemann Lambertsen
756 unexpected failures, and counting...
Re: libffi & powerpc
Finally, I've tried it the dirty way, ie by commenting out all the
"stfd" instructions at the beginning of the ppc_closure.S file and
things seem to work !!!
"stfd" are used to save fpu registers and were always executed, even
if no float/double arguments were involved in the call and if no fpu
is present.
Of course, I'm still unable to use float/double with the libffi but I
don't need it so I don't think I'm going to dig into this. As far as I
understand, calls to the soft float ABI would be required to fix this.
What worries me a bit is that "stfd" instructions are used to save fpu
registers states before the call (it's my guess) and I would expect
them to be restored afterwards, probably with "lfd" assembly
instructions (that I would need to comment out as well). But I can't
see such instructions...
Any thoughts about that ?
And should I report a new bug for this libffi/powerpc problem ?
And thanks again to all of you for your help.
Patrick
On 5/14/07, Mike Stump <[EMAIL PROTECTED]> wrote:
On May 14, 2007, at 8:46 AM, Patrick Olinet wrote:
> Running with gdb, it looks like the problem comes from the
> ppc_closure.S file of the libffi/src/powerpc directory, at line 32 :
Maybe something like:
#ifndef _SOFT_FLOAT
> stfd %f1, 48(%r1)
#endif
but then, you might have to have something like:
#define CPP_SPEC \
"%{msoft-float: -D_SOFT_FLOAT} \
(picked at random from lynx.h) in the .h file for your port.
:-) But I'm sure there would be more work to do.
Re: libffi & powerpc
Patrick Olinet writes: > Finally, I've tried it the dirty way, ie by commenting out all the > "stfd" instructions at the beginning of the ppc_closure.S file and > things seem to work !!! > > "stfd" are used to save fpu registers and were always executed, even > if no float/double arguments were involved in the call and if no fpu > is present. > > Of course, I'm still unable to use float/double with the libffi but I > don't need it so I don't think I'm going to dig into this. As far as I > understand, calls to the soft float ABI would be required to fix this. I guess that's ok. > What worries me a bit is that "stfd" instructions are used to save fpu > registers states before the call (it's my guess) and I would expect > them to be restored afterwards, probably with "lfd" assembly > instructions (that I would need to comment out as well). But I can't > see such instructions... > > Any thoughts about that ? It doen't matter, because the caller knows that these registers will not be saved. > And should I report a new bug for this libffi/powerpc problem ? It wouldn't hurt. Andrew.
Re: libffi & powerpc
Patrick Olinet writes: > > > I thought that fpu emulation worked by trapping cpu exceptions when a > > > fpu instruction is being executed and then emulating this instruction > > > on software level. > > > > Yes. > > > > > Isn't the mechanism implemented by the "--with-float=soft" option ? > > > > No. FPU emulation requires no special compile-time options. The > > whole idea is that it runs the same code as native FP. > > > > In contrast, soft-float generates inline subroutine calls for all > > floating-point operations. > > ok, I get it. So, is there a way to add fpu emulation emulation to my > platform without having to change anything to my native binary code ? It's the kernel's job. Nothing at all to do with user space code. Andrew.
Re: A reload inheritance bug
Rask Ingemann Lambertsen wrote:
On Tue, May 15, 2007 at 09:31:10AM +0100, Mark Shinwell wrote:
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used for the instruction at B looks like this:
[snip]
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), inc by 8
[snip]
I could be missing something here, but aren't matched operands given a
reload type of RELOAD_OTHER rather than RELOAD_FOR_INPUT?
I might be tripping up on the terminology here then. The original
instruction is:
(insn:HI 5291 5282 5295 2 (set (reg:DF 4078 [ Jd+1040 ])
(mem/s:DF (plus:SI (reg/f:SI 3275)
(reg:SI 3812)) [30 Jd+1040 S8 A64])) 578 {*movdf_vfp} (nil)
(expr_list:REG_DEAD (reg/f:SI 3275)
(expr_list:REG_DEAD (reg:SI 3812)
(nil
Where is the matched input operand you're referring to? I don't see any
in the *movdf_vfp pattern.
Sorry, I am mistaken in the terminology. Change the bullet point to:
- the last use of reg2 (in B) is inside an input operand.
Mark
Re: A reload inheritance bug
Mark Shinwell wrote: > The bug is currently only exhibiting itself on a proprietary testcase > when compiled for an ARM target and is extremely sensitive to the > particular code involved. It arises as follows, using the same notation > as in Richard's mail: If you can't post the testcase, the best thing you can do to help is to print out all the involved RTL insns before and after, as well as output from debug_reload for all of them (possibly once after returning to reload_as_needed from find_reloads, and again after choose_reload_regs has run). Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
dumping profiling info in gmon.out file format
Hello all, gmon.out file is created in mcleanup function.This function however doesn't dump the data in the grof gmon.out data format. When i looked into the code for i386 and sparc in the backend nothing has been done to store the profiling info the required format. How is it that the file thus created is recognized by gprof? Or am i missing something? Thanks for your time. Regards, Shafi.
Stepping down as CLI back-end maintainer
Hello, as a result of my decision to leave STMicroelectronics by the end of the month, I'm stepping down as the maintainer of the st/cli development branch (the home of the CLI back-end). In my next job, I will be working in quite a different field; I already know it won't be compatible with a participation to the community. This means that I may still be able to work on isolated patches, but I will definitely not be able to be an active and continuous contributor. Therefore, I'm giving up the write-after-approval status. I will take care of that in the following days, before leaving ST. I would like to thank everybody in the great GCC community for all the words of encouragement, suggestions and advices, guidance you have relentlessly given me. I have learned a lot while working on GCC and, even most important, I had a lot of fun! The CLI back-end project goes on, and it will be led and maintained by Andrea Ornstein and Erven Rohou at STMicroelectronics. I'm sorry I will not be able to attend this summer's GCC summit, and in particular to give the talk about the CLI back-end. Hopefully, Andrea will replace me... I must say the talk is in very good hands! (By the way, if somebody knows specific summit organizers I should notify... well, please, tell me) Finally, I would like to stay in touch with all of you. This is my personal e-mail is: roberto tod costa ta ensta tod org (reverse the letters of the punctuation words...) I'm looking forward to hearing from you! Cheers, Roberto
Re: A reload inheritance bug
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
> I'm fairly certain that this is the correct approach to fix this
> issue, but I'm less certain that I have correctly guarded the call
> to forget_old_reloads_1, and indeed that I've done everything to
> eradicate the previous reloads involving H. For example, should I be
> wiping the necessary range in reg_last_reload_reg?
No, any use of reg_last_reload_reg should be guarded by
TEST_HARD_REG_BIT(reg_reloaded_valid, reg). It is just an optimization to
avoid a linear scan of reg_reloaded_contents.
> On the subject of
> the guard, I am unsure because the existing code involves a much
> more complicated check:
>
> if (i < 0
> && ((rld[r].out != 0
>&& (REG_P (rld[r].out)
>|| (MEM_P (rld[r].out)
>&& REG_P (rld[r].out_reg
> || (rld[r].out == 0 && rld[r].out_reg
> && REG_P (rld[r].out_reg
>
> Should I perhaps be mirroring this check for the input case too?
> I'm quite keen to make the fix for this bug cover all eventualities
> in terms of the various varieties of reload that might arise, if
> possible...
Reload is 15000+ lines and many if() statements are even more complex
than the one you quote. It is fine to want to cover all eventualities, but
this is the fifth time someone runs into a reload inheritance bug since
about August 2006, so be realistic. I think changes to (except for rewrites
of) reload are best kept small.
There are two places in reload_as_needed() where note_stores() calls
forget_old_reloads(). The first one at the top before emitting reload insns:
else if (INSN_P (insn))
{
regset_head regs_to_forget;
INIT_REG_SET (®s_to_forget);
note_stores (PATTERN (insn), forget_old_reloads_1, ®s_to_forget);
The second one after emitting reload insns, just before the big
AUTO_INC_DEC block at the end:
if (num_eliminable && chain->need_elim)
update_eliminable_offsets ();
/* Any previously reloaded spilled pseudo reg, stored in this
* insn,
is no longer validly lying around to save a future reload.
Note that this does not detect pseudos that were reloaded
for this insn in order to be stored in
(obeying register constraints). That is correct; such reload
registers ARE still valid. */
forget_marked_reloads (®s_to_forget);
CLEAR_REG_SET (®s_to_forget);
/* There may have been CLOBBER insns placed after INSN. So scan
between INSN and NEXT and use them to forget old reloads. */
for (x = NEXT_INSN (insn); x != old_next; x = NEXT_INSN (x))
if (NONJUMP_INSN_P (x) && GET_CODE (PATTERN (x)) == CLOBBER)
note_stores (PATTERN (x), forget_old_reloads_1, NULL);
#ifdef AUTO_INC_DEC
/* Likewise for regs altered by auto-increment in this insn.
It might be worth investigating why these calls to
forget_old_reloads_1(), in particular the second one, don't handle your
case, and which changes would fix it. I'm thinking that maybe we should
include the reload insns themselves in the scan.
--
Rask Ingemann Lambertsen
Re: A reload inheritance bug
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1, and indeed that I've done everything to
eradicate the previous reloads involving H. For example, should I be
wiping the necessary range in reg_last_reload_reg?
No, any use of reg_last_reload_reg should be guarded by
TEST_HARD_REG_BIT(reg_reloaded_valid, reg). It is just an optimization to
avoid a linear scan of reg_reloaded_contents.
OK, thanks.
There are two places in reload_as_needed() where note_stores() calls
forget_old_reloads(). The first one at the top before emitting reload insns:
else if (INSN_P (insn))
{
regset_head regs_to_forget;
INIT_REG_SET (®s_to_forget);
note_stores (PATTERN (insn), forget_old_reloads_1, ®s_to_forget);
This one won't catch the store to the reload register r9 that causes
the clobber because it's only scanning PATTERN (insn). It's the same
issue as noted in the existing comment in emit_reload_insns:
/* If a register gets output-reloaded from a non-spill register,
that invalidates any previous reloaded copy of it.
But forget_old_reloads_1 won't get to see it, because
it thinks only about the original insn. So invalidate it here.
Also do the same thing for RELOAD_OTHER constraints where the
output is discarded. */
The second one after emitting reload insns, just before the big
AUTO_INC_DEC block at the end:
if (num_eliminable && chain->need_elim)
update_eliminable_offsets ();
/* Any previously reloaded spilled pseudo reg, stored in this
* insn,
is no longer validly lying around to save a future reload.
Note that this does not detect pseudos that were reloaded
for this insn in order to be stored in
(obeying register constraints). That is correct; such reload
registers ARE still valid. */
forget_marked_reloads (®s_to_forget);
CLEAR_REG_SET (®s_to_forget);
/* There may have been CLOBBER insns placed after INSN. So scan
between INSN and NEXT and use them to forget old reloads. */
for (x = NEXT_INSN (insn); x != old_next; x = NEXT_INSN (x))
if (NONJUMP_INSN_P (x) && GET_CODE (PATTERN (x)) == CLOBBER)
note_stores (PATTERN (x), forget_old_reloads_1, NULL);
#ifdef AUTO_INC_DEC
/* Likewise for regs altered by auto-increment in this insn.
This case relies on the presence of a CLOBBER though, which we don't
have.
As per Bernd's request I'll provide some more reload/RTL dumps shortly
which might clarify this.
> I'm thinking that maybe we should
include the reload insns themselves in the scan.
I'm not suitably qualified to answer this one, but it sounds more
invasive than my current patch.
Mark
Re: A reload inheritance bug
Bernd Schmidt wrote:
Mark Shinwell wrote:
The bug is currently only exhibiting itself on a proprietary testcase
when compiled for an ARM target and is extremely sensitive to the
particular code involved. It arises as follows, using the same notation
as in Richard's mail:
If you can't post the testcase, the best thing you can do to help is to
print out all the involved RTL insns before and after, as well as output
from debug_reload for all of them (possibly once after returning to
reload_as_needed from find_reloads, and again after choose_reload_regs
has run).
The relevant RTL instructions before reload are as follows. These
correspond to points A, B and C respectively in my previous email.
(insn:HI 5301 3071 3079 2 (set (reg/f:SI 4082)
(reg/f:SI 3275)) 572 {*arm_movsi_vfp} (nil)
(expr_list:REG_EQUIV (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
(nil)))
---
(insn:HI 5291 5282 5295 2 (set (reg:DF 4078 [ Jd+1040 ])
(mem/s:DF (plus:SI (reg/f:SI 3275)
(reg:SI 3812)) [30 Jd+1040 S8 A64])) 578 {*movdf_vfp} (nil)
(expr_list:REG_DEAD (reg/f:SI 3275)
(expr_list:REG_DEAD (reg:SI 3812)
(nil
---
(insn:HI 5314 5308 5318 2 (set (reg:DF 4096 [ Jd+1040 ])
(mem/s:DF (plus:SI (reg/f:SI 4082)
(reg:SI 4084)) [30 Jd+1040 S8 A64])) 578 {*movdf_vfp} (nil)
(expr_list:REG_EQUIV (mem/s:DF (plus:SI (reg/f:SI 4082)
(reg:SI 4084)) [30 Jd+1040 S8 A64])
(nil)))
After reload we end up with the following. I've added dividers to show
the correspondence with the insns above.
(insn:HI 5301 3071 3079 2 (set (mem/f/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 12 [0xc])) [36 S4 A32])
(reg/f:SI 9 r9 [3275])) 572 {*arm_movsi_vfp} (nil)
(expr_list:REG_EQUIV (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
(nil)))
---
(insn 6675 5282 5291 2 (set (reg:SI 9 r9)
(plus:SI (reg/f:SI 9 r9 [3275])
(reg:SI 10 sl [3812]))) 4 {*arm_addsi3} (nil)
(nil))
(insn:HI 5291 6675 5295 2 (set (reg:DF 75 s12 [orig:4078 Jd+1040 ] [4078])
(mem/s:DF (reg:SI 9 r9) [30 Jd+1040 S8 A64])) 578 {*movdf_vfp} (nil)
(nil))
---
(insn 6680 5308 6681 2 (set (reg:SI 1 r1)
(const_int 4928 [0x1340])) 572 {*arm_movsi_vfp} (nil)
(nil))
(insn 6681 6680 5314 2 (set (reg:SI 1 r1)
(plus:SI (reg/f:SI 9 r9 [3275])
(reg:SI 1 r1))) 4 {*arm_addsi3} (nil)
(nil))
(insn:HI 5314 6681 5318 2 (set (reg:DF 75 s12 [orig:4096 Jd+1040 ] [4096])
(mem/s:DF (reg:SI 1 r1) [30 Jd+1040 S8 A64])) 578 {*movdf_vfp} (nil)
(expr_list:REG_EQUIV (mem/s:DF (reg:SI 1 r1) [30 Jd+1040 S8 A64])
(nil)))
We see here how pseudo 3275 was allocated to r9 and pseudo 4082 was
spilled to the stack. At insn 5291, r9 has been allocated [*] as the
reload register since pseudo 3275 dies in that instruction; at insn
5314 we see the then-incorrect use of r9 (in instruction 6681)
for the value of pseudo 4082. Note also how the dump shows that the
compiler thinks r9 still holds the value of pseudo 3275 at insn 6681.
The reloads and the values of the "insn" variable in reload_as_needed
are as follows. These have been dumped at the points you suggest
(the output after choose_reload_regs being the same as after
find_reloads).
For instruction 5301:
(insn:HI 5301 3071 3079 2 (set (reg/f:SI 4082)
(reg/f:SI 9 r9 [3275])) 572 {*arm_movsi_vfp} (nil)
(expr_list:REG_EQUIV (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
(nil)))
Reload 0: reload_out (SI) = (reg/f:SI 4082)
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (reg/f:SI 4082)
For instruction 5291:
(insn:HI 5291 5282 5295 2 (set (reg:DF 75 s12 [orig:4078 Jd+1040 ] [4078])
(mem/s:DF (plus:SI (reg/f:SI 9 r9 [3275])
(reg:SI 10 sl [3812])) [30 Jd+1040 S8 A64])) 578
{*movdf_vfp} (nil)
(expr_list:REG_DEAD (reg/f:SI 9 r9 [3275])
(expr_list:REG_DEAD (reg:SI 10 sl [3812])
(nil
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 9 r9 [3275])
(reg:SI 10 sl [3812]))
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), inc by 8
reload_in_reg: (plus:SI (reg/f:SI 9 r9 [3275])
(reg:SI 10 sl [3812]))
reload_reg_rtx: (reg:SI 9 r9)
For instruction 5314:
(insn:HI 5314 5308 5318 2 (set (reg:DF 75 s12 [orig:4096 Jd+1040 ] [4096])
(mem/s:DF (plus:SI (reg/f:SI 4082)
(reg:SI 4084)) [30 Jd+1040 S8 A64])) 578 {*movdf_vfp} (nil)
(expr_list:REG_EQUIV (mem/s:DF (plus:SI (reg/f:SI 4082)
(reg:SI 4084)) [30 Jd+1040 S8 A64])
(nil)))
Reload 0: reload_in (SI) = (reg/f:SI 4082)
GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
reload_in_reg: (reg/f:SI 4082)
Reload 1: reload_in (SI) = (const_int 4928 [0x1340])
GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1), can't combine
Re: Stepping down as CLI back-end maintainer
On 5/15/07, Roberto COSTA <[EMAIL PROTECTED]> wrote: Hello, as a result of my decision to leave STMicroelectronics by the end of the month, I'm stepping down as the maintainer of the st/cli development branch (the home of the CLI back-end). In my next job, I will be working in quite a different field; I already know it won't be compatible with a participation to the community. This means that I may still be able to work on isolated patches, but I will definitely not be able to be an active and continuous contributor. Therefore, I'm giving up the write-after-approval status. I will take care of that in the following days, before leaving ST. I would like to thank everybody in the great GCC community for all the words of encouragement, suggestions and advices, guidance you have relentlessly given me. I have learned a lot while working on GCC and, even most important, I had a lot of fun! The CLI back-end project goes on, and it will be led and maintained by Andrea Ornstein and Erven Rohou at STMicroelectronics. I'm sorry I will not be able to attend this summer's GCC summit, and in particular to give the talk about the CLI back-end. Hopefully, Andrea will replace me... I must say the talk is in very good hands! (By the way, if somebody knows specific summit organizers I should notify... well, please, tell me) Finally, I would like to stay in touch with all of you. This is my personal e-mail is: roberto tod costa ta ensta tod org (reverse the letters of the punctuation words...) I'm looking forward to hearing from you! Cheers, Roberto Thanks for your efforts. i'm a newbie in GCC community. -- nothing is impossible
Re: A reload inheritance bug
Mark Shinwell wrote: > These dumps are of course taken before the application of my patch. > > Hope that helps, Thanks. I may have missed it in the previous mails, but which piece of code exactly decides to use R9 for reload 0 of insn 5314? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: A reload inheritance bug
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
> I'm fairly certain that this is the correct approach to fix this
> issue, but I'm less certain that I have correctly guarded the call
> to forget_old_reloads_1,
[snip]
> Index: reload1.c
> ===
> --- reload1.c (revision 170932)
> +++ reload1.c (working copy)
> @@ -7506,6 +7506,9 @@ emit_reload_insns (struct insn_chain *ch
> }
> }
>
> + if (i < 0 && rld[r].in != NULL_RTX && rld[r].reg_rtx != NULL_RTX)
> + forget_old_reloads_1 (rld[r].reg_rtx, NULL_RTX, NULL);
> +
>/* The following if-statement was #if 0'd in 1.34 (or before...).
> It's reenabled in 1.35 because supposedly nothing else
> deals with this problem. */
It seems to me that the only special thing happening in your testcase is
that reload.in(_reg) is a PLUS rather than a REG or MEM. Does you patch not
prevent reload inheritance in many cases where it would be OK?
Hmm, the immediately preceeding if() block begins:
/* I is nonneg if this reload used a register.
If rld[r].reg_rtx is 0, this is an optional reload
that we opted to ignore. */
if (i >= 0 && rld[r].reg_rtx != 0)
{
I'd like a similiar comment just before your code. It is the i < 0 in
your case which prevents the preceeding if() block from updating
reg_reloaded_valid and so on.
--
Rask Ingemann Lambertsen
Re: A reload inheritance bug
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1,
[snip]
Index: reload1.c
===
--- reload1.c (revision 170932)
+++ reload1.c (working copy)
@@ -7506,6 +7506,9 @@ emit_reload_insns (struct insn_chain *ch
}
}
+ if (i < 0 && rld[r].in != NULL_RTX && rld[r].reg_rtx != NULL_RTX)
+ forget_old_reloads_1 (rld[r].reg_rtx, NULL_RTX, NULL);
+
/* The following if-statement was #if 0'd in 1.34 (or before...).
It's reenabled in 1.35 because supposedly nothing else
deals with this problem. */
It seems to me that the only special thing happening in your testcase is
that reload.in(_reg) is a PLUS rather than a REG or MEM. Does you patch not
prevent reload inheritance in many cases where it would be OK?
See below.
Hmm, the immediately preceeding if() block begins:
/* I is nonneg if this reload used a register.
If rld[r].reg_rtx is 0, this is an optional reload
that we opted to ignore. */
if (i >= 0 && rld[r].reg_rtx != 0)
{
I'd like a similiar comment just before your code. It is the i < 0 in
your case which prevents the preceeding if() block from updating
reg_reloaded_valid and so on.
I'm not as clear as I ought to be about the i < 0 condition; what I
was trying to establish here was "is this reload register a hard
register that was pre-existing in the subexpression being reloaded"?
I believe this corresponds to "is this register not a spill register"
(hence the use of i < 0, following the existing code below) -- but there
doesn't seem anywhere to be a concrete definition of exactly what
counts as a spill register in this context, so I may be mistaken.
Part of the reason for starting this thread was that I was concerned
about invalidating reloads that could be re-used later. However, it
seems to me that in every circumstance where the reload register is a
hard register and the value assigned to that reload register is
different from the value held by the register during the evaluation of
the subexpression being reloaded (as we have here with r9 <- r9 + r10),
we must invalidate all previous reloads involving that hard register.
I may well have encoded that logic incorrectly in the patch, though.
Mark
--
/* If a register gets output-reloaded from a non-spill register,
that invalidates any previous reloaded copy of it.
But forget_old_reloads_1 won't get to see it, because
it thinks only about the original insn. So invalidate it here.
Also do the same thing for RELOAD_OTHER constraints where the
output is discarded. */
if (i < 0
&& ((rld[r].out != 0
&& (REG_P (rld[r].out)
|| (MEM_P (rld[r].out)
&& REG_P (rld[r].out_reg
|| (rld[r].out == 0 && rld[r].out_reg
&& REG_P (rld[r].out_reg
{
rtx out = ((rld[r].out && REG_P (rld[r].out))
? rld[r].out : rld[r].out_reg);
int nregno = REGNO (out);
/* REG_RTX is now set or clobbered by the main instruction.
As the comment above explains, forget_old_reloads_1 only
sees the original instruction, and there is no guarantee
that the original instruction also clobbered REG_RTX.
For example, if find_reloads sees that the input side of
a matched operand pair dies in this instruction, it may
use the input register as the reload register.
Calling forget_old_reloads_1 is a waste of effort if
REG_RTX is also the output register.
If we know that REG_RTX holds the value of a pseudo
register, the code after the call will record that fact. */
if (rld[r].reg_rtx && rld[r].reg_rtx != out)
forget_old_reloads_1 (rld[r].reg_rtx, NULL_RTX, NULL);
Re: A reload inheritance bug
Bernd Schmidt wrote: Mark Shinwell wrote: These dumps are of course taken before the application of my patch. Hope that helps, Thanks. I may have missed it in the previous mails, but which piece of code exactly decides to use R9 for reload 0 of insn 5314? I'm afraid I'm not sure exactly -- but given that r9 is still deemed to contain a valid reload, isn't that logic correct given the pseudo register numbers in question? Mark
Re: mainline fails to build?
> > On 5/14/07, Mike Stump <[EMAIL PROTECTED]> wrote: > >> > >> it gets farther. Anyone want to claim this is obvious? I glanced at > >> the code and it seems reasonable. > > > > Nothing has changed in dwarf2out.c since April 24. > > > > Now on the other hand c-format.c changed, which might have been the > > problem in the first place. > > Looks like either a change in hwint.h or several changes in #def macros. > > Aaron The problem started with version 124715 which is Rafael Espindola's change to get rid of the unsigned_type langhook. Looks like he is already working on a partial revert to fix the problem. See http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00958.html Steve Ellcey [EMAIL PROTECTED]
Code Samples
Hello, Does anyone know of a good web site for sample C code supported by GCC 3.3.2? Specifically, I am looking for code that can read files from a directory and do I/O. thanks, Craig _ PC Magazines 2007 editors choice for best Web mailaward-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507
Re: Code Samples
I'm sure there are some at your school's website. Or you can ask you TA for help with your homework. -bw On May 15, 2007, at 11:33 AM, craig clow wrote: Hello, Does anyone know of a good web site for sample C code supported by GCC 3.3.2? Specifically, I am looking for code that can read files from a directory and do I/O. thanks, Craig _ PC Magazines 2007 editors choice for best Web mailaward-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507
is gcc 4.2.0 released?
The tarballs for gcc 4.2.0 have been up on the gcc.gnu.org ftp site for a couple of days now. Should we consider gcc 4.2.0 is be released now? Jack
GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.
Hi developers, For the current trunk of GCC, thinking about the related thing of gprof and option -pg of GCC, it's important to output correctly the data with non-fatal accuracy, preferably 4 digits decimal instead of 2, e.g 0. ms instead of 0.00 s. It's important so that the Amdahl's Law can be applicable, mainly to improve the gain of sequential programs. It does not have anything to do with the software's parallelization. http://en.wikipedia.org/wiki/Amdahl's_law To understand, to see the A & B figure and the speedup 1 / (F + (1 - F)/N). Seeing the graph, what happens if B1 is 0.00, B2 is 0.00, .. Bn is 0.00 because of bad accuraccy of 2 digits decimal and in seconds instead of ms? (being B=B1+B2+..+Bn). http://gcc.gnu.org/ml/gcc/2007-04/msg00175.html http://gcc.gnu.org/ml/gcc/2007-04/msg00176.html http://gcc.gnu.org/ml/gcc/2007-04/msg00177.html
Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.
2007/5/15, J.C. Pizarro <[EMAIL PROTECTED]> wrote: http://en.wikipedia.org/wiki/Amdahl's_law It's a wrong link, the next is the correct http://en.wikipedia.org/wiki/Amdahl%27s_law
Re: GCC 4.2.0 Status Report (2007-05-11)
2007/5/12, Mike Stump <[EMAIL PROTECTED]> wrote: On May 11, 2007, at 3:36 PM, J.C. Pizarro wrote: > On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> PR 31797: An infinite loop in the compiler while building RTEMS. > > 1. Can you localize its last output that stops in its internal > infinite loop? > 2. Or, is there an infinite outputting in the console? Did you read the referenced bug report? I suspect not. If not, please consider that you consume $100 for each email you post here and ask yourself, have I donated $100 worth of code to the project recently to pay for the cost of the email. If not, consider not posting the email or donating some more code to pay for it. Are you a president? You are mistaken, i have my freedom of expression. I am free like any person. I'm not a spammer. With the current tools (e.g. bugzilla, mail searcher, ..), if you can not localize the problem's origin then the problem will persist in the future. Is this due to bad A.I.? Poor agent of semantic network?
Re: is gcc 4.2.0 released?
On Tue, May 15, 2007 at 04:28:33PM -0400, Jack Howarth wrote: >The tarballs for gcc 4.2.0 have been up on the gcc.gnu.org > ftp site for a couple of days now. Actually, they've been up for less than 24 hours. As a general rule, the announcement isn't posted until 24 hours after the tarballs go up, to allow time to reach all the mirrors around the world. I'm sure we'll hear from Mark, Real Soon Now.
Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.
On Tue, May 15, 2007 at 10:32:09PM +0200, J.C. Pizarro wrote: > For the current trunk of GCC, thinking about > the related thing of gprof and option -pg of GCC, > > it's important to output correctly the data with non-fatal accuracy, > preferably 4 digits decimal instead of 2, e.g 0. ms instead of 0.00 s. On many platforms, there is only a timer tick 60 times per second. Reporting the result to four places will still give a zero if no timer tick occurred during the execution of a given function. The output is printing to the approximate precision of the data, so printing two places is the correct thing to do. For more accuracy, you need to run the program for a longer time. Most of your queries would be better suited to gcc-help than to gcc, because you don't understand the compiler well enough to make useful contributions to its development.
Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.
2007/5/15, Joe Buck <[EMAIL PROTECTED]> wrote: On Tue, May 15, 2007 at 10:32:09PM +0200, J.C. Pizarro wrote: > For the current trunk of GCC, thinking about > the related thing of gprof and option -pg of GCC, > > it's important to output correctly the data with non-fatal accuracy, > preferably 4 digits decimal instead of 2, e.g 0. ms instead of 0.00 s. On many platforms, there is only a timer tick 60 times per second. Reporting the result to four places will still give a zero if no timer tick occurred during the execution of a given function. The output is printing to the approximate precision of the data, so printing two places is the correct thing to do. It's not well reasoned. Is this the reason to use only 2 digits decimal because a timer only exists? For more accuracy, you need to run the program for a longer time. It's false, it's like a false positive. There are cases in that stretching the run time does not improve accuracy of the program. For a better accuracy, it's slowering the CPU clock to stretch the accuracy, This is obtained of several ways: * to use an old PC of few MHz. * to lower the frequency of clock of a modern PC. * or to use a slow emulator, but in the reality, its real timings are unpredictable due to the difficulty to complete all its necessary logic like predicting the timings of the scheduling of the instructions and of the memories like the caches and the DRAMs. Most of your queries would be better suited to gcc-help than to gcc, because you don't understand the compiler well enough to make useful contributions to its development. Are you saying me that I don't understand compilers? and if I am clever?.
Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.
On Wed, May 16, 2007 at 12:02:57AM +0200, J.C. Pizarro wrote: > 2007/5/15, Joe Buck <[EMAIL PROTECTED]> wrote: > [ explanation of why gprof is as it is ] > It's not well reasoned. If you don't like my explanation, feel free to rewrite the software; it is free software after all. This list usually responds even to good ideas with "patches welcome", meaning that it is up to the proposer to do the work. I'm not going to engage you in further discussion.
Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.
On 5/15/07, Joe Buck <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 12:02:57AM +0200, J.C. Pizarro wrote: > 2007/5/15, Joe Buck <[EMAIL PROTECTED]> wrote: > [ explanation of why gprof is as it is ] > It's not well reasoned. If you don't like my explanation, feel free to rewrite the software; it is free software after all. This list usually responds even to good ideas with "patches welcome", meaning that it is up to the proposer to do the work. I'm not going to engage you in further discussion. Of course gprof is unrelated to GCC except for the call to mcount that GCC is able to emit so this is offtopic at best. -- Pinski
Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.
2007/5/16, Joe Buck <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 12:02:57AM +0200, J.C. Pizarro wrote: > 2007/5/15, Joe Buck <[EMAIL PROTECTED]> wrote: > [ explanation of why gprof is as it is ] > It's not well reasoned. If you don't like my explanation, feel free to rewrite the software; it is free software after all. This list usually responds even to good ideas with "patches welcome", meaning that it is up to the proposer to do the work. I'm not going to engage you in further discussion. With my comments, i can help them to attempt to improve the things. Before beginning, this will be an affair between 3 entities: gprof, gcc and linux kernel. The tricks are to use instructions of timing of CPU like RDTSC in addition to timers clocks (ticks: 1 Hz or 50, 60, 100, 120, 250, 1000 Hz) and kernel patches. The kernel will have to inform (if it was requested by the user process through a system call) to the user process the corresponding needed information being written it to a memory's cell previously requested. Any type of flaw does not have to happen. This information must contain minimumly the number (long64) of the subcontext sequence uniquely identified as a result of the context's switches, system calls, interruptions, signals, etc. The kernel or a daemon must give a detailed list of the timings of subcontexts that were available for only the requested process of user (user time of program's running only) without counting the lost times by I/O, interruptions, signals, etc. The list of the lost times can be requested too. With this numerous information, the profiler can collect this data and calculate the timings shown as presentation in a horizontal bar (or vertical bar) to be applicable the Amhdal's Law. For instance, this tuple stored in the memory's cell of the user process gives an idea * number of quantum's subcontext: long64 * moment of time that the subcontext started: long64 (CPU cycles, from RDTSC) * (optional) moment subcontext started: uint32 (Unix's seconds from 1970) * etc. (a context is formed by several subcontexts) Initially, it's known that the duration of one ideal RDTSC's cycle is calculated (double64) or that how many cycles of RDTSC are one second (long64). Then, profiler's functions can use this tuple to compare if the differences between RDTSC's values are inside of the time quantum or not. There are many other alternatives as don't store it in the memory's cell of the user process. It's like to store the tuples in the list of the kernel, of the daemon or of another place. This is only the end point of an iceberg. Sincerely yours, J.C.
GCC 4.2 branch open for regression fixes
The GCC 4.2.0 release is done, so the 4.2 branch is now open for checkins under the usual branch rules: regression fixes only. I know that the GCC 4.2.0 release was a long time coming. Thanks to everyone who worked on it, and for the constructive comments and criticisms! I'll be thinking about a possible 4.1.3 release, an upcoming 4.2.1 release, and 4.3.0 planning in the near future and will send a status report at this time. Here's the (boring) set of patches that I checked in as part of the release checklist. While simple, I've made mistakes with these patches before; if you spot any, please let me know! I'll be sending out a release announcement momentarily. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Index: ChangeLog === --- ChangeLog (revision 124663) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2007-05-13 Mark Mitchell <[EMAIL PROTECTED]> + + * gennews (files): Reference GCC 4.2 web pages. + 2007-04-04 Zack Weinberg <[EMAIL PROTECTED]> * texi2pod.pl: Correct handling of @itemize with no argument. Index: gennews === --- gennews (revision 124623) +++ gennews (working copy) @@ -22,7 +22,9 @@ # Boston, MA 02110-1301, USA. website=http://gcc.gnu.org/ -files="gcc-4.1/index.html gcc-4.1/changes.html +files=" +gcc-4.2/index.html gcc-4.2/changes.html +gcc-4.1/index.html gcc-4.1/changes.html gcc-4.0/index.html gcc-4.0/changes.html gcc-3.4/index.html gcc-3.4/changes.html gcc-3.3/index.html gcc-3.3/changes.html Index: gcc-4.2/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.2/index.html,v retrieving revision 1.1 diff -c -5 -p -r1.1 index.html *** gcc-4.2/index.html 21 Oct 2006 02:54:29 - 1.1 --- gcc-4.2/index.html 14 May 2007 00:46:02 - *** *** 6,15 GCC 4.2 Release Series ! No releaes yet. --- 6,54 GCC 4.2 Release Series ! May 13, 2007 ! ! The http://www.gnu.org";>GNU project and the GCC ! developers are pleased to announce the release of GCC 4.2.0. ! ! This release is a major release, containing new features (as well ! as many other improvements) relative to GCC 4.1.x. ! ! Release History ! ! ! GCC 4.2.0 ! May 13, 2007 ! (changes) ! ! ! ! ! References and Acknowledgements ! ! GCC used to stand for the GNU C Compiler, but since the compiler ! supports several other languages aside from C, it now stands for the ! GNU Compiler Collection. ! ! A list of successful builds is updated ! as new information becomes available. ! ! The GCC developers would like to thank the numerous people that have ! contributed new features, improvements, bug fixes, and other changes as ! well as test results to GCC. ! This http://gcc.gnu.org/onlinedocs/gcc/Contributors.html";>amazing ! group of volunteers is what makes GCC successful. ! ! For additional information about GCC please refer to the ! GCC project web site or contact the ! mailto:gcc@gcc.gnu.org";>GCC development mailing list. ! ! To obtain GCC please use our mirror sites, ! one of the http://www.gnu.org/order/ftp.html";>GNU mirror sites, ! or our SVN server. 2007-05-13 Mark Mitchell <[EMAIL PROTECTED]> * cpplib.pot: Regenerate. 2007-05-13 Mark Mitchell <[EMAIL PROTECTED]> * gcc.pot: Regenerate. Index: DEV-PHASE === --- DEV-PHASE (revision 124718) +++ DEV-PHASE (revision 124719) @@ -0,0 +1 @@ +prerelease Index: ChangeLog === --- ChangeLog (revision 124718) +++ ChangeLog (revision 124719) @@ -1,3 +1,8 @@ +2007-05-14 Mark Mitchell <[EMAIL PROTECTED]> + + * BASE-VER: Set to 4.2.1. + * DEV-PHASE: Set to prerelease. + 2007-05-13 Release Manager * GCC 4.2.0 released. Index: BASE-VER === --- BASE-VER(revision 124718) +++ BASE-VER(revision 124719) @@ -1 +1 @@ -4.2.0 +4.2.1 Index: develop.html === RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v retrieving revision 1.79 diff -c -5 -p -r1.79 develop.html *** develop.html14 Feb 2007 08:30:52 - 1.79 --- develop.html14 May 2007 19:19:08 - *** stages of development, branch points, an *** 373,383 | | +-- GCC 4.2 branch created --+ |(Oct 20 2006)\ v v ! GCC 4.3 Stage 1 (ends Jan 20 2007) GCC 4.2.0 release | v GCC 4.3 Stage 2 | v --- 373,383 | | +-- GCC 4.2 branch created --+ |(Oct 20 2
4.2.0 build/test results
Here are some build/test results for the 4.2.0 release. #1: i686-pc-linux-gnu on RHEL 3, booted with gcc 3.4.2 (all languages except Ada). http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00713.html (NOTE: booting with the RHEL-supplied compiler fails the compare). #2: x86_64-unknown-linux-gnu on RHEL 3, booted with Red Hat's 3.2.3 (all languages except Ada). http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00710.html #3: sparc-sun-solaris2.8: failure in building jv-convert (while building libjava). Test result for languages other than Java or Ada: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00714.html The failure I got was /bin/ksh ./libtool --tag=GCJ --mode=link /remote/atg5/jbuck/gcc-4.2.0-sol2-build/gcc/gcj -B/remote/atg5/jbuck/gcc-4.2.0-sol2-build/sparc-sun-solaris2.8/libjava/ -B/remote/atg5/jbuck/gcc-4.2.0-sol2-build/gcc/ -L/remote/atg5/jbuck/gcc-4.2.0-sol2-build/sparc-sun-solaris2.8/libjava -g -O2 -o jv-convert --main=gnu.gcj.convert.Convert -rpath /u/jbuck/cvs.sol2/4.2.0/lib -shared-libgcc -L/remote/atg5/jbuck/gcc-4.2.0-sol2-build/sparc-sun-solaris2.8/libjava/.libs libgcj.la /remote/atg5/jbuck/gcc-4.2.0-sol2-build/gcc/gcj -B/remote/atg5/jbuck/gcc-4.2.0-sol2-build/sparc-sun-solaris2.8/libjava/ -B/remote/atg5/jbuck/gcc-4.2.0-sol2-build/gcc/ -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/remote/atg5/jbuck/gcc-4.2.0-sol2-build/sparc-sun-solaris2.8/libjava -L/remote/atg5/jbuck/gcc-4.2.0-sol2-build/sparc-sun-solaris2.8/libjava/.libs ./.libs/libgcj.so -L/remote/atg5/jbuck/gcc-4.2.0-sol2-build/sparc-sun-solaris2.8/libstdc++-v3/src -L/remote/atg5/jbuck/gcc-4.2.0-sol2-build/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -lpthread -lrt -ldl -L/remote/atg5/jbuck/gcc-4.2.0-sol2-build/./gcc -L/usr/ccs/lib -lgcc_s -lgcc_s -Wl,--rpath -Wl,/u/jbuck/cvs.sol2/4.2.0/lib /u/jbuck/gnu.sol2/bin/ld: unrecognized option '-Wl,-rpath' /u/jbuck/gnu.sol2/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status /u/jbuck/gnu.sol2/bin/ld is GNU ld version 2.17.
Re: 4.2.0 build/test results
On Tue, May 15, 2007 at 06:04:11PM -0700, Joe Buck wrote: > #3: sparc-sun-solaris2.8: failure in building jv-convert (while > building libjava). I think this is due to libiconv problems. It's a machine I don't control where someone put a GNU libiconv in /usr/local, which tends to mess things up. I don't usually build Java because it takes so long on that box.
Re: dumping profiling info in gmon.out file format
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> gmon.out file is created in mcleanup function.This function however
> doesn't dump the data in the grof gmon.out data format. When i looked
> into the code for i386 and sparc in the backend nothing has been done
> to store the profiling info the required format. How is it that the
> file thus created is recognized by gprof? Or am i missing something?
Assuming you are referring to gcc/config/{i386,sparc}/gmon-sol2.c,
that code is only used on Solaris, not on other operating systems.
Are you using Solaris?
On GNU/Linux gmon.out is generated by code in glibc, not gcc. The
glibc code is in gmon/gmon.c in the glibc sources.
Ian
Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.
2007/5/16, J.C. Pizarro <[EMAIL PROTECTED]> wrote: For instance, this tuple stored in the memory's cell of the user process gives an idea * number of quantum's subcontext: long64 * moment of time that the subcontext started: long64 (CPU cycles, from RDTSC) * (optional) moment subcontext started: uint32 (Unix's seconds from 1970) * etc. I'm sorry, i forgot to put the fields of the finished moments of the previous subcontext (or last subcontext). * number of quantum's subcontext: long64 * moment of time that the subcontext started: long64 (CPU cycles, from RDTSC) * moment of time that the subcontext finished: long64 (CPU cycles, from RDTSC) * (optional) moment subcontext started: uint32 (Unix's seconds from 1970) * (optional) moment subcontext finished: uint32 (Unix's seconds from 1970) * etc. Note: to request the seconds from 1970 of timer clock can be slow (or not) when the things are measured in nanoseconds, so that by a design decision, it is possible not to recommend the use of this slow request. Sincerely yours, J.C.
Re: libffi & powerpc
On May 15, 2007, at 2:20 AM, Patrick Olinet wrote: Finally, I've tried it the dirty way, ie by commenting out all the "stfd" instructions at the beginning of the ppc_closure.S file and things seem to work !!! Wonderful. If you could, would you submit the patch to gcc- patches... I suspect it is better than nothing, and it might be trivial enough to go in without paperwork. Additionally, it might provide a basis for another contributor to build upon, as they then only have to do half the work. Thanks. What worries me a bit is that "stfd" instructions are used to save fpu registers states before the call (it's my guess) and I would expect them to be restored afterwards, probably with "lfd" assembly instructions (that I would need to comment out as well). But I can't see such instructions... Any thoughts about that ? Sure, don't worry about it, there is no matching instruction. You just can't do functions that return float/double/long double from my quick reading. And should I report a new bug for this libffi/powerpc problem ? We prefer to have a bug report for each bug... :-)
Re: GCC's trunk, it is necessary to improve the timings from gprof/gcc -pg.
This has nothing to do with the development of gcc, so please take it elsewhere.
Re: GCC 4.2.0 Status Report (2007-05-11)
On May 15, 2007, at 2:03 PM, J.C. Pizarro wrote: 2007/5/12, Mike Stump <[EMAIL PROTECTED]> wrote: On May 11, 2007, at 3:36 PM, J.C. Pizarro wrote: > On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> PR 31797: An infinite loop in the compiler while building RTEMS. > > 1. Can you localize its last output that stops in its internal > infinite loop? > 2. Or, is there an infinite outputting in the console? Did you read the referenced bug report? I suspect not. If not, please consider that you consume $100 for each email you post here and ask yourself, have I donated $100 worth of code to the project recently to pay for the cost of the email. If not, consider not posting the email or donating some more code to pay for it. Are you a president? Sure. You are mistaken, i have my freedom of expression. I am free like any person. Really? So, do you think you're free to talk about how to bake brownies on this list? Watch the google video linked to from slashdot a little while ago about code development in open source projects: http://developers.slashdot.org/article.pl?sid=07/03/12/1449201 and see what role you play, then see what role the people that tell you your posts are off-topic play and try and guess what role I play. Ask yourself, what direct benefit to the project does your contribution have? This list is for people that want to contribute code to gcc and for those that want to help and enable people that want to contribute code to gcc. My response to you I think is fairly off-topic for the list and is why I didn't include the whole list on that response, and I think your response above is off-topic as well. Let me repeat once more, please, stop posting off-topic posts to this list. This list is not open to off-topic posts. If you want to talk about the appropriateness of posting things to this list, you can talk about that on [EMAIL PROTECTED] if you'd like. Thank you for your consideration in this matter.
Re: c-common.c line 5179: isn't this a nop?
Matt Thomas <[EMAIL PROTECTED]> writes: > In handle_aligned_attributes in c-common.c, at line 5146, it does > > type = &TREE_TYPE (decl); > > Then at 5179 it does > > TREE_TYPE (decl) = *type; > > In between, type doesn't change so that's really > > TREE_TYPE (decl) = * &TREE_TYPE (decl); > or > TREE_TYPE (decl) = TREE_TYPE (decl); > > now that seems redundant to me. Maybe it was supposed to be > something else. I agree that this is redundant. It's because of how the code was changed when attribute handling was broken up from a single big function to a table of function pointers: 2001-09-21 Joseph S. Myers <[EMAIL PROTECTED]> Table-driven attributes. Ian
Re: Supporting 'MAC' instruction on gcc v4.1.1
On 5/12/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> But for the following example
> int a = 1;
> int b = 2;
> int c = 3;
> c = c + a * b;
> the MAC pattern is not getting recognized, instead it is still using
> PLUS and MULT patterns.
Your example is bogus. This is optimized to "c = 5" well before we get to RTL.
Thank you for the responses.
Yes, my example was wrong. I was hoping that the combining of related
instructions, by the combiner, will be taking place when no
optimization (-O0) is enabled.
When i changed my example to:
int a, b, c;
scanf ("%d", &a);
scanf ("%d", &b);
scanf ("%d", &c);
c = c + a * b;
printf("c = %d\n", c);
and compiled with optimization (-O1 to -O3, -Os), the MAC pattern got
recognized.
But for -O0 optimization, even the 'progname.c.*.combine file' is
*not* getting generated for '-fdump-rtl-all / -fdump-rtl-combine'
options.
Please tell me whether the combining of related instructions, by the
combiner, will be taking place only when optimization is enabled? if
that is the case, is there any way to make gcc recognize the 'MAC"
pattern for -O0 optimisation?
Paul
Regards,
Rahul
