कैसे संकलक इतने विश्वसनीय हैं?

62

हम एक दैनिक आधार पर कंपाइलर का उपयोग करते हैं जैसे कि उनकी शुद्धता दी गई है, लेकिन कंपाइलर प्रोग्राम भी हैं, और इसमें संभवतः कीड़े भी हो सकते हैं। मैं हमेशा इस अचूक मजबूती के बारे में सोचता था। क्या आपको कभी कंपाइलर में बग का सामना करना पड़ा है? यह क्या था और आपको कंपाइलर में ही समस्या का एहसास कैसे हुआ?

... और कैसे करते हैं वे compilers इतना विश्वसनीय बनाते हैं?

— एप्सिलॉनवेक्टर
स्रोत

16

खैर, वे इसमें संकलक संकलित करते हैं ...

— माइकल के

31

वे अचूक नहीं हैं। संकलक कीड़े हैं - यह सिर्फ इतना है कि वे बहुत दुर्लभ हैं।

— ChrisF

5

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

— फिक्स

आप को देख कैसे एक संकलक कि द्वारा कुछ सीख सकते हैं करता है कीड़ों का एक बहुत कुछ है (SDCC की तरह!) जीसीसी की तरह एक संकलक जो अधिक मजबूत और विश्वसनीय है से अलग है।

— बेन जैक्सन

4

VC ++ 6 में एक बग था।

— मतीन उल्हाक

96

वे समय के साथ हजारों या लाखों डेवलपर्स द्वारा उपयोग के माध्यम से पूरी तरह से परीक्षण करते हैं।

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

इसके अलावा, आमतौर पर बग्स को पुन: पेश करना भी आसान होता है: सटीक प्लेटफॉर्म और कंपाइलर संस्करण जानकारी के अलावा, आमतौर पर आपको केवल इनपुट कोड का एक टुकड़ा चाहिए होता है। यह उल्लेख नहीं करने के लिए कि संकलक उपयोगकर्ता (स्वयं डेवलपर्स होने के नाते) किसी भी औसत कंप्यूटर उपयोगकर्ता की तुलना में कहीं अधिक सटीक और विस्तृत बग रिपोर्ट देते हैं :-)

— पेरेक को दर्शाता है
स्रोत

32

कंपाइलर कोड का अधिक भाग शायद सही साबित हो सकता है।

— biziclop

@biziclop, अच्छी बात है, यह कार्य की विशेष प्रकृति का एक और परिणाम है।

— पेटर टॉरक

पहला पूरा संकलक 1957 में जॉन बैकस द्वारा फोरट्रान भाषा के लिए लिखा गया था। तो, आप देखते हैं, संकलक तकनीक 50 वर्ष से अधिक पुरानी है। हमारे पास इसे ठीक करने के लिए काफी समय है, हालांकि अन्य लोग बताते हैं कि कंपाइलर्स में कीड़े होते हैं।

— leed25d

@biziclop, वास्तव में, कुछ घटक जैसे कि लेक्सर्स और पार्सर्स को एक व्याकरण से भी ऑटोजेनर किया जा सकता है, जो फिर से बग के जोखिम को कम करता है (बशर्ते कि लेक्सर / पार्सर जनरेटर मजबूत है - जो वे आमतौर पर ऊपर सूचीबद्ध समान कारणों के लिए हैं) ।

— पास्टर तोक

2

@ पैटर: अधिक व्यापक रूप से उपयोग किए जाने वाले कंपाइलरों में लेक्सर / पार्सर जेनरेटर दुर्लभ प्रतीत होते हैं - अधिकांश लेसर और पार्सर विभिन्न कारणों से हाथ से लिखते हैं, जिसमें प्रश्न में भाषा के लिए गति और पर्याप्त स्मार्ट पार्सर / लेसर जनरेटर की कमी भी शामिल है (जैसे C )।

61

सभी महान जवाब के अलावा अब तक:

आपके पास एक "पर्यवेक्षक पूर्वाग्रह" है। आप बग का निरीक्षण नहीं करते हैं, और इसलिए आप मानते हैं कि कोई भी नहीं है।

मैं जैसा सोचता था, वैसा ही आप करते थे। फिर मैंने पेशेवर रूप से कम्पाइलर लिखना शुरू किया, और मैं आपको बता दूं, कि वहां बहुत सारे कीड़े हैं!

