🧝🏿 🚳 ✌🏻 पीवीएस-स्टूडियो के साथ जीसीसी 10 कंपाइलर का परीक्षण 🤪 🍲 🍞

जीसीसी संकलक मैक्रोज़ के प्रचुर उपयोग के साथ लिखा गया है। पीवीएस-स्टूडियो का उपयोग कर जीसीसी कोड की एक और जाँच एक बार फिर हमारी टीम की राय की पुष्टि करती है कि मैक्रोज़ खराब हैं। इस तरह के कोड को न केवल एक स्थिर विश्लेषक के लिए समझना मुश्किल है, बल्कि एक प्रोग्रामर के लिए भी। बेशक, जीसीसी डेवलपर्स पहले से ही परियोजना के लिए उपयोग किए जाते हैं और इसमें अच्छी तरह से पारंगत हैं। लेकिन बगल से कुछ समझना बहुत मुश्किल है। दरअसल, मैक्रोज़ के कारण, कोड सत्यापन पूरी तरह से करना संभव नहीं था। फिर भी, हमेशा की तरह पीवीएस-स्टूडियो विश्लेषक ने दिखाया कि यह कंपाइलरों में भी त्रुटियां पा सकता है।

जीसीसी संकलक कोड को दोबारा जांचने का समय

पिछली बार मैंने चार साल पहले जीसीसी कंपाइलर की जाँच की थी। समय जल्दी और अगोचर रूप से उड़ता है, और किसी तरह मैं सभी इस परियोजना पर वापस जाना और इसे फिर से देखना भूल गया। प्रकाशन " जीसीसी 10 में स्थैतिक विश्लेषण " ने इस विचार को वापस धकेल दिया ।

वास्तव में, यह कोई रहस्य नहीं है कि संकलक के पास अपने स्वयं के अंतर्निहित स्थिर कोड विश्लेषक हैं और वे भी विकसित कर रहे हैं। इसलिए, समय-समय पर हम लेख लिखते हैं कि पीवीएस-स्टूडियो स्टैटिक विश्लेषक कंपाइलरों के अंदर भी त्रुटियां पा सकते हैं और यह कि हम बेकार खाने वाली रोटी में नहीं हैं :)।

वास्तव में, आप संकलक के साथ शास्त्रीय स्थिर विश्लेषक की तुलना नहीं कर सकते। स्टेटिक विश्लेषक न केवल कोड में त्रुटियों के लिए एक खोज है, बल्कि एक विकसित बुनियादी ढांचा भी है। उदाहरण के लिए, यह सोनारक्यूब, PlatformIO, Azure DevOps, Travis CI, CircleCI, GitLab CI / CD, Jenkins, Visual Studio जैसी प्रणालियों के साथ एकीकरण है। ये बड़े पैमाने पर चेतावनी दमन के लिए विकसित तंत्र हैं, जो आपको एक बड़ी पुरानी परियोजना में भी पीवीएस-स्टूडियो का उपयोग जल्दी से शुरू करने की अनुमति देता है। यह एक अधिसूचना मेलिंग सूची है। इत्यादि इत्यादि। हालांकि, वैसे भी, पहला सवाल पूछा गया है: "क्या पीवीएस-स्टूडियो कुछ ऐसा ढूंढ सकता है जो कंपाइलर नहीं मिल सकता है?"। इसलिए, हम इन कंपाइलरों की स्वयं जाँच करने के बारे में बार-बार लेख लिखेंगे।

आइए GCC परियोजना सत्यापन के विषय पर वापस आते हैं। इस परियोजना पर ध्यान केंद्रित करने और यह बताने की आवश्यकता नहीं है कि यह क्या है। आइए बेहतर बात करते हैं कि इस परियोजना के अंदर क्या है।

