Bug 1310467
Summary: | CORD__next() miscompiled on s390(x) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dan Horák <dan> | ||||
Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 24 | CC: | davejohansen, jakub, jwakely, law, mpolacek | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | s390x | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | gcc-6.0.0-0.14.fc24 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2016-03-03 09:15:02 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 467765 | ||||||
Attachments: |
|
Description
Dan Horák
2016-02-21 22:54:35 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase Created attachment 1130804 [details]
preprocessed source file
gcc -DHAVE_CONFIG_H -I./include -I./include -DUSE_GET_STACKBASE_FOR_MAIN -fexceptions -DGC_VISIBILITY_HIDDEN_SET -fvisibility=hidden -Wall -Wextra -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -E cord/cordbscs.c -fPIC -DPIC -o cord/cordbscs.i
I'm afraid that is not enough for a wrong-code, I'd need to know how exactly it is called and how to recognize good vs. bad. Does it keep failing with O2 and working with O1 if you add __attribute__((noinline, noclone)) to CORD__next? What about CORD__extend_path, does it have to be inlined for the wrong behavior? Can you cook up a minimal main that will just call __attribute__((noinline, noclone)) to CORD__next with the right arguments on which it reproduces (of course it is not just the argument structure itself, but whatever other points it uses, just malloc them or set pointers to automatic variables in main also initialized with right values. Can you add code to main (or to CORD__extend_path if it doesn't have to be inlined) to detect the wrong vs. good behavior and __builtin_abort () if it is wrong? (In reply to Jakub Jelinek from comment #3) > I'm afraid that is not enough for a wrong-code, I'd need to know how exactly > it is called and how to recognize good vs. bad. I know, still working on better test case > Does it keep failing with O2 and working with O1 if you add > __attribute__((noinline, noclone)) to CORD__next? What about > CORD__extend_path, does it have to be inlined for the wrong behavior? behaves incorrectly with -O2 even with __attribute__((noinline, noclone)) for both functions > Can you cook up a minimal main that will just call __attribute__((noinline, > noclone)) to CORD__next with the right arguments on which it reproduces (of > course it is not just the argument structure itself, but whatever other > points it uses, just malloc them or set pointers to automatic variables in > main also initialized with right values. Can you add code to main (or to > CORD__extend_path if it doesn't have to be inlined) to detect the wrong vs. > good behavior and __builtin_abort () if it is wrong? the "main" looks like this (reduced from cord/tests/cordtest.c after realizing gdb is lying about the lines), reproduceable also with upstream (https://github.com/ivmai/bdwgc) char id_cord_fn(size_t i, void * client_data) { if (client_data != 0) ABORT("id_cord_fn: bad client data"); return((char)i); } void test_basics(void) { register int i; char c; CORD y; CORD_pos p; y = CORD_from_fn(id_cord_fn, 0, 13); i = 0; CORD_set_pos(p, y, i); while(CORD_pos_valid(p)) { c = CORD_pos_fetch(p); if(c != i) ABORT("Traversal of function node failed"); CORD_next(p); i++; } if (i != 13) ABORT("Bad apparent length for function node"); } int main(void) { GC_INIT(); test_basics(); CORD_fprintf(stdout, "SUCCEEDED\n"); return(0); } result is [sharkcz@devel10 bdwgc]$ ./cordtest FAILED: Traversal of function node failed Aborted (core dumped) Managed to create small self-contained testcase and bisect, tracking upstream in PR70025. I can confirm that using gcc-6.0.0-0.14.fc24 the test-suite passes. Fixed then. |