Clang :: Analysis/localization-aggressive.m fails with gcc-13

When I use latest gcc-13 to build clang/llvm, Clang :: Analysis/localization-aggressive.m test fails with release build while it's OK with debug build.

Environment:

$ uname -a
Linux xxx 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux

As a comparison, gcc-12.2.0 works well.

gcc source code

commit 14d11df96336e9d06a4c8108b61815ad94866519 (origin/trunk, origin/master, origin/HEAD, master)                                                                                           
Author: GCC Administrator <gccadmin@gcc.gnu.org>
Date:   Mon Nov 28 00:16:43 2022 +0000

    Daily bump.

llvm source code

commit 5279e6a7d677cdf4488883b77aacab911318100c (HEAD)
Author: Michał Górny <mgorny@gentoo.org>
Date:   Sat Nov 19 20:54:54 2022 +0100

    [cmake] Fix Findzstd.cmake to handle OpenBSD shared libraries

    Fix Findzstd CMake to handle shared libraries on OpenBSD correctly.
    This userland does not use shared library symlinks without SOVERSION,
    so the result of find_library() does not ever end with
    zstd_SHARED_LIBRARY_SUFFIX.  To work around this, reverse the logic
    to compare the result against zstd_STATIC_LIBRARY_SUFFIX and assume
    shared library otherwise.

    While at it, fix the conditions not to fall back to "result is static
    library" path if it actually was recognized as a shared library but
    zstd_shared target already existed.

    Fixes #59056

    Differential Revision: https://reviews.llvm.org/D138361

How to build gcc

#!/bin/bash

set -x 
set -e

./contrib/download_prerequisites
mkdir objdir
cd objdir
$PWD/../configure --prefix=$PWD/../gcc-install-13 --enable-languages=c,c++
make -j32
make install

How to build clang/llvm

#!/bin/bash
set -e
set -x

CONFIG_AND_BUILD=false
if [ "$1" == "r" ];then
    CONFIG_AND_BUILD=true
fi

BUILD_TYPE=Release # it's OK if BUILD_TYPE=Debug
BUILD_DIR=_build
INSTALL_DIR="$PWD/llvm_install"

while $CONFIG_AND_BUILD ; do
  rm -rf $BUILD_DIR
  mkdir $BUILD_DIR
  cmake -S llvm -B $BUILD_DIR -G Ninja \
    -DLLVM_CCACHE_BUILD=ON \
    -DCMAKE_C_COMPILER=/path/to/gcc-install-13/bin/gcc \
    -DCMAKE_CXX_COMPILER=/path/to/gcc-install-13/bin/g++ \
    -DCMAKE_INSTALL_PREFIX="$INSTALL_DIR" \
    -DCMAKE_BUILD_TYPE=$BUILD_TYPE \
    -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="LoongArch" \
    -DLLVM_ENABLE_PROJECTS="clang" \
    -DLLVM_ENABLE_ASSERTIONS=ON \
    -DLLVM_ENABLE_OCAMLDOC=OFF \
    -DLLVM_ENABLE_BINDINGS=OFF \
    -DLLVM_BUILD_LLVM_DYLIB=ON \
    -DLLVM_LINK_LLVM_DYLIB=ON
  break
done

cmake --build $BUILD_DIR -j 32
cmake --build $BUILD_DIR --target check-clang

Test

$ ./_build/bin/llvm-lit clang/test/Analysis/localization-aggressive.m -v
llvm-lit: /path/to/llvm-project/llvm/utils/lit/lit/llvm/config.py:457: note: using clang: /path/to/llvm-project/_build/bin/clang
-- Testing: 1 tests, 1 workers --
FAIL: Clang :: Analysis/localization-aggressive.m (1 of 1)
******************** TEST 'Clang :: Analysis/localization-aggressive.m' FAILED ********************
Script:
--
: 'RUN: at line 1';   /path/to/llvm-project/_build/bin/clang -cc1 -internal-isystem /path/to/llvm-project/_build/lib/clang/16/include -nostdsysteminc -fblocks -x objective-c-header -emit-pch -o /path/to/llvm-project/_build/tools/clang/test/Analysis/Output/localization-aggressive.m.tmp.pch /path/to/llvm-project/clang/test/Analysis/Inputs/localization-pch.h
: 'RUN: at line 3';   /path/to/llvm-project/_build/bin/clang -cc1 -internal-isystem /path/to/llvm-project/_build/lib/clang/16/include -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -fblocks    -analyzer-config optin.osx.cocoa.localizability.NonLocalizedStringChecker:AggressiveReport=true    -analyzer-checker=optin.osx.cocoa.localizability.NonLocalizedStringChecker    -analyzer-checker=optin.osx.cocoa.localizability.EmptyLocalizationContextChecker    -include-pch /path/to/llvm-project/_build/tools/clang/test/Analysis/Output/localization-aggressive.m.tmp.pch -verify  /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m
--
Exit Code: 1

Command Output (stderr):
--
error: 'warning' diagnostics expected but not seen: 
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 245: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 246: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 247: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 251: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 252: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 253: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 257: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 258: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 259: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 263: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 264: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 265: Localized string macro should include a non-empty comment for translators
  File /path/to/llvm-project/clang/test/Analysis/localization-aggressive.m Line 269: Localized string macro should include a non-empty comment for translators
13 errors generated.

--

********************
********************
Failed Tests (1):
  Clang :: Analysis/localization-aggressive.m

Testing Time: 0.21s
  Failed: 1

You would probably need to find the offending gcc change and report this to gcc bugtracker.

You would probably need to find the offending gcc change and report this to gcc bugtracker.

Thanks. I will try to use git bisect to find that change.