आपको बग नहीं दिखते क्योंकि आप कोड लिखते हैं जो बाकी सभी कोड के 99.999% की तरह है जो लोग लिखते हैं। आप शायद पूरी तरह से सामान्य, सरल, स्पष्ट रूप से सही कोड लिखते हैं जो विधियों को कॉल करता है और लूप चलाता है और कुछ भी फैंसी या अजीब नहीं करता है, क्योंकि आप सामान्य डेवलपर हैं जो सामान्य व्यावसायिक समस्याओं को हल कर रहे हैं।

आपको कोई कंपाइलर बग दिखाई नहीं देता क्योंकि कंपाइलर बग्स सीधे-सरल सामान्य कोड परिदृश्यों का विश्लेषण करने में सक्षम नहीं होते हैं; बग अजीब कोड के विश्लेषण में हैं जो आप नहीं लिखते हैं।

मैं दूसरी तरफ विपरीत पर्यवेक्षक पूर्वाग्रह है। मैं हर दिन पूरे दिन पागल कोड देखता हूं, और इसलिए मुझे कंपाइलर कीड़े से भरा हुआ लगता है।

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

static void N(ref int x){}
...
N(ref 123);

कंपाइलर तीन त्रुटियां देता है।

एक रेफरी या आउट तर्क एक परिवर्तनीय चर होना चाहिए।
N (Ref int x) के लिए सर्वश्रेष्ठ मिलान में अमान्य तर्क हैं।
तर्क 1 पर "रेफ" गुम।

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

यह स्पष्ट नहीं है कि सही तीसरा त्रुटि संदेश क्या है, लेकिन यह नहीं है। वास्तव में, यह स्पष्ट नहीं है कि दूसरी त्रुटि संदेश सही है या नहीं। क्या ओवरलोड रिज़ॉल्यूशन विफल हो जाना चाहिए, या "रेफरी 123" को सही प्रकार के रेफरी तर्क के रूप में माना जाना चाहिए? मुझे अब इसे कुछ विचार देना होगा और इसे ट्राइएज टीम के साथ बात करनी होगी ताकि हम यह निर्धारित कर सकें कि सही व्यवहार क्या है।

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

— एरिक लिपर्ट को दर्शाता है
स्रोत

4

पहले एक के बाद अच्छे त्रुटि संदेश बहुत कठिन हैं।

निश्चित रूप से ऊर्जा को बेहतर तरीके से खर्च करना होगा ताकि कंपाइलरों को पूरी तरह से "मूर्ख"

— -प्रूफ बनाया जा सके

2

@MKO: बिल्कुल। कीड़े के बहुत सारे तय नहीं है। कभी-कभी फिक्स इतना महंगा होता है और परिदृश्य इतना अस्पष्ट होता है कि लागत लाभ द्वारा उचित नहीं होती है। और कभी-कभी पर्याप्त लोग "छोटी गाड़ी" व्यवहार पर भरोसा करने के लिए आए हैं जिसे आपको इसे बनाए रखना होगा।

— एरिक लिपर्ट

एमएमएम ... बग जो त्रुटि संदेशों में समाप्त होते हैं, वे "ठीक" हैं। यह हमेशा काम करने के लिए कोड को थोड़ा सा फेटना संभव है। उन बगों के बारे में जो संकलक स्रोत कोड को स्वीकार करते हैं और "गलत" assmebly आउटपुट का उत्पादन करते हैं। यह डरावना है

— जियानलुका घेटिनी

7

@ वैज: "स्पष्ट रूप से कानूनी सी # कोड" के अर्थ में सही है। उदाहरण के लिए, क्या आपने कभी एक इंटरफेस युक्त प्रोग्राम लिखा है जिसमें दो इंटरफेस विरासत में मिले हैं, जहां एक इंटरफेस में एक संपत्ति थी और दूसरे में संपत्ति के समान नाम का एक तरीका था? त्वरित, कल्पना को देखे बिना: क्या वह कानूनी है ? अब मान लीजिए कि आपके पास उस तरीके की कॉल है; क्या यह अस्पष्ट है ? और इसी तरह। लोग ऐसा कोड लिखते हैं जो हर समय उनका मतलब नहीं होता है। लेकिन केवल शायद ही कभी वे कोड लिखते हैं जहां आपको यह कहने के लिए एक विशेषज्ञ विशेषज्ञ होना चाहिए कि क्या यह कानूनी सी # भी है।