और अंदर बड़ी संख्या में मैक्रो हैं जो सत्यापन में हस्तक्षेप करते हैं। सबसे पहले, पीवीएस-स्टूडियो विश्लेषक बड़ी संख्या में झूठी सकारात्मक उत्पन्न करता है। इसमें कुछ भी गलत नहीं है, लेकिन उनके द्वारा जारी रिपोर्ट का अध्ययन करना और शुरू करना इतना आसान नहीं है। एक अच्छे तरीके से, आपको मैक्रोज़ में झूठी चेतावनी को दबाने के लिए काम करने की ज़रूरत है। अन्यथा, उपयोगी चेतावनी केवल शोर की एक धारा में डूब जाती है। यह सेटअप इस लेख लेखन कार्य के दायरे से परे है। वास्तव में, मैं पूरी तरह से ईमानदार रहूंगा - मैं ऐसा करने के लिए बहुत आलसी था, हालांकि इसके बारे में कुछ भी जटिल नहीं है। शोर के कारण रिपोर्ट देखना काफी सतही था।

दूसरे, मेरे लिए यह बहुत मुश्किल है, क्योंकि एक व्यक्ति परियोजना से परिचित नहीं है, कोड को समझने के लिए। मैक्रोज़, मैक्रोज़ ... आपको यह देखना होगा कि वे यह समझने के लिए तैनात हैं कि विश्लेषक चेतावनी क्यों देता है। बहुत मुश्किल। मुझे मैक्रों पसंद नहीं हैं । कोई कह सकता है कि सी में मैक्रोज़ के बिना नहीं कर सकते। लेकिन सीसीसी में लंबे समय तक जीसीसी नहीं लिखा गया है। हां, ऐतिहासिक कारणों की फाइलों में एक्सटेंशन .c है, लेकिन आप वहां देखते हैं, और:

//  alias.c
....
struct alias_set_hash : int_hash <int, INT_MIN, INT_MIN + 1> {};
struct GTY(()) alias_set_entry {
  alias_set_type alias_set;
  bool has_zero_child;
  bool is_pointer;
  bool has_pointer;
  hash_map<alias_set_hash, int> *children;
};
....

यह स्पष्ट रूप से C नहीं है, लेकिन C ++ है।

सामान्य तौर पर, मैक्रोज़ और कोडिंग शैली में विश्लेषक की रिपोर्ट का अध्ययन करना बहुत मुश्किल होता है। इसलिए इस बार मैं विभिन्न त्रुटियों की एक लंबी सूची को खुश नहीं करूंगा। कठिनाई के साथ और कुछ कप कॉफी का उपयोग करके, मैंने 10 दिलचस्प अंश लिखे, और इसने मुझे अकेला छोड़ दिया :)।

10 संदिग्ध कोड स्निपेट

Fragment N1, असफल कॉपी-पेस्ट लगता है

static bool
try_crossjump_to_edge (int mode, edge e1, edge e2,
                       enum replace_direction dir)
{
  ....
  if (FORWARDER_BLOCK_P (s->dest))
    s->dest->count += s->count ();

  if (FORWARDER_BLOCK_P (s2->dest))
    s2->dest->count -= s->count ();
  ....
}

PVS-Studio चेतावनी: V778 दो समान कोड अंश पाए गए। शायद, यह एक टाइपो है और 's2' वेरिएबल का उपयोग 's' के बजाय किया जाना चाहिए। cfgcleanup.c 2126

वास्तव में, मुझे यकीन नहीं है कि यह एक गलती है। हालाँकि, मुझे यह संदेह है कि यह कोड कॉपी-पेस्ट का उपयोग करके लिखा गया था, और दूसरे ब्लॉक में एक जगह पर वे s2 के साथ s को बदलना भूल गए । यही है, मुझे ऐसा लगता है कि कोड का दूसरा ब्लॉक इस तरह होना चाहिए:

if (FORWARDER_BLOCK_P (s2->dest))
  s2->dest->count -= s2->count ();

फ्रैगमेंट एन 2, टाइपो

