ฉันจะสร้างลูปที่ไม่มีที่สิ้นสุดที่ไม่ได้รับการปรับให้เหมาะสมได้อย่างไร

มาตรฐาน C11 ดูเหมือนจะบ่งบอกว่างบการวนซ้ำที่มีการควบคุมการแสดงออกอย่างต่อเนื่องไม่ควรปรับให้เหมาะสม ฉันรับคำแนะนำจากคำตอบนี้ซึ่งอ้างอิงส่วน 6.8.5 จากร่างมาตรฐานโดยเฉพาะ:

คำสั่งวนซ้ำซึ่งนิพจน์การควบคุมไม่ใช่นิพจน์คงที่ ... อาจถูกสันนิษฐานโดยการนำไปใช้เพื่อยุติ

ในคำตอบนั้นระบุว่าการวนซ้ำเช่นwhile(1) ;นั้นไม่ควรมีการปรับให้เหมาะสม

ดังนั้น ... ทำไม Clang / LLVM เพิ่มประสิทธิภาพลูปด้านล่าง (รวบรวมด้วยcc -O2 -std=c11 test.c -o test)?

#include <stdio.h>

static void die() {
    while(1)
        ;
}

int main() {
    printf("begin\n");
    die();
    printf("unreachable\n");
}

บนเครื่องของฉันสิ่งนี้จะพิมพ์ออกมาbeginและเกิดปัญหากับคำสั่งที่ผิดกฎหมาย ( ud2กับดักวางไว้die()) เมื่อวันที่ godboltputsเราจะเห็นว่าไม่มีอะไรที่จะถูกสร้างขึ้นหลังจากการเรียกร้องให้

มันเป็นงานที่ยากอย่างน่าประหลาดใจที่ทำให้ Clang แสดงผลวนลูปไม่สิ้นสุดภายใต้-O2- ในขณะที่ฉันสามารถทดสอบvolatileตัวแปรซ้ำได้ซึ่งเกี่ยวข้องกับการอ่านหน่วยความจำที่ฉันไม่ต้องการ และถ้าฉันทำอะไรแบบนี้:

#include <stdio.h>

static void die() {
    while(1)
        ;
}

int main() {
    printf("begin\n");
    volatile int x = 1;
    if(x)
        die();
    printf("unreachable\n");
}

... เสียงดังกราวพิมพ์beginตามด้วยunreachableราวกับว่าวงวนไม่สิ้นสุด

คุณจะทำให้ Clang ส่งออกลูปไม่สิ้นสุดที่ไม่ต้องเข้าถึงหน่วยความจำได้อย่างเหมาะสมโดยเปิดการปรับให้เหมาะสมได้อย่างไร

มาตรฐาน C11 บอกสิ่งนี้ 6.8.5 / 6:

คำสั่งการวนซ้ำซึ่งนิพจน์การควบคุมไม่ใช่นิพจน์คงที่¹⁵⁶⁾ที่ไม่มีการดำเนินการอินพุต / เอาท์พุตไม่สามารถเข้าถึงวัตถุที่ระเหยได้และไม่ทำการซิงโครไนซ์หรือการดำเนินการอะตอมมิกในร่างกายการควบคุมนิพจน์หรือ (ในกรณี คำสั่ง) expression-3 อาจถูกสันนิษฐานโดยการนำไปใช้เพื่อยกเลิก ¹⁵⁷⁾

บันทึกย่อแบบสองเท้าไม่ได้เป็นบรรทัดฐาน แต่ให้ข้อมูลที่เป็นประโยชน์:

156) นิพจน์ควบคุมที่ถูกละเว้นถูกแทนที่ด้วยค่าคงที่ที่ไม่ใช่ศูนย์ซึ่งเป็นนิพจน์ค่าคงที่

157) สิ่งนี้มีวัตถุประสงค์เพื่อให้การแปลงคอมไพเลอร์เช่นการลบลูปที่ว่างเปล่าแม้ว่าจะไม่สามารถพิสูจน์ได้ว่าการเลิกจ้าง

ในกรณีของคุณwhile(1)เป็นนิพจน์คงที่ใสดังนั้นอาจไม่สามารถสันนิษฐานโดยการนำไปใช้เพื่อยุติ การดำเนินการดังกล่าวจะถูกทำลายอย่างสิ้นหวังเนื่องจากลูป "ตลอดกาล" เป็นโครงสร้างโปรแกรมทั่วไป

จะเกิดอะไรขึ้นกับ "โค้ดที่ไม่สามารถเข้าถึงได้" หลังจากลูปเป็นสิ่งที่ฉันรู้ว่าไม่ได้กำหนดไว้อย่างดี อย่างไรก็ตามเสียงดังกราวทำหน้าที่แปลกมาก เปรียบเทียบรหัสเครื่องกับ gcc (x86):

gcc 9.2 -O3 -std=c11 -pedantic-errors