— एरिक लिपर्ट

51

क्या आप मेरे साथ मजाक कर रहे हैं? कंपाइलर्स में कीड़े होते हैं, वास्तव में लोड होते हैं।

GCC संभवतः ग्रह में खुले स्रोत संकलक के रूप में सबसे अधिक मनाया जाता है और इसके बग डेटाबेस पर एक नज़र डालें: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%bB%2B&resolution=-- -

GCC 3.2 और GCC 3.2.3 के बीच एक नज़र डालें कि कितने कीड़े ठीक हुए: http://gcc.gnu.org/gcc-3.2/changes.html

विजुअल C ++ जैसे अन्य लोगों के लिए, मैं भी शुरू नहीं करना चाहता।

आप संकलक को विश्वसनीय कैसे बनाते हैं? अच्छी तरह से एक शुरुआत के लिए उनके पास यूनिट परीक्षणों का भार और भार है। और पूरा ग्रह उनका उपयोग करता है इसलिए परीक्षकों की कोई कमी नहीं है।

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

— फैनटिक 23 का खुलासा हुआ
स्रोत

19

मैंने अपने दिन में दो या तीन का सामना किया है। एक का पता लगाने का एकमात्र वास्तविक तरीका विधानसभा कोड को देखना है।

यद्यपि अन्य पोस्टरों ने बताया है कि कम्पाइलर अत्यधिक विश्वसनीय हैं, इसलिए मुझे लगता है कि कंपाइलर विश्वसनीयता अक्सर एक आत्म-पूर्ण मूल्यांकन है। प्रोग्रामर कंपाइलर को मानक के रूप में देखते हैं। जब कुछ गलत होता है, तो आप अपनी गलती मानते हैं (क्योंकि समय का 99.999% है), और अपने कोड को संकलक समस्या के आसपास काम करने के लिए अन्य तरीकों के बजाय बदल दें। उदाहरण के लिए, एक उच्च अनुकूलन सेटिंग के तहत कोड दुर्घटनाग्रस्त होना निश्चित रूप से एक कंपाइलर बग है, लेकिन ज्यादातर लोग इसे थोड़ा कम सेट करते हैं और बग को रिपोर्ट किए बिना आगे बढ़ते हैं।

— कार्ल बेवफेल्ड
स्रोत

6

+1 "कंपाइलर को मानक के रूप में देखने के लिए।" मैंने लंबे समय तक बनाए रखा है कि दो चीजें हैं जो वास्तव में एक भाषा को परिभाषित करती हैं: संकलक और मानक पुस्तकालय। एक मानक दस्तावेज सिर्फ दस्तावेज है।

— मेसन व्हीलर

8

@ मेसन: यह एक कार्यान्वयन वाली भाषाओं के लिए अच्छा काम करता है। कई भाषाओं के लिए, मानक महत्वपूर्ण है। वास्तविक जीवन का प्रभाव यह है कि, यदि आप किसी चीज़ के बारे में शिकायत करते हैं, तो विक्रेता आपको गंभीरता से लेगा यदि यह एक मानक मुद्दा है, और यदि यह अपरिभाषित व्यवहार या ऐसा कुछ है तो आपको ब्रश कर देगा।

— डेविड थॉर्नले

2

@ मैसन - ऐसा केवल इसलिए है क्योंकि कुछ भाषाओं का मानक है और / जिनके लिए वे पालन करते हैं। किसी भी तरह के गंभीर विकास के लिए, btw, IMHO, यह अच्छी बात नहीं है - यह एक से अधिक ओएस पीढ़ी तक चलने की उम्मीद है।

— रूक

1

@ डेविड: या अधिक सटीक, एक प्रभावी कार्यान्वयन। बोरलैंड ने पास्कल को परिभाषित किया और माइक्रोसॉफ्ट ने C # को परिभाषित किया कि परवाह किए बिना ANSI और ECMA क्या कहते हैं।

— dan04

4

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

— फिल मिलर

