Bug 521991 - gcc 4.4.1-10 breaks kernel build
Summary: gcc 4.4.1-10 breaks kernel build
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
: 528061 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2009-09-09 01:29 UTC by Dave Airlie
Modified: 2009-10-08 20:37 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-10-08 18:33:00 UTC
Type: ---

Attachments (Terms of Use)
Fix for the arch/x86/mm/kmmio.o compile error (519 bytes, patch)
2009-09-09 06:07 UTC, Alexandre Oliva
no flags Details | Diff
Kernel build on Fedora Rawhide 11.91 x86_64 fails (fs/xfs/xfs_mount.o) (873.54 KB, application/octet-stream)
2009-10-02 10:02 UTC, Patrick Proche
no flags Details
C.i.bz2 (152.45 KB, application/octet-stream)
2009-10-07 23:18 UTC, Jakub Jelinek
no flags Details
gcc44-vta-rh521991-2.patch (1.33 KB, patch)
2009-10-08 08:05 UTC, Jakub Jelinek
no flags Details | Diff

Comment 1 Alexandre Oliva 2009-09-09 06:07:32 UTC
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.

Comment 2 Alexandre Oliva 2009-09-09 07:35:05 UTC
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

Comment 3 Jakub Jelinek 2009-09-09 17:32:32 UTC
Should be fixed in gcc-4.4.1-11.

Comment 4 Roland McGrath 2009-09-16 18:31:30 UTC

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.

Comment 5 Jakub Jelinek 2009-09-16 20:44:48 UTC
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;
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?

Comment 6 Roland McGrath 2009-09-16 21:25:31 UTC
Groovy.  Now I'll think up yet another DWARF extension to represent the rematerialization of "x" as the "address" of a computed value!

Comment 7 Alexandre Oliva 2009-09-22 21:17:27 UTC
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.

Comment 8 Patrick Proche 2009-10-02 10:02:13 UTC
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@lists.sourceforge.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

Comment 9 Jakub Jelinek 2009-10-02 10:14:00 UTC
Should be fixed in gcc-4.4.1-18.fc12.

Comment 10 Sami Farin 2009-10-07 19:18:09 UTC
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

Comment 11 Jakub Jelinek 2009-10-07 23:18:22 UTC
Created attachment 364050 [details]

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).

Comment 12 Jakub Jelinek 2009-10-08 08:05:29 UTC
Created attachment 364063 [details]

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.

Comment 13 Jakub Jelinek 2009-10-08 18:33:00 UTC
With gcc-4.4.1-20.fc12 (which includes the #c12 patch) kernel- built just fine on all 4 arches (with -fno-var-tracking-assignments hack removed from kernel.spec).

Comment 14 Alexandre Oliva 2009-10-08 18:44:20 UTC
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.

Comment 15 Jakub Jelinek 2009-10-08 19:09:04 UTC
*** Bug 528061 has been marked as a duplicate of this bug. ***

Comment 16 Josh Boyer 2009-10-08 20:37:31 UTC
(In reply to comment #13)
> With gcc-4.4.1-20.fc12 (which includes the #c12 patch) kernel-
> 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

Note You need to log in before you can comment on or make changes to this bug.