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

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

[doko at ubuntu dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3700 bytes --]

[forwarded from http://bugs.debian.org/513420]

Reverting the fix for PR38615 on the 4.3 branch lets the build succeed.

What am I trying to do:
* Build libgsf from source again on amd64 (or build libgsf svn trunk).

How am I trying to do it / steps to reproduce:
* Set up a sid environment in which to build libgsf from the Debian source
  package, e.g. in pbuilder.
* Get the libgsf source package and extract it.
* In the source directory, run
        env MALLOC_CHECK_=2 debian/rules build

What behaviour did I expect to get:
* The libgsf build runs to completion.

What behaviour did I actually get:
* The libgsf build fails during documentation generation, with messages
  similar to the following:
        creating gsf-scan
        gtk-doc: Running scanner gsf-scan
        sh: line 1: 27898 Segmentation fault      ( ./gsf-scan )
        Scan failed: 
        make[3]: *** [scan-build.stamp] Error 139
        make[3]: Leaving directory `/tmp/buildd/libgsf-1.14.11/build/doc'
* This behaviour is fully repeatable for me.

Notes and observations:
* "gsf-scan" is built from generated sources using gtk-doc-tools.
* To preserve the gsf-scan sources and objects, comment out the unlink line
  which removes them in /usr/bin/gtkdoc-scangobj .
* When running plain "debian/rules build" without the env MALLOC_CHECK_=2,
  the problem manifests at a later point in the build as follows:
        cd ../../doc/html && gtkdoc-mkhtml   gsf ../gsf-docs.sgml
        ../xml/text.xml:255: parser error : Input is not proper UTF-8, indicate
encoding !
        Bytes: 0xD0 0x45 0x2E 0x02
        <para>When to quote fields.</para><para>Default value: ÐE.\x02</para>
                                                               ^
        ../xml/text.xml:255: parser error : PCDATA invalid Char value 2
        <para>When to quote fields.</para><para>Default value: ÐE.\x02</para>
                                                                  ^
        ../xml/text.xml:279: parser error : chunk is not well balanced

        ^
        ../gsf-docs.sgml:232: parser error : Failure to process entity GsfText
            &GsfText;
                     ^
        ../gsf-docs.sgml:232: parser error : Entity 'GsfText' not defined
            &GsfText;
                     ^
        unable to parse ../gsf-docs.sgml
        make[3]: *** [html-build.stamp] Error 6
  This can be tracked back to a garbage string in the <DEFAULT> block within
  the <ARG> block for GsfOutputCsvQuotingMode in doc/gsf.args which is a
  file generated by gsf-scan. The garbage string can vary between repeated
  attempts.
* This libgsf version (1.14.11-1) has previously been built successfully on
  all architectures.
* The problem is still reproducible for me when the optimisation level is
  reduced (in debian/rules) to -O1 .
* I could not reproduce the problem in the following variations:
  * When lowering the optimisation level to -O0 .
  * Building in a 32-bit pbuilder chroot on amd64.
  * Building in a sid environment with the gcc-4.3 packages downgraded to
    the 4.3.2-1.1 versions from testing.
  * Building using CC=gcc-4.2 .
  * Building using CC=gcc-4.1 .
  * Building using CC=/usr/lib/gcc-snapshot/bin/gcc .
  which makes me suspect that the problem isn't with the (generated)
  gsf-scan sources, but with gcc's code generation.


-- 
           Summary: [4.3 regression] wrong code building libgsf
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: doko at ubuntu dot com


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

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

[jdassen at debian dot org]

------- Comment #1 from jdassen at debian dot org  2009-01-29 09:10 -------
Created an attachment (id=17206)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17206&action=view)
The (gtk-doc-tools generated) gsf-scan.c file which gets miscompiled


-- 


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

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

[jdassen at debian dot org]

------- Comment #2 from jdassen at debian dot org  2009-01-29 09:11 -------
Created an attachment (id=17207)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17207&action=view)
The (gtk-doc-tools generated) gsf-scan.c file which gets miscompiled,
preprocessed.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-29 10:01 -------
The best option would be to revert that patch on the branch.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sje at gcc dot gnu dot org,
                   |                            |rguenth at gcc dot gnu dot
                   |                            |org
           Priority|P3                          |P1
   Target Milestone|---                         |4.3.4


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

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

[doko at ubuntu dot com]

------- Comment #4 from doko at ubuntu dot com  2009-01-29 10:14 -------
when Ray wrote he tested with a snapshot build, I assume this was 20090107
without the patch applied, so the status on the trunk is not known yet. will
test with current trunk later.


-- 


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

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

[jdassen at debian dot org]

------- Comment #5 from jdassen at debian dot org  2009-01-29 10:24 -------
(In reply to comment #4)
> when Ray wrote he tested with a snapshot build, I assume this was 20090107
> without the patch applied,

Yes, I was using sid's gcc-snapshot 20090107-1.


-- 


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

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

[sje at cup dot hp dot com]

------- Comment #6 from sje at cup dot hp dot com  2009-01-29 17:00 -------
What GCC options was gsf-scan.i compiled with?  I am trying to see what
variables are getting/not getting promoted during the compilation and I am not
seeing it affect any variables if I just compile gsf-scan.i with -O[0123].


-- 


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

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

[jdassen at debian dot org]

------- Comment #7 from jdassen at debian dot org  2009-01-29 17:53 -------
(In reply to comment #3)
> The best option would be to revert that patch on the branch.

Matthias did that in the 4.3.3-3 packages and with them, the problem has
indeed gone away.

(In reply to comment #6)
> What GCC options was gsf-scan.i compiled with?

compile line: /bin/sh ../libtool --mode=compile cc -Wl,-z,defs -Wl,-O1
-Wl,--as-needed     -O2 -Wall -Wmissing-prototypes -Wnested-externs
-Wpointer-arith -Wno-sign-compare  -DG_DISABLE_DEPRECATED -Wno-system-headers
-Wfloat-equal -Wpointer-arith -Wbad-function-cast -Wwrite-strings
-Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wformat -Wnested-externs -Winline
-Wdeclaration-after-statement -Wundef -W -Wmissing-noreturn
-Wmissing-format-attribute -Wno-pointer-sign -DLIBGSF_GNOMEVFS_VIA_GIO -I../..
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2  
-O2 -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith
-Wno-sign-compare  -DG_DISABLE_DEPRECATED -Wno-system-headers -Wfloat-equal
-Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wsign-compare
-Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wformat -Wnested-externs -Winline
-Wdeclaration-after-statement -Wundef -W -Wmissing-noreturn
-Wmissing-format-attribute -Wno-pointer-sign -DLIBGSF_GNOMEVFS_VIA_GIO -c -o
gsf-scan.lo gsf-scan.c

link line: /bin/sh ../libtool --mode=link cc -Wl,-z,defs -Wl,-O1
-Wl,--as-needed  -O2 -Wall -Wmissing-prototypes -Wnested-externs
-Wpointer-arith -Wno-sign-compare  -DG_DISABLE_DEPRECATED -Wno-system-headers
-Wfloat-equal -Wpointer-arith -Wbad-function-cast -Wwrite-strings
-Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wformat -Wnested-externs -Winline
-Wdeclaration-after-statement -Wundef -W -Wmissing-noreturn
-Wmissing-format-attribute -Wno-pointer-sign -DLIBGSF_GNOMEVFS_VIA_GIO 
-no-undefined  -o gsf-scan gsf-scan.lo ../gsf/libgsf-1.la -lgobject-2.0
-lglib-2.0 -lxml2   -no-undefined 


-- 


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

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

[pinskia at gmail dot com]

------- Comment #8 from pinskia at gmail dot com  2009-01-29 17:53 -------
Subject: Re:  [4.3 regression] wrong code building libgsf



Sent from my iPhone

On Jan 29, 2009, at 2:01 AM, "rguenth at gcc dot gnu dot org"
<gcc-bugzilla@gcc.gnu.org 
 > wrote:

>
>
> ------- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-29  
> 10:01 -------
> The best option would be to revert that patch on the branch.

Except it alone could not cause wrong code.  Some other pass is  
causing it.  And then again with a testcase it is hard to figure out  
what is going wrong.  That patch just disables one small optimization  
in one case.

>
>
>
> -- 
>
> rguenth at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> --- 
> --- 
> ----------------------------------------------------------------------
>                 CC|                            |sje at gcc dot gnu  
> dot org,
>                   |                            |rguenth at gcc dot  
> gnu dot
>                   |                            |org
>           Priority|P3                          |P1
>   Target Milestone|---                         |4.3.4
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
>


-- 


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

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

[Andrew Thomas Pinski]

Sent from my iPhone

On Jan 29, 2009, at 2:01 AM, "rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org 
 > wrote:

>
>
> ------- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-29  
> 10:01 -------
> The best option would be to revert that patch on the branch.

Except it alone could not cause wrong code.  Some other pass is  
causing it.  And then again with a testcase it is hard to figure out  
what is going wrong.  That patch just disables one small optimization  
in one case.

>
>
>
> -- 
>
> rguenth at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> --- 
> --- 
> ----------------------------------------------------------------------
>                 CC|                            |sje at gcc dot gnu  
> dot org,
>                   |                            |rguenth at gcc dot  
> gnu dot
>                   |                            |org
>           Priority|P3                          |P1
>   Target Milestone|---                         |4.3.4
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
>

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

[sje at cup dot hp dot com]

------- Comment #9 from sje at cup dot hp dot com  2009-01-29 18:57 -------
So far I have been unable to reproduce this problem.  When compiling gsf-scan.i
I do not even reach the code that I changed in PR 38615 and I get the same code
with or without my change included.

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.  If the optimization affects whether or not these holes get set to
zero and if the program is accessing these uninitialized locations that could
cause a change in behaviour.


-- 


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

[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=17213&action=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=revision&revision=1039

Thank you very much!


-- 


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