.LC0:
        .string "begin"
main:
        sub     rsp, 8
        mov     edi, OFFSET FLAT:.LC0
        call    puts
.L2:
        jmp     .L2

เสียงดังกราว 9.0.0 -O3 -std=c11 -pedantic-errors

main:                                   # @main
        push    rax
        mov     edi, offset .Lstr
        call    puts
.Lstr:
        .asciz  "begin"

gcc สร้างลูปเสียงดังกราวเพียงวิ่งเข้าไปในป่าและออกด้วยข้อผิดพลาด 255

ฉันเอนตัวไปทางนี้เป็นพฤติกรรมที่ไม่สอดคล้องของเสียงดังกราว เพราะฉันพยายามที่จะขยายตัวอย่างของคุณเพิ่มเติมเช่นนี้:

#include <stdio.h>
#include <setjmp.h>

static _Noreturn void die() {
    while(1)
        ;
}

int main(void) {
    jmp_buf buf;
    _Bool first = !setjmp(buf);

    printf("begin\n");
    if(first)
    {
      die();
      longjmp(buf, 1);
    }
    printf("unreachable\n");
}

ฉันเพิ่ม C11 _Noreturnในความพยายามที่จะช่วยให้คอมไพเลอร์เพิ่มเติมพร้อม ควรชัดเจนว่าฟังก์ชั่นนี้จะวางสายจากคำหลักนั้นเพียงอย่างเดียว

setjmpจะคืนค่า 0 เมื่อดำเนินการครั้งแรกดังนั้นโปรแกรมนี้ควรชนไปwhile(1)และหยุดอยู่ที่นั่นเพียงพิมพ์ "เริ่มต้น" (สมมติว่า \ n ล้างข้อมูล stdout) สิ่งนี้เกิดขึ้นกับ gcc

หากการวนซ้ำถูกลบออกไปก็ควรพิมพ์ "เริ่มต้น" 2 ครั้งจากนั้นพิมพ์ "ไม่สามารถเข้าถึงได้" อย่างไรก็ตามในเสียงดังกราว ( godbolt ) มันพิมพ์ "เริ่มต้น" 1 ครั้งแล้ว "ไม่สามารถเข้าถึงได้" ก่อนที่จะส่งคืนรหัสทางออก 0 นั่นเป็นความผิดปกติธรรมดาไม่ว่าคุณจะใส่มันอย่างไร

ฉันไม่พบกรณีที่อ้างว่ามีพฤติกรรมที่ไม่ได้กำหนดไว้ที่นี่ดังนั้นสิ่งที่ฉันใช้คือว่านี่เป็นข้อผิดพลาดในเสียงดังกราว พฤติกรรมนี้ทำให้เสียงดังกราว 100% ไร้ประโยชน์สำหรับโปรแกรมเช่นระบบฝังตัวซึ่งคุณจะต้องพึ่งพาลูปนิรันดร์ที่แขวนโปรแกรมไว้ (ในขณะที่รอคอยสุนัขเฝ้าบ้าน ฯลฯ )

คุณต้องใส่นิพจน์ที่อาจทำให้เกิดผลข้างเคียง

ทางออกที่ง่ายที่สุด:

static void die() {
    while(1)
       __asm("");
}

ลิงค์ Godbolt

คำตอบอื่น ๆ ที่กล่าวถึงวิธีที่ทำให้ Clang ปล่อยวงวนไม่สิ้นสุดด้วยภาษาแอสเซมบลีแบบอินไลน์หรือผลข้างเคียงอื่น ๆ ฉันแค่ต้องการยืนยันว่านี่เป็นข้อผิดพลาดคอมไพเลอร์ โดยเฉพาะมันเป็นข้อผิดพลาด LLVM ที่ยาวนานมานาน - ใช้แนวคิด C ++ ของ "ลูปทั้งหมดที่ไม่มีผลข้างเคียงต้องยุติ" กับภาษาที่ไม่ควรเช่น C

ตัวอย่างเช่นภาษาโปรแกรมมิง Rustยังอนุญาตให้วนซ้ำไม่สิ้นสุดและใช้ LLVM เป็นแบ็คเอนด์และมีปัญหาเดียวกันนี้

ในระยะสั้นปรากฏว่า LLVM จะยังคงสมมติว่า "ลูปทั้งหมดที่ไม่มีผลข้างเคียงต้องยุติ" สำหรับภาษาใด ๆ ที่อนุญาตให้llvm.sideeffectวนซ้ำไม่สิ้นสุด LLVM คาดว่าส่วนหน้าเพื่อแทรกopcode ลงในลูปดังกล่าว นี่คือสิ่งที่ Rust กำลังวางแผนที่จะทำดังนั้นเสียงดังกราว (เมื่อรวบรวมรหัส C) อาจจะต้องทำเช่นนั้นด้วย

นี่คือข้อผิดพลาดของเสียงดังกราว

