| Summary: | pragma pack changes padding in struct gcov_info on 64-bit archs | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Alexander Monakov <amonakov> |
| Component: | gcov-profile | Assignee: | Richard Biener <rguenth> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | arthur.j.odwyer, gcc-bugs, jengelh, tglek |
| Priority: | P3 | ||
| Version: | 4.5.0 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | 5.2.0, 6.0 | |
| Known to fail: | 5.1.0 | Last reconfirmed: | 2015-07-08 00:00:00 |
| Attachments: | proposed patch | ||
Created attachment 20455 [details]
proposed patch
*** Bug 43825 has been marked as a duplicate of this bug. *** (In reply to comment #1) > Created an attachment (id=20455) [edit] > proposed patch > GCC generates gcov structures at runtime, and #pragma pack(1) in the source file affects their layout. We probably can reset the alignment in create_coverage to avoid that. The above patch implements a different approach -- it rearranges structure fields and manually sets alignment so that layout does not depend on current structure packing. For the record, I just noticed the same issue, using -fpack-struct instead of #pragma pack. Whatever the fix ends up being, please make sure it also handles -fpack-struct.
cat >test.c <<EOF
int main() { return 0; }
EOF
gcc -fpack-struct=4 -fprofile-generate test.c
./a.out
Segmentation fault
(In reply to comment #4) > gcc -fpack-struct=4 -fprofile-generate test.c -fpack-struct changes the ABI so it is not fully a bug there. (In reply to comment #5) > (In reply to comment #4) > > gcc -fpack-struct=4 -fprofile-generate test.c > > -fpack-struct changes the ABI so it is not fully a bug there. It's a gray area. -fprofile-generate is not documented as relying on "structs", as far as I could tell, so it's not intuitively obvious that it should have any interaction with -fpack-struct= at all. IMHO -fprofile-generate should always produce working code. At the very least, the interaction should be documented in the documentation for -fprofile-generate. The same pitfalls also apply to -fprofile-arcs. (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > gcc -fpack-struct=4 -fprofile-generate test.c > > > > -fpack-struct changes the ABI so it is not fully a bug there. > > It's a gray area. -fprofile-generate is not documented as relying on "structs", > as far as I could tell, so it's not intuitively obvious that it should have any > interaction with -fpack-struct= at all. IMHO -fprofile-generate should always > produce working code. At the very least, the interaction should be documented > in the documentation for -fprofile-generate. Maybe it does not says it relays on structs but it relays on the current ABI that is used. This is just like saying the Fortran front-end does say it relays on structs but things go bad when you use that option. I don't see why this should be documented when it is already documented that -fpack-struct changes the ABI. Hi, I was strglign for last 2 night with my aplication which generated coverage files for all source files but one. At the end I found out that C++ file was including .h file. If I commented out .h file then coverage was generated. Only unusual thing I noticed was #pragma pack(1). When I removed it the coverage was generated again ! Short search I found this bug. I can reproduce it all the time. The version of g++ and gcov below : michal@ubuntu:~/git/blpr$ g++ --version g++ (Ubuntu 4.9.1-16ubuntu6) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. michal@ubuntu:~/git/blpr$ gcov --version gcov (Ubuntu 4.9.1-16ubuntu6) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Can you somehow patch it ? Regards Michal *** Bug 66805 has been marked as a duplicate of this bug. *** Mine. Fixed on trunk with 2015-07-09 Richard Biener <rguenther@suse.de> * toplev.c (compile_file): Reset maximum_field_alignment after parsing. and queued for backporting. Author: rguenth Date: Fri Jul 10 12:33:28 2015 New Revision: 225671 URL: https://gcc.gnu.org/viewcvs?rev=225671&root=gcc&view=rev Log: 2015-07-10 Richard Biener <rguenther@suse.de> Backport from mainline 2015-07-10 Richard Biener <rguenther@suse.de> PR tree-optimization/66823 * tree-if-conv.c (memrefs_read_or_written_unconditionally): Fix inverted predicate. * gcc.dg/vect/pr61194.c: Remove -ftree-loop-if-convert-stores which should not be necessary. XFAIL. 2015-07-08 Richard Biener <rguenther@suse.de> PR middle-end/43341 * toplev.c (compile_file): Reset maximum_field_alignment after parsing. 2015-07-08 Richard Biener <rguenther@suse.de> PR tree-optimization/66794 * gimple-ssa-isolate-paths.c (gimple_ssa_isolate_erroneous_paths): Free post-dominators. * gcc.dg/torture/pr66794.c: New testcase. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr66794.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/gimple-ssa-isolate-paths.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/gcc.dg/vect/pr61194.c branches/gcc-5-branch/gcc/toplev.c branches/gcc-5-branch/gcc/tree-if-conv.c Fixed. |
cat <<EOF > t.c int foo(){} #pragma pack(1) EOF gcc -S -fprofile-generate t.c grep '^\.LPBX' -A 2 t.s .LPBX0: .long 875574314 .quad 0 The padding ('.zero 4') between .long and .quad that correspond to the first two fields of struct gcov_info (an int and a ptr) is gone. This makes building Firefox with profile feedback impossible on amd64. At least gcc-4.[1345] behave this way.