14

कंपाइलर्स में कई गुण होते हैं जो उनकी शुद्धता की ओर ले जाते हैं:

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

— blueberryfields
स्रोत

2

इसके अलावा कई मामलों में कोड पुराना है, जीसीसी 20 साल से अधिक पुराना है, जैसा कि कई अन्य हैं, इसलिए बहुत सारे बग्स पर लंबे समय तक काम किया गया है।

— ज़ाचारी के

13

हम दैनिक आधार पर संकलक का उपयोग करते हैं

... और वे संकलक को इतना विश्वसनीय कैसे बनाते हैं?

वे नहीं करते। हम कर। क्योंकि हर कोई हर समय उनका उपयोग करता है, कीड़े जल्दी से पाए जाते हैं।

यह एक नंबर का खेल है। क्योंकि कंपाइलर्स का उपयोग बहुत ही व्यापक रूप से किया जाता है, यह बहुत अधिक संभावना है कि किसी भी बग को किसी के द्वारा ट्रिगर किया जाएगा , लेकिन क्योंकि उपयोगकर्ताओं की इतनी बड़ी संख्या है, यह अत्यधिक संभावना नहीं है कि कोई आप विशेष रूप से होगा।

तो, यह आपके दृष्टिकोण पर निर्भर करता है: सभी उपयोगकर्ताओं में, कंपाइलर छोटी गाड़ी हैं। लेकिन यह बहुत संभव है कि किसी और कोड की एक ऐसी ही टुकड़ा संकलित होगा है इससे पहले कि आप था, इसलिए अगर उनकी है था अपने से एक बग, यह उन्हें मारा गया होगा, नहीं आप ऐसा व्यक्ति , दृष्टि यह लग रहा है बग की तरह था वहां कभी नही।

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

— जोर्ग डब्ल्यू मित्तग
स्रोत

11

पहले से ही सभी उत्तरों के अलावा, मैं जोड़ना चाहूंगा:

मेरा मानना है कि कई बार, विक्रेता अपने कुत्ते का खाना खा रहे हैं। मतलब, वे अपने आप में कंपाइलर लिख रहे हैं।

— DevSolo
स्रोत

7

मैं अक्सर संकलक कीड़े में चला गया हूँ।

आप उन्हें गहरे कोनों में पा सकते हैं जहां कम परीक्षक हैं। उदाहरण के लिए, जीसीसी में कीड़े खोजने के लिए आपको प्रयास करना चाहिए:

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

— ज़ैन लिंक्स
स्रोत

हम IA64 (इटेनियम) के साथ बहुत सारी समस्याएं पाते हैं। हमारे पास उस प्लेटफ़ॉर्म के लिए बहुत अधिक ग्राहक नहीं हैं, इसलिए अनुकूलन स्तर को काटना हमारा सामान्य बगफिक्स है। यह अन्य उत्तरों के लिए वापस हो जाता है, लोकप्रिय आर्किटेक्चर के लिए लोकप्रिय भाषाओं के कंपाइलरों के पास आमतौर पर पर्याप्त उपयोगकर्ता प्रदर्शन और पर्याप्त समर्थन होने के लिए बहुत अच्छा होता है, लेकिन जैसा कि आप कम लोकप्रिय आर्किटेक्चर और / या भाषाओं में जाते हैं, आपको विश्वसनीयता की उम्मीद करनी चाहिए।

— ओमेगा सेंटॉरी

@ ओमेगा: ऑप्टिमाइज़ेशन वापस काटने से लगता है कि हर कोई क्या करता है। दुर्भाग्य से, इटेनियम को अच्छा प्रदर्शन करने के लिए उच्च-अनुकूलन वाले संकलक की आवश्यकता होती है । ओह ठीक है ...

— ज़ेन लिंक्स

मैं तुम्हें सुनता हूं। सच कहूं तो आर्किटेक्चर पहले से ही अप्रचलित था जब वह बाहर आया, सौभाग्य से एएमडी ने Int86 पर x86-64 के साथ हाथ मजबूर किया (जो इसके कई मौसा को बुरा नहीं लगता)। यदि आप अपने स्रोत फ़ाइलों को अलग कर सकते हैं तो आप समस्या को अलग करने में सक्षम हो सकते हैं और समस्या को हल कर सकते हैं। Thats हम क्या करते हैं अगर यह एक महत्वपूर्ण मंच है, लेकिन IA64 के लिए, नहीं।

