On Wed, 17 Mar 2010, Jakub Jelinek wrote:
On Wed, Mar 17, 2010 at 09:26:29PM +0100, Jakub Jelinek wrote:
That will very much pessimize debug info. While we are now always in
-funit-at-a-time mode, that doesn't mean DECL_RTL is computed early enough.
From the file scope non-static vars, at
On Thu, Mar 18, 2010 at 04:25:03PM +0100, Richard Guenther wrote:
On Wed, 17 Mar 2010, Jakub Jelinek wrote:
On Wed, Mar 17, 2010 at 09:26:29PM +0100, Jakub Jelinek wrote:
That will very much pessimize debug info. While we are now always in
-funit-at-a-time mode, that doesn't mean
Hi folks.
I am debugging a bunch of Fortran -fdebug-compare failures on the
testsuite, all of which stem from symbols ending up on different alias
set slots. Notice the 2 versus 3 discrepancy below:
(insn:TI# 0 0 a.f90:3 (set (mem/c/i:SI (symbol_ref:DI (i.0.1535)
[flags 0x2] var_decl # i.0) [2
On Wed, Mar 17, 2010 at 12:06:49PM -0400, Aldy Hernandez wrote:
What happens is that rtl_for_decl_location():dwarf2out.c will call
make_decl_rtl() which further down the call chain will call
get_alias_set/new_alias_set. It matters not that we reset DECL_RTL
immediately after, we have already
On Wed, Mar 17, 2010 at 5:32 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Mar 17, 2010 at 12:06:49PM -0400, Aldy Hernandez wrote:
What happens is that rtl_for_decl_location():dwarf2out.c will call
make_decl_rtl() which further down the call chain will call
get_alias_set/new_alias_set. It
On Wed, Mar 17, 2010 at 5:51 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Mar 17, 2010 at 5:32 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Mar 17, 2010 at 12:06:49PM -0400, Aldy Hernandez wrote:
What happens is that rtl_for_decl_location():dwarf2out.c will call
I guess best would be to make sure no new alias set is created in these
places. Perhaps
int save_strict_aliasing = flag_strict_aliasing;
flag_strict_aliasing = 0;
rtl = DECL_RTL (decl);
flag_strict_aliasing = save_strict_aliasing;
in both places?
Remember when I said I had come up with
? ? rtl = DECL_RTL (decl);
? ? /* Reset DECL_RTL back, as various parts of the compiler expects
? ? ? ?DECL_RTL set meaning it is actually going to be output. ?*/
? ? SET_DECL_RTL (decl, NULL);
... why do this in the first place? ?Is this an issue for all decls or just
for
On Wed, Mar 17, 2010 at 6:28 PM, Aldy Hernandez al...@redhat.com wrote:
? ? rtl = DECL_RTL (decl);
? ? /* Reset DECL_RTL back, as various parts of the compiler expects
? ? ? ?DECL_RTL set meaning it is actually going to be output. ?*/
? ? SET_DECL_RTL (decl, NULL);
... why do this in
On Wed, Mar 17, 2010 at 6:40 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Mar 17, 2010 at 6:28 PM, Aldy Hernandez al...@redhat.com wrote:
? ? rtl = DECL_RTL (decl);
? ? /* Reset DECL_RTL back, as various parts of the compiler expects
? ? ? ?DECL_RTL set meaning it is
On Wed, Mar 17, 2010 at 06:40:30PM +0100, Richard Guenther wrote:
var_decl 0x7794d140 __BLNK__
type record_type 0x779493f0 SI
size integer_cst 0x77854988 constant 32
unit size integer_cst 0x77854690 constant 4
align 32 symtab 0 alias set -1
On Wed, Mar 17, 2010 at 09:26:29PM +0100, Jakub Jelinek wrote:
That will very much pessimize debug info. While we are now always in
-funit-at-a-time mode, that doesn't mean DECL_RTL is computed early enough.
From the file scope non-static vars, at the point debug info is generated only
the
Are you suggesting we remove the entire code path here:
?/* Try harder to get a rtl. ?If this symbol ends up not being emitted
? ? in the current CU, resolve_addr will remove the expression referencing
? ? it. ?*/
??
Yes.
That will very much pessimize debug info.
On Wed, Mar 17, 2010 at 06:08:06PM -0400, Aldy Hernandez wrote:
So... Richi, et al. Instead, should I remove alias set numbers
on the -fcompare-debug case, or inhibit new alias sets like thus:
unsigned int save_aliasing = flag_strict_aliasing;
flag_strict_aliasing = 0;
do
14 matches
Mail list logo
