Bug 590727 - var tracking issues with various kde applications
var tracking issues with various kde applications
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-10 10:57 EDT by Rex Dieter
Modified: 2010-05-10 11:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-10 11:17:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2010-05-10 10:57:19 EDT
Symptoms similar to past issues like bug #538233 seem to have resurfaced lately, on my own box, I see this trying to build both kdepim and konversation

$ rpm -q gcc
gcc-4.4.4-2.fc13.x86_64

I compared past and recent build-times in koji, and these don't seem to vary much, so maybe it's something particular to my own box that has updates-testing enabled.

I'll keep digging for reproducers in the meantime.
Comment 1 Jakub Jelinek 2010-05-10 11:11:55 EDT
You need to be more factual, on which sources, what g++ command line options, attach preprocessed sources.  And, how long is too slow (for the insanely huge routines KDE uses so much)?  Is the var-tracking limit reached or not?

The generated debug info quality increased quite a lot over the last few months
and in some cases it means more values tracked in var-tracking, which on these several thousand basic blocks long functions isn't exactly cheap.
Comment 2 Rex Dieter 2010-05-10 11:16:23 EDT
OK, it seems to take a little while for problematic files, but not nearly as bad as it was previously.

For example, konversation now takes ~5 minutes longer (on a fast builder) than when using -fno-var-tracking-assignments
Comment 3 Rex Dieter 2010-05-10 11:17:33 EDT
I'll do some more tests, but these slightly longer times seems to be acceptable for the extra work being done.  so, consider it not an issue unless I find something 'really bad'(tm)
Comment 4 Jakub Jelinek 2010-05-10 11:22:32 EDT
We definitely intend to work on var-tracking speed improvements (especially Alex Oliva), on the other side have several big projects which severely improve debug info quality at the expense of tracking yet more stuff.
~5 minutes longer compilation on huge functions is bad, but not extremely high priority - that would be for something taking hours to build or eating way too much memory or a significant slowdown across large codebase.

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