Section anchors have broken profile data on powerpc*-linux; the problems
described here started with this mainline patch:
r113395 | dje | 2006-04-30 19:23:13 +0000 (Sun, 30 Apr 2006)
Tests mesa, gap, and perlbmk in SPEC CPU2000 fail when compiled with and
, although all source files that contain static
variables have extra space generated after the profile counts. Here's what I
get for file dlist.c in mesa:
.section ".bss"
.align 3
.set .LANCHR0,. + 0
.type .LPBX1, @object
.size .LPBX1, 8496
LPBX1:
.zero 8496
.zero 18446744073709551128
.type init_flag.9563, @object
.size init_flag.9563, 4
In this case the assembler complains that ".space repeat count is zero" for the
line with the second .zero, and the -fprofile-use compile fails because of
corrupted profile data. gcov shows bogus numbers in this case, although when
the size of the second .zero is small, tests run correctly and gcov data looks
fine.
I don't have a small test case that fails for -fprofile-use or has bogus gcov
results, but here's one where the second .zero is clearly bogus:
void
foo (int *p, int n)
{
int i;
for (i = 0; i < n; i++)
p[i] = i;
}
static int tmp [1000];
int
main ()
{
foo (tmp, 1000);
return 0;
}
Part of the corresponding .s file:
.section ".bss"
.align 3
.set .LANCHR0,. + 0
.type .LPBX1, @object
.size .LPBX1, 32
LPBX1:
.zero 32
.zero 7976
.type tmp, @object
.size tmp, 4000
tmp:
.zero 4000

Comment #1 from pinskia at gcc dot gnu dot org 2006-06-18 16:35
Breakpoint 6, assemble_zeros (size=7976) at //gcc/varasm.c:1526

6170 assemble_zeros (SYMBL_REF_BLCKFFSET (symbol) - offset);

(gdb) p debug_rtx(symbol)
(symbol_ref:DI ("tmp") [flags 0x82] <var_decl 0x42c9eea0 tmp>)

Comment #2 from rsandifo at gcc dot gnu dot org 2006-06-19 12:57
In response to comment #1, "tmp" isn't really the problem.
The problem is coverage_counter_alloc(), which initially
create an array of 1000 counters, and only supplies the
real type at the end of compilation:

/* Generate and save a copy of this so it can be shared. */
/* We don't know the size yet; make it big enough that nobody
will make any clever transformation on it. */
char buf[20];
tree gcov_type_node = get_gcov_type ();
tree domain_tree
= build_index_type (build_int_cst (NULL_TREE, 1000)); /* replaced later
*/
tree gcov_type_array_type
= build_array_type (gcov_type_node, domain_tree);

If the final array has fewer than 1000 counters (as in the
reduced testcase), we get some silly padding, but correct code.
If the array has more than 1000 counters (as in the original
testcase), the offset calculation wraps.

Like the -ftree-vectorize thing, this is a chicken-and-egg ordering
problem. The fix is to avoid using section anchors for tree_ctr_tables[].

Richard

Comment #3 from rsandifo at gcc dot gnu dot org 2006-06-19 14:31
Created an attachment (id=11704)
()
Candidate patch

Janis, can you try this patch? It avoids the use of section anchors
for coverage counters. I'm bootstrapping it on i686-pc-linux-gnu,
but that's not really much of a test.

Richard

Comment #4 from janis at gcc dot gnu dot org 2006-06-19 21:08
I tried the patch with a C-only bootstrap for biarch powerpc64-linux and ran
the three CPU2000 tests that had failed with profile generate/use; with the
patch they work.

Comment #6 from rsandifo at gcc dot gnu dot org 2006-06-21 21:28
Patch applied.

Comment #5 from rsandifo at gcc dot gnu dot org 2006-06-21 21:27
Subject: Bug 28034

Author: rsandifo
Date: Wed Jun 21 21:27:19 2006
New Revision: 114870

URL:
Log:
gcc/
PR middle-end/28034
* coverage.c (coverage_counter_alloc): Leave the index type
unspecified.
(coverage_counter_alloc): Use null arguments for operands 2 and 3
of the ARRAY_REF.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/coverage.c