[Bug 398403] Re: [PR40735] gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error
Bug Watch Updater
398403 at bugs.launchpad.net
Thu Jun 30 10:33:35 UTC 2011
Launchpad has imported 14 comments from the remote bug at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40735.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2009-07-13T19:37:16+00:00 Matthias Klose wrote:
[forwarded from https://launchpad.net/bugs/398403]
Building the attached file with gcc from the 4.4 branch with -g -fstack-
protector -fPIE -Os, the build fails (killed by oom), last info seen is
memory usage of about 1500mb. Building without -fPIE memory usage is
limited around 700MB.
Same behaviour for 4.3. With gcc-4.2 peak memory usage is with/without
-fPIE below 400MB. Not checked on trunk, currently fails to build.
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/10
------------------------------------------------------------------------
On 2009-07-13T19:37:36+00:00 Matthias Klose wrote:
Created attachment 18188
preprocessed source
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/11
------------------------------------------------------------------------
On 2009-07-14T09:20:58+00:00 Rguenth wrote:
I cannot compile the attached testcase.
gcc-4.2 -S -o /dev/null -g -fstack-protector -fPIE -Os test_node.i -std=c99
In file included from ../nih/test_alloc.h:32,
from ../nih/test.h:36,
from tests/test_node.c:23:
../nih/list.h:110: warning: declaration does not declare anything
In file included from tests/test_node.c:40:
./parse.h:71: warning: declaration does not declare anything
tests/test_node.c: In function ‘test_start_tag’:
tests/test_node.c:211: error: ‘ParseStack’ has no member named ‘node’
tests/test_node.c:251: error: ‘ParseStack’ has no member named ‘node’
tests/test_node.c:297: error: ‘ParseStack’ has no member named ‘data’
tests/test_node.c:297: error: ‘ParseStack’ has no member named ‘data’
tests/test_node.c:365: error: ‘ParseStack’ has no member named ‘node’
tests/test_node.c:422: error: ‘ParseStack’ has no member named ‘data’
tests/test_node.c:422: error: ‘ParseStack’ has no member named ‘data’
tests/test_node.c: In function ‘test_object_functions’:
tests/test_node.c:1256: error: ‘NihListEntry’ has no member named ‘str’
tests/test_node.c:1256: error: ‘NihListEntry’ has no member named ‘str’
...
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/16
------------------------------------------------------------------------
On 2009-07-14T10:31:19+00:00 Matthias Klose wrote:
my bad, should be -std=gnu99 instead: gcc-4.2 -S -o /dev/null -g
-fstack-protector -fPIE -Os test_node.i -std=gnu99
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/17
------------------------------------------------------------------------
On 2009-07-14T11:31:00+00:00 Rguenth wrote:
This is likely caused by the DF merge. There are numerous bugs about this
already and nothing really can be done here.
Btw, my numbers are
rguenther at murzim:/tmp> ~/bin/maxmem2.sh gcc-4.4 -S -o /dev/null -g -fstack-protector -fPIE -Os test_node.i -std=gnu99
total: 744108 kB
rguenther at murzim:/tmp> ~/bin/maxmem2.sh gcc-4.3 -S -o /dev/null -g -fstack-protector -fPIE -Os test_node.i -std=gnu99
total: 719836 kB
rguenther at murzim:/tmp> ~/bin/maxmem2.sh gcc-4.2 -S -o /dev/null -g -fstack-protector -fPIE -Os test_node.i -std=gnu99
total: 459757 kB
Thus not 1.5GB but 750MB vs 450MB.
rguenther at murzim:/tmp> ~/bin/maxmem2.sh gcc-4.4 -S -o /dev/null -fPIE -Os test_node.i -std=gnu99
total: 743380 kB
rguenther at murzim:/tmp> ~/bin/maxmem2.sh gcc-4.4 -S -o /dev/null -Os test_node.i -std=gnu99
total: 630756 kB
the -fPIE effect itself is even less recognizable.
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/18
------------------------------------------------------------------------
On 2009-07-14T23:07:07+00:00 Mikpe wrote:
Seems heavily target-dependent. With 4.3.4 I see peak usage of 640M for
i686, just under 1.2G for powerpc, and 1.6G for arm.
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/19
------------------------------------------------------------------------
On 2009-07-14T23:10:36+00:00 Pinskia wrote:
Hmm, maybe scheduling is causing it. Does -fno-schedule-insns -fno-
schedule-insns2 cause the memory usage to go down?
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/20
------------------------------------------------------------------------
On 2009-07-14T23:33:27+00:00 Mikpe wrote:
(In reply to comment #6)
> Hmm, maybe scheduling is causing it. Does -fno-schedule-insns
> -fno-schedule-insns2 cause the memory usage to go down?
Nope, memory usage patterns stayed the same.
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/21
------------------------------------------------------------------------
On 2009-07-15T07:34:32+00:00 stevenb wrote:
Does seem to be a real issue, somewhere.
When trunk builds again, can you please give it a try too?
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/22
------------------------------------------------------------------------
On 2009-07-15T09:44:41+00:00 Rguenth wrote:
DF time on this testcase is already big, and the testcase has lots of function
calls which would explain the difference between targets (DF needs to track all
call-used/clobbered regs).
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/23
------------------------------------------------------------------------
On 2009-07-16T18:33:18+00:00 Mikpe wrote:
More memory usage numbers on this test case:
With 4.4.1-RC-20090715: i686 peaks at 616M, powerpc at 799M, and arm at
1211M.
With 4.5.0-20090709: i686 peaks at 530M, powerpc at 707M, and arm at
933M.
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/24
------------------------------------------------------------------------
On 2009-08-04T12:30:16+00:00 Rguenth wrote:
GCC 4.3.4 is being released, adjusting target milestone.
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/25
------------------------------------------------------------------------
On 2010-05-22T18:13:40+00:00 Rguenth wrote:
GCC 4.3.5 is being released, adjusting target milestone.
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/26
------------------------------------------------------------------------
On 2011-06-27T12:14:51+00:00 Rguenth wrote:
4.3 branch is being closed, moving to 4.4.7 target.
Reply at: https://bugs.launchpad.net/gcc/+bug/398403/comments/37
** Changed in: gcc
Importance: Unknown => Medium
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to libnih in Ubuntu.
https://bugs.launchpad.net/bugs/398403
Title:
[PR40735] gcc-4.4 fails to build upstart 0.6 on armel due to an
internal compiler error
Status in The GNU Compiler Collection:
Confirmed
Status in Linaro GCC:
Fix Released
Status in “gcc-4.4” package in Ubuntu:
Fix Released
Status in “libnih” package in Ubuntu:
Fix Released
Status in “upstart” package in Ubuntu:
Fix Released
Bug description:
Binary package hint: gcc-4.4
in
https://edge.launchpad.net/ubuntu/+source/upstart/0.6.0-2/+build/1112005/+files/buildlog_ubuntu-karmic-armel.upstart_0.6.0-2_FAILEDTOBUILD.txt.gz
we see that the buidd appears to time out (in reality its hiding the actual error).
building that package on a local armel machine spits out the following:
/bin/bash ../libtool --tag=CC --mode=link gcc -std=gnu99 -Wall -g -fstack-protector -fPIE -Os -static -Wl,-z,relro -Wl,-z,now -pie -Wl,-O1 -o test_file test_file.o libnih.la
libtool: link: gcc -std=gnu99 -Wall -g -fstack-protector -fPIE -Os -Wl,-z -Wl,relro -Wl,-z -Wl,now -pie -Wl,-O1 -o test_file test_file.o ./.libs/libnih.a -lrt
gcc -std=gnu99 -DHAVE_CONFIG_H -DLOCALEDIR="\"/usr/share/locale\"" -I.. -I.. -I../intl -Wall -g -fstack-protector -fPIE -Os -MT test_watch.o -MD -MP -MF .deps/test_watch.Tpo -c -o test_watch.o `test -f 'tests/test_watch.c' || echo './'`tests/test_watch.c
tests/test_watch.c: In function ‘test_new’:
tests/test_watch.c:590: internal compiler error: in df_ref_record, at df-scan.c:2845
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions.
make[3]: *** [test_watch.o] Error 1
make[3]: Leaving directory `/home/ogra/devel/upstart-0.6.0/nih'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/home/ogra/devel/upstart-0.6.0/nih'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/ogra/devel/upstart-0.6.0'
To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/398403/+subscriptions
More information about the foundations-bugs
mailing list