We're using NS_LITERAL_STRING("stuff") very extensively throughout mozilla, and on older versions of gcc, this means that we're doing a lot of 8-to-16-bit conversions at runtime, every time. When NS_LITERAL_STRING went in, we were promised that gcc would do this soon and we'd get the speedup on linux that the other platforms already had. Jag says that gcc 2.97.highnum finally does the right thing with L"string". We should use it for release builds, and make a comment on the builds/unix.html page recommending a compiler version that we think is safe. If there's something wrong with 2.97.* that prevents us from using it, then let's find a version that does work, or reference a url here for a gcc bug that tracks the issue, or whatever we need to do to track this..

dbaron has more info on this.

We've already discussed moving to a different gcc quite a bit in other bugs. It would also give us the advantage of moving to -O2. I think bryner did performance measurements of the actual benefits of switching.

And you mean 2.96-XX, not 2.97-XX, and that's a RedHat 7-specific compiler, basically. (Unless you want to move to 3.0.)

*** This bug has been marked as a duplicate of 53486 ***

verified dup.

Does anyone know what the actual version number is in which the NS_LITERAL_STRING macros actually do the right thing? Bug 53486 (to which this has been duped) concerns -O level and doesn't actually include plans for moving to any particular compiler revision (that may turn out to be the fix, but no such plans are currently mentioned in the comments for that bug). Apparently 3.0 breaks plugins so using it would be a major change, so if there's a 2.xx compiler that solves this problem it would be useful to know about it.

See http://bugzilla.mozilla.org/show_bug.cgi?id=63857#c10 One can safely use L"string" starting with gcc 2.96-70.