I have found the gcc change causing this issue. In case others meet the same issue, post it here:

87dd4c8c83768aafad92588853fd84a6070553d6 is the first bad commit                                                                                                                              
commit 87dd4c8c83768aafad92588853fd84a6070553d6                                                                                                                                               
Author: Andrew MacLeod <amacleod@redhat.com>                                                                                                                                                  
Date:   Fri Jul 29 12:05:38 2022 -0400                                                                                                                                                        

    Check equivalencies when calculating range on entry.                                                                                                                                      

    When propagating on-entry values in the cache, checking if any equivalence                                                                                                                
    has a known value can improve results.  No new calculations are made.                                                                                                                     
    Only queries via dominators which do not populate the cache are checked.                                                                                                                  

            PR tree-optimization/106474                                                                                                                                                       
            gcc/                                                                                                                                                                              
            * gimple-range-cache.cc (ranger_cache::fill_block_cache): Query
            range of equivalences that may contribute to the range.                                                                                                                           

            gcc/testsuite/                                                                                                                                                                    
            * g++.dg/pr106474.C: New.

Hmm this is still the case with latest gcc and clang. @SixWeining could you post the respective gcc bugzilla link so people could track the progress and hopefully get this fixed before the gcc 13.1 release?

Hmm this is still the case with latest gcc and clang. @SixWeining could you post the respective gcc bugzilla link so people could track the progress and hopefully get this fixed before the gcc 13.1 release?

I have not filed this bug in gcc bugzilla because I find it's hard to meet the writing guidelines. "build llvm and check-clang" seems not a good bug report. I'm not sure is there a simpler way to describe the issue that can help troubleshooting.

I'm still hitting this with GCC 13 (13.0.1 202304020) and reverting 87dd4c8c83768aafad92588853fd84a6070553d6 "fixes" the failure.

@tstellar has kindly pinged Andrew, so let's see what happens. I'm also reluctant to report myself without more information just because I've already got one open bug where I need to reduce it (another LLVM issue, actually, but on ppc).

(FWIW though, if you genuinely can't reduce something, it's still better to file something rather than not. I only found this bug by chance.)

My cheesy revert (it didn't revert cleanly):

--- a/gcc/gimple-range-cache.cc
+++ b/gcc/gimple-range-cache.cc
@@ -1211,79 +1211,14 @@ ranger_cache::fill_block_cache (tree name, basic_block bb, basic_block def_bb)
   // Check if a dominators can supply the range.
   if (range_from_dom (block_result, name, bb, RFD_FILL))
     {
+      m_on_entry.set_bb_range (name, bb, block_result);
       if (DEBUG_RANGE_CACHE)
        {
          fprintf (dump_file, "Filled from dominator! :  ");
          block_result.dump (dump_file);
          fprintf (dump_file, "\n");
        }
-      // See if any equivalences can refine it.
-      if (m_oracle)
-       {
-         tree equiv_name;
-         relation_kind rel;
-         int prec = TYPE_PRECISION (type);
-         FOR_EACH_PARTIAL_AND_FULL_EQUIV (m_oracle, bb, name, equiv_name, rel)
-           {
-             basic_block equiv_bb = gimple_bb (SSA_NAME_DEF_STMT (equiv_name));
-
-             // Ignore partial equivs that are smaller than this object.
-             if (rel != VREL_EQ && prec > pe_to_bits (rel))
-               continue;
-
-             // Check if the equiv has any ranges calculated.
-             if (!m_gori.has_edge_range_p (equiv_name))
-               continue;
-
-             // PR 108139. It is hazardous to assume an equivalence with
-             // a PHI is the same value.  The PHI may be an equivalence
-             // via UNDEFINED arguments which is really a one way equivalence.
-             // PHIDEF == name, but name may not be == PHIDEF.
-             if (is_a<gphi *> (SSA_NAME_DEF_STMT (equiv_name)))
-               continue;
-
-             // Check if the equiv definition dominates this block
-             if (equiv_bb == bb ||
-                 (equiv_bb && !dominated_by_p (CDI_DOMINATORS, bb, equiv_bb)))
-               continue;
-
-             if (DEBUG_RANGE_CACHE)
-               {
-                 if (rel == VREL_EQ)
-                   fprintf (dump_file, "Checking Equivalence (");
-                 else
-                   fprintf (dump_file, "Checking Partial equiv (");
-                 print_relation (dump_file, rel);
-                 fprintf (dump_file, ") ");
-                 print_generic_expr (dump_file, equiv_name, TDF_SLIM);
-                 fprintf (dump_file, "\n");
-               }
-             Value_Range equiv_range (TREE_TYPE (equiv_name));
-             if (range_from_dom (equiv_range, equiv_name, bb, RFD_READ_ONLY))
-               {
-                 if (rel != VREL_EQ)
-                   range_cast (equiv_range, type);
-                 if (block_result.intersect (equiv_range))
-                   {
-                     if (DEBUG_RANGE_CACHE)
-                       {
-                         if (rel == VREL_EQ)
-                           fprintf (dump_file, "Equivalence update! :  ");
-                         else
-                           fprintf (dump_file, "Partial equiv update! :  ");
-                         print_generic_expr (dump_file, equiv_name, TDF_SLIM);
-                         fprintf (dump_file, " has range  :  ");
-                         equiv_range.dump (dump_file);
-                         fprintf (dump_file, " refining range to :");
-                         block_result.dump (dump_file);
-                         fprintf (dump_file, "\n");
-                       }
-                   }
-               }
-           }
-       }

-      m_on_entry.set_bb_range (name, bb, block_result);
       gcc_checking_assert (m_workback.length () == 0);
       return;

@jakubjelinek has reported this at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109462. Thank you!

llvm / llvm-project