tree
vn_reference_lookup_pieces (....)
{
  struct vn_reference_s vr1;
  ....
  vr1.set = set;
  vr1.set = base_set;
  ....
}

PVS-Studio चेतावनी: V519 'vr1.set' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 3448, 3449. ट्री- ssa-sccvn.c 3449

यह बहुत अजीब है कि एक ही चर में दो बार अलग-अलग मान लिखे गए हैं। यह एक स्पष्ट टाइपो है। इस फ़ाइल के आगे यह कोड है:

vr1.set = set;
vr1.base_set = base_set;

सबसे अधिक संभावना है, संदिग्ध कोड में इसे बिल्कुल वैसा ही लिखा जाना चाहिए था।

टुकड़ा N3, एक चर को खुद को सौंपना

static omp_context *
new_omp_context (gimple *stmt, omp_context *outer_ctx)
{
  omp_context *ctx = XCNEW (omp_context);

  splay_tree_insert (all_contexts, (splay_tree_key) stmt,
         (splay_tree_value) ctx);
  ctx->stmt = stmt;

  if (outer_ctx)
    {
      ctx->outer = outer_ctx;
      ctx->cb = outer_ctx->cb;
      ctx->cb.block = NULL;
      ctx->local_reduction_clauses = NULL;
      ctx->outer_reduction_clauses = ctx->outer_reduction_clauses;  // <=
      ctx->depth = outer_ctx->depth + 1;
    }
  ....
}

PVS-Studio चेतावनी: V570 'ctx-> external_reduction_clauses' वेरिएबल को ही सौंपा गया है। omp-low.c 935

अपने आप को एक चर असाइन करना बहुत अजीब है।

टुकड़ा करना N4। 0,1,2, फ्रेडी आपको उठाएगा।

मैंने हाल ही में एक लेख प्रकाशित किया, " जीरो, वन, टू, फ्रेडी विल टेक यू ।" यह मुझे लगता है कि निम्नलिखित कोड स्निपेट इस लेख में चर्चा की गई त्रुटियों का संग्रह जारी रखता है।

#define GET_MODE(RTX)    ((machine_mode) (RTX)->mode)
....
static int
add_equal_note (rtx_insn *insns, rtx target, enum rtx_code code, rtx op0,
                rtx op1, machine_mode op0_mode)
{
  ....
  if (commutative_p
      && GET_MODE (xop0) != xmode0 && GET_MODE (xop1) != xmode1
      && GET_MODE (xop0) == xmode1 && GET_MODE (xop1) == xmode1)
    std::swap (xop0, xop1);
  ....
}

पीवीएस-स्टूडियो चेतावनी: V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा गलत होता है:
((मशीन_मोड) (xop1) -> मोड) == xmode1। Optabs.c 1053

इन दो उप विषयों पर ध्यान दें:

GET_MODE (xop1)! = Xmode1
GET_MODE (xop1) == xmode1

AND ऑपरेशन इन सबएक्सप्रेस के परिणामों पर किया जाता है, जिसका स्पष्ट रूप से कोई व्यावहारिक अर्थ नहीं है। दरअसल, यदि दूसरा उपप्रकार का निष्पादन किया जाना शुरू हो जाता है, तो यह पहले से ही ज्ञात है कि इसका परिणाम गलत होगा ।

सबसे अधिक संभावना है, शून्य और लोगों में यहां एक टाइपो है, और वास्तव में स्थिति इस तरह होनी चाहिए:

&& GET_MODE (xop0) != xmode0 && GET_MODE (xop1) != xmode1
&& GET_MODE (xop0) == xmode1 && GET_MODE (xop1) == xmode0

बेशक, मुझे यकीन नहीं है कि अगर मैंने कोड को सही ढंग से बदल दिया है, क्योंकि मैं परियोजना में निर्देशित नहीं हूं।

टुकड़े करना N5। तर्क मूल्य में संदिग्ध परिवर्तन