... เมื่ออินไลน์ฟังก์ชันที่มีการวนซ้ำไม่สิ้นสุด พฤติกรรมจะแตกต่างกันเมื่อwhile(1);ปรากฏในหลักโดยตรงซึ่งมีกลิ่นมากสำหรับฉัน

ดูคำตอบของสรุปและลิงก์ของ @ Arnavion ส่วนที่เหลือของคำตอบนี้ถูกเขียนขึ้นก่อนที่ฉันจะยืนยันว่ามันเป็นข้อผิดพลาด

ในการตอบคำถามชื่อ: ฉันจะทำให้วนที่ไม่มีที่สิ้นสุดที่จะไม่ได้รับการเพิ่มประสิทธิภาพได้อย่างไร ? -
สร้างdie()แมโครไม่ใช่ฟังก์ชันเพื่อแก้ไขข้อบกพร่องนี้ใน Clang 3.9 และใหม่กว่า (รุ่นก่อนหน้านี้อย่างใดอย่างหนึ่งดังกราวช่วยให้วงหรือส่งเสียงcallไปยังรุ่นที่ไม่ใช่แบบอินไลน์ของฟังก์ชั่นที่มีห่วงอนันต์.) ที่ปรากฏจะปลอดภัยแม้ว่าprint;while(1);print;inlines ฟังก์ชั่นเข้ามาของผู้โทร ( Godbolt ) -std=gnu11vs. -std=gnu99ไม่เปลี่ยนแปลงอะไรเลย

หากคุณสนใจ GNU C เพียงอย่างเดียวP__J ____asm__("");ในวงก็สามารถใช้ได้เช่นกันและไม่ควรทำให้โค้ดที่ล้อมรอบเหมาะสมสำหรับคอมไพเลอร์ใด ๆ ที่เข้าใจ คำสั่ง asm GNU C Basic นั้นมีความหมายโดยนัยvolatileดังนั้นสิ่งนี้จึงนับเป็นผลข้างเคียงที่มองเห็นได้ซึ่งต้อง "เรียกใช้" หลาย ๆ ครั้งตามที่มันเป็นในเครื่องนามธรรม C (และใช่เสียงดังกร่างใช้ภาษา GNU ของ C ตามที่จัดทำโดยคู่มือ GCC)

บางคนแย้งว่ามันอาจถูกกฎหมายเพื่อเพิ่มประสิทธิภาพการวนซ้ำที่ไม่มีที่สิ้นสุด ผมไม่เห็นด้วย¹แต่แม้ว่าเรายอมรับว่ามันไม่สามารถนอกจากนี้ยังจะมีกฎหมายสำหรับเสียงดังกราวที่จะสรุปงบหลังจากที่วงจะไม่สามารถเข้าถึงและให้การดำเนินการในฤดูใบไม้ร่วงปิดท้ายของฟังก์ชั่นในการทำงานต่อไปหรือลงในถังขยะ ที่ถอดรหัสเป็นคำแนะนำแบบสุ่ม

(นั่นจะเป็นไปตามมาตรฐานสำหรับ Clang ++ (แต่ยังไม่มีประโยชน์มาก); ลูปที่ไม่มีที่สิ้นสุดโดยไม่มีผลข้างเคียงใด ๆ คือ UB ใน C ++ แต่ไม่ใช่ C
คือขณะที่ (1) พฤติกรรมที่ไม่ได้กำหนดใน C? UB ทำให้คอมไพเลอร์ปล่อย สำหรับโค้ดบนเส้นทางของการดำเนินการที่จะพบ UB แน่นอนasmคำสั่งในลูปจะหลีกเลี่ยง UB นี้สำหรับ C ++ แต่ในทางปฏิบัติ Clang การคอมไพล์เป็น C ++ จะไม่ลบลูปที่ไม่มีที่สิ้นสุดของนิพจน์ยกเว้นเมื่ออินไลน์เหมือนกับ รวบรวมเป็น C. )

การแทรกแบบอินไลน์ด้วยตนเองwhile(1);เปลี่ยนวิธีการรวบรวมเสียงดังกังวาน: วงวนไม่สิ้นสุดแสดงเป็น asm นี่คือสิ่งที่เราคาดหวังจาก POV นักกฎหมาย

#include <stdio.h>
int main() {
    printf("begin\n");
    while(1);
    //infloop_nonconst(1);
    //infloop();
    printf("unreachable\n");
}

บนตัวรวบรวมคอมไพเลอร์ Godbolt Clang 9.0 -O3 คอมไพล์เป็น C ( -xc) สำหรับ x86-64:

main:                                   # @main
        push    rax                       # re-align the stack by 16
        mov     edi, offset .Lstr         # non-PIE executable can use 32-bit absolute addresses
        call    puts
.LBB3_1:                                # =>This Inner Loop Header: Depth=1
        jmp     .LBB3_1                   # infinite loop


