PVS-Studioアナライザーを使用してGCCコンパイラコードのエラーを見つける

PVS-Studio静的コードアナライザー（C、C ++、C＃）の機能を実証するために、さまざまなオープンソースプロジェクトを定期的にチェックしています。 GCCコンパイラの時代が来ました。 間違いなく、GCCは非常に高品質でテスト済みのプロジェクトであるため、少なくともいくつかのエラーを見つけることは、どのツールにとっても素晴らしい成果です。 嬉しいことに、PVS-Studioはこのタスクに対処しました。 タイプミスや不注意から免れる人はいません。 それが、PVS-Studioがバグとの終わりのない戦争の前にあなたの追加の防衛線になることができる理由です。

Gcc

GNU Compiler Collection （一般的にGCCと略される）は、GNUプロジェクトの一部として開発されたさまざまなプログラミング言語用のコンパイラのコレクションです。 GCCは、GNU GPLおよびGNU LGPL Free Software Foundationによって配布されているフリーソフトウェアであり、GNUツールチェーンの重要なコンポーネントです。 プロジェクトはCおよびC ++で記述されています。



GCCコンパイラには、コンパイル段階で多くのエラーを識別するのに役立つ優れた組み込み診断機能​​があります。 当然、GCCはGCCを使用して構築されているため、独自のコードでエラーを検出できます。 さらに、GCCソースコードはCoverityアナライザーを使用して検証されます。 とにかく、GCCは多くのアナライザーやその他のツールを使用して愛好家によってテストされたと思います。 これにより、GCCバグ検索がPVS-Studioコードアナライザーの大きなテストになります。



分析のために、トランクバージョンはgitリポジトリから取得されました：（git）commit 00a7fcca6a4657b6cf203824beda1e89f751354b svn + ssh：//gcc.gnu.org/svn/gcc/trunk@238976



ご注意 この記事はリリースに伴って遅延し、おそらくいくつかのエラーはすでに修正されています。 しかし、それは問題ではありません。新しいエラーが絶えず現れ、古いエラーは消えます。 主なもの-この記事は、静的分析がプログラマーがエラーを表示した後に特定するのに役立つことを示しています。

議論を予想する

はじめに述べたように、GCCは高品質のコードを備えたプロジェクトだと考えています。 多くの人が議論したいと思うでしょう。 例として、ロシア語のウィキペディアから引用します。



Theo de RaadtやOtto Moerbeekなどの一部のOpenBSD開発者は、GCCを「扱いにくく、バグがあり、遅く、不正なコードを生成する」と言って批判しています。



私はそのような声明は根拠がないと考えています。 はい、おそらくGCCコードには読みにくくする多くのマクロが含まれています。 しかし、私は彼のバギーに関する声明に同意することはできません。 GCCにバグがある場合、どこでも機能しません。 コンパイルして正常に動作するプログラムの数を覚えているだけです。 GCCの作成者は、優れたプロ意識を持って巨大で複雑な仕事をしています。 彼らに感謝します。 このような高品質のプロジェクトでPVS-Studioの動作をテストできることを嬉しく思います。



Clangコンパイラコードはまだまだクールだと言う人のために、PVS-Studioでエラーが検出されたことを思い出させてください： 1、2 。

PVS-Studio

LinuxアナライザーのPVS-Studioのアルファ版でGCCコードをチェックしました。 2016年9月中旬に、関心のあるプログラマーにアナライザーのベータ版の発行を開始する予定です。 プロジェクトでPVS-Studio for Linuxのベータ版を試すことができる最初の人になる方法については、記事「 PVS-StudioがLinuxに対する愛を宣言する 」を参照してください。



2016年9月よりずっと後にこの記事を読んでPVS-Studio for Linuxを試してみたい場合は、製品ページhttp://www.viva64.com/en/pvs-studio/に招待します。

検証結果

最も興味深いセクションにたどり着きました。私たちの常連読者は楽しみにしています。 アナライザーがエラーまたは非常に疑わしい瞬間を見つけたコードのセクションを検討してください。



残念ながら、コンパイラ開発者に完全なレポートを提供することはできません。 アナライザーがLinuxの世界に完全に対応する準備が整っていないという事実に関連するゴミ（誤検知）がまだ多すぎます。 使用される典型的な構造に関する誤った警告の数を減らす作業を行う必要があります。 簡単な例で説明します。 多くの診断では、マクロのアサートに関連する式を誓う必要はありません。 これらのマクロは非常に創造的であり、アナライザーに注意を払わないように教える必要があります。 しかし、実際には、 assertマクロは非常に異なる方法で定義されており、すべての一般的なオプションでアナライザーをトレーニングする必要があります。



そのため、GCC開発者には、少なくともベータ版のアナライザーのリリースを待つようお願いします。 未完成のバージョンで生成されたレポートで印象を損ないたくありません。

クラシック（コピーペースト）

V501診断プログラムで検出される最も古典的で一般的な間違いから始めます。 原則として、このようなエラーはコピーペースト中の不注意のために表示されるか、単に新しいコードを入力するときに入力ミスが許可されます。

static bool dw_val_equal_p (dw_val_node *a, dw_val_node *b) { .... case dw_val_class_vms_delta: return (!strcmp (a->v.val_vms_delta.lbl1, b->v.val_vms_delta.lbl1) && !strcmp (a->v.val_vms_delta.lbl1, b->v.val_vms_delta.lbl1)); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V501「&&」演算子の左と右に同じ副次式「！Strcmp（a-> v.val_vms_delta.lbl1、b-> v.val_vms_delta.lbl1）」があります。 dwarf2out.c 1428



エラーがすぐに問題になることを確認し、注意深く調べる必要があります。 そのため、コードレビューとリファクタリング中にエラーが検出されませんでした。



strcmp関数は、同じ行を2回比較します。 2度目には、クラスlbl1のメンバーではなくlbl2を比較する必要があったように思えます。 正しいコードは次のようになります。

 return (!strcmp (a->v.val_vms_delta.lbl1, b->v.val_vms_delta.lbl1) && !strcmp (a->v.val_vms_delta.lbl2, b->v.val_vms_delta.lbl2));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この記事のコードは、X軸上のスペースをほとんどとらないようにわずかにフォーマットされていますが、実際には次のようになります。

「テーブル」コードアライメントを使用すれば、おそらく間違いを回避できたでしょう。 たとえば、次のようにコードをフォーマットすると、エラーがわかりやすくなります。

このアプローチについては、電子書籍「 プログラミング、リファクタリング、その他すべての主な問題 」で詳しく検討しました（N13章「同じタイプのコードを「テーブル」に揃える」を参照）。 コードの品質を気にする人には、ここで提供されているリンクを知っておくことをお勧めします。



Copy-Pasteが原因で発生したと思われる別のエラーを見てみましょう。

 const char *host_detect_local_cpu (int argc, const char **argv) { unsigned int has_avx512vl = 0; unsigned int has_avx512ifma = 0; .... has_avx512dq = ebx & bit_AVX512DQ; has_avx512bw = ebx & bit_AVX512BW; has_avx512vl = ebx & bit_AVX512VL; // <= has_avx512vl = ebx & bit_AVX512IFMA; // <= .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V519 'has_avx512vl'変数には値が連続して2回割り当てられます。 おそらくこれは間違いです。 行を確認してください：500、501。driver-i386.c 501



has_avx512vl変数には、さまざまな値が連続して2回書き込まれます。 意味がありません コードを調べて、 has_avx512ifma変数を発見しました 。 ほとんどの場合、式ebx＆bit_AVX512IFMAで初期化する必要があります。 正しいコードは次のようになります。

 has_avx512vl = ebx & bit_AVX512VL; has_avx512ifma = ebx & bit_AVX512IFMA;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タイプミス

あなたのマインドフルネスのテストを続けます。 コードを見て、下を覗かずにエラーを見つけてください。

 static bool ubsan_use_new_style_p (location_t loc) { if (loc == UNKNOWN_LOCATION) return false; expanded_location xloc = expand_location (loc); if (xloc.file == NULL || strncmp (xloc.file, "\1", 2) == 0 || xloc.file == '\0' || xloc.file[0] == '\xff' || xloc.file[1] == '\xff') return false; return true; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V528 「char」タイプへのポインターが「\ 0」値と比較されるのは奇妙です。 おそらく以下を意味します：* xloc.file == '\ 0'。 ubsan.c 1472



ここで、プログラマーは、式xloc.file == '\ 0'のポインターを逆参照するのを誤って忘れていました。 その結果、ポインターは単純に0と比較されます。 NULLを使用します 。 以前はこのようなチェックがすでに実行されていたため、これは効果がありません： xloc.file == NULL 。



プログラマがターミナルゼロを「\ 0」と書き留めておくと便利です。 これにより、コードが間違っていることとその修正方法をすばやく理解できます。 このことについては、本でも書きました（N9章：リテラル「\ 0」を使用してターミナルゼロを示します）。



正しいコードは次のとおりです。

 if (xloc.file == NULL || strncmp (xloc.file, "\1", 2) == 0 || xloc.file[0] == '\0' || xloc.file[0] == '\xff' || xloc.file[1] == '\xff') return false;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、コードをもう少し改善しましょう。 次のように式をフォーマットすることをお勧めします。

 if ( xloc.file == NULL || strncmp (xloc.file, "\1", 2) == 0 || xloc.file[0] == '\0' || xloc.file[0] == '\xff' || xloc.file[1] == '\xff') return false;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注意：今、あなたが同じ間違いをした場合、それに気付く可能性はわずかに高くなります：

 if ( xloc.file == NULL || strncmp (xloc.file, "\1", 2) == 0 || xloc.file == '\0' || xloc.file[0] == '\xff' || xloc.file[1] == '\xff') return false;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

潜在的なNULLポインターの逆参照

このセクションは、「10万番目の例、マクロが悪い理由」とも呼ばれます。 私はマクロが本当に嫌いで、常にマクロの使用を控えるよう勧めています。 マクロは、コードの読み取りを困難にし、エラーを引き起こし、静的アナライザーの作業を複雑にします。 GCCコードとの短い会話から、著者はマクロを非常に好んでいるように思えました。 私はこのマクロまたはそのマクロが何で明らかにされているのかを研究するために苦しみました。それがおそらく多くの興味深いエラーを見逃した理由です。 私は時々、怠け者です。 ただし、マクロに関連するいくつかのエラーを引き続き示します。

 odr_type get_odr_type (tree type, bool insert) { .... odr_types[val->id] = 0; gcc_assert (val->derived_types.length() == 0); if (odr_types_ptr) val->id = odr_types.length (); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V595 nullptrに対して検証される前に、「odr_types_ptr」ポインターが使用されました。 行を確認してください：2135、2139。ipa-devirt.c 2135



ここに間違いがありますか？ 私はそうは思いませんし、アナライザーのメッセージは明瞭さをもたらしません。 問題は、 odr_typesは変数名ではなく、次のように宣言されたマクロであるということです。

 #define odr_types (*odr_types_ptr)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マクロを開いて、関係のないものをすべて削除すると、次のコードが取得されます。

 (*odr_types_ptr)[val->id] = 0; if (odr_types_ptr)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初に、ポインターは逆参照され、チェックされます。 これが実際にトラブルにつながるかどうかを言うのは難しいでしょう。 それはすべて、ポインターが実際にnullptrであるときに状況が発生する可能性があるかどうかに依存します。 この状況が不可能な場合は、余分なチェックを削除する必要があります。これは、コードとコードアナライザーをサポートする人々を誤解させます。 ポインターがヌルになる可能性がある場合、これは深刻な間違いであり、さらに注意と修正が必要です。



別の同様のケースを考えてみましょう：

 static inline bool sd_iterator_cond (sd_iterator_def *it_ptr, dep_t *dep_ptr) { .... it_ptr->linkp = &DEPS_LIST_FIRST (list); if (list) continue; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V595 nullptrに対して検証される前に「リスト」ポインターが使用されました。 行を確認してください：1627、1629。sched-int.h 1627



エラーを表示するには、マクロデバイスを再度表示する必要があります。

 #define DEPS_LIST_FIRST(L) ((L)->first)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マクロを開き、以下を取得します。

 it_ptr->linkp = &((list)->first); if (list) continue;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして今、多くの人が叫ぶでしょう：「やめて、やめて！ 間違いはありません。 クラスのメンバーへのポインタを取得するだけです。 ここでは、nullポインターの逆参照はありません。 はい、おそらくコードは正確ではありませんが、ここにはエラーはありません！」



それほど単純ではありません。 ここで未定義の動作が発生します。 そして、そのようなコードが実際に機能するという事実は幸運です。 実際、そのように書くことはできません。 たとえば、最適化コンパイラは、 list->を最初に見て、 if（リスト）チェックを削除できます。 ->演算子を実行したため、ポインターがnullptrではないことを意味します。 その場合、ポインターを確認する必要はありません。



このトピックに関する記事全体を書きました：「 nullポインターを逆参照すると未定義の動作が発生します。」 同様のケースがそこで検討されています。 議論する前に、この記事を注意深く読んでください。



ただし、考慮される状況は非常に複雑で明白ではありません。 私はまだ間違っている可能性があり、間違いがないことを認めます。 しかし、これまでのところ誰も私にこれを証明することができませんでした。 GCC開発者がこの記事に注意を払うと、GCC開発者からのコメントを聞くのは面白いでしょう。 彼らは、コンパイラがどのように機能するか、そしてそのようなコードがエラーとして解釈されるべきかどうかを正確に知る必要があります。

破壊された配列を使用する

 static void dump_hsa_symbol (FILE *f, hsa_symbol *symbol) { const char *name; if (symbol->m_name) name = symbol->m_name; else { char buf[64]; sprintf (buf, "__%s_%i", hsa_seg_name (symbol->m_segment), symbol->m_name_number); name = buf; } fprintf (f, "align(%u) %s_%s %s", hsa_byte_alignment (symbol->m_align), hsa_seg_name(symbol->m_segment), hsa_type_name(symbol->m_type & ~BRIG_TYPE_ARRAY_MASK), name); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V507のローカル配列「buf」へのポインターは、この配列のスコープ外に保存されます。 そのようなポインターは無効になります。 hsa-dump.c 704



一時バッファbufに文字列が形成されます。 この一時バッファのアドレスは変数名に保存され、後で関数の本体で使用されます。 エラーは、変数nameにバッファーを書き込んだ後、このバッファー自体が破棄されることです。



破壊されたバッファへのポインタは使用できません。 正式には、不定の動作を扱っています。 実際には、このコードは非常にうまく機能します。 プログラムの正しい動作は、未定義の動作を明示するためのオプションの1つです。



いずれにしても、このコードにはエラーが含まれているため、修正する必要があります。 コードは、コンパイラが他の変数または配列の後続の格納に一時バッファを使用する必要がないと考えるかもしれないという理由で機能する場合があります。 そして、スタック上に作成された配列は破壊されたと見なされますが、実際には誰もそれに触れることができず、関数はその仕事を正しく行います。 それはいつでも終わらせることができる幸運であり、10年間働いていたコードは、突然、コンパイラの新しいバージョンに切り替えると、驚くほどの動作を開始します。



エラーを修正するには、 名前ポインタと同じスコープでbuf配列を宣言するだけです：

 static void dump_hsa_symbol (FILE *f, hsa_symbol *symbol) { const char *name; char buf[64]; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

条件に関係なく同じアクションを実行する

アナライザーは、エラーとして明確に特定できないコードのセクションを検出しました。 ただし、チェックを実行し、その結果に関係なく同じアクションを実行することは非常に疑わしいです。 もちろん、おそらくこれは未来に影響を与えており、これまでのところすべてが正しいですが、コードのこのセクションを確認する価値があることは明らかです。

 bool thread_through_all_blocks (bool may_peel_loop_headers) { .... /* Case 1, threading from outside to inside the loop after we'd already threaded through the header. */ if ((*path)[0]->e->dest->loop_father != path->last ()->e->src->loop_father) { delete_jump_thread_path (path); e->aux = NULL; ei_next (&ei); } else { delete_jump_thread_path (path); e->aux = NULL; ei_next (&ei); } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V523 「then」ステートメントは「else」ステートメントと同等です。 tree-ssa-threadupdate.c 2596



このコードに誤りがある場合、残念ながら、修正方法がわかりません。 これは、修正を行うためにプロジェクトに精通する必要がある場合です。

フォームの過剰な表現（A == 1 || A！= 2）

 static const char * alter_output_for_subst_insn (rtx insn, int alt) { const char *insn_out, *sp ; char *old_out, *new_out, *cp; int i, j, new_len; insn_out = XTMPL (insn, 3); if (alt < 2 || *insn_out == '*' || *insn_out != '@') return insn_out; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V590この式の検査を検討してください。 表現が過剰であるか、誤植が含まれています。 gensupport.c 1640



条件に興味があります：（alt <2 || * insn_out == '*' || * insn_out！= '@'）



短縮できます：（alt <2 || * insn_out！= '@'）



演算子！=を==に置き換える必要があると思い込んでいます。 次に、コードはより意味のある外観になります。

 if (alt < 2 || *insn_out == '*' || *insn_out == '@')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

間違ったポインターをゼロにする

リソースを解放する機能を検討してください。

 void free_original_copy_tables (void) { gcc_assert (original_copy_bb_pool); delete bb_copy; bb_copy = NULL; delete bb_original; bb_copy = NULL; delete loop_copy; loop_copy = NULL; delete original_copy_bb_pool; original_copy_bb_pool = NULL; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V519「bb_copy」変数には連続して2回値が割り当てられます。 おそらくこれは間違いです。 行を確認してください：1076、1078。cfg.c 1078



次の4行のコードに注意してください。

 delete bb_copy; bb_copy = NULL; delete bb_original; bb_copy = NULL;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

bb_copyポインターが誤って2回無効にされます。 正しいオプション：

 delete bb_copy; bb_copy = NULL; delete bb_original; bb_original = NULL;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何もチェックしないとアサートする

gcc_assertマクロの引数である誤った条件は、プログラムの正確性には影響しませんが、エラーが発生した場合の検索を複雑にします。 コードを考慮してください：

 static void output_loc_operands (dw_loc_descr_ref loc, int for_eh_or_skip) { unsigned long die_offset = get_ref_die_offset (val1->v.val_die_ref.die); .... gcc_assert (die_offset > 0 && die_offset <= (loc->dw_loc_opc == DW_OP_call2) ? 0xffff : 0xffffffff); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V502おそらく「？：」オペレーターは予想とは異なる方法で動作します。 「？：」演算子の優先順位は、「<=」演算子よりも低くなっています。 dwarf2out.c 2053



三項演算子？の優先順位：比較演算子<=の優先順位よりも低い。 これは、次の形式の条件を扱っていることを意味します。

 die_offset > 0 && ((die_offset <= (loc->dw_loc_opc == DW_OP_call2)) ? 0xffff : 0xffffffff);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、 &&演算子の第2オペランドは、値0xffffまたは0xffffffffを取ることができます。 これらは両方とも真であるため、式は次のように簡略化できます。

 (die_offset > 0)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは明らかにプログラマが意図したものではありません。 これを修正するには、括弧をいくつか追加します。

 gcc_assert (die_offset > 0 && die_offset <= ((loc->dw_loc_opc == DW_OP_call2) ? 0xffff : 0xffffffff));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

演算子？：非常に潜行性があり、複雑な式では使用しない方が良いです。 間違えるのはとても簡単です。 さまざまなオープンソースプロジェクトでPVS-Studioアナライザーによって検出されたこのようなエラーの例を多数収集しました。 演算子についての詳細は？：すでに前述した本に書きました（N4章：演算子を恐れますか？：そして括弧で囲みます）。

彼らは「費用」を忘れているようです

alg_hash_entry構造体は 、次のように宣言されます。

 struct alg_hash_entry { unsigned HOST_WIDE_INT t; machine_mode mode; enum alg_code alg; struct mult_cost cost; bool speed; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

synth_mult関数で、プログラマーは、これが必要なオブジェクトであるかどうかを確認することにしました。 これを行うには、構造フィールドを比較する必要があります。 ただし、この場所には間違いがあるようです。

 static void synth_mult (....) { .... struct alg_hash_entry *entry_ptr; .... if (entry_ptr->t == t && entry_ptr->mode == mode && entry_ptr->mode == mode && entry_ptr->speed == speed && entry_ptr->alg != alg_unknown) { .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V501「&&」演算子の左側と右側には、同じサブ表現「entry_ptr-> mode == mode」があります。 expmed.c 2573



モードは連続して2回チェックされますが、 コストチェックはありません。 おそらく、比較の1つを削除するだけか、 コストを比較する必要があります 。 私が判断するのは難しいですが、コードは明らかに修正する価値があります。

割り当ての重複

私の意見では、コードの次のセクションは危険ではなく、重複した割り当てを簡単に削除できるようです。



ケースN1

 type_p find_structure (const char *name, enum typekind kind) { .... structures = s; // <= s->kind = kind; s->ustag = name; structures = s; // <= return s; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V519「構造」変数には、連続して2回値が割り当てられます。 おそらくこれは間違いです。 行を確認してください：842、845。gengtype.c 845



ケースN2

 static rtx ix86_expand_sse_pcmpistr (....) { unsigned int i, nargs; .... case V8DI_FTYPE_V8DI_V8DI_V8DI_INT_UQI: case V16SI_FTYPE_V16SI_V16SI_V16SI_INT_UHI: case V2DF_FTYPE_V2DF_V2DF_V2DI_INT_UQI: case V4SF_FTYPE_V4SF_V4SF_V4SI_INT_UQI: case V8SF_FTYPE_V8SF_V8SF_V8SI_INT_UQI: case V8SI_FTYPE_V8SI_V8SI_V8SI_INT_UQI: case V4DF_FTYPE_V4DF_V4DF_V4DI_INT_UQI: case V4DI_FTYPE_V4DI_V4DI_V4DI_INT_UQI: case V4SI_FTYPE_V4SI_V4SI_V4SI_INT_UQI: case V2DI_FTYPE_V2DI_V2DI_V2DI_INT_UQI: nargs = 5; // <= nargs = 5; // <= mask_pos = 1; nargs_constant = 1; break; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V519「nargs」変数には、連続して2回値が割り当てられます。 おそらくこれは間違いです。 チェック行：39951、39952。i386.c 39952



ケースN3



後者のケースは、他のケースよりも奇妙です。 おそらく何らかの間違いがあります。 変数steptypeの値は2回または3回割り当てられます。 これは疑わしいです。

 static void cand_value_at (....) { aff_tree step, delta, nit; struct iv *iv = cand->iv; tree type = TREE_TYPE (iv->base); tree steptype = type; // <= if (POINTER_TYPE_P (type)) steptype = sizetype; // <= steptype = unsigned_type_for (type); // <= .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioアナライザーの警告： V519「steptype」変数には、連続して2回値が割り当てられます。 おそらくこれは間違いです。 行を確認してください：5173、5174。tree-ssa-loop-ivopts.c 5174

おわりに

この記事を書いてうれしいです。 「GCCは同じ警告を出すので、PVS-Studioは必要ありません」などのコメントに対応するものがあります。 ご覧のとおり、PVS-Studioは非常に強力なツールであり、GCCよりも診断機能に優れています。 GCCに優れた診断機能があることを否定しません。 このコンパイラは、適切に構成されていれば、コードの多くの問題を明らかにします。 しかし、PVS-Studioは専門的かつ急速に開発されているツールです。つまり、コンパイラよりもコードのエラーを検出する方が常に優れています。



私たちのサイトのこのセクションにアクセスして、他の有名なオープンソースプロジェクトのチェックに精通してください。 また、Twitterを使用している場合は、 @ Code_Analysisをフォローしてください 。 CおよびC ++でのプログラミングに関する興味深い記事へのリンクを定期的に公開し、アナライザーの新しい成果についても説明します。





この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Andrey karpov。 PVS-Studioの助けを借りてGCCで見つかったバグ 。