bool
ipa_polymorphic_call_context::set_by_invariant (tree cst,
                                                tree otr_type,
                                                HOST_WIDE_INT off)
{
  poly_int64 offset2, size, max_size;
  bool reverse;
  tree base;

  invalid = false;
  off = 0;                // <=
  ....
  if (otr_type && !contains_type_p (TREE_TYPE (base), off, otr_type))
    return false;

  set_by_decl (base, off);
  return true;
}

पीवीएस-स्टूडियो चेतावनी: V763 पैरामीटर 'ऑफ' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। ipa-polymorphic-call.c 766 ऑफ

तर्क का मान तुरंत 0. बदल दिया जाता है। इसके अलावा, कोई व्याख्यात्मक टिप्पणी नहीं है। यह सब बहुत संदिग्ध है। डिबगिंग के दौरान कभी-कभी यह कोड दिखाई देता है। प्रोग्रामर को यह देखने की आवश्यकता है कि फ़ंक्शन एक निश्चित मोड में कैसे व्यवहार करता है, इसलिए उसने अस्थायी रूप से तर्क के मूल्य को बदल दिया, और फिर वे इस लाइन को हटाना भूल गए। परिणामस्वरूप, कोड में एक त्रुटि दिखाई देती है। बेशक, सब कुछ यहीं हो सकता है, लेकिन इस कोड को स्पष्ट रूप से जांचने और स्पष्ट करने की आवश्यकता है ताकि भविष्य में इसी तरह के प्रश्न उत्पन्न न हों। खंडन N6। छोटी सी बात

cgraph_node *
cgraph_node::create_clone (....)
{
  ....
  new_node->icf_merged = icf_merged;
  new_node->merged_comdat = merged_comdat;   // <=
  new_node->thunk = thunk;
  new_node->unit_id = unit_id;
  new_node->merged_comdat = merged_comdat;   // <=
  new_node->merged_extern_inline = merged_extern_inline;
  ....
}

PVS-Studio चेतावनी: V519 'new_node-> merged_comdat' वैरिएबल को दो बार क्रमिक रूप से असाइन किया गया है। शायद यह एक गलती है। जाँच लाइनें: 406, 409. cgraphclones.c 409 असाइनमेंट को

यादृच्छिक रूप से डुप्लिकेट किया गया है। सबसे अधिक संभावना कुछ भी गलत नहीं है। हालांकि, हमेशा एक जोखिम होता है कि वास्तव में वे कुछ अन्य असाइनमेंट करना भूल गए।

खंडन N7। कोड जो खतरनाक दिखता है

static void
complete_mode (struct mode_data *m)
{
  ....
  if (m->cl == MODE_COMPLEX_INT || m->cl == MODE_COMPLEX_FLOAT)
    alignment = m->component->bytesize;
  else
    alignment = m->bytesize;

  m->alignment = alignment & (~alignment + 1);

  if (m->component)
  ....
}

PVS-Studio चेतावनी: V595 nullptr के खिलाफ सत्यापित होने से पहले 'm-> घटक' पॉइंटर का उपयोग किया गया था। जाँच लाइनें: 407, 415. genmodes.c 407

शुरुआत में, m-> घटक सूचक को if स्टेटमेंट की शाखाओं में से एक में dereferenced जाता है । मेरा मतलब है कि यह अभिव्यक्ति: m-> घटक-> बाइटसेज़ ।

यह आगे पता चलता है कि यह सूचक शून्य हो सकता है। यह चेक से इस प्रकार है: यदि (m-> घटक) ।

यह कोड आवश्यक रूप से गलत नहीं है। यह पूरी तरह से संभव है कि एक निष्क्रिय शाखा को केवल तभी निष्पादित किया जाता है जब सूचक शून्य नहीं होता है। यही है, चर m-> cl और m-> घटक के मूल्य के बीच एक अप्रत्यक्ष संबंध है। लेकिन यह कोड किसी भी मामले में बहुत खतरनाक दिखता है। और कोई व्याख्यात्मक टिप्पणी नहीं है।