.section .rodata
 ...
.Lstr:
        .asciz  "begin"

คอมไพเลอร์เดียวกันที่มีตัวเลือกเดียวกันจะคอมไพล์ a mainที่เรียกinfloop() { while(1); }ไปยังอันดับแรกputsแต่จากนั้นก็หยุดการเปล่งคำสั่งmainหลังจากนั้น ดังนั้นอย่างที่ฉันได้กล่าวไว้การประมวลผลจะตกจากจุดสิ้นสุดของฟังก์ชั่นไปยังฟังก์ชันใด ๆ ก็ตามที่อยู่ถัดไป (แต่ด้วยสแต็กที่ไม่ถูกต้องสำหรับรายการฟังก์ชันดังนั้นมันจึงไม่ใช่ tailcall ที่ใช้ได้)

ตัวเลือกที่ถูกต้องจะเป็น

• ปล่อยlabel: jmp labelลูปไม่สิ้นสุด
• หรือ (ถ้าเรายอมรับว่าสามารถลบลูปไม่สิ้นสุด) ปล่อยสายอื่นเพื่อพิมพ์สตริงที่ 2 และreturn 0จากmainนั้น

การหยุดทำงานหรือดำเนินการต่อโดยไม่พิมพ์ "ไม่สามารถเข้าถึง" นั้นไม่ชัดเจนสำหรับการใช้งาน C11 เว้นแต่ว่ามี UB ที่ฉันไม่ได้สังเกตเห็น

เชิงอรรถ 1:

สำหรับบันทึกฉันเห็นด้วยกับคำตอบของ @ Lundin ซึ่งอ้างอิงมาตรฐานสำหรับหลักฐานว่า C11 ไม่อนุญาตให้มีการยุติการวนซ้ำแบบไม่ จำกัด แม้ในขณะที่ว่างเปล่า (ไม่มี I / O, ระเหย, การซิงโครไนซ์หรืออื่น ๆ ผลข้างเคียงที่มองเห็นได้)

นี่เป็นชุดของเงื่อนไขที่จะอนุญาตให้รวบรวมลูปเป็นลูป asm ที่ว่างเปล่าสำหรับ CPU ปกติ (แม้ว่าเนื้อความจะไม่ว่างเปล่าในแหล่งที่มาการมอบหมายให้ตัวแปรไม่สามารถมองเห็นได้ในเธรดหรือตัวจัดการสัญญาณอื่นที่ไม่มี data-race UB ในขณะที่ลูปทำงานอยู่ดังนั้นการดำเนินการตามมาตรฐานจึงสามารถลบลูปเนื้อความดังกล่าวได้ถ้าต้องการ เป็นแล้วจากนั้นคำถามจะบอกว่าสามารถลบลูปเองได้หรือไม่ ISO C11 บอกว่าไม่ชัดเจน)

เนื่องจาก C11 แยกออกมาเป็นกรณีที่การใช้งานไม่สามารถถือว่าการวนซ้ำสิ้นสุดลง (และไม่ใช่ UB) ดูเหมือนว่าพวกเขาตั้งใจที่จะนำเสนอการวนรอบในเวลาทำงาน การนำไปใช้งานที่กำหนดเป้าหมาย CPUs ด้วยโมเดลการดำเนินการที่ไม่สามารถทำงานได้อย่างไม่มีขีด จำกัด ในเวลาที่ จำกัด นั้นไม่มีเหตุผลที่จะลบลูปอนันต์คงที่ว่างเปล่า หรือโดยทั่วไปแล้วถ้อยคำที่แน่นอนนั้นเกี่ยวกับว่าพวกเขาสามารถ "สันนิษฐานว่าจะยุติ" หรือไม่ หากลูปไม่สามารถยุติได้นั่นหมายความว่าโค้ดในภายหลังนั้นไม่สามารถเข้าถึงได้ไม่ว่าคุณจะโต้แย้งอะไรเกี่ยวกับคณิตศาสตร์และอินฟินิตี้และต้องใช้เวลานานเท่าใดในการทำงานจำนวนมหาศาลบนเครื่องจักรสมมุติ

นอกจากนั้นเสียงดังกังวานไม่เพียง แต่เป็น DeathStation 9000 ที่เป็นไปตามมาตรฐาน ISO C เท่านั้น แต่ตั้งใจให้เป็นประโยชน์สำหรับการเขียนโปรแกรมระบบระดับต่ำในโลกแห่งความเป็นจริงรวมถึงเมล็ดและสิ่งฝังตัว ดังนั้นไม่ว่าหรือไม่คุณยอมรับข้อโต้แย้งเกี่ยวกับ C11 ที่ช่วยให้การกำจัดของwhile(1);มันไม่ได้ทำให้รู้สึกว่าเสียงดังกราวอยากจะทำจริงว่า ถ้าคุณเขียนwhile(1);นั่นอาจไม่ใช่อุบัติเหตุ การกำจัดลูปที่สิ้นสุดโดยไม่ตั้งใจโดยอุบัติเหตุ (ด้วยนิพจน์ตัวแปรควบคุมรันไทม์) อาจเป็นประโยชน์และมันก็สมเหตุสมผลสำหรับคอมไพเลอร์ในการทำเช่นนั้น

เป็นเรื่องยากที่คุณจะต้องหมุนจนกว่าจะมีการขัดจังหวะครั้งต่อไป แต่ถ้าคุณเขียนลงใน C นั่นคือสิ่งที่คุณคาดหวัง (และจะเกิดอะไรขึ้นใน GCC และ Clang ยกเว้น Clang เมื่อวงวนไม่สิ้นสุดอยู่ในฟังก์ชัน wrapper)

ตัวอย่างเช่นในเคอร์เนลระบบปฏิบัติการดั้งเดิมเมื่อตัวกำหนดตารางเวลาไม่มีภารกิจในการรันมันอาจรันภารกิจว่าง while(1);การดำเนินแรกของการที่อาจจะมี

หรือสำหรับฮาร์ดแวร์ที่ไม่มีคุณสมบัติการประหยัดพลังงานซึ่งอาจเป็นการใช้งานเพียงอย่างเดียว (จนถึงต้นยุค 2000 นั่นคือฉันคิดว่าไม่หายากใน x86 แม้ว่าhltคำสั่งจะมีอยู่จริง IDK ถ้ามันช่วยประหยัดพลังงานได้อย่างมีความหมายจนกระทั่ง CPU เริ่มมีสถานะไม่ใช้พลังงานต่ำ)

เพียงเพื่อบันทึกเสียงดังกราวก็ซุกซนกับgoto:

static void die() {
nasty:
    goto nasty;
}

int main() {
    int x; printf("begin\n");
    die();
    printf("unreachable\n");
}

มันก่อให้เกิดผลลัพธ์เช่นเดียวกับในคำถามคือ:

main: # @main
  push rax
  mov edi, offset .Lstr
  call puts
.Lstr:
  .asciz "begin"

ฉันเห็นไม่เห็นวิธีใด ๆ ในการอ่านตามที่ได้รับอนุญาตใน C11 ซึ่งพูดเพียง:

6.8.6.1 (2) gotoคำสั่งทำให้การข้ามแบบไม่มีเงื่อนไขไปยังคำสั่งนำหน้าด้วยเลเบลที่ระบุชื่อในฟังก์ชันล้อมรอบ

เช่น gotoไม่ได้เป็น "คำสั่งซ้ำ" (6.8.5 รายการwhile, doและfor) ไม่มีอะไรพิเศษเกี่ยวกับ "การเลิกจ้าง-สันนิษฐานว่า" หวานหูนำไปใช้ แต่คุณต้องการที่จะอ่านพวกเขา

ต่อคอมไพเลอร์ลิงก์คำถามของ Godbolt คือ x86-64 Clang 9.0.0 และแฟล็กคือ -g -o output.s -mllvm --x86-asm-syntax=intel -S --gcc-toolchain=/opt/compiler-explorer/gcc-9.2.0 -fcolor-diagnostics -fno-crash-diagnostics -O2 -std=c11 example.c

กับคนอื่น ๆ เช่น x86-64 GCC 9.2 คุณจะได้รับความสมบูรณ์แบบ:

.LC0:
  .string "begin"
main:
  sub rsp, 8
  mov edi, OFFSET FLAT:.LC0
  call puts
.L2:
  jmp .L2

ธง: -g -o output.s -masm=intel -S -fdiagnostics-color=always -O2 -std=c11 example.c

ฉันจะเล่นทนายของปีศาจและยืนยันว่ามาตรฐานไม่ได้ห้ามนักแปลอย่างชัดเจนจากการหาวงที่ไม่สิ้นสุด

คำสั่งวนซ้ำที่นิพจน์การควบคุมไม่ใช่นิพจน์คงที่ 156) ที่ไม่มีการดำเนินการอินพุต / เอาท์พุตไม่สามารถเข้าถึงวัตถุที่ระเหยได้และไม่ทำการซิงโครไนซ์หรือการดำเนินการอะตอมมิกในร่างกายการควบคุมนิพจน์หรือ (ในกรณีของ คำสั่ง) expression-3 ของมันอาจถูกสันนิษฐานโดยการนำไปใช้เพื่อยุติการใช้ 158)

ลองแยกวิเคราะห์กัน คำสั่งการทำซ้ำที่ตรงกับเกณฑ์บางอย่างอาจถูกสมมติให้ยุติ:

if (satisfiesCriteriaForTerminatingEh(a_loop)) 
    if (whatever_reason_or_just_because_you_feel_like_it)
         assumeTerminates(a_loop);

สิ่งนี้ไม่ได้พูดอะไรเกี่ยวกับสิ่งที่เกิดขึ้นหากเกณฑ์ไม่เป็นที่พอใจและสมมติว่าลูปอาจยุติแม้จะไม่ถูกห้ามอย่างชัดเจนตราบใดที่มีการปฏิบัติตามกฎอื่น ๆ ของมาตรฐาน

do { } while(0) หรือ while(0){}ตามหลังคำสั่งวนซ้ำทั้งหมด (ลูป) ที่ไม่เป็นไปตามเกณฑ์ที่อนุญาตให้คอมไพเลอร์เพิ่งสันนิษฐานในสิ่งที่พวกเขายุติและยังเห็นได้ชัดว่าพวกเขาจะยุติ

แต่คอมไพเลอร์สามารถเพิ่มประสิทธิภาพได้while(1){}หรือไม่

5.1.2.3p4พูดว่า:

ในเครื่องนามธรรมการแสดงออกทั้งหมดจะถูกประเมินตามที่กำหนดโดยความหมาย การนำไปปฏิบัติจริงไม่จำเป็นต้องประเมินส่วนหนึ่งของนิพจน์หากสามารถอนุมานได้ว่าไม่ได้ใช้ค่านั้นและไม่สร้างผลข้างเคียงที่จำเป็น (รวมถึงสิ่งใดก็ตามที่เกิดจากการเรียกใช้ฟังก์ชันหรือเข้าถึงวัตถุระเหย)

สิ่งนี้กล่าวถึงการแสดงออกไม่ใช่ข้อความดังนั้นจึงไม่ใช่เรื่องน่าเชื่อ 100% แต่แน่นอนว่าสามารถเรียกได้เช่น:

void loop(void){ loop(); }

int main()
{
    loop();
}

ที่จะข้ามไป ที่น่าสนใจเสียงดังกราวไม่ข้ามมันและ GCC ไม่

ฉันเชื่อว่านี่เป็นเพียงข้อผิดพลาดเก่า ๆ ฉันออกจากการทดสอบด้านล่างและโดยเฉพาะอย่างยิ่งการอ้างอิงถึงการอภิปรายในคณะกรรมการมาตรฐานสำหรับเหตุผลบางอย่างที่ฉันมีก่อนหน้านี้

ฉันคิดว่านี่เป็นพฤติกรรมที่ไม่ได้กำหนด (ดูที่สิ้นสุด) และเสียงดังกราวมีเพียงการใช้งานเพียงครั้งเดียว GCC ใช้งานได้ตามที่คุณคาดหวังโดยปรับให้เหมาะสมกับunreachableคำสั่งการพิมพ์เท่านั้น บางวิธีที่เสียงดังกังวานตัดสินใจอย่างผิดปกติเมื่อรวมการเรียงแถวเข้าด้วยกันและกำหนดว่าจะทำอย่างไรกับลูป

พฤติกรรมนั้นแปลกมาก - มันลบการพิมพ์ขั้นสุดท้ายดังนั้น "เห็น" ลูปที่ไม่มีที่สิ้นสุด แต่จากนั้นก็กำจัดลูปด้วยเช่นกัน

มันแย่ยิ่งกว่าที่ฉันบอกได้ การลบอินไลน์ที่เราได้รับ:

die: # @die
.LBB0_1: # =>This Inner Loop Header: Depth=1
  jmp .LBB0_1
main: # @main
  push rax
  mov edi, offset .Lstr
  call puts
.Lstr:
  .asciz "begin"

ดังนั้นฟังก์ชั่นจึงถูกสร้างขึ้นและการโทรออกจะปรับให้เหมาะสม นี่คือความยืดหยุ่นที่มากกว่าที่คาดไว้:

#include <stdio.h>

void die(int x) {
    while(x);
}

int main() {
    printf("begin\n");
    die(1);
    printf("unreachable\n");
}

ส่งผลให้เกิดการชุมนุมที่ไม่เหมาะสมที่สุดสำหรับฟังก์ชั่น แต่การเรียกใช้ฟังก์ชั่นจะได้รับการปรับให้เหมาะสมอีกครั้ง! ยิ่งเลวร้ายลง:

void die(x) {
    while(x++);
}

int main() {
    printf("begin\n");
    die(1);
    printf("unreachable\n");
}

ฉันทำการทดสอบอื่น ๆ ด้วยการเพิ่มตัวแปรท้องถิ่นและเพิ่มขึ้นผ่านตัวชี้การใช้gotoฯลฯ ... ณ จุดนี้ฉันจะยอมแพ้ หากคุณต้องใช้เสียงดังกราว

static void die() {
    int volatile x = 1;
    while(x);
}

ทำงาน มันดูดที่เพิ่มประสิทธิภาพ (ชัด) printfและใบในรอบสุดท้ายที่ซ้ำซ้อน อย่างน้อยโปรแกรมก็ไม่หยุด อาจ GCC หลังจากทั้งหมดหรือไม่

ภาคผนวก

หลังจากการสนทนากับ David ฉันขอให้มาตรฐานไม่ได้พูดว่า "ถ้าเงื่อนไขคงที่คุณอาจไม่ถือว่าลูปสิ้นสุด" ดังนั้นและภายใต้มาตรฐานไม่มีพฤติกรรมที่สังเกตได้ (ตามที่กำหนดไว้ในมาตรฐาน) ฉันจะเถียงเพียงเพื่อความมั่นคง - หากคอมไพเลอร์ปรับออปชั่นออกจากลูปเพราะมันถือว่ามันสิ้นสุดลง

Heck n1528มีพฤติกรรมแบบไม่ได้กำหนดถ้าฉันอ่านถูกต้อง เฉพาะ

ปัญหาสำคัญของการทำเช่นนี้คือมันอนุญาตให้โค้ดเคลื่อนที่ข้ามลูปที่อาจไม่สิ้นสุด

จากที่นี่ฉันคิดว่ามันสามารถมีส่วนร่วมในการอภิปรายในสิ่งที่เราต้องการ (คาดหวัง?) มากกว่าสิ่งที่ได้รับอนุญาต

ดูเหมือนว่านี่เป็นข้อผิดพลาดในคอมไพเลอร์เสียงดังกราว หากไม่มีการบังคับใด ๆ ในdie()ฟังก์ชั่นที่จะเป็นฟังก์ชั่นคงทำไปด้วยstaticและทำให้มันinline:

#include <stdio.h>

inline void die(void) {
    while(1)
        ;
}

int main(void) {
    printf("begin\n");
    die();
    printf("unreachable\n");
}

มันทำงานได้ตามที่คาดไว้เมื่อรวบรวมกับ Clang compiler และพกพาได้เช่นกัน

Compiler Explorer (godbolt.org) - เสียงดังกราว 9.0.0-O3 -std=c11 -pedantic-errors

main:                                   # @main
        push    rax
        mov     edi, offset .Lstr
        call    puts
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
        jmp     .LBB0_1
.Lstr:
        .asciz  "begin"

ดูเหมือนว่าต่อไปนี้จะทำงานสำหรับฉัน:

#include <stdio.h>

__attribute__ ((optnone))
static void die(void) {
    while (1) ;
}

int main(void) {
    printf("begin\n");
    die();
    printf("unreachable\n");
}

ที่godbolt

บอก Clang อย่างชัดแจ้งว่าไม่ควรปรับให้เหมาะสมว่าฟังก์ชั่นหนึ่งทำให้เกิดการวนซ้ำไม่สิ้นสุดตามที่คาดไว้ หวังว่าจะมีวิธีในการปิดใช้งานการเพิ่มประสิทธิภาพบางอย่างโดยเลือกแทนที่จะปิดพวกเขาทั้งหมดแบบนั้น เสียงดังกังวานยังคงปฏิเสธที่จะปล่อยรหัสที่สองprintfแม้ว่า ในการบังคับให้ทำเช่นนั้นฉันต้องแก้ไขโค้ดภายในmainเป็น:

volatile int x = 0;
if (x == 0)
    die();

ดูเหมือนว่าคุณจะต้องปิดการใช้งานการปรับให้เหมาะสมสำหรับฟังก์ชั่นการวนรอบไม่สิ้นสุดของคุณจากนั้นตรวจสอบให้แน่ใจว่าการวนซ้ำไม่สิ้นสุดของคุณถูกเรียกตามเงื่อนไข ในโลกแห่งความเป็นจริงมันมักจะเป็นอย่างนั้นเสมอไป

การนำไปปฏิบัติที่สอดคล้องกันอาจและหลาย ๆ ทางปฏิบัติทำกำหนดข้อ จำกัด โดยพลการเกี่ยวกับระยะเวลาที่โปรแกรมอาจดำเนินการหรือจำนวนคำสั่งที่จะดำเนินการและดำเนินการตามอำเภอใจหากข้อ จำกัด เหล่านั้นถูกละเมิดหรือ - ภายใต้กฎ "as-if" - หากพิจารณาแล้วเห็นว่าพวกเขาจะถูกละเมิดอย่างหลีกเลี่ยงไม่ได้ โดยมีเงื่อนไขว่าการดำเนินการสามารถประสบความสำเร็จอย่างน้อยหนึ่งโปรแกรมที่ใช้ชื่อขีด จำกัด ทั้งหมดที่ระบุไว้ใน N1570 5.2.4.1 โดยไม่ต้องกดขีด จำกัด การแปลใด ๆ การดำรงอยู่ของข้อ จำกัด ขอบเขตที่มีการบันทึกไว้และผลกระทบของพวกเขา ปัญหาคุณภาพการดำเนินการทั้งหมดอยู่นอกเขตอำนาจศาลของมาตรฐาน

