|
Bugzilla – Full Text Bug Listing |
| Summary: | gperftools fails to build with GCC 7 | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Martin Liška <martin.liska> |
| Component: | Basesystem | Assignee: | Daniel Oliveira <doliveira> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 1030236 | ||
|
Description
Martin Liška
2017-03-21 08:58:08 UTC
hm, not sure why I'm getting this. ... Craig ? I poked at this, off and on, trying to figure out the problem. No success so far. And this apparently hasn't been encountered upstream yet. I think no one has tried compiling gperftools with GCC7 yet. I'm assigning to Daniel, hoping he can figure it out better than I can with his C++ experience. (Granted, this is a compiler complexity, not necessarily a C++ issue, but I'm hoping he'll see what I haven't been able to see.) I'll isolate the asm statement so that we can investigate what exactly violates the constraint. Ok, I've just created GCC PR that: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80470 Would you please point me to the URL with the source you are trying to build so I can check it out? Or are we just using the 'openSUSE:Factory:Staging:Gcc7' (which I supposed is the same latest version 'https://github.com/gperftools/gperftools')? It really seems related to the 'inline-asm' statements. Are we building it with ' gcc 7.0.1+r247019-15.1' or newer? I will test it with the latest gcc and clang (in case we haven't yet), just to see if both compilers will show the same behavior when building it. (In reply to Daniel Oliveira from comment #5) > Would you please point me to the URL with the source you are trying to build > so I can check it out? Or are we just using the > 'openSUSE:Factory:Staging:Gcc7' (which I supposed is the same latest version > 'https://github.com/gperftools/gperftools')? > > It really seems related to the 'inline-asm' statements. Are we building it > with ' > gcc 7.0.1+r247019-15.1' or newer? Both would cause the same behavior. > > I will test it with the latest gcc and clang (in case we haven't yet), just > to see if both compilers will show the same behavior when building it. Well, please read the PR I've created. It's probably related to fact that the inline asm is in a function that's annotated as 'inline'. That probably increases register pressure in a function where the function is inlined and RA can't handle with that. Yes, that's why I mentioned the *'inline-asm' statements* in my last comment (https://bugzilla.suse.com/show_bug.cgi?id=1030246#c5). Now, just out of my curiosity, I didn't realize/know we were building a whole lot of 32bit these days. Is gperftools the only one showing this kind of problem with gcc (so far)? (In reply to Daniel Oliveira from comment #7) > Yes, that's why I mentioned the *'inline-asm' statements* in my last comment > (https://bugzilla.suse.com/show_bug.cgi?id=1030246#c5). Ah, ok :) > > Now, just out of my curiosity, I didn't realize/know we were building a > whole lot of 32bit these days. Is gperftools the only one showing this kind > of problem with gcc (so far)? If you take a look at the meta bug: https://bugzilla.opensuse.org/showdependencytree.cgi?id=1030236&hide_resolved=1 There are couple of packages that have test failures on i586. However, it might be an error in test-suite rather than a real bug in compiler. I'm waiting for an explanation of GCC folks about the inline asm. Let's see. Well, with updated GCC, that package builds on i586. Looks it's quite fragile, let's see whether it will work. I will close the PR eventually. Martin, With update version of gcc? I thought I asked if we were running the latest version (7.0.1 as per https://bugzilla.suse.com/show_bug.cgi?id=1030246#c5), and my understanding was that we were already running it. Glad to know it worked though. I know you asked me. To be honest it probably changed during last month where only minor development active has happened. Cool. Thanks for the update! Did you update the GCC PR upstream with the new info? (In reply to Daniel Oliveira from comment #12) > Cool. Thanks for the update! Did you update the GCC PR upstream with the new > info? No, because the explanation I was given does not solve the issue. And I guess the problem is currently latent and can eventually pop up. The PR would be good for tracking that. Martin, It doesn't seem we still have any updates from GCC upstream on this (for awhile now). Would you need anything else at this point I could help with? Please, let me know. Thanks. Fixed on Factory. |