Bug 521991

Created attachment 360163 [details]
Fix for the arch/x86/mm/kmmio.o compile error

This is a patch that fixes the kmmio compile error.  The problem is that tls_mem_loc_descriptor calls get_base_address with a tree that ultimately expands to a NULL variable.  In the trunk, this never happens, because of the alias-export patch.

Local x86-32 kernel build completed with this patch.  Jakub installed a slightly different patch that should work just as well.  http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151552

Should be fixed in gcc-4.4.1-11.

https://koji.fedoraproject.org/koji/taskinfo?taskID=1683619

compiler crash building kernel on ppc64:

fs/xfs/xfs_mount.c: In function 'xfs_initialize_perag':
fs/xfs/xfs_mount.c:391: internal compiler error: in referenced_var_lookup, at tree-dfa.c:565
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/cc71nRvU.out file, please attach this to your bugreport.

Distilled testcase (-g -O is enough):
static inline int
foo (void *x, unsigned y)
{
  unsigned z = *(unsigned long *) x % y; 
  *(unsigned long *) x = *(unsigned long *) x / y;
  return z;
}

struct S
{
  unsigned t;
};
 
void
bar (struct S *x, int *y)
{
  int a = 0;
  unsigned long b = x->t;
  foo (&b, x->t);
  for (;; a++)
    if (b)
      *y = 1;
}

In *.ccp1 we have:
  b ={v} b.1_4;
  b.1_5 = x_3(D)->t;
  # DEBUG x => &b
  # DEBUG y => b.1_5
  # DEBUG z => *&b % b.1_5
(i.e. b has address taken only in the DEBUG stmts; in *.einline* it had it even in code), then substitute_and_fold decides to optimize *&b into b and as b is no longer considered addressable (get_expr_operands doesn't consider ADDR_EXPRs in DEBUG_STMTs to be taking the address), it marks it for renaming, except that b isn't considered a referenced var.  Alex, any ideas?

Groovy.  Now I'll think up yet another DWARF extension to represent the rematerialization of "x" as the "address" of a computed value!

I think the right thing to do here is to make all occurrences of &b disappear from debug stmts when b is deemed unreferenced.  After all, &b doesn't make sense any more, and *&b is just a special case of that.  With some sufficiently advanced technology (AKA magic), we might be able to figure out that *&b should be “the value of x->t back then”, and then realize that the value of x->t didn't change, but I'll focus on avoiding the ICE for the time being.

Created attachment 363454 [details]
Kernel build on Fedora Rawhide 11.91 x86_64 fails (fs/xfs/xfs_mount.o)

Kernel build on Fedora Rawhide 11.91 x86_64 fails - internal compiler error: 
in referenced_var_lookup, at tree-dfa.c:565:

CC [M]  fs/xfs/xfs_mount.o
fs/xfs/xfs_mount.c: In Funktion »xfs_initialize_perag«:
fs/xfs/xfs_mount.c:391: interner Compiler-Fehler: in referenced_var_lookup, bei tree-dfa.c:565
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es
dienlich ist.
Fehler in der deutschen Übersetzung sind an translation-team-de.net zu melden.

Gehen Sie gemäß den Hinweisen in <http://bugzilla.redhat.com/bugzilla> vor.
Preprocessed source stored into /tmp/cchgZK59.out file, please attach this to your bugreport.
make[2]: *** [fs/xfs/xfs_mount.o] Fehler 1
make[1]: *** [fs/xfs] Fehler 2
make: *** [fs] Fehler 2

Should be fixed in gcc-4.4.1-18.fc12.

fs/xfs/xfs_mount.c now compiles with gcc-4.4.1-19, but:

fs/xfs/xfs_vnodeops.c:2530: internal compiler error: Segmentation fault

Created attachment 364050 [details]
C.i.bz2

Indeed, reproduced.  x86_64/i686/ppc kernels build fine, ppc64 doesn't.
Attached is preprocessed source.
Can be reproduced with current redhat/gcc-4_4-branch plus
gcc44-vta-rh521991.patch patch, doesn't reproduce without that patch,
with anything -> powerpc64-linux cross and ./cc1 -g -O2 -m64 C.i.
With that patch, we have at loopinit:
# DEBUG mod => (uint32_t) (*&len % (__u64) maxrecs.964_62)
but in copyprop4:
# DEBUG mod => (uint32_t) (len % (__u64) D.37988_8)
Without that patch copyprop4 has len_64 instead of len - the PARM_DECL was properly renamed to SSA_NAME.  And this obviously causes various issues later, a lot of code isn't prepared to see non-SSA_NAME in e.g. FOR_EACH_SSA_USE_OPERAND.
So replace_uses_in crashes, because SSA_NAME_VERSION on a PARM_DECL gives garbage (with checking enabled would report a checking error).

Created attachment 364063 [details]
gcc44-vta-rh521991-2.patch

Incremental patch that fixes this.
Alex, does it look ok to you?

I wonder if for unreferenced vars it is always a good idea to drop the whole DEBUG stmt value on the floor.  E.g. for PARM_DECLs, couldn't we just make the PARM_DECL referenced before marking it for renaming?  PARM_DECLs have high chance that they will be, at least on some targets, available.

With gcc-4.4.1-20.fc12 (which includes the #c12 patch) kernel-2.6.31.1-61.fc12 built just fine on all 4 arches (with -fno-var-tracking-assignments hack removed from kernel.spec).

Yeah, the patch is ok, thanks.

Marking a variable as referenced that in the absence of debug stmts isn't could cause codegen differences, so I'd not recommend that.  The idea of somehow referring to the original parm decl is an interesting one, but we have to think it through.  That the variable was addressable means it could have been modified by other means that may have been optimized out, and simply referring the user to the original value would not get us correct debug info.

*** Bug 528061 has been marked as a duplicate of this bug. ***

(In reply to comment #13)
> With gcc-4.4.1-20.fc12 (which includes the #c12 patch) kernel-2.6.31.1-61.fc12
> built just fine on all 4 arches (with -fno-var-tracking-assignments hack
> removed from kernel.spec).  

Could you build this for dist-f13?  I could then shadow it and try a dist-f13 kernel build for ppc/ppc64