This is an exact error message: ../../../Source/WebCore/html/HTMLFormElement.cpp:876:1: internal compiler error: in output_index_string, at dwarf2out.c:21825 } // namespace ^
Created attachment 271923 [details] Patch
Comment on attachment 271923 [details] Patch Add a FIXME please!
What FIXME do you mean? equalLettersIgnoringASCIICase(..., "off") where "off" is literal is used in many other places of this file, and I guess this form is a bit faster because literal needs not need is8Bit() check.
Comment on attachment 271923 [details] Patch No this is not right. It was meant to be off (without the quotes), referring to the local off variable.
(In reply to comment #4) > No this is not right. It was meant to be off (without the quotes), referring > to the local off variable. Surely equalLettersIgnoringASCIICase does not have different behavior depending on whether I pass a wtf::String or a literal?
Comment on attachment 271923 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=271923&action=review > Source/WebCore/ChangeLog:7 > + The change log does not explain why this should be "off" instead of off. It seems valid to use off without quotes to me. It should end up calling: inline bool equalIgnoringASCIICase(const AtomicString& a, const String& b);
(In reply to comment #6) > Comment on attachment 271923 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=271923&action=review > > > Source/WebCore/ChangeLog:7 > > + > > The change log does not explain why this should be "off" instead of off. It > seems valid to use off without quotes to me. It should end up calling: > inline bool equalIgnoringASCIICase(const AtomicString& a, const String& b); I don't think we do have a equalIgnoringASCIICase() overload that takes a literal. Therefore, if you pass "off" it likely calls: inline bool equalIgnoringASCIICase(const String& a, const char* b); Which means we don't know the length of b in advance. If we pass a String in, the size of b is known in advance.
(In reply to comment #7) > I don't think we do have a equalIgnoringASCIICase() overload that takes a > literal. Therefore, if you pass "off" it likely calls: > inline bool equalIgnoringASCIICase(const String& a, const char* b); > > Which means we don't know the length of b in advance. If we pass a String > in, the size of b is known in advance. I believe it calls template<unsigned length> bool equalLettersIgnoringASCIICase(const StringImpl&, const char (&lowercaseLetters)[length]);
(In reply to comment #8) > (In reply to comment #7) > > > I don't think we do have a equalIgnoringASCIICase() overload that takes a > > literal. Therefore, if you pass "off" it likely calls: > > inline bool equalIgnoringASCIICase(const String& a, const char* b); > > > > Which means we don't know the length of b in advance. If we pass a String > > in, the size of b is known in advance. > > I believe it calls > > template<unsigned length> bool equalLettersIgnoringASCIICase(const > StringImpl&, const char (&lowercaseLetters)[length]); oh, I did indeed miss the one taking a literal: template<unsigned length> inline bool equalLettersIgnoringASCIICase(const AtomicString& string, const char (&lowercaseLetters)[length]); That said, it does not explain why the previous code does not work in GCC. It seems perfectly legal to me.
(In reply to comment #9) > That said, it does not explain why the previous code does not work in GCC. > It seems perfectly legal to me. That's hard to explain internal compiler errors. If you are interested I'll prepare reduced test case which should reveal broken C++ construction.
Comment on attachment 271923 [details] Patch Ok to unbreak you and because equalIgnoringASCIICase() has a literal taking an override. However, I wish we understood the problem a bit better.
Comment on attachment 271923 [details] Patch Clearing flags on attachment: 271923 Committed r196946: <http://trac.webkit.org/changeset/196946>
All reviewed patches have been landed. Closing bug.
(In reply to comment #11) > Comment on attachment 271923 [details] > Patch > > Ok to unbreak you and because equalIgnoringASCIICase() has a literal taking > an override. However, I wish we understood the problem a bit better. To be clear, it's a GCC bug causing some obsolete version of GCC to crash (ICE = internal compiler error), and this modification is a workaround for that crash. It'd be reasonable to accept the patch (it's a one-liner that adds support for a new compiler) or reject it (it's a workaround for a compiler we technically don't support anymore), I'd err on the side of accept... which you did. (In reply to comment #8) > I believe it calls > > template<unsigned length> bool equalLettersIgnoringASCIICase(const > StringImpl&, const char (&lowercaseLetters)[length]); Wow! This is quite esoteric C++, the only time I ever saw this syntax was in a trivia question... array parameters are normally just pointers, but for templates it's not necessarily true!