खंडन N8। दोहरी जाँच

void
pointer_and_operator::wi_fold (value_range &r, tree type,
                               const wide_int &lh_lb,
                               const wide_int &lh_ub,
                               const wide_int &rh_lb ATTRIBUTE_UNUSED,
                               const wide_int &rh_ub ATTRIBUTE_UNUSED) const
{
  // For pointer types, we are really only interested in asserting
  // whether the expression evaluates to non-NULL.
  if (wi_zero_p (type, lh_lb, lh_ub) || wi_zero_p (type, lh_lb, lh_ub))
    r = range_zero (type);
  else 
    r = value_range (type);
}

PVS-Studio चेतावनी: V501 समान उप-अभिव्यक्तियाँ हैं 'wi_zero_p (प्रकार, lh_lb, lh_ub)' बाईं ओर और 'दाईं ओर' ऑपरेटर। रेंज-op.cc 2657

किसी प्रकार की अजीब जाँच। Wi_zero_p फ़ंक्शन को वास्तविक तर्क के समान सेट के साथ दो बार कहा जाता है। किसी को संदेह हो सकता है कि वास्तव में, दूसरी कॉल को बाहर से स्वीकार किए गए तर्कों का उपयोग करना चाहिए: rh_lb , rh_ub। लेकिन नहीं, इन तर्कों को अप्रयुक्त ( ATTRIBUTE_UNUSED ) के रूप में चिह्नित किया गया है ।

इसलिए, मेरे लिए यह स्पष्ट नहीं है कि चेक लिखना आसान क्यों नहीं है:

if (wi_zero_p (type, lh_lb, lh_ub))
  r = range_zero (type);
else 
  r = value_range (type);

या यहाँ कुछ टाइपो है? या एक तार्किक गलती? मुझे नहीं पता, लेकिन कोड बहुत अजीब है।

टुकड़े करना N9। खतरनाक सरणी का उपयोग

struct algorithm
{
  struct mult_cost cost;
  short ops;
  enum alg_code op[MAX_BITS_PER_WORD];
  char log[MAX_BITS_PER_WORD];
};

static void
synth_mult (struct algorithm *alg_out, unsigned HOST_WIDE_INT t,
            const struct mult_cost *cost_limit, machine_mode mode)
{
  int m;
  struct algorithm *alg_in, *best_alg;
  ....
  /* Cache the result.  */
  if (!cache_hit)
  {
    entry_ptr->t = t;
    entry_ptr->mode = mode;
    entry_ptr->speed = speed;
    entry_ptr->alg = best_alg->op[best_alg->ops];
    entry_ptr->cost.cost = best_cost.cost;
    entry_ptr->cost.latency = best_cost.latency;
  }

  /* If we are getting a too long sequence for `struct algorithm'
     to record, make this search fail.  */
  if (best_alg->ops == MAX_BITS_PER_WORD)
    return;
  ....
}

PVS-Studio चेतावनी: V781 'best_alg-> ops' वैरिएबल के मान का उपयोग करने के बाद जाँच की जाती है। शायद प्रोग्राम लॉजिक में कोई गलती है। चेक लाइनें: 3157, 3164. expmed.c 3157

चलो यह स्पष्ट करने के लिए कोड को छोटा करें कि विश्लेषक को क्या पसंद नहीं है:

if (!cache_hit)
{
  entry_ptr->alg = best_alg->op[best_alg->ops];
}
if (best_alg->ops == MAX_BITS_PER_WORD)

शुरुआत में, चर को अनुक्रमित करने के लिए वैरिएबल best_alg-> ऑप्स का उपयोग किया जाता है। और उसके बाद ही यह चर सीमा मूल्य के लिए जाँच करता है। सैद्धांतिक रूप से, किसी सरणी का ओवरफ़्लो (क्लासिक प्रकार की त्रुटि CWE-193: ऑफ़-बाय-वन एरर ) हो सकता है।

