जीसीसी: प्रोग्राम संकलन विकल्प के साथ काम नहीं करता है- ओ 3

Question

मैं एक सी ++ प्रोग्राम लिख रहा हूं जो काम नहीं करता है (मुझे सेगमेंटेशन गलती मिलती है) जब मैं ऑप्टिमाइज़ेशन के साथ संकलित करता हूं (विकल्प-ओ 1, -ओ 2, -ओ 3 , इत्यादि), लेकिन जब मैं अनुकूलन के बिना इसे संकलित करता हूं तो यह ठीक काम करता है।

क्या कोई मौका है कि त्रुटि मेरे कोड में है? या मुझे लगता है कि यह जीसीसी में एक बग है?

मेरा जीसीसी संस्करण 3.4.6 है।

क्या इस तरह की समस्या के लिए कोई ज्ञात कामकाज है?

मेरे प्रोग्राम के अनुकूलित और अप्रत्याशित संस्करण के बीच गति में एक बड़ा अंतर है, इसलिए मुझे वास्तव में अनुकूलन का उपयोग करने की आवश्यकता है।

---

यह मेरा मूल मज़ेदार है। एक है कि अनुकूलन का कोई स्तर के साथ ठीक काम करता है और अनुकूलन के किसी भी स्तर के साथ एक विभाजन गलती फेंकता है:

struct distanceToPointSort{ 
    indexedDocument* point ; 
    distanceToPointSort(indexedDocument* p): point(p) {} 
    bool operator() (indexedDocument* p1,indexedDocument* p2){ 
     return distance(point,p1) < distance(point,p2) ; 
    } 
} ; 

और यह एक अनुकूलन के किसी भी स्तर के साथ दोषरहित काम करता है:

struct distanceToPointSort{ 
    indexedDocument* point ; 
    distanceToPointSort(indexedDocument* p): point(p) {} 
    bool operator() (indexedDocument* p1,indexedDocument* p2){ 

     float d1=distance(point,p1) ; 
     float d2=distance(point,p2) ; 

     std::cout << "" ; //without this line, I get a segmentation fault anyways 

     return d1 < d2 ; 
    } 
} ; 

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

Answer 1

अब आपने कोड खंड लिखा है और एक कामकाजी कामकाज पाया गया है (@ विन्डोज प्रोग्रामर का जवाब), मैं कह सकता हूं कि शायद आप जो खोज रहे हैं वह -ffloat-store है।

-ffloat-स्टोर

रजिस्टरों में चल बिन्दु चर की दुकान मत करो, और अन्य विकल्पों को बदल सकते हैं कि एक चल बिन्दु मूल्य एक रजिस्टर या स्मृति से लिया जाता है कि क्या रोकना।

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

स्रोत: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Optimize-Options.html

Answer 2

आप एक एलियासिंग समस्या में भाग ले रहे हैं (या यह एक लाख अन्य चीजें हो सकती है)। -फिक्ट-एलाइजिंग विकल्प देखें।

इस प्रकार का प्रश्न बिना किसी जानकारी के ठीक से जवाब देना असंभव है।

Answer 3

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

Answer 4

मुझे लगता है कि आपका कोड पहले गलत है।
हालांकि यह कहना मुश्किल है।

क्या आपका कोड 0 चेतावनियों के साथ संकलित करता है?

g++ -Wall -Wextra -pedantic -ansi 

Answer 5

यह लगभग (लगभग) कभी नहीं संकलक है।

सबसे पहले, सुनिश्चित करें कि आप चेतावनी मुक्त कर रहे हैं, साथ-साथ।

यदि इससे आपको "यूरेका" पल नहीं दिया गया है, तो अपने निष्पादन योग्य के कम से कम अनुकूलित संस्करण में एक डीबगर संलग्न करें जो क्रैश हो और देखें कि यह क्या कर रहा है और यह कहां जाता है।

5 आपको 10 मिलेगा कि आपने इस बिंदु से समस्या को ठीक कर दिया है।

Answer 6

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

Answer 7

वाह, मैं जवाब तो quicly उम्मीद नहीं थी, और इतने सारे ...

त्रुटि एसटीडी का उपयोग कर :: एक std :: संकेत के वेक्टर छँटाई प्रकार पर होता है()

मैं प्रदान करते हैं सख्त कमजोर आदेश देने वाले मज़ेदार।

लेकिन मुझे पता है कि जो मैं प्रदान करता हूं वह सही है क्योंकि मैंने इसे बहुत उपयोग किया है और यह ठीक काम करता है।

प्लस, त्रुटि वेक्टर में कुछ अमान्य सूचक नहीं हो सकती है क्योंकि जब मैं वेक्टर सॉर्ट करता हूं तो त्रुटि होती है। अगर मैं पहले std :: sort को लागू किए बिना वेक्टर के माध्यम से पुन: प्रयास करता हूं, तो प्रोग्राम ठीक काम करता है।

मैंने अभी यह पता लगाने के लिए जीडीबी का उपयोग किया है कि क्या हो रहा है। त्रुटि तब होती है जब std :: sort मेरे functor का आह्वान करता है। स्पष्ट रूप से std :: प्रकार मेरे मज़ेदार को एक अमान्य सूचक पास कर रहा है। (बेशक यह केवल अनुकूलित संस्करण के साथ होता है, ऑप्टिमाइज़ेशन के किसी भी स्तर -ओ, -ओ 2, -ओ 3)

Answer 8

मुझे कुछ टिप्पणियां पढ़ने के बाद यहां कुछ डाउनवॉट प्राप्त करने की उम्मीद है, लेकिन कंसोल गेम प्रोग्रामिंग दुनिया में, यह सामान्य ज्ञान है कि उच्च अनुकूलन स्तर कभी-कभी अजीब किनारे के मामलों में गलत कोड उत्पन्न कर सकते हैं। यह बहुत अच्छा हो सकता है कि किनारे के मामलों को कोड में सूक्ष्म परिवर्तनों के साथ ठीक किया जा सकता है।

Answer 9

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

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

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

Answer 10

यहाँ कुछ कोड लगता है कि काम करने के लिए है जब तक आप -O3 मारा ...

#include <stdio.h> 

int main() 
{ 
    int i = 0, j = 1, k = 2; 
    printf("%d %d %d\n", *(&j-1), *(&j), *(&j+1)); 
    return 0; 
} 

अनुकूलन के बिना

, मैं "2 1 0"; अनुकूलन के साथ मुझे "40 1 22 9 3680" मिलता है। क्यूं कर? क्योंकि मैं और के अनुकूलित हो गया!

लेकिन मैं जम्मू का पता ले रहा था और जे को आवंटित स्मृति क्षेत्र से बाहर जा रहा था। मानक द्वारा इसकी अनुमति नहीं है। यह सबसे अधिक संभावना है कि आपकी समस्या मानक से समान विचलन के कारण होती है।

मुझे लगता है कि valgrind अक्सर इस तरह के सहायक होते हैं।

संपादित करें: कुछ टिप्पणीकर्ता इस धारणा के तहत हैं कि मानक मनमाने ढंग से पॉइंटर अंकगणित की अनुमति देता है। यह नहीं करता है। याद रखें कि कुछ आर्किटेक्चर में मजाकिया एड्रेसिंग स्कीम हैं, संरेखण महत्वपूर्ण हो सकता है, और अगर आप कुछ रजिस्टरों को ओवरफ्लो करते हैं तो आपको समस्याएं मिल सकती हैं!

[ड्राफ़्ट] मानक के शब्दों

बताया/एक सूचक से/एक पूर्णांक घटाकर पर (जोर जोड़ा):

"अगर दोनों सूचक संकार्य और एक ही सरणी वस्तु के तत्वों के परिणाम बिंदु , या सरणी वस्तु के अंतिम तत्व के बाद एक, मूल्यांकन एक अतिप्रवाह प्रस्तुत करेगा नहीं, अन्यथा, व्यवहार अपरिभाषित है "

देखकर रूप & j भी एक सरणी वस्तु को इंगित नहीं करता है। & जे -1 और & जे + 1 शायद ही कभी भाग ओ को इंगित कर सकता है एक ही सरणी वस्तु एफ। तो बस & जे + 1 का मूल्यांकन करना (अकेले इसे संदर्भित करना) अनिश्चित व्यवहार है।

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

Answer 11

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

Answer 12

जैसा कि अद्यतन प्रश्न दिखाएगा;), समस्या std::vector<T*> के साथ मौजूद है। वैक्टरों के साथ एक आम त्रुटि आरक्षित() है जो आकार बदलनी चाहिए() डी। नतीजतन, आप सरणी सीमाओं के बाहर लिख रहे होंगे। एक अनुकूलक उन लिखने को त्याग सकता है।

Answer 13

ठीक है ... यह मेरी सबसे अजीब समस्याओं में से एक है।
मुझे नहीं लगता कि मेरे पास यह प्रमाण है कि यह एक जीसीसी बग है, लेकिन ईमानदारी से ... यह वास्तव में एक जैसा दिखता है।

यह मेरा मूल मज़ेदार है। एक है कि अनुकूलन का कोई स्तर के साथ ठीक काम करता है और अनुकूलन के किसी भी स्तर के साथ एक विभाजन गलती फेंकता है:

struct distanceToPointSort{ 
    indexedDocument* point ; 
    distanceToPointSort(indexedDocument* p): point(p) {} 
    bool operator() (indexedDocument* p1,indexedDocument* p2){ 
     return distance(point,p1) < distance(point,p2) ; 
    } 
} ; 

और यह एक अनुकूलन के किसी भी स्तर के साथ दोषरहित काम करता है:

struct distanceToPointSort{ 
    indexedDocument* point ; 
    distanceToPointSort(indexedDocument* p): point(p) {} 
    bool operator() (indexedDocument* p1,indexedDocument* p2){ 

     float d1=distance(point,p1) ; 
     float d2=distance(point,p2) ; 

     std::cout << "" ; //without this line, I get a segmentation fault anyways 

     return d1 < d2 ; 
    } 
} ; 

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

Answer 14

एक प्रयोग के रूप में, यह देखने का प्रयास करें कि क्या यह संकलक को लगातार सबकुछ घूमने के लिए मजबूर करेगा।

volatile float d1=distance(point,p1) ; 
volatile float d2=distance(point,p2) ; 
return d1 < d2 ; 

Answer 15

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

Answer 16

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

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

मैं -ffloat-store पर सबसे अच्छा समाधान (पहले से ही सीज़रबी द्वारा सुझाया गया) मानता हूं।