This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
$ gcc initramfs.i -O2 -c -funit-at-a-time (...) init/initramfs.c: At top level: init/initramfs.c:10: error: message causes a section type conflict init/initramfs.c:33: error: head causes a section type conflict init/initramfs.c:80: error: ino causes a section type conflict init/initramfs.c:80: error: major causes a section type conflict init/initramfs.c:80: error: minor causes a section type conflict init/initramfs.c:80: error: nlink causes a section type conflict init/initramfs.c:81: error: mode causes a section type conflict init/initramfs.c:82: error: body_len causes a section type conflict init/initramfs.c:82: error: name_len causes a section type conflict init/initramfs.c:83: error: uid causes a section type conflict init/initramfs.c:84: error: gid causes a section type conflict init/initramfs.c:85: error: rdev causes a section type conflict init/initramfs.c:121: error: state causes a section type conflict init/initramfs.c:121: error: next_state causes a section type conflict init/initramfs.c:123: error: victim causes a section type conflict init/initramfs.c:124: error: count causes a section type conflict init/initramfs.c:125: error: this_header causes a section type conflict init/initramfs.c:125: error: next_header causes a section type conflict init/initramfs.c:127: error: dry_run causes a section type conflict init/initramfs.c:138: error: collected causes a section type conflict init/initramfs.c:139: error: remains causes a section type conflict init/initramfs.c:140: error: collect causes a section type conflict init/initramfs.c:156: error: header_buf causes a section type conflict init/initramfs.c:156: error: symlink_buf causes a section type conflict init/initramfs.c:156: error: name_buf causes a section type conflict init/initramfs.c:239: error: wfd causes a section type conflict
Created an attachment (id=9433) [edit] testcase
Reducing.
Confirmed, reduced testcase: static __attribute__ ((__section__ (".init.data"))) char *message; static __attribute__ ((__section__ (".init.data"))) int (*actions[])(void) = {}; void unpack_to_rootfs(void) { while (!message) { if(!actions[0]) return; } }
I spotted this bug at some time before while doing VAX development. Taken from http://www.pergamentum.com/pipermail/linux-vax/2005-July/000031.html, cvs HEAD was already broken (wrt. this bug) at Jul 24, 2005. I seem to remember that cvs HEAD was okay one or two months prior that date. Maybe this'll help you tracking it down. This issue ist still valid with current (Aug 20, 2005, 13:15 UTC) cvs HEAD.
The declaration of the variable "actions" (in the given example) is being changed to READONLY by the ipa- reference pass (in function static_execute), so when it comes time to create the section in "named_section", the default flags do not include SECTION_WRITE, and so they conflict with the flags for the variable "message", producing the error message.
Marking the variables with the attribute used will stop the ipa optimizations from changing them. but I feel that we should not reject the code still.
It seems like TREE_CONSTANT has the semantics we're looking for (value doesn't change) instead of TREE_READONLY, but I think someone more familiar with this pass (perhaps the author, Kenneth Zadeck?) would have to make that judgement.
(In reply to comment #7) > It seems like TREE_CONSTANT has the semantics we're looking for (value doesn't change) instead of > TREE_READONLY, but I think someone more familiar with this pass (perhaps the author, Kenneth > Zadeck?) would have to make that judgement. Actually TREE_READONLY is correct and TREE_CONSTANT is incorrect to use this context (there was a discussion about this before but I cannot find it). TREE_CONSTANT is not set by the way on "static const" variables in C anyways, only TREE_READONLY.
(In reply to comment #8) > Actually TREE_READONLY is correct and TREE_CONSTANT is incorrect to use this context (there was a > discussion about this before but I cannot find it). > TREE_CONSTANT is not set by the way on "static const" variables in C anyways, only TREE_READONLY. Your second sentence is consistent with my (admittedly naive) understanding - that TREE_READONLY represents whether the value is declared constant, and TREE_READONLY represents whether the value actually changes. Sorry if this has been hashed out already - I thought I would put down what I've seen in case it hadn't been looked into yet. I'll search the web archives to see if I can find that previous discussion. Thanks!
The reduced testcase from comment #3 starts failing with this patch from zadeck and dberlin: http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg00635.html
Subject: Bug 23237 CVSROOT: /cvs/gcc Module name: gcc Changes by: jconner@gcc.gnu.org 2005-09-12 15:46:35 Modified files: gcc : ChangeLog ipa-reference.c Log message: pr middle-end/23237 * ipa-reference.c (static_execute): Don't mark variables in named sections TREE_READONLY. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9940&r2=2.9941 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ipa-reference.c.diff?cvsroot=gcc&r1=2.3&r2=2.4
Subject: Bug 23237 CVSROOT: /cvs/gcc Module name: gcc Changes by: jconner@gcc.gnu.org 2005-09-12 15:50:08 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr23237.c Log message: pr middle-end/23237 * gcc.c-torture/compile/pr23237.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6047&r2=1.6048 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr23237.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
Fixed.
I'm seeing some failures with 4.1.2-RC2 on test case pr23237.c on powerpc7400-apple-darwin8, posted: http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00475.html Are these known/expected/new?