https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768
Bug ID: 66768 Summary: __seg_fs and __seg_gs: issue when adding address space support Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: arigo at tunes dot org Target Milestone: --- Created attachment 35913 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35913&action=edit Input incorrectly compiled with gcc-5.1.0-patched I implemented support for %fs and %gs segment prefixes on the x86 and x86-64 platforms, in what turns out to be a small patch. A full description and the motivation can be found in https://gcc.gnu.org/ml/gcc/2015-07/msg00031.html . This bug report is unusual in that it is not about a bug in the current version of gcc, but in the gcc with a patch added (https://gcc.gnu.org/ml/gcc/2015-07/txtJZYwz9PTTI.txt). It might of course be that my patch is incorrect, but the patch really only adds two extra address spaces; given that it is straightforward, I'd guess there is a chance that the same bug occurs on other platforms that already have multiple address spaces. (Either that, or some code somewhere is confused by the standard-sized, alternate-address-spaced pointers.) The bug is that with gcc 5.1.0 patched as above, compiling bug1.c on x86-64 with "-O1" produces https://gcc.gnu.org/ml/gcc/2015-07/msg00031/bug1.s. In one case, the __seg_gs address space is incorrectly dropped. With "-O0" it works fine. If I try to dump all the rtl passes, I see that the __seg_gs address space is already missing in the first rtl dump, so I suspect that some earlier optimization does not respect the presence of address spaces. (I tried to replace the "-O1" with the list of "-f" flags output by "-O1 -Q --help=optimizers" with the goal of removing most of them until I can pinpoint which optimization causes the problem, but with no luck: even replacing "-O1" by all the [enabled] flags produces a different and correct result...)