क्या यह वास्तविक गलती है? और जैसा कि इस लेख में लगातार हो रहा है, मुझे यकीन नहीं है :)। शायद इस सूचकांक और cache_hit चर के मूल्य के बीच एक संबंध है । यदि इंडेक्स अधिकतम ( MAX_BITS_PER_WORD ) पर है तो कुछ भी कैश नहीं किया जाता है । फ़ंक्शन कोड बड़ा है, और मैंने इसका पता नहीं लगाया।

किसी भी मामले में, इस कोड को सबसे अच्छी तरह से जांचा जाता है। और यहां तक कि अगर यह सही हो जाता है, तो मैं एक टिप्पणी के साथ कार्यक्रम के विचारशील अनुभाग के साथ सिफारिश करूंगा। यह न केवल मुझे या पीवीएस-स्टूडियो को भ्रमित कर सकता है, बल्कि किसी और को भी।

घर्षण N10। कोड जो 4 वर्षों में तय नहीं किया गया है।

पिछले लेख में, मैंने इस कोड पर ध्यान आकर्षित किया:

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 1481

दो strcmp फ़ंक्शन समान पॉइंटर्स की तुलना करते हैं। यही है, एक स्पष्ट रूप से निरर्थक जांच की जाती है। पिछले लेख में, मैंने सुझाव दिया कि यह एक टाइपो था, और वास्तव में लिखा जाना चाहिए:

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));

हालांकि, 4 साल के लिए यह कोड तय नहीं किया गया है। उसी समय, हमने लेखकों को कोड के संदिग्ध अनुभागों के बारे में सूचित किया जो हमने लेख में वर्णित किया था। अब मुझे यकीन नहीं है कि यह एक गलती है। शायद यह सिर्फ बेमानी कोड है। इस मामले में, अभिव्यक्ति को सरल बनाया जा सकता है:

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

देखते हैं कि जीसीसी डेवलपर्स नए लेख के बाद इस कोड को बदलेंगे या नहीं।

निष्कर्ष

मैं आपको याद दिलाता हूं कि आप खुली परियोजनाओं की जांच के लिए इस मुफ्त लाइसेंस विकल्प का उपयोग कर सकते हैं । वैसे, पीवीएस-स्टूडियो के मुफ्त लाइसेंस के अन्य विकल्प भी हैं, यहां तक कि बंद परियोजनाओं के लिए भी। वे यहां सूचीबद्ध हैं: " पीवीएस-स्टूडियो फ्री लाइसेंसिंग विकल्प "।

ध्यान देने के लिए आपको धन्यवाद। और हमारे ब्लॉग को पढ़े । कई दिलचस्प बातें हैं।

संकलक जाँच के बारे में हमारे अन्य लेख

एलएलवीएम चेक (क्लैंग) (अगस्त 2011), दूसरा चेक (अगस्त 2012), तीसरा चेक (अक्टूबर 2016), चौथा चेक (अप्रैल 2019)
जीसीसी की समीक्षा (अगस्त 2016)
Huawei आर्क कंपाइलर (दिसंबर 2019) की जांच करें
.NET कंपाइलर प्लेटफ़ॉर्म ("रोज़लिन") का सत्यापन (दिसंबर 2015), दूसरा निरीक्षण (अप्रैल 2019)
रोसलिन एनालाइज़र रिव्यू (अगस्त 2019)
PascalABC.NET की जाँच (मार्च 2017)

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: एंड्री कारपोव। पीवीएस-स्टूडियो के साथ जीसीसी 10 कंपाइलर की जांच ।

पीवीएस-स्टूडियो के साथ जीसीसी 10 कंपाइलर का परीक्षण

जीसीसी संकलक कोड को दोबारा जांचने का समय

10 संदिग्ध कोड स्निपेट

निष्कर्ष

संकलक जाँच के बारे में हमारे अन्य लेख

More articles: