--- 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
--- 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/bu
--- 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 ch
--- 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
--- 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"
wrote:
>
>
> --- Comment #3 from rguenth at gcc dot gnu dot org 2009-01
--- 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 opti
LAST_UPDATED: Tue Jan 27 22:35:18 UTC 2009 (revision 143701)
Target: powerpc-linux-gnu
gcc version 4.3.3 (Debian 4.3.3-3)
Native configuration is powerpc-unknown-linux-gnu
=== g++ tests ===
Running target unix
FAIL: g++.dg/torture/pr38565.C -O0 (test for excess errors)
FAIL:
LAST_UPDATED: Tue Jan 27 22:35:18 UTC 2009 (revision 143701)
Target: i486-linux-gnu
gcc version 4.3.3 (Debian 4.3.3-3)
Native configuration is i486-pc-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
LAST_UPDATED: Tue Jan 27 22:35:18 UTC 2009 (revision 143701)
Target: x86_64-linux-gnu
gcc version 4.3.3 (Debian 4.3.3-3)
Native configuration is x86_64-pc-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
LAST_UPDATED: Tue Jan 27 22:35:18 UTC 2009 (revision 143712)
Target: powerpc-linux-gnu
gcc version 4.3.3 (Debian 4.3.3-2)
Native configuration is powerpc-unknown-linux-gnu
=== g++ tests ===
Running target unix
FAIL: g++.dg/torture/pr38565.C -O0 (test for excess errors)
FAIL:
LAST_UPDATED: Tue Jan 27 22:35:18 UTC 2009 (revision 143712)
Target: i486-linux-gnu
gcc version 4.3.3 (Debian 4.3.3-2)
Native configuration is i486-pc-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
--- 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[01
FYI: The status of the gcc-4.2 source package
in Debian's testing distribution has changed.
Previous version: 4.2.4-5
Current version: 4.2.4-6
--
This email is automatically generated; the Debian Release Team
is responsible.
See http://release.debian.org/testing-watch/ for more information
FYI: The status of the gcc-4.1 source package
in Debian's testing distribution has changed.
Previous version: 4.1.2-24
Current version: 4.1.2-25
--
This email is automatically generated; the Debian Release Team
is responsible.
See http://release.debian.org/testing-watch/ for more informati
Accepted:
cpp-4.3_4.3.3-3_amd64.deb
to pool/main/g/gcc-4.3/cpp-4.3_4.3.3-3_amd64.deb
cpp-4.3_4.3.3-3_i386.deb
to pool/main/g/gcc-4.3/cpp-4.3_4.3.3-3_i386.deb
cpp-4.3_4.3.3-3_powerpc.deb
to pool/main/g/gcc-4.3/cpp-4.3_4.3.3-3_powerpc.deb
fixincludes_4.3.3-3_amd64.deb
to pool/main/g/gcc-4.3/
gcc-4.3_4.3.3-3_multi.changes uploaded successfully to localhost
along with the files:
libstdc++6-4.3-dev_4.3.3-3_amd64.deb
gfortran-4.3-multilib_4.3.3-3_i386.deb
libmudflap0-dbg_4.3.3-3_i386.deb
lib64mudflap0-dbg_4.3.3-3_i386.deb
lib64gfortran3_4.3.3-3_i386.deb
gobjc++-4.3-multilib_4.3
--- 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_
--- 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_
On Thu, Jan 29, 2009 at 02:55:20 +, Steve Cotton wrote:
> I've spent a while looking at what runs what, and realised that it will be
> quite time consuming for someone not familiar with your package to extact
> a test case.
>
> Would it be possible for you to isolate the gsf-scan bit;
.c and .
--- 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
--
jdassen at debian dot org changed:
What|Removed |Added
Attachment #17207|application/octet-stream|text/x-csrc
mime type||
http://gcc.
--- 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/bugzil
--- 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
Hi Ray,
I've spent a while looking at what runs what, and realised that it
will be quite time consuming for someone not familiar with your
package to extact a test case. Would it be possible for you to
isolate the gsf-scan bit; and provide the arguments and input
files to run it in isolation rath
24 matches
Mail list logo
