2009-04-27 Gavin Barraclough <barraclough@apple.com>

        Reviewed by Maciej Stachowiak.

        Tweak a loop condition to keep GCC happy,
        some GCCs seem to be having issues with this. :-/

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::breakTarget):
        * wtf/Platform.h:



git-svn-id: svn://svn.chromium.org/blink/trunk@42922 bbb929c8-8fbe-4397-9dbb-9b2b20218538

third_party/WebKit/JavaScriptCore/ChangeLog

+2009-04-27  Gavin Barraclough  <barraclough@apple.com>
+
+        Reviewed by Maciej Stachowiak.
+
+        Tweak a loop condition to keep GCC happy,
+        some GCCs seem to be having issues with this. :-/
+
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::BytecodeGenerator::breakTarget):
+        * wtf/Platform.h:
+
 2009-04-27  Adam Roben  <aroben@apple.com>
 
         Windows Debug build fix

third_party/WebKit/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp

@@ -1587,8 +1587,17 @@ void BytecodeGenerator::popFinallyContext()
 LabelScope* BytecodeGenerator::breakTarget(const Identifier& name)
 {
     // Reclaim free label scopes.
-    while (m_labelScopes.size() && !m_labelScopes.last().refCount())
+    //
+    // The condition was previously coded as 'm_labelScopes.size() && !m_labelScopes.last().refCount()',
+    // however sometimes this appears to lead to GCC going a little haywire and entering the loop with
+    // size 0, leading to segfaulty badness.  We are yet to identify a valid cause within our code to
+    // cause the GCC codegen to misbehave in this fashion, and as such the following refactoring of the
+    // loop condition is a workaround.
+    while (m_labelScopes.size()) {
+        if  (m_labelScopes.last().refCount())
+            break;
         m_labelScopes.removeLast();
+    }
 
     if (!m_labelScopes.size())
         return 0;