ฉันคิดว่าความตั้งใจของมาตรฐานค่อนข้างชัดเจนว่าผู้รวบรวมไม่ควรคิดว่าการwhile(1) {}วนซ้ำที่ไม่มีผลข้างเคียงหรือbreakข้อความจะสิ้นสุดลง ตรงกันข้ามกับสิ่งที่บางคนอาจคิดว่าผู้เขียนมาตรฐานไม่ได้เชิญนักเขียนคอมไพเลอร์ให้โง่หรือป้าน การใช้งานที่สอดคล้องกันอาจมีประโยชน์ในการตัดสินใจที่จะยุติโปรแกรมใด ๆ ซึ่งหากไม่ขัดจังหวะดำเนินการคำสั่งฟรีผลข้างเคียงมากกว่าที่มีอะตอมในจักรวาล แต่การดำเนินการที่มีคุณภาพไม่ควรดำเนินการดังกล่าวบนพื้นฐานของสมมติฐาน การเลิกจ้าง แต่อยู่บนพื้นฐานที่การทำเช่นนั้นอาจมีประโยชน์และจะไม่เลวร้ายไปกว่าไร้ประโยชน์

การวนซ้ำไม่มีผลข้างเคียงและสามารถปรับให้เหมาะสมได้ การวนซ้ำเป็นไปอย่างไม่มีที่สิ้นสุดจำนวนการวนซ้ำของการทำงานเป็นศูนย์ นี่ไม่ได้กำหนดไว้ในคณิตศาสตร์และในเชิงตรรกะและมาตรฐานไม่ได้บอกว่าการใช้งานจะได้รับอนุญาตให้ทำสิ่งที่ไม่มีที่สิ้นสุดหากแต่ละสิ่งสามารถทำได้ในเวลาศูนย์ การตีความของ Clang นั้นสมเหตุสมผลอย่างสมบูรณ์แบบในการรักษาอนันต์คูณศูนย์เป็นศูนย์มากกว่าไม่มีที่สิ้นสุด มาตรฐานไม่ได้บอกว่าลูปไม่มีที่สิ้นสุดสามารถสิ้นสุดได้หรือไม่หากงานทั้งหมดในลูปเสร็จสมบูรณ์

คอมไพเลอร์ได้รับอนุญาตให้ปรับแต่งสิ่งที่ไม่ใช่พฤติกรรมที่สังเกตได้ตามที่กำหนดไว้ในมาตรฐาน ซึ่งรวมถึงเวลาดำเนินการ ไม่จำเป็นต้องเก็บรักษาความจริงที่ว่าลูปหากไม่ได้รับการปรับให้เหมาะสมจะใช้เวลาไม่ จำกัด ได้รับอนุญาตให้เปลี่ยนเป็นระยะเวลาที่สั้นกว่ามาก - อันที่จริงแล้วคือจุดที่การปรับให้เหมาะสมที่สุด การวนซ้ำของคุณได้รับการปรับปรุง

แม้ว่าเสียงดังกราวแปลรหัสอย่างไร้เดียงสาคุณสามารถจินตนาการ CPU ที่ปรับให้เหมาะสมซึ่งสามารถทำซ้ำแต่ละครั้งได้ในครึ่งเวลาที่การทำซ้ำก่อนหน้านี้ใช้ นั่นจะทำให้วงวนไม่สิ้นสุดในเวลา จำกัด ซีพียูที่เหมาะสมที่สุดนั้นละเมิดมาตรฐานหรือไม่? ดูเหมือนว่าไร้สาระที่จะพูดว่าการเพิ่มประสิทธิภาพของ CPU จะเป็นการละเมิดมาตรฐานหากการปรับให้เหมาะสมนั้นดีเกินไป เช่นเดียวกับคอมไพเลอร์

ฉันขอโทษถ้านี่ไม่ใช่กรณีที่ไร้สาระฉันก็สะดุดกับโพสต์นี้และฉันรู้เพราะปีของฉันใช้ Gentoo Linux distro ว่าถ้าคุณต้องการให้คอมไพเลอร์ไม่ปรับรหัสของคุณคุณควรใช้ -O0 (ศูนย์) ฉันอยากรู้เกี่ยวกับมันและรวบรวมและเรียกใช้รหัสข้างต้นและวงจะไปอย่างไม่มีกำหนด รวบรวมโดยใช้เสียงดังกราว -9:

cc -O0 -std=c11 test.c -o test

การwhileวนซ้ำที่ว่างเปล่าไม่มีผลข้างเคียงใด ๆ ต่อระบบ

ดังนั้นเสียงดังกราวจึงลบออก มีวิธีที่ "ดีกว่า" เพื่อให้บรรลุพฤติกรรมตามที่ตั้งใจซึ่งบังคับให้คุณต้องชัดเจนยิ่งขึ้นจากความตั้งใจของคุณ

while(1); คือ baaadd