— ओमेगा सेंटौरी

@ ओमेगा: दुर्भाग्य से, मैं वास्तव में इटेनियम को पसंद करता हूं। यह एक अद्भुत वास्तुकला है। मैं x86 और x86-64 को अप्रचलित मानता हूं लेकिन निश्चित रूप से वे कभी नहीं मरेंगे।

— ज़ैन लिंक्स

X86 थोड़ा अजीब है। वे इसमें नया सामान जोड़ते रहते हैं, इसलिए यह एक बार में एक मस्सा हो जाता है। लेकिन, ऑर्डर एक्ज़ीक्यूशन इंजन बहुत अच्छा काम करता है, और नया SSE => AVX सामान इसे कोड करने के इच्छुक लोगों के लिए कुछ वास्तविक क्षमता प्रदान करता है। माना जाता है कि अर्ध-अप्रचलित सामान को करने के लिए बहुत सारे ट्रांजिस्टर समर्पित हैं, लेकिन विरासत की अनुकूलता के लिए एक कीमत एक है।

— ओमेगा सेंटौरी

5

कई कारण:

संकलक लेखक " अपने कुत्ते का खाना खाते हैं "।
संकलक सीएस के अच्छी तरह से समझे गए सिद्धांतों पर आधारित हैं ।
कंपाइलर एक बहुत स्पष्ट कल्पना के लिए बनाए गए हैं ।
संकलनकर्ता पाने का परीक्षण किया ।
कंपाइलर हमेशा बहुत विश्वसनीय नहीं होते हैं ।

— Kramii
स्रोत

4

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

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

— ओमेगा सेंटौरी
स्रोत

4

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

— केविन क्लाइन
स्रोत

दुर्भाग्य से हम बग के दूसरे वर्ग को नहीं देख सकते हैं: कोड संकलन = सब कुछ ठीक है। तो शायद आधे बग (दो बग वर्गों के बीच 50-50 का विभाजन अनुपात मानते हुए) लोगों द्वारा नहीं पाए जाते हैं, लेकिन संकलक इकाई परीक्षणों के माध्यम से

— जियानलुका गेथिनी

3

हां, मुझे कल ही ASP.NET कंपाइलर में बग का सामना करना पड़ा:

जब आप दृश्‍य में दृढ़ता से टाइप किए गए मॉडल का उपयोग करते हैं तो कितने पैरामीटर टेम्पलेट हो सकते हैं, इसकी एक सीमा है। जाहिर है कि यह 4 से अधिक टेम्पलेट पैरामीटर नहीं ले सकता है, ताकि नीचे दिए गए दोनों उदाहरण संकलक को संभालने के लिए बहुत अधिक बनाते हैं:

ViewUserControl<System.Tuple<type1, type2, type3, type4, type5>>

के रूप में संकलित नहीं है, लेकिन अगर type5हटा दिया जाएगा।

ViewUserControl<System.Tuple<MyModel, System.Func<type1, type2, type3, type4>>>

type4निकाले जाने पर संकलित करेंगे ।

ध्यान दें कि System.Tupleकई अधिभार हैं और 16 पैरामीटर तक ले सकते हैं (यह पागल है मुझे पता है)।

— user8685
स्रोत

3

क्या आपको कभी कंपाइलर में बग का सामना करना पड़ा है? यह क्या था और आपको कंपाइलर में ही समस्या का एहसास कैसे हुआ?

हाँ!

दो सबसे यादगार पहले दो थे जिन्हें मैंने कभी पार किया। वे दोनों 1985-7 के लगभग 680x0 मैक के लिए लाइट्सपीड सी कंपाइलर में थे।

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

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

