Bug 30297
Summary: | Segfaults if compiled under current environment | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Enrico Scholz <rh-bugzilla> |
Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | nalin, pbrown, teg |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-03-15 19:37:11 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Enrico Scholz
2001-03-02 13:15:46 UTC
Can't reproduce this on my system with all the latest packages. This defect considered MUST-FIX for Florence Gold release I can reproduce it on yesterdays tree... I'll try upgrading it. I think this is a problem with gcc - if you build it with -O0 or -O2, it works fine. If you add our standard "-march=i386 -mcpu=i686" flags as well, it segfaults when run. Ouch, this won't be easy to find out. I've tracked it down to the gcc-c++-addressof.patch, but unfortunately that patch changes the assembly output considerably, so I haven't located which routine gets miscompiled yet. Preston, Glen... I think you might want to look at this: These are our default compiler options. Localized to aspell_default_writable_repl::WritableReplS::soundslike_elements(void) const being miscompiled, more to follow (hopefully). Minimalized into: class G {}; struct N { N *a; }; struct V { typedef N *W; W *m, *n; int s() const { return int(n - m); } const W &operator[](int x) const { return *(m + x); } }; struct H; struct J { N *c; H *d; J(N *x, H *y) : c(x), d(y) {} }; struct K { const N *c; const H *d; K(const N *x, const H *y) : c(x), d(y) {} K(const J &x) : c(x.c), d(x.d) {} }; struct H { V e; int f; J u() { for (int x = 0; x < e.s(); ++x) if (e[x]) return J(e[x], this); return v(); } J v() { return J((N*)64, this); } }; struct I { H d; J u() { return d.u(); } J v() { return d.v(); } }; struct bar { virtual ~bar() {} }; struct E { K g; E(K x) : g(x) {} }; struct foo : public bar { K h; E i; foo(const K x, const E &y) : h(x), i(y) {} }; struct A { I *l; foo *baz() const; }; foo *A::baz() const { return new foo(l->u(), E(l->v())); } A x; I i; foo *f; int main () { x.l = &i; f = x.baz(); if (f->h.c != f->i.g.c || f->h.d != f->i.g.d) return 1; return 0; } which fails with -O2 -mcpu=i686 and does not fail with -O2 (or -O0). The issue is that scheduling reorders load with store to the same location, but the load is marked as mem/u (constant), so I need to find out what is supposed to prevent this reordering. When you've found at more about it, please tell us which packages may be miscompiled by this (how long has this patch been there). Trond, I'm afraid this would be pretty hard to tell, hacking the backend so that it would go and discover these cases would be non-trivial. Anyway, I've just created a patch which seems to make this go away with -O2 -mcpu=i686 -fPIC (what aspell is actually using), unfortunately the testcase I've created from it is still miscompiled at -O2 -mcpu=i686 (without -fpic). I've called for help to gcc-local for the second time (and will at least try to sufficiently test the patch I've made later today). the only real C++ packages that matter in the distribution are kde and aspell. If KDE isn't segafaulting, then this problem I doubt this problem is being encountered there. BTW: Anybody see any reason why: MakeVirEmulation(const Iterator i, const Parms & p = Parms()) : i_(i), parms_(p) {} uses const Iterator instead of either Iterator or const Iterator & ? (I'm discussing the fix on gcc-patches now, so don't take this as an attempt not to fix gcc, but the above thing which is what causes the miscompilation does not make sense to me). Not really - ask kevina.net. I've added debugging into the place and potentially many C++ programs could be miscompiled (I'm not saying they are, it just has to have bad luck and be scheduled "right" so that loads precede stores to it. aspell is affected, doxygen freetype htdig ImageMagick kdeadmin kdegames kdegraphics kdelibs kdemultimedia kdenetwork kdenetwork kdepim kdesdk kdeutils koffice kpppload lam mozilla qt tripwire might be, plus maybe some of the C++ stuff which failed during last mass rebuild. ETA on the compiler fix? fixed compiler is in the tree. |