| Summary: | Bogus symbol inserted into valid C++ code at low optimization level | ||
|---|---|---|---|
| Product: | gcc | Reporter: | mi <mi> |
| Component: | middle-end | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bangerth, gcc-bugs |
| Priority: | P3 | ||
| Version: | 3.4.4 | ||
| Target Milestone: | 4.0.4 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | ||
| Attachments: | The result of preprocessing of ICU's icu/source/test/intltest/loctest.cpp | ||
|
Description
mi@aldan.algebra.com
2006-10-08 20:48:41 UTC
Created attachment 12396 [details]
The result of preprocessing of ICU's icu/source/test/intltest/loctest.cpp
Sorry, I forgot to explicitly specify, that the bogus symbol is seen, when compiling at either -O0 or -O1 levels (symbol name and the line number, where it, supposedly, appears, change). Compiling at -O2 does not exhibit the problem. What target are you compiling for? I'm compiling on and for FreeBSD/i386. Regarding the major-normal downgrade, I must note, that other (also compiler-related, apparently) problems in ICU require the ability to run the tests under debugger, which is rather difficult, when the code is built with -O2... Thanks! (In reply to comment #4) > Regarding the major-normal downgrade. The main reason why I did that is because 3.4.x is no longer being maintained so it might just be better to use 4.0.3. This works fine on 4.0.4 so closing as fixed. 3.4.4 (or 3.4.6) are the system compilers on FreeBSD-5.x and FreeBSD-6.x Would it be possible to locate the diff, that fixed the problem, so it can be merged into our toolchain? Thanks! (In reply to comment #7) > 3.4.4 (or 3.4.6) are the system compilers on FreeBSD-5.x and FreeBSD-6.x So what, we are talking about the FSF GCC and not freebsd and 3.4.x is no longer maintained by the FSF. > Would it be possible to locate the diff, that fixed the problem, so it can be > merged into our toolchain? Thanks! We could but that is doing the same thing as supporting an older compiler which we don't have the resources to do this. (In reply to comment #8) > (In reply to comment #7) > > 3.4.4 (or 3.4.6) are the system compilers on FreeBSD-5.x and FreeBSD-6.x > So what, we are talking about the FSF GCC and not freebsd and 3.4.x is no > longer maintained by the FSF. Maybe slightly more diplomatic than Andrew's answer: we try to maintain current development mainline + two older release branches (presently 4.0.x and 4.1.x). Our limited resources do not allow to support older releases. That said, since you have access to a FreeBSD system, finding the relevant patch using a binary search of the subversion archive between the revision numbers of the 3.4 branchpoint and the 4.0 release shouldn't be too hard. Of course, whether the relevant patch applies cleanly is another matter. W. (In reply to comment #9) > finding the relevant patch using a binary search of the subversion archive > between the revision numbers of the 3.4 branchpoint and the 4.0 release That's the problem -- how can I, who has never seen the internals of the GNU compiler, figure out, which patch is "the relevant" one? For you, the developers, it is, probably, indeed faster, than writing another explanation, why you "have no resources" to do it... (In reply to comment #10) > For you, the developers, it is, probably, indeed faster, than writing another > explanation, why you "have no resources" to do it... No, it will actually take significant time, since one has to do lots of bootstraps. We as a group decided that our time would be better spent on maintaining 2 release branches + one development mainline. But that aside, it's just a matter of fact that very few of us actually have FreeBSD systems we could try this on. W. In comment #9: shouldn't be too hard. In comment #11: No, it will actually take significant time If the explanation for the above discrepancy is simply not having access to a FreeBSD machine, such an access can be arranged in an hour or so. Just send me (by private e-mail) your ssh public key (~/.ssh/id_dsa.pub) and the /etc/passwd line for your account information (without the actual password). Thanks! (In reply to comment #12) > In comment #9: shouldn't be too hard. > In comment #11: No, it will actually take significant time It's a long and boring process. It's not complicated, it just takes time. > If the explanation for the above discrepancy is simply not having access to a > FreeBSD machine, such an access can be arranged in an hour or so. No, you don't understand. I have no intention of doing this. I believe my time is better spent working on bugs that haven't been fixed on any current release branch yet. I have no interest in working on things that have been sorted out long ago. If you really want to see this fixed, you will have to find a volunteer who is willing to spend the necessary time and who has access to the relevant machines. That's just not me, sorry. W. Ok, the problem is triggered by the ``-march=pentium4'' flag:
c++ -O0 -g -c -fno-strict-aliasing -pipe -march=pentium4 loctest.ii
mteterin@mi:source/test/intltest (1127) nm loctest.o | grep LC
U .LC786
U _ZNK7icu_3_66Locale7getLCIDEv
vs.
c++ -O0 -g -c -fno-strict-aliasing -pipe loctest.ii
mteterin@mi:source/test/intltest (1129) nm loctest.o | grep LC
U _ZNK7icu_3_66Locale7getLCIDEv
Would this narrow the search for a fix down enough?
The problem does not exist with the gcc-3.2.3 (tested on RedHat), nor with gcc-3.4.1 (tested on the same FreeBSD box as the originally reported 3.4.4).
Removing either the line 16037 or the 15167 in the loctest.ii gets rid of the problem.
The lines both reference a string literal ("en_GB_EURO"), thus the bug, likely, has something to do with how the identical literals are herded together by 3.4.x on either pentium3 or pentium4 (but not pentium2)...
|