यह 68000 सीपीयू पर बहुत अच्छा काम करता है, लेकिन जब आप 68020 सीपीयू पर एक ही कोड चलाते हैं, तो यह अक्सर अजीब चीजें करता है। यह पता चला कि 68020 की एक नई विशेषता एक आदिम निर्देश 256-बाइट अनुदेश कैश था। सीपीयू कैश के साथ शुरुआती दिनों में, इसे कैश के "गंदा" होने और रिफिल होने की आवश्यकता की कोई धारणा नहीं थी; मुझे लगता है कि मोटोरोला में सीपीयू डिजाइनर स्व-संशोधित कोड के बारे में नहीं सोचते थे। इसलिए यदि आपने अपने निष्पादन अनुक्रम में एक साथ दो डिस्क संचालन को पर्याप्त रूप से बंद कर दिया है, और लाइट्सपीड रनटाइम ने स्टैक पर एक ही स्थान पर वास्तविक निर्देशों का निर्माण किया है, तो सीपीयू गलती से यह सोचेगा कि यह एक निर्देश कैश हिट था और पहले डिस्क ऑपरेशन को दो बार चलाएं।

फिर, पता लगा कि बाहर एक डिस्सेम्बलर के साथ कुछ खुदाई हुई, और एक कम-स्तर डिबगर में एकल-कदम। मेरा वर्कअराउंड प्रत्येक डिस्क ऑपरेशन को कॉल करने के लिए एक फ़ंक्शन के साथ उपसर्ग करना था जो 256 "एनओपी" निर्देश करता था, जो अनुदेश कैश को बाढ़ गया (और इस प्रकार साफ हो गया)।

तब से 25-ईश वर्षों में, मैंने समय के साथ कम और कम संकलक कीड़े देखे हैं। मुझे लगता है कि इसके कुछ कारण हैं:

संकलक के लिए सत्यापन परीक्षणों का एक लगातार बढ़ता हुआ सेट है।
आधुनिक कंपाइलरों को आमतौर पर दो या अधिक भागों में विभाजित किया जाता है, जिनमें से एक प्लेटफ़ॉर्म इंडिपेंडेंट कोड (जैसे LLVM का टारगेट जिसे आप एक काल्पनिक सीपीयू मानते हैं) उत्पन्न करते हैं, और दूसरा जो आपके वास्तविक लक्ष्य हार्डवेयर के लिए निर्देश में अनुवाद करता है। मल्टी-प्लेटफॉर्म कंपाइलरों में, पहले भाग का उपयोग हर जगह किया जाता है, इसलिए इसे वास्तविक-विश्व परीक्षण के कई टन मिलते हैं।

— बॉब मर्फी
स्रोत

स्व-संशोधित कोड से बचने के कारणों में से एक।

— टेक्नोफाइल

3

5.5 साल पहले टर्बो पास्कल में एक चमकदार त्रुटि मिली। संकलक के पिछले (5.0) और न ही अगले (6.0) संस्करण में मौजूद एक त्रुटि। और एक है कि यह परीक्षण करने के लिए आसान होना चाहिए था, क्योंकि यह बिल्कुल एक cornercase नहीं था (बस एक कॉल जो आमतौर पर उपयोग नहीं किया जाता है)।

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

— jwenting
स्रोत

2

जब -O0 और -O2 के साथ संकलित किए जाने पर आपके सॉफ़्टवेयर का व्यवहार भिन्न होता है, तो आपको एक कंपाइलर बग मिला है।

जब आपके सॉफ़्टवेयर का व्यवहार आपकी अपेक्षा से भिन्न होता है, तो संभावना है कि बग आपके कोड में है।

— mouviciel
स्रोत

8

जरुरी नहीं। C और C ++ में, अनिर्दिष्ट और अपरिभाषित व्यवहार की एक कष्टप्रद मात्रा है, और यह वैध रूप से चंद्रमा या डॉव जोन्स इंडेक्स के आंदोलन के चरण या चरण के आधार पर भिन्न हो सकते हैं। यह परीक्षण अधिक चुस्त परिभाषित भाषाओं में काम करता है।

— डेविड थॉर्नले

2

संकलक कीड़े होते हैं, लेकिन आप उन्हें विषम कोनों में ढूंढते हैं ...

1990 के दशक में डिजिटल उपकरण निगम VAX VMS C कंपाइलर में एक अजीब बग था

(मैं अपने बेल्ट पर एक प्याज पहने हुए था, जैसा कि उस समय फैशन था)

लूप के लिए पूर्ववर्ती अर्धविराम कहीं भी लूप के शरीर के रूप में संकलित किया जाएगा।

