GCC 3.4.4 Status (2005-04-29)

GCC 3.4.4 Status (2005-04-29)

[Mark Mitchell]

Now that GCC 4.0 is out the door, I've spent some time looking at the
status of the 3.4 branch.  As stated previously, I'll be doing a 3.4.4
release, and then turning the branch over to Gaby, to focus
exclusively on 4.0/4.1. 

The 3.4 branch is in pretty good shape, despite what Bugzilla might
lead you to believe.  There are a lot of regression reports (150) but
I've scanned through them, and most involve corner cases in some
pretty dark corners.  Even the 53 ICE-on-valid, rejects-valid, and
wrong-code cases are mostly very firmly in those categories.  A number
of these cases have patches that have already been applied to
mainline, and probably can be backported to the 3.4 branch relatively
easily.

In general, GCC 3.4.3 is working for people; the point of 3.4.4 is
just to get another round of bug fixes done.  We don't want to go to
heroic lengths to try to fix things, at the risk of destabilizing a
pretty good compiler.

Therefore, I plan to create a 3.4.4 RC1 in one week, on May 7th, with
a final release shortly thereafter, unless there are serious problems
discovered.  Speaking for myself, during this time, I plan to go
through the open reports, finding critical C++ bugs that I fixed, and
backport the patches.  I'd encourage others to do the same, and
to look in particular at wrong-code problems that affect your favorite
platforms.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

libjava/3.4.4 problem (was Re: GCC 3.4.4 Status (2005-04-29))

[Thorsten Glaser]

Mark Mitchell dixit:

>In general, GCC 3.4.3 is working for people

I've been playing around a lot with the various 3.4.4 snapshots
lately, and got everything to work, except for libjava:

