[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf

[jakub at gcc dot gnu dot org]

--- 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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015

[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf

[jakub at gcc dot gnu dot org]

--- 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.  gsf_output_csv_quoting_mode_get_type
just needs to be fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|wrong-code  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015

[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf

[jakub at gcc dot gnu dot org]

--- 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

[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf

[jakub at gcc dot gnu dot org]

--- 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||caolanm at redhat dot com
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015

[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf

[jdassen at debian dot org]

--- 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

[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf

[doko at ubuntu dot com]

--- 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:

   What|Removed |Added

  Known to fail|4.3.4   |4.3.4 4.4.0
Summary|[4.3 regression] wrong code |[4.3/4.4 regression] wrong
   |building libgsf |code building libgsf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015

[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf

[pinskia at gcc dot gnu dot org]

--- 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015

[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf

[pinskia at gcc dot gnu dot org]

--- 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 holes are all zero but the array GbArgTable is already declared as static
so there will be no difference between before and after the patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015