Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 590727 - var tracking issues with various kde applications
Summary: var tracking issues with various kde applications
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-10 14:57 UTC by Rex Dieter
Modified: 2010-05-10 15:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-05-10 15:17:33 UTC
Type: ---

Attachments (Terms of Use)

Description Rex Dieter 2010-05-10 14:57:19 UTC
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

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 15:11:55 UTC
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 15:16:23 UTC
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 15:17:33 UTC
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 15:22:32 UTC
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.