https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93222
Bug ID: 93222
Summary: __attribute__((always_inline)) changes program
behaviour unexpectedly
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: imzhuli at vip dot qq.com
Target Milestone: ---
Created attachment 47627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47627&action=edit
source codes (DList.h Task.h ZETaskScheduler.h sample.c) compiling temp files
(sample.ii sample.s) output files a.out (on ubuntu desktop 18.04 LTS)
Version:
g++ 8.3.1 (on ubuntu desktop 18.04 LTS)
g++ 9.1.0 (on mingw, win10, msys2)
compile params:
g++ --std=c++17 sample.cpp -O -fschedule-insns -fstrict-aliasing
(** it's strange that extracting all -O optimization params to command line
according to manual won't trigger the strange behaviour, maybe I got the
options wrong)
codes: see appendix (I also packed the temp files by adding -save-temps to
commandline)
I am sorry that I tried to make the codes simpler, but when I simply the
cases (like just iterating a list), the strange behaviour just went gone.
expected:
The program includes a double list (with a simple version of
forward_iterator). and a task scheduler with a table of d-list working as a
time-wheel (simplified in the example).
Each time scheduler updates, it steps forward, and pick of tasks from one
list in the table, and execute them and reschedule it to a later list.
The program actually adds only one task to add a counter and keeps looping
to update scheduler.
After two time of task execution, it ends the loop by setting run flag to
false.
problem: ( DList.h : line: 96)
When I added __attribute__((always_inline)) to DList::begin() to generate a
forward_iterator, it fails on ZETaskScheduler.cpp:82 which should grab list
from the table. But program would work fine if I removed the
__attribute__((always_inline)) or just simply add some random code before
ZETaskScheduler.cpp:82 (like printf("hello world!")).
I am not familiar with asm, I just guess the compiler reordered some
instructions or optimized out something? By the way I run codes on intel nuc
with cpu model I3 8109, if that info helps.
Thanks
