--- Comment #13 from jakub at gcc dot gnu dot org 2009-01-30 10:58 ---
Nothing changed in gsf-scan.c, but out of the 3 objects in libgsf.so that
changed it seems to be gsf-output-csv.c where r143570 makes difference for
gsf-scan. Looking at it now...
--
--- Comment #14 from jakub at gcc dot gnu dot org 2009-01-30 11:38 ---
And clearly the bug is in libgsf, not in gcc.
g_enum_register_static documentation says:
GObject keeps a reference to the data, so it cannot be stack-allocated.
so this relies on this optimization.
--- Comment #15 from jakub at gcc dot gnu dot org 2009-01-30 11:39 ---
Created an attachment (id=17213)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17213action=view)
libgsf-enum-register.patch
Patch that fixes this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
--- Comment #16 from jakub at gcc dot gnu dot org 2009-01-30 11:40 ---
Invalid.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #17 from jdassen at debian dot org 2009-01-30 17:02 ---
Now fixed in libgsf upstream:
http://svn.gnome.org/viewvc/libgsf?view=revisionrevision=1039
Thank you very much!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
--- Comment #10 from doko at ubuntu dot com 2009-01-29 22:36 ---
I'm able to reproduce it with trunk 20090129. The gsf-scan executable links
against the just built libgsf.so, so I assume we have to look for a miscompiled
file in libgsf.
--
doko at ubuntu dot com changed:
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-01-29 22:39
---
I don't see anything in gsf-scan.c which would have been changed by that patch.
All the arrays are already marked as static. The only ones that changed by
that patch are auto arrays.
--
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-01-29 22:41
---
(In reply to comment #9)
Assuming there is a way to trigger this, I wonder if the program is legal. In
particular I was looking at the initialization of GbArgTable which has a lot
of
holes in it.
Those