f(){...}
;
g(){...}

void test(){
  int i;
  for ( i=0; i < 10; i++){
     puts("hello");
  }
}

संकलक प्रश्न में, लूप केवल एक बार निष्पादित करता है।

यह देखता है

f(){...}
g(){...}

void test(){
  int i;
  for ( i=0; i < 10; i++) ;  /* empty statement for fun */

  {
     puts("hello");
  }
}

मुझे बहुत समय लगा।

पीआईसी सी कंपाइलर का पुराना संस्करण (जिसका इस्तेमाल) हम काम के अनुभव के लिए करते हैं, जो उच्च प्राथमिकता वाले व्यवधान को सही ढंग से इस्तेमाल करने वाले कोड को उत्पन्न नहीं कर सकता। आपको 2-3 साल इंतजार करना होगा और अपग्रेड करना होगा।

MSVC 6 कंपाइलर लिंकर में एक निफ्टी बग था, यह बिना किसी कारण के समय-समय पर खराबी और मर जाएगा। एक साफ निर्माण आम तौर पर यह तय है (लेकिन विलाप हमेशा नहीं)।

— टिम विलिसक्रॉफ्ट
स्रोत

2

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

— एक्सल
स्रोत

1

मैंने कई संकलक कीड़े देखे हैं, कुछ स्वयं (विशेष रूप से एफ # में) की सूचना दी।

उस ने कहा, मुझे लगता है कि कंपाइलर बग दुर्लभ हैं क्योंकि कंपाइलर लिखने वाले लोग आमतौर पर कंप्यूटर विज्ञान की कठोर अवधारणाओं के साथ बहुत सहज होते हैं जो उन्हें कोड के गणितीय प्रभावों के बारे में वास्तव में जागरूक करते हैं।

उनमें से अधिकांश संभवतः लंबोदर कलन, औपचारिक सत्यापन, संप्रदाय शब्दार्थ आदि जैसी चीजों से परिचित हैं - सामान जो मेरे जैसे एक औसत प्रोग्रामर केवल मुश्किल से समझ सकते हैं।

इसके अलावा, आमतौर पर कंपाइलरों में इनपुट से आउटपुट तक काफी सरल मैपिंग होती है, इसलिए एक प्रोग्रामिंग भाषा को डीबग करना शायद बहुत आसान है, कहते हैं, एक ब्लॉग इंजन।

— री मियाँका
स्रोत

1

मुझे C # कंपाइलर में एक बग बहुत पहले नहीं मिला, आप देख सकते हैं कि एरिक लिपर्ट (जो कि # डिजाइन टीम में हैं) ने यह पता लगा लिया कि बग यहां क्या था ।

पहले से दिए गए उत्तरों के अलावा, मैं कुछ और चीजें जोड़ना चाहूंगा। कंपाइलर डिजाइनर अक्सर बहुत अच्छे प्रोग्रामर होते हैं। कंपाइलर बहुत महत्वपूर्ण हैं: अधिकांश प्रोग्रामिंग कंपाइलर्स का उपयोग करके की जाती है, इसलिए यह अनिवार्य है कि कंपाइलर उच्च गुणवत्ता का हो। इसलिए यह कंपाइलर बनाने वाली कंपनियों के सर्वोत्तम हित में है कि वे अपने सबसे अच्छे लोगों को इस पर रखें (या कम से कम, बहुत अच्छे: सबसे अच्छे लोगों को कंपाइलर डिज़ाइन पसंद नहीं हो सकते हैं)। Microsoft अपने C और C ++ कंपाइलरों को ठीक से काम करने के लिए बहुत पसंद करेगा, या कंपनी के बाकी लोग अपना काम नहीं कर सकते।

इसके अलावा, यदि आप वास्तव में जटिल संकलक का निर्माण कर रहे हैं, तो आप इसे एक साथ हैक नहीं कर सकते। संकलक के पीछे तर्क अत्यधिक जटिल और औपचारिक रूप से आसान है। इसलिए, इन कार्यक्रमों को अक्सर एक बहुत ही 'मजबूत' और सामान्य तरीके से बनाया जाएगा, जिसके परिणामस्वरूप कम कीड़े होते हैं।

— एलेक्स दस कगार का पता चलता है
स्रोत