public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures
@ 2009-03-11 14:28 jakub at gcc dot gnu dot org
2009-03-11 16:57 ` [Bug debug/39432] " vmakarov at redhat dot com
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-03-11 14:28 UTC (permalink / raw)
To: gcc-bugs
Running ../../../gdb/testsuite/gdb.base/store.exp ...
FAIL: gdb.base/store.exp: upvar charest l; print old l, expecting -1 .*
FAIL: gdb.base/store.exp: upvar short l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar int l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar long l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar longest l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar doublest l; print old l, expecting -1
are new failures in gdb testsuite when compiled with 4.4 compared to store.c
compiled with 4.3.x. The difference seems to be introduced by IRA, when
compiled with -fno-ira (when trunk still had that option) the test worked.
With the old RA, -g -O0 -dA -fverbose-asm compiled:
unsigned int foo (unsigned int, unsigned int);
unsigned int bar (register unsigned int a, register unsigned int b)
{
register unsigned int c = a, d = b;
c = foo (c, d);
return c + d;
}
d is allocated in a call-saved register (%ebx), which is fine and c is assigned
a stack slot. With IRA d is still allocated in %ebx, but c is in %eax,
call-clobbered register. So when gdb in the foo call does up and checks the
value in c and d, it finds correct value of d, but garbage in c.
Could we perhaps at -O0 avoid allocating user variables that are live accross
function calls in call-clobbered registers? For -O1 it is obviously a fine
decision.
--
Summary: [4.4 Regression] gdb.base/store.exp failures
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures
2009-03-11 14:28 [Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures jakub at gcc dot gnu dot org
@ 2009-03-11 16:57 ` vmakarov at redhat dot com
2009-03-11 17:02 ` rguenth at gcc dot gnu dot org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vmakarov at redhat dot com @ 2009-03-11 16:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from vmakarov at redhat dot com 2009-03-11 16:57 -------
Jakub, how is about the following patch. Is it ok for you? I mean correct
user variable identification.
2009-03-11 Vladimir Makarov <vmakarov@redhat.com>
PR debug/39432
* ira-int.h (struct allocno): Fix comment for calls_crossed_num.
* ira-conflicts.c (ira_build_conflicts): Prohibit call used
registers for allocnos created from user-defined variables.
Index: ira-int.h
===================================================================
--- ira-int.h (revision 144543)
+++ ira-int.h (working copy)
@@ -333,7 +333,7 @@ struct ira_allocno
/* Accumulated frequency of calls which given allocno
intersects. */
int call_freq;
- /* Length of the previous array (number of the intersected calls). */
+ /* Accumulated number of the intersected calls. */
int calls_crossed_num;
/* Non NULL if we remove restoring value from given allocno to
MEM_OPTIMIZED_DEST at loop exit (see ira-emit.c) because the
Index: ira-conflicts.c
===================================================================
--- ira-conflicts.c (revision 144543)
+++ ira-conflicts.c (working copy)
@@ -800,29 +800,33 @@ ira_build_conflicts (void)
}
FOR_EACH_ALLOCNO (a, ai)
{
- if (ALLOCNO_CALLS_CROSSED_NUM (a) == 0)
- continue;
- if (! flag_caller_saves)
+ reg_attrs *attrs;
+ tree decl;
+
+ if ((! flag_caller_saves && ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
+ /* For debugging purposes don't put user defined variables in
+ callee-clobbered registers. */
+ || (optimize <= 1
+ && (attrs = REG_ATTRS (regno_reg_rtx [ALLOCNO_REGNO (a)])) !=
NULL
+ && (decl = attrs->decl) != NULL
+ && VAR_OR_FUNCTION_DECL_P (decl)
+ && DECL_NAME (decl) != NULL))
{
IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
call_used_reg_set);
- if (ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
- IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
- call_used_reg_set);
+ IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
+ call_used_reg_set);
}
- else
+ else if (ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
{
IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
no_caller_save_reg_set);
IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
temp_hard_reg_set);
- if (ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
- {
- IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
- no_caller_save_reg_set);
- IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
- temp_hard_reg_set);
- }
+ IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
+ no_caller_save_reg_set);
+ IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
+ temp_hard_reg_set);
}
}
if (optimize && ira_conflicts_p
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures
2009-03-11 14:28 [Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures jakub at gcc dot gnu dot org
2009-03-11 16:57 ` [Bug debug/39432] " vmakarov at redhat dot com
@ 2009-03-11 17:02 ` rguenth at gcc dot gnu dot org
2009-03-11 17:11 ` vmakarov at redhat dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-03-11 17:02 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-11 17:02 -------
You should use DECL_ARTIFICIAL I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures
2009-03-11 14:28 [Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures jakub at gcc dot gnu dot org
2009-03-11 16:57 ` [Bug debug/39432] " vmakarov at redhat dot com
2009-03-11 17:02 ` rguenth at gcc dot gnu dot org
@ 2009-03-11 17:11 ` vmakarov at redhat dot com
2009-03-11 17:12 ` jakub at gcc dot gnu dot org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vmakarov at redhat dot com @ 2009-03-11 17:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from vmakarov at redhat dot com 2009-03-11 17:10 -------
Thanks, Richard.
So instead of "DECL_NAME (decl) != NULL" I should use "! DECL_ARTIFICIAL
(decl)". Right?
Ok, I'll test the new patch then and send it for approval after testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures
2009-03-11 14:28 [Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures jakub at gcc dot gnu dot org
` (2 preceding siblings ...)
2009-03-11 17:11 ` vmakarov at redhat dot com
@ 2009-03-11 17:12 ` jakub at gcc dot gnu dot org
2009-03-11 17:28 ` vmakarov at redhat dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-03-11 17:12 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from jakub at gcc dot gnu dot org 2009-03-11 17:11 -------
Also perhaps should test DECL_HARD_REGISTER, for DECL_HARD_REGISTER we
shouldn't limit them in any way to allow the user to shoot himself.
In any case, I'll test your patch momentarily.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures
2009-03-11 14:28 [Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures jakub at gcc dot gnu dot org
` (3 preceding siblings ...)
2009-03-11 17:12 ` jakub at gcc dot gnu dot org
@ 2009-03-11 17:28 ` vmakarov at redhat dot com
2009-03-11 19:38 ` jakub at gcc dot gnu dot org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vmakarov at redhat dot com @ 2009-03-11 17:28 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from vmakarov at redhat dot com 2009-03-11 17:28 -------
As for DECL_HARD_REGISTER, such decl regs are never considered by IRA for
allocation. So I think there is no necessity to check them here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures
2009-03-11 14:28 [Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures jakub at gcc dot gnu dot org
` (4 preceding siblings ...)
2009-03-11 17:28 ` vmakarov at redhat dot com
@ 2009-03-11 19:38 ` jakub at gcc dot gnu dot org
2009-03-12 14:40 ` vmakarov at gcc dot gnu dot org
2009-03-12 15:49 ` jakub at gcc dot gnu dot org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-03-11 19:38 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from jakub at gcc dot gnu dot org 2009-03-11 19:38 -------
I can confirm that trunk with the #c1 patch modified as mentioned in #c3 cures
all the gdb.base/store.exp failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures
2009-03-11 14:28 [Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures jakub at gcc dot gnu dot org
` (5 preceding siblings ...)
2009-03-11 19:38 ` jakub at gcc dot gnu dot org
@ 2009-03-12 14:40 ` vmakarov at gcc dot gnu dot org
2009-03-12 15:49 ` jakub at gcc dot gnu dot org
7 siblings, 0 replies; 9+ messages in thread
From: vmakarov at gcc dot gnu dot org @ 2009-03-12 14:40 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from vmakarov at gcc dot gnu dot org 2009-03-12 14:40 -------
Subject: Bug 39432
Author: vmakarov
Date: Thu Mar 12 14:39:55 2009
New Revision: 144812
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144812
Log:
2009-03-12 Vladimir Makarov <vmakarov@redhat.com>
PR debug/39432
* ira-int.h (struct allocno): Fix comment for calls_crossed_num.
* ira-conflicts.c (ira_build_conflicts): Prohibit call used
registers for allocnos created from user-defined variables.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-conflicts.c
trunk/gcc/ira-int.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/39432] [4.4 Regression] gdb.base/store.exp failures
2009-03-11 14:28 [Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures jakub at gcc dot gnu dot org
` (6 preceding siblings ...)
2009-03-12 14:40 ` vmakarov at gcc dot gnu dot org
@ 2009-03-12 15:49 ` jakub at gcc dot gnu dot org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-03-12 15:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from jakub at gcc dot gnu dot org 2009-03-12 15:49 -------
Fixed, thanks.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-03-12 15:49 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-11 14:28 [Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures jakub at gcc dot gnu dot org
2009-03-11 16:57 ` [Bug debug/39432] " vmakarov at redhat dot com
2009-03-11 17:02 ` rguenth at gcc dot gnu dot org
2009-03-11 17:11 ` vmakarov at redhat dot com
2009-03-11 17:12 ` jakub at gcc dot gnu dot org
2009-03-11 17:28 ` vmakarov at redhat dot com
2009-03-11 19:38 ` jakub at gcc dot gnu dot org
2009-03-12 14:40 ` vmakarov at gcc dot gnu dot org
2009-03-12 15:49 ` jakub at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).