gmake[1]: Entering directory `/usr/obj/gcc/libjava'
/bin/ksh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I/usr/src/gcc/libjava -I./include -I./gcj -I/usr/src/gcc/libjava -Iinclude -I/usr/src/gcc/libjava/include -I/usr/src/gcc/boehm-gc/include  -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1   -I/usr/src/gcc/libjava/libltdl -I/usr/src/gcc/libjava/libltdl -I../libstdc++-v3/include -I../libstdc++-v3/include/i386-ecce-mirbsd8 -I/usr/src/gcc/libjava/../libstdc++-v3/libsupc++ -I/usr/src/gcc/libjava/.././libjava/../gcc  -I/usr/src/gcc/libjava/../libffi/include -I../libffi/include  -isystem /usr/src/gcc/libjava -fno-rtti -fnon-call-exceptions  -fdollars-in-identifiers -Wswitch-enum -ffloat-store  -I/usr/X11R6/include -W -Wall -D_GNU_SOURCE -DPREFIX="\"/usr\"" -DLIBDIR="\"/usr/lib\"" -DBOOT_CLASS_PATH="\"/usr/share/java/libgcj-3.4.4.jar\"" -O2 -c /usr/src/gcc/libjava/prims.cc
mkdir .libs
 c++ -DHAVE_CONFIG_H -I. -I/usr/src/gcc/libjava -I./include -I./gcj -I/usr/src/gcc/libjava -Iinclude -I/usr/src/gcc/libjava/include -I/usr/src/gcc/boehm-gc/include -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -I/usr/src/gcc/libjava/libltdl -I/usr/src/gcc/libjava/libltdl -I../libstdc++-v3/include -I../libstdc++-v3/include/i386-ecce-mirbsd8 -I/usr/src/gcc/libjava/../libstdc++-v3/libsupc++ -I/usr/src/gcc/libjava/.././libjava/../gcc -I/usr/src/gcc/libjava/../libffi/include -I../libffi/include -isystem /usr/src/gcc/libjava -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -ffloat-store -I/usr/X11R6/include -W -Wall -D_GNU_SOURCE -DPREFIX=\"/usr\" -DLIBDIR=\"/usr/lib\" -DBOOT_CLASS_PATH=\"/usr/share/java/libgcj-3.4.4.jar\" -O2 -Wp,-MD,.deps/prims.pp -c /usr/src/gcc/libjava/prims.cc  -fPIC -DPIC -o .libs/prims.o
In file included from /usr/src/gcc/libjava/java/lang/Object.h:16,
                 from /usr/src/gcc/libjava/gcj/cni.h:16,
                 from ./include/platform.h:40,
                 from /usr/src/gcc/libjava/prims.cc:12:
/usr/src/gcc/libjava/gcj/javaprims.h:486: error: declaration of C function `java::lang::Thread* _Jv_AttachCurrentThread(java::lang::String*, java::lang::ThreadGroup*)' conflicts with
/usr/src/gcc/libjava/gcj/javaprims.h:484: error: previous declaration `jint _Jv_AttachCurrentThread(java::lang::Thread*)' here
In file included from ./java/lang/String.h:9,
                 from /usr/src/gcc/libjava/java/lang/Class.h:18,
                 from /usr/src/gcc/libjava/gcj/cni.h:17,
                 from ./include/platform.h:40,
                 from /usr/src/gcc/libjava/prims.cc:12:
/usr/src/gcc/libjava/gcj/array.h: In function `jsize JvGetArrayLength(__JArray*)':
/usr/src/gcc/libjava/gcj/array.h:29: error: previous declaration of `jsize JvGetArrayLength(__JArray*)' with Java linkage
/usr/src/gcc/libjava/gcj/array.h:138: error: conflicts with new declaration with C linkage
In file included from /usr/src/gcc/libjava/gcj/cni.h:17,
                 from ./include/platform.h:40,
                 from /usr/src/gcc/libjava/prims.cc:12:
/usr/src/gcc/libjava/java/lang/Class.h: At global scope:
/usr/src/gcc/libjava/java/lang/Class.h:366: error: declaration of C function `void _Jv_InitField(java::lang::Object*, java::lang::Class*, int)' conflicts with
/usr/src/gcc/libjava/java/lang/Class.h:365: error: previous declaration `void _Jv_InitField(java::lang::Object*, java::lang::Class*, _Jv_Field*)' here
In file included from ./include/platform.h:40,
                 from /usr/src/gcc/libjava/prims.cc:12:
/usr/src/gcc/libjava/gcj/cni.h: In function `java::lang::Object* JvAllocObject(java::lang::Class*, jsize)':
/usr/src/gcc/libjava/gcj/cni.h:31: error: declaration of C function `java::lang::Object* JvAllocObject(java::lang::Class*, jsize)' conflicts with
/usr/src/gcc/libjava/gcj/cni.h:25: error: previous declaration `java::lang::Object* JvAllocObject(java::lang::Class*)' here
/usr/src/gcc/libjava/gcj/cni.h: In function `java::lang::String* JvNewStringLatin1(const char*)':
/usr/src/gcc/libjava/gcj/cni.h:64: error: declaration of C function `java::lang::String* JvNewStringLatin1(const char*)' conflicts with
/usr/src/gcc/libjava/gcj/cni.h:58: error: previous declaration `java::lang::String* JvNewStringLatin1(const char*, jsize)' here
/usr/src/gcc/libjava/prims.cc: In function `void unblock_signal(int)':
/usr/src/gcc/libjava/prims.cc:136: warning: right-hand operand of comma has no effect
/usr/src/gcc/libjava/prims.cc: At global scope:
/usr/src/gcc/libjava/prims.cc:132: warning: 'void unblock_signal(int)' defined but not used
gmake[1]: *** [prims.lo] Error 1
gmake[1]: Leaving directory `/usr/obj/gcc/libjava'
gmake: *** [all-recursive] Error 1
*** Error code 2

Stop in /usr/src/gcc/libjava (line 99 of /usr/share/mk/bsd.cfwrap.mk).
*** Error code 1

Stop in /usr/src/gcc.
*** Error code 1

Stop in /usr/src/gcc (line 23 of /usr/src/gcc/Makefile).


What's more weird is: if I take the line which starts with "c++"
(the fourth line above) and just add a -E, then take the .i file
and give it to c++ with the same parametres, it gives me the same
errors - if I do a removal of all '^# [1-9].*$' lines on the .i
file, it compiles the file without errors.

Does anyone have an idea where to look?

Thanks,
//mirabile
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
	-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: GCC 3.4.4 Status (2005-04-29)

[Joseph S. Myers]

What's the position on closing 3.4 regression bugs which are fixed in 4.0 
and where it doesn't seem worthwhile to attempt to backport a fix?  I'm 
thinking in particular of issues relating to c-decl.c (16666, 18799, 
18935, 19694) since c-decl.c in 3.4 was part way through a rewrite and 
that intermediate version is fairly buggy and fragile.  Several other 3.4 
regression bugs relating to c-decl.c have previously been closed on the 
basis of being fixed in 4.0.0.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: GCC 3.4.4 Status (2005-04-29)

[Mark Mitchell]

Joseph S. Myers wrote:
> What's the position on closing 3.4 regression bugs which are fixed in 4.0 
> and where it doesn't seem worthwhile to attempt to backport a fix? 

They should be closed as FIXED, with a note.  It would be wrong to use 
WONTFIX, since the bug is in fact FIXED in 4.0; it might make sense to 
use WONTFIX if the bug was introduced on the 3.4 branch and never 
present elsewhere.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: libjava/3.4.4 problem (was Re: GCC 3.4.4 Status (2005-04-29))

[Andrew Pinski]

On Apr 29, 2005, at 5:33 PM, Thorsten Glaser wrote:

> Mark Mitchell dixit:
>
>> In general, GCC 3.4.3 is working for people

> Does anyone have an idea where to look?

This is a bug in your config, you forgot to define NO_IMPLICIT_EXTERN_C.

-- Pinski

Re: GCC 3.4.4 Status (2005-04-29)

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Now that GCC 4.0 is out the door, I've spent some time looking at the
| status of the 3.4 branch.  As stated previously, I'll be doing a 3.4.4
| release, and then turning the branch over to Gaby, to focus
| exclusively on 4.0/4.1. 

I'm happy to help there.  I have to post the status for 3.3.6 tonight
-- it is pretty satisfactory when considering pressing regressions.
It is actually quite good and very stable.

(My time have been mostly consumed recently in dealing with C++
concepts stuff and hopefully, one of the bigeest parts should be out
the door by tomorrow so that leaves more time to focus on getting
3.4.x continue as far as it proves useful and needed.  And I apologize
for that.)

-- Gaby

Re: libjava/3.4.4 problem

[Thorsten Glaser]

Andrew Pinski dixit:

>> Does anyone have an idea where to look?
>
> This is a bug in your config, you forgot to define NO_IMPLICIT_EXTERN_C.

Thanks a lot, I will try that after I updated to 20050429.

bye,
//mirabile

Re: libjava/3.4.4 problem (SOLVED)

[Thorsten Glaser]

Dixi:

>Mark Mitchell dixit:
>
>>In general, GCC 3.4.3 is working for people
>
>I've been playing around a lot with the various 3.4.4 snapshots
>lately, and got everything to work, except for libjava:

With the change in the configuration file, it works now. However,
I'm curious about why FreeBSD defines it while NetBSD and OpenBSD
do not, and which implications it might have elsewhere.

gcj works now, as in "99 Bottles of Beer" compiled from source to
bytecode and executed with sunjdk-1.4.2 (native), compiled from
source or bytecode to executable. gij does not work because boehm-gc
is (still) broken on all OpenBSD/ELF platforms (and, apparently,
OpenBSD derivates like MirOS). I'll try with GC disabled now.

libjava is a pain in the ass, regarding "writes to build directory
during installation time". libtool relinking issues, and the list
of headers to be installed. I have worked around these, but it's
probably unportable. Also, having its own libltdl is... weird.

But I'm really happy with the huge (and I mean it) increase in
overall quality between 3.2.3 and 3.4.4 (prerelease).

There's still one thing I miss: a list of all flags allowed for
a specific compiler/language. For example, I cannot specify -Wformat
for Ada, -DPIC for Java, etc. (at the moment, during libstdc++-v3
and libjava build I ignore the user-settable CFLAGS (/etc/mk.conf)
and for Ada I remove some via gmake features).
I suppose I might be able to dig it out from the source, though.
(What I was talking about is an easy to read overview, e.g. a table.)

bye,
//mirabile
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
	-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: GCC 3.4.4 Status (2005-04-29)

[Richard Guenther]

On 4/29/05, Mark Mitchell <mark@codesourcery.com> wrote:
> Joseph S. Myers wrote:
> > What's the position on closing 3.4 regression bugs which are fixed in 4.0
> > and where it doesn't seem worthwhile to attempt to backport a fix?
> 
> They should be closed as FIXED, with a note.  It would be wrong to use
> WONTFIX, since the bug is in fact FIXED in 4.0; it might make sense to
> use WONTFIX if the bug was introduced on the 3.4 branch and never
> present elsewhere.

What about bugs like PR17860 which are not regressions to previous versions
but fixed in 4.0?  In the audit trail there was the remark that closing as FIXED
is not ok.  Though I would say closing as FIXED and using the target milestone
to indicate where it was fixed seems ok.  WONTFIX would certainly be misleading
(though we won't fix it for the release the bug was reported against).

RIchard.

Re: GCC 3.4.4 Status (2005-04-29)

[Mark Mitchell]

Richard Guenther wrote:
> On 4/29/05, Mark Mitchell <mark@codesourcery.com> wrote:
> 
>>Joseph S. Myers wrote:
>>
>>>What's the position on closing 3.4 regression bugs which are fixed in 4.0
>>>and where it doesn't seem worthwhile to attempt to backport a fix?
>>
>>They should be closed as FIXED, with a note.  It would be wrong to use
>>WONTFIX, since the bug is in fact FIXED in 4.0; it might make sense to
>>use WONTFIX if the bug was introduced on the 3.4 branch and never
>>present elsewhere.
> 
> 
> What about bugs like PR17860 which are not regressions to previous versions
> but fixed in 4.0?  In the audit trail there was the remark that closing as FIXED
> is not ok.  Though I would say closing as FIXED and using the target milestone
> to indicate where it was fixed seems ok.  WONTFIX would certainly be misleading
> (though we won't fix it for the release the bug was reported against).

I'm not sure we need to worry too much about exactly how we mark these. 
  We've got the situation where 3.4.4 will follow 4.0.0 chronologically, 
though it somewhat precedes it conceptually.  So, what target milestone 
should we use?  I'm happy to use the one in which we first fixed the bug 
chronologically.  So, if we're not going to fix 17860 in 3.4.x, we 
should just marked it FIXED in 4.0.  But if we marked it WONTFIX, I 
don't think that would be a major problem.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: GCC 3.4.4 Status (2005-04-29)

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Richard Guenther wrote:
| > On 4/29/05, Mark Mitchell <mark@codesourcery.com> wrote:
| >
| >>Joseph S. Myers wrote:
| >>
| >>>What's the position on closing 3.4 regression bugs which are fixed in 4.0
| >>>and where it doesn't seem worthwhile to attempt to backport a fix?
| >>
| >>They should be closed as FIXED, with a note.  It would be wrong to use
| >>WONTFIX, since the bug is in fact FIXED in 4.0; it might make sense to
| >>use WONTFIX if the bug was introduced on the 3.4 branch and never
| >>present elsewhere.
| > What about bugs like PR17860 which are not regressions to previous
| > versions
| > but fixed in 4.0?  In the audit trail there was the remark that closing as FIXED
| > is not ok.  Though I would say closing as FIXED and using the target milestone
| > to indicate where it was fixed seems ok.  WONTFIX would certainly be misleading
| > (though we won't fix it for the release the bug was reported against).
| 
| I'm not sure we need to worry too much about exactly how we mark
| these. We've got the situation where 3.4.4 will follow 4.0.0
| chronologically, though it somewhat precedes it conceptually.  So,

I believe we could that this has become traditional, given experience
with the 3.2.x anf 3.3.x series.

| what target milestone should we use?  I'm happy to use the one in
| which we first fixed the bug chronologically.  So, if we're not going
| to fix 17860 in 3.4.x, we should just marked it FIXED in 4.0. 

that makes sense to me.

-- Gaby

Re: libjava/3.4.4 problem (SOLVED)

[Tom Tromey]

>>>>> "Thorsten" == Thorsten Glaser <tg@66h.42h.de> writes:

Thorsten> libjava is a pain in the ass, regarding "writes to build directory
Thorsten> during installation time". libtool relinking issues, and the list
Thorsten> of headers to be installed. I have worked around these, but it's
Thorsten> probably unportable.

Please file detailed bug reports for these.

Thorsten> Also, having its own libltdl is... weird.

It didn't seem reasonable to assume that libltdl would be available.
And, the cost of putting it in the tree seemed small.  I wouldn't mind
a configury option to use the system libltdl (like we do for zlib), if
someone wants to write it.

Tom

RE: GCC 3.4.4 Status (2005-04-29)

[Gary Funck]

> From: Mark Mitchell
> Sent: Friday, April 29, 2005 12:00 PM
> 
> Now that GCC 4.0 is out the door, I've spent some time looking at the
> status of the 3.4 branch.  As stated previously, I'll be doing a 3.4.4
> release, and then turning the branch over to Gaby, to focus
> exclusively on 4.0/4.1. [...]

What is the target date for 3.4.4?  Thanks.