on 27/05/2008 22:00 Andrew Pinski said the following:
On Tue, May 27, 2008 at 11:56 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote:
Thank you for the explanation! I didn't realize the difference.
OTOH, do you think that those arithmetic warnings are practical (as opposed
to being correct)?
I thin
Hi.
I'm trying to figure out the structure of MIPS stack frame and how to
write .frame / .mask properly. Since gcc/config/mips/mips.c was
rewritten by Richard Sandiford, it got clearer that what GCC does
(thanks for that).
- In gcc/config/mips/mips.c:mips_compute_frame_info() you do
/
On 5/27/08, Joe Buck <[EMAIL PROTECTED]> wrote:
> A third alternative is to issue a snapshot (at whatever time interval
> is chosen) iff there's been a checkin on the branch.
I thought that's how it worked already.
If L_R_A does nothing with it,
the normal reload handling will first try:
(const:HI (plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int 2
This worked just as your described after I added test of
reg_equiv_constant[] inside L_R_A .
So I guess that looks like the fix for bug I post
Thank you very much for reply. reload is such a lonely place!
TBH, it sounds like the opposite: LEGITIMIZE_RELOAD_ADDRESS should
not be handling this address at all.
Yes but reload will not do anything before call to L_R_A. So in practice
that would mean L_R_A has
to check reg_equiv_constant[re
Andy H <[EMAIL PROTECTED]> writes:
> I am am tracking down ICE bug in reload during global register allocation.
>
> I have managed to find root of problem but I am not sure how it should
> work correctly. I would appreciate anyones advise on this.
>
> ICE is from assert in push_reload to ensure
On Tue, May 27, 2008 at 10:48 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> > My recommendation in my very unoffical role as "carer of the snapshots"
> > is to stop doing those weekly snapshots for the 4.1 branch, and I will
> > be happy to roll a new snapshot upon request in case someone (like
On Tue, May 27, 2008 at 10:48 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> At this point, we have three open release branches (4.1, 4.2, and 4.3)
> and trunk. Currently we are generating weekly snapshots for all four
> of these.
>
> A while ago we agreed, for a number of reasons, not to do any
Hello all,
In the context of the GlobalGCC project (http://www.ggcc.info,
http://gcc.gnu.org/ml/gcc/2006-10/msg00676.html) we are developing a
facility for automatically enforcing coding rules.
Coding rules codify "good programming practices" that improve
reliability and maintainability in langua
At this point, we have three open release branches (4.1, 4.2, and 4.3)
and trunk. Currently we are generating weekly snapshots for all four
of these.
A while ago we agreed, for a number of reasons, not to do any further
GCC 4.1.x releases and the speed of changes on that branch has noticably
slo
On Tue, May 27, 2008 at 11:56 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote:
> Thank you for the explanation! I didn't realize the difference.
>
> OTOH, do you think that those arithmetic warnings are practical (as opposed
> to being correct)?
I think so as the short int case has a defined overflow o
on 27/05/2008 21:48 Andrew Pinski said the following:
On Tue, May 27, 2008 at 11:29 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote:
Should I still open a new one or maybe it's better to follow up on one of
those two.
And just in case, here's a better description of what I am reporting
(demonstratio
On Tue, May 27, 2008 at 11:29 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote:
> Should I still open a new one or maybe it's better to follow up on one of
> those two.
>
> And just in case, here's a better description of what I am reporting
> (demonstration by comparison):
The warnings with the below co
on 27/05/2008 13:50 Manuel López-Ibáñez said the following:
Please, open a bug report: http://gcc.gnu.org/bugzilla/
Manuel,
I looked through open GCC bugs and it seems that the following bugs are
very similar to what I report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34389
http://gcc.gnu.
gdb guy wrote:
> If I have the following code:
>
>
> Basically I'm just curious to understand why gcc adds this extra space.
The stack pointer is always 16-aligned. Does that help?
Andrew.
If I have the following code:
struct bob{
int a;
char b[8];
int c;
};
struct bob barker;
...
void sub1(unsigned int size){
int someflag=0;
struct bob dole;
memcpy(&dole.b,&barker.b,size);
}
let's say I call the code as sub(8) (the code is intentiona
16 matches
Mail list logo
