Re: [PATCH] Delete GCJ

[Andrew Haley]

On 23/01/17 13:41, Jakub Jelinek wrote:
> On Mon, Jan 23, 2017 at 04:51:44AM -0800, Per Bothner wrote:

>> The last part is moot, as we should strive to not move pages and thus break 
>> links.
> 
> I meant updating URLs in the pages when they refer to external web pages
> which move over time (or switch from http to https, or disappear, etc.).  
> Gerald
> does a great job handling that, but if there are too many pages for
> historical purpose only, it will make his work harder.

We can redirect to somewhere else.

Andrew.

Re: [PATCH] Delete GCJ

[Jakub Jelinek]

On Mon, Jan 23, 2017 at 04:51:44AM -0800, Per Bothner wrote:
> On 01/23/2017 01:05 AM, Jakub Jelinek wrote:
> > On Mon, Jan 23, 2017 at 09:01:24AM +, Andrew Haley wrote:
> > > On 22/01/17 18:41, Per Bothner wrote:
> > > > In my opinion, all/most of these should be restored.
> > > 
> > > Because of the historical interest?  That's a good point, and perhaps
> > > I was too hasty.  Sorry.
> > 
> > But then it should be probably moved somewhere where Gerald won't have to
> > spent time maintaining those pages (verification of URLs in there, updating
> > them when they are moved etc.).
> 
> The last part is moot, as we should strive to not move pages and thus break 
> links.

I meant updating URLs in the pages when they refer to external web pages
which move over time (or switch from http to https, or disappear, etc.).  Gerald
does a great job handling that, but if there are too many pages for
historical purpose only, it will make his work harder.

Jakub

Re: [PATCH] Delete GCJ

[Per Bothner]

On 01/23/2017 01:05 AM, Jakub Jelinek wrote:

On Mon, Jan 23, 2017 at 09:01:24AM +, Andrew Haley wrote:

On 22/01/17 18:41, Per Bothner wrote:

In my opinion, all/most of these should be restored.


Because of the historical interest?  That's a good point, and perhaps
I was too hasty.  Sorry.


But then it should be probably moved somewhere where Gerald won't have to
spent time maintaining those pages (verification of URLs in there, updating
them when they are moved etc.).


The last part is moot, as we should strive to not move pages and thus break 
links.
--
--Per Bothner
p...@bothner.com   http://per.bothner.com/

Re: [PATCH] Delete GCJ

[Jakub Jelinek]

On Mon, Jan 23, 2017 at 09:01:24AM +, Andrew Haley wrote:
> On 22/01/17 18:41, Per Bothner wrote:
> > In my opinion, all/most of these should be restored.
> 
> Because of the historical interest?  That's a good point, and perhaps
> I was too hasty.  Sorry.

But then it should be probably moved somewhere where Gerald won't have to
spent time maintaining those pages (verification of URLs in there, updating
them when they are moved etc.).  Also to make it clear that GCJ is no longer
supported.

Jakub

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 22/01/17 18:41, Per Bothner wrote:
> In my opinion, all/most of these should be restored.

Because of the historical interest?  That's a good point, and perhaps
I was too hasty.  Sorry.

Andrew.

Re: [PATCH] Delete GCJ

[Gerald Pfeifer]

On Sun, 2 Oct 2016, Andreas Schwab wrote:
> Things we may want to remove:
> 
> - references to java in contrib (download_ecj, gcc_update,
>   patch_tester.sh, update-copyright.py)

I have taken care of these (patch_tester.sh to follow shortly)...

> - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
> - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
> - references to java in install.texi

...and config/i386 as well as libgcc and install.texi, plus a
number of changes on the web pages.

Is there anything else you see?  Anything you might help tackle?

Gerald

Re: [PATCH] Delete GCJ

[Per Bothner]

In my opinion, all/most of these should be restored.

On 01/22/2017 08:51 AM, Gerald Pfeifer wrote:

On Fri, 30 Sep 2016, Andrew Haley wrote:

Note I did not include all the removed java/* contents.  Is there
anything particular you'd like to retain there?

No, please delete it all.


Okay, so I (finally) went ahead and removed all of java/papers:

cvs commit: Examining java/papers
cvs commit: Examining java/papers/cni
Removing java/papers/README.sgml;
/cvs/gcc/wwwdocs/htdocs/java/papers/README.sgml,v  <--  README.sgml
new revision: delete; previous revision: 1.1
done
Removing java/papers/cni.sgml;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni.sgml,v  <--  cni.sgml
new revision: delete; previous revision: 1.5
done
Removing java/papers/compcon97.ps.gz;
/cvs/gcc/wwwdocs/htdocs/java/papers/compcon97.ps.gz,v  <--  compcon97.ps.gz
new revision: delete; previous revision: 1.1
done
Removing java/papers/compiling.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/compiling.html,v  <--  compiling.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/compjava.pdf;
/cvs/gcc/wwwdocs/htdocs/java/papers/compjava.pdf,v  <--  compjava.pdf
new revision: delete; previous revision: 1.1
done
Removing java/papers/compjava.ps.gz;
/cvs/gcc/wwwdocs/htdocs/java/papers/compjava.ps.gz,v  <--  compjava.ps.gz
new revision: delete; previous revision: 1.1
done
Removing java/papers/esc97.sgml;
/cvs/gcc/wwwdocs/htdocs/java/papers/esc97.sgml,v  <--  esc97.sgml
new revision: delete; previous revision: 1.1
done
Removing java/papers/esc97w-slides.ps.gz;
/cvs/gcc/wwwdocs/htdocs/java/papers/esc97w-slides.ps.gz,v  <--  
esc97w-slides.ps.gz
new revision: delete; previous revision: 1.1
done
Removing java/papers/gcc-java.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/gcc-java.html,v  <--  gcc-java.html
new revision: delete; previous revision: 1.6
done
Removing java/papers/gcc-java.ps.gz;
/cvs/gcc/wwwdocs/htdocs/java/papers/gcc-java.ps.gz,v  <--  gcc-java.ps.gz
new revision: delete; previous revision: 1.1
done
Removing java/papers/native++.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/native++.html,v  <--  native++.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/native++.sgml;
/cvs/gcc/wwwdocs/htdocs/java/papers/native++.sgml,v  <--  native++.sgml
new revision: delete; previous revision: 1.3
done
Removing java/papers/nosb.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/nosb.html,v  <--  nosb.html
new revision: delete; previous revision: 1.6
done
Removing java/papers/nosb.ps.gz;
/cvs/gcc/wwwdocs/htdocs/java/papers/nosb.ps.gz,v  <--  nosb.ps.gz
new revision: delete; previous revision: 1.1
done
Removing java/papers/page.png;
/cvs/gcc/wwwdocs/htdocs/java/papers/page.png,v  <--  page.png
new revision: delete; previous revision: 1.1
done
Removing java/papers/table.png;
/cvs/gcc/wwwdocs/htdocs/java/papers/table.png,v  <--  table.png
new revision: delete; previous revision: 1.1
done
Removing java/papers/cni/HTML.manifest;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/HTML.manifest,v  <--  HTML.manifest
new revision: delete; previous revision: 1.3
done
Removing java/papers/cni/t1.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1.html,v  <--  t1.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/cni/t1178.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1178.html,v  <--  t1178.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1215.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1215.html,v  <--  t1215.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1262.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1262.html,v  <--  t1262.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/cni/t1308.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1308.html,v  <--  t1308.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1324.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1324.html,v  <--  t1324.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1331.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1331.html,v  <--  t1331.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t134.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t134.html,v  <--  t134.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/cni/t1405.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1405.html,v  <--  t1405.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1421.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1421.html,v  <--  t1421.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/cni/t1431.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1431.html,v  <--  t1431.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1457.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1457.html,v  <--  t1457.html
new revision: delete; previous revision: 1.1
done
Removing java/papers/cni/t1467.html;

Re: [PATCH] Delete GCJ

[Gerald Pfeifer]

And here is more or less the last patch in this series, removing
java/libgcj2.html and two images (gcj.jpg and swingshot.png).

The only thing left in wwwdocs is a potential merge of java/news.html
into our general news.html that I am considering.  That'd take a bit
more time, and I'll see whether I can do that before the GCC 7.1 release.

Gerald

Index: java/libgcj2.html
===
RCS file: java/libgcj2.html
diff -N java/libgcj2.html
--- java/libgcj2.html   30 Jun 2014 09:29:09 -  1.12
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,38 +0,0 @@
-
-
-
-The libgcj home page
-
-
-
-
-The libgcj home page
-
-What is it?
-
-``libgcj'' is the runtime that goes along with the gcj front end to GCC.  libgcj includes parts
-of the Java Class Libraries, plus glue to connect the libraries to
-the compiler and the underlying OS.
-
-What you get
-
-libgcj eventually builds a couple of libraries (one for the
-runtime and one for the garbage collector), a ``zip'' version of
-the class libraries, and a program called ``jv-convert'' which can
-be used to do character encoding transformations.
-
-What is missing?
-
-The runtime is not yet fully complete.  Parts of the standard
-class libraries are missing (most notably AWT), though much of the
-equivalent of JDK 1.2 has been supported.
-Also, the bytecode interpreter available only on certain platforms.
-
-How to build it
-
-Just follow our https://gcc.gnu.org/install/;>installation
-instructions.
-
-
-
Index: java/gcj.jpg
===
RCS file: java/gcj.jpg
diff -N java/gcj.jpg
Binary files /tmp/cvseTgpza and /dev/null differ
Index: java/swingshot.png
===
RCS file: java/swingshot.png
diff -N java/swingshot.png
Binary files /tmp/cvsGkz1jF and /dev/null differ

Re: [PATCH] Delete GCJ

[Gerald Pfeifer]

On Fri, 30 Sep 2016, Andrew Haley wrote:
>> Note I did not include all the removed java/* contents.  Is there
>> anything particular you'd like to retain there?
> No, please delete it all.

Okay, so I (finally) went ahead and removed all of java/papers:

cvs commit: Examining java/papers
cvs commit: Examining java/papers/cni
Removing java/papers/README.sgml;
/cvs/gcc/wwwdocs/htdocs/java/papers/README.sgml,v  <--  README.sgml
new revision: delete; previous revision: 1.1
done
Removing java/papers/cni.sgml;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni.sgml,v  <--  cni.sgml
new revision: delete; previous revision: 1.5
done
Removing java/papers/compcon97.ps.gz;
/cvs/gcc/wwwdocs/htdocs/java/papers/compcon97.ps.gz,v  <--  compcon97.ps.gz
new revision: delete; previous revision: 1.1
done
Removing java/papers/compiling.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/compiling.html,v  <--  compiling.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/compjava.pdf;
/cvs/gcc/wwwdocs/htdocs/java/papers/compjava.pdf,v  <--  compjava.pdf
new revision: delete; previous revision: 1.1
done
Removing java/papers/compjava.ps.gz;
/cvs/gcc/wwwdocs/htdocs/java/papers/compjava.ps.gz,v  <--  compjava.ps.gz
new revision: delete; previous revision: 1.1
done
Removing java/papers/esc97.sgml;
/cvs/gcc/wwwdocs/htdocs/java/papers/esc97.sgml,v  <--  esc97.sgml
new revision: delete; previous revision: 1.1
done
Removing java/papers/esc97w-slides.ps.gz;
/cvs/gcc/wwwdocs/htdocs/java/papers/esc97w-slides.ps.gz,v  <--  
esc97w-slides.ps.gz
new revision: delete; previous revision: 1.1
done
Removing java/papers/gcc-java.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/gcc-java.html,v  <--  gcc-java.html
new revision: delete; previous revision: 1.6
done
Removing java/papers/gcc-java.ps.gz;
/cvs/gcc/wwwdocs/htdocs/java/papers/gcc-java.ps.gz,v  <--  gcc-java.ps.gz
new revision: delete; previous revision: 1.1
done
Removing java/papers/native++.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/native++.html,v  <--  native++.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/native++.sgml;
/cvs/gcc/wwwdocs/htdocs/java/papers/native++.sgml,v  <--  native++.sgml
new revision: delete; previous revision: 1.3
done
Removing java/papers/nosb.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/nosb.html,v  <--  nosb.html
new revision: delete; previous revision: 1.6
done
Removing java/papers/nosb.ps.gz;
/cvs/gcc/wwwdocs/htdocs/java/papers/nosb.ps.gz,v  <--  nosb.ps.gz
new revision: delete; previous revision: 1.1
done
Removing java/papers/page.png;
/cvs/gcc/wwwdocs/htdocs/java/papers/page.png,v  <--  page.png
new revision: delete; previous revision: 1.1
done
Removing java/papers/table.png;
/cvs/gcc/wwwdocs/htdocs/java/papers/table.png,v  <--  table.png
new revision: delete; previous revision: 1.1
done
Removing java/papers/cni/HTML.manifest;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/HTML.manifest,v  <--  HTML.manifest
new revision: delete; previous revision: 1.3
done
Removing java/papers/cni/t1.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1.html,v  <--  t1.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/cni/t1178.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1178.html,v  <--  t1178.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1215.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1215.html,v  <--  t1215.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1262.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1262.html,v  <--  t1262.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/cni/t1308.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1308.html,v  <--  t1308.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1324.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1324.html,v  <--  t1324.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1331.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1331.html,v  <--  t1331.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t134.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t134.html,v  <--  t134.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/cni/t1405.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1405.html,v  <--  t1405.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1421.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1421.html,v  <--  t1421.html
new revision: delete; previous revision: 1.3
done
Removing java/papers/cni/t1431.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1431.html,v  <--  t1431.html
new revision: delete; previous revision: 1.2
done
Removing java/papers/cni/t1457.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1457.html,v  <--  t1457.html
new revision: delete; previous revision: 1.1
done
Removing java/papers/cni/t1467.html;
/cvs/gcc/wwwdocs/htdocs/java/papers/cni/t1467.html,v  <--  t1467.html
new revision: delete; previous revision: 1.2

Re: Remove stray '@' from install.texi (was Re: [PATCH] Delete GCJ)

[David Malcolm]

On Tue, 2016-11-29 at 18:20 -0700, Sandra Loosemore wrote:
> On 11/29/2016 06:10 PM, David Malcolm wrote:
> > [snip]
> > 
> > r242985 seems to have broken the build, for me at least (with
> > texinfo
> > 5.1):
> > 
> > ../../src/gcc/doc/install.texi:2199: use braces to give a command
> > as an argument to @=
> > make[2]: *** [doc/gccinstall.info] Error 1
> > 
> > The attached patch fixes it.
> > 
> > OK to commit?
> 
> OK.  (This is so trivial it would qualify under the obvious patch
> rule 
> anyway.)
> 
> -Sandra

My texinfo skills aren't as strong as yours, so I was half-wondering if
this was some syntax I wasn't aware of, or maybe a version issue. 

Thanks for the confirmation; committed to trunk as r242991.

Dave

Re: Remove stray '@' from install.texi (was Re: [PATCH] Delete GCJ)

[Sandra Loosemore]

On 11/29/2016 06:10 PM, David Malcolm wrote:

[snip]

r242985 seems to have broken the build, for me at least (with texinfo
5.1):

../../src/gcc/doc/install.texi:2199: use braces to give a command as an 
argument to @=
make[2]: *** [doc/gccinstall.info] Error 1

The attached patch fixes it.

OK to commit?


OK.  (This is so trivial it would qualify under the obvious patch rule 
anyway.)


-Sandra

Remove stray '@' from install.texi (was Re: [PATCH] Delete GCJ)

[David Malcolm]

On Tue, 2016-11-29 at 14:23 -0700, Jeff Law wrote:
> On 11/21/2016 04:23 PM, Matthias Klose wrote:
> > On 21.11.2016 18:16, Rainer Orth wrote:
> > > Hi Matthias,
> > > 
> > > > ahh, didn't see that :-/ Now fixed, is this clearer now?
> > > > 
> > > > The options @option{--with-target-bdw-gc-include} and
> > > > @option{--with-target-bdw-gc-lib} must always specified
> > > > together for
> > >^ be
> > 
> > thanks to all sorting out the documentation issues. Now attaching
> > the updated
> > diff. Ok to commit?
> > 
> > Matthias
> > 
> > 

[...]

> > gcc/
> > 
> > 2016-11-19  Matthias Klose  
> > 
> > * doc/install.texi: Document configure options --enable
> > -objc-gc
> > and --with-target-bdw-gc.

[...]

r242985 seems to have broken the build, for me at least (with texinfo
5.1):

../../src/gcc/doc/install.texi:2199: use braces to give a command as an 
argument to @=
make[2]: *** [doc/gccinstall.info] Error 1

The attached patch fixes it.

OK to commit?
DaveFrom 60ec369e17c898fb3cdcbca43ed77d450a30d074 Mon Sep 17 00:00:00 2001
From: David Malcolm 
Date: Tue, 29 Nov 2016 20:38:53 -0500
Subject: [PATCH] Remove stray character from install.texi

gcc/ChangeLog:
	* doc/install.texi (--with-target-bdw-gc): Remove stray '@'.
---
 gcc/doc/install.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5d96e5f..140ff80 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2196,7 +2196,7 @@ continues.
 @itemx --with-target-bdw-gc-lib=@var{list}
 Specify search directories for the garbage collector header files and
 libraries. @var{list} is a comma separated list of key value pairs of the
-form @samp{@var{multilibdir}@=@var{path}}, where the default multilib key
+form @samp{@var{multilibdir}=@var{path}}, where the default multilib key
 is named as @samp{.} (dot), or is omitted (e.g.
 @samp{--with-target-bdw-gc=/opt/bdw-gc,32=/opt-bdw-gc32}).
 
-- 
1.8.5.3

Re: [PATCH] Delete GCJ

[Jeff Law]

On 11/21/2016 04:23 PM, Matthias Klose wrote:

On 21.11.2016 18:16, Rainer Orth wrote:

Hi Matthias,


ahh, didn't see that :-/ Now fixed, is this clearer now?

The options @option{--with-target-bdw-gc-include} and
@option{--with-target-bdw-gc-lib} must always specified together for

   ^ be


thanks to all sorting out the documentation issues. Now attaching the updated
diff. Ok to commit?

Matthias



2016-11-19  Matthias Klose  

* Makefile.def: Remove reference to boehm-gc target module.
* configure.ac: Include pkg.m4, check for --with-target-bdw-gc
options and for the bdw-gc pkg-config module.
* configure: Regenerate.
* Makefile.in: Regenerate.

gcc/

2016-11-19  Matthias Klose  

* doc/install.texi: Document configure options --enable-objc-gc
and --with-target-bdw-gc.

config/

2016-11-19  Matthias Klose  

* pkg.m4: New file.

libobjc/

2016-11-19  Matthias Klose  

* configure.ac (--enable-objc-gc): Allow to configure with a
system provided boehm-gc.
* configure: Regenerate.
* Makefile.in (OBJC_BOEHM_GC_LIBS): Get value from configure.
* gc.c: Include system bdw-gc headers.
* memory.c: Likewise
* objects.c: Likewise

boehm-gc/

2016-11-19  Matthias Klose  

Remove

OK.

Jeff

Re: [PATCH] Delete GCJ

[Sandra Loosemore]

On 11/21/2016 04:23 PM, Matthias Klose wrote:

On 21.11.2016 18:16, Rainer Orth wrote:

Hi Matthias,


ahh, didn't see that :-/ Now fixed, is this clearer now?

The options @option{--with-target-bdw-gc-include} and
@option{--with-target-bdw-gc-lib} must always specified together for

^ be


thanks to all sorting out the documentation issues. Now attaching the updated
diff. Ok to commit?


The documentation part is OK now.

-Sandra

Re: [PATCH] Delete GCJ

[Matthias Klose]

On 21.11.2016 18:16, Rainer Orth wrote:
> Hi Matthias,
> 
>> ahh, didn't see that :-/ Now fixed, is this clearer now?
>>
>> The options @option{--with-target-bdw-gc-include} and
>> @option{--with-target-bdw-gc-lib} must always specified together for
>^ be 

thanks to all sorting out the documentation issues. Now attaching the updated
diff. Ok to commit?

Matthias



2016-11-19  Matthias Klose  

* Makefile.def: Remove reference to boehm-gc target module.
* configure.ac: Include pkg.m4, check for --with-target-bdw-gc
options and for the bdw-gc pkg-config module.
* configure: Regenerate.
* Makefile.in: Regenerate.

gcc/

2016-11-19  Matthias Klose  

* doc/install.texi: Document configure options --enable-objc-gc
and --with-target-bdw-gc.

config/

2016-11-19  Matthias Klose  

* pkg.m4: New file.

libobjc/

2016-11-19  Matthias Klose  

* configure.ac (--enable-objc-gc): Allow to configure with a
system provided boehm-gc.
* configure: Regenerate.
* Makefile.in (OBJC_BOEHM_GC_LIBS): Get value from configure.
* gc.c: Include system bdw-gc headers.
* memory.c: Likewise
* objects.c: Likewise

boehm-gc/

2016-11-19  Matthias Klose  

Remove



2016-11-19  Matthias Klose  

	* Makefile.def: Remove reference to boehm-gc target module.
  	* configure.ac: Include pkg.m4, check for --with-target-bdw-gc
	options and for the bdw-gc pkg-config module.
	* configure: Regenerate.
	* Makefile.in: Regenerate.

gcc/

2016-11-19  Matthias Klose  

	* doc/install.texi: Document configure options --enable-objc-gc
	and --with-target-bdw-gc.

config/

2016-11-19  Matthias Klose  

	* pkg.m4: New file.

libobjc/

2016-11-19  Matthias Klose  

	* configure.ac (--enable-objc-gc): Allow to configure with a
	system provided boehm-gc.
	* configure: Regenerate.
	* Makefile.in (OBJC_BOEHM_GC_LIBS): Get value from configure.
	* gc.c: Include system bdw-gc headers.
	* memory.c: Likewise
	* objects.c: Likewise

boehm-gc/

2016-11-19  Matthias Klose  

	Remove

Index: Makefile.def
===
--- Makefile.def	(revision 242681)
+++ Makefile.def	(working copy)
@@ -166,7 +166,6 @@
 target_modules = { module= libgloss; no_check=true; };
 target_modules = { module= libffi; no_install=true; };
 target_modules = { module= zlib; };
-target_modules = { module= boehm-gc; };
 target_modules = { module= rda; };
 target_modules = { module= libada; };
 target_modules = { module= libgomp; bootstrap= true; lib_path=.libs; };
@@ -543,7 +542,6 @@
 // a dependency on libgcc for native targets to configure.
 lang_env_dependencies = { module=libiberty; no_c=true; };
 
-dependencies = { module=configure-target-boehm-gc; on=all-target-libstdc++-v3; };
 dependencies = { module=configure-target-fastjar; on=configure-target-zlib; };
 dependencies = { module=all-target-fastjar; on=all-target-zlib; };
 dependencies = { module=configure-target-libgo; on=configure-target-libffi; };
@@ -551,8 +549,6 @@
 dependencies = { module=all-target-libgo; on=all-target-libbacktrace; };
 dependencies = { module=all-target-libgo; on=all-target-libffi; };
 dependencies = { module=all-target-libgo; on=all-target-libatomic; };
-dependencies = { module=configure-target-libobjc; on=configure-target-boehm-gc; };
-dependencies = { module=all-target-libobjc; on=all-target-boehm-gc; };
 dependencies = { module=configure-target-libstdc++-v3; on=configure-target-libgomp; };
 dependencies = { module=configure-target-liboffloadmic; on=configure-target-libgomp; };
 dependencies = { module=configure-target-libsanitizer; on=all-target-libstdc++-v3; };
Index: config/pkg.m4
===
--- config/pkg.m4	(nonexistent)
+++ config/pkg.m4	(working copy)
@@ -0,0 +1,825 @@
+dnl pkg.m4 - Macros to locate and utilise pkg-config.   -*- Autoconf -*-
+dnl serial 11 (pkg-config-0.29)
+dnl
+dnl Copyright © 2004 Scott James Remnant .
+dnl Copyright © 2012-2015 Dan Nicholson 
+dnl
+dnl This program is free software; you can redistribute it and/or modify
+dnl it under the terms of the GNU General Public License as published by
+dnl the Free Software Foundation; either version 2 of the License, or
+dnl (at your option) any later version.
+dnl
+dnl This program is distributed in the hope that it will be useful, but
+dnl WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+dnl General Public License for more details.
+dnl
+dnl You should have received a copy of the GNU General Public License
+dnl along with this program; if not, write to the Free 

Re: [PATCH] Delete GCJ

[Rainer Orth]

Hi Matthias,

> ahh, didn't see that :-/ Now fixed, is this clearer now?
>
> The options @option{--with-target-bdw-gc-include} and
> @option{--with-target-bdw-gc-lib} must always specified together for
   ^ be 
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Delete GCJ

[Peter Bergner]

On 11/21/16 10:40 AM, Matthias Klose wrote:

On 21.11.2016 17:23, Sandra Loosemore wrote:

On 11/21/2016 05:57 AM, Matthias Klose wrote:
I'm sure you didn't mean exactly the same --with-foo in all 3 places, but I'm a
dummy about what you really intended to say here.


ahh, didn't see that :-/ Now fixed, is this clearer now?

The options @option{--with-target-bdw-gc-include} and
@option{--with-target-bdw-gc-lib} must always specified together for
each multilib variant and take precedence over
@option{--with-target-bdw-gc}.  If none of these options are
specified, the values are taken from the @command{pkg-config}
@samp{bdw-gc} module.


s/must always specified/must always be specified/

and possibly:

s/variant and take precedence/variant and they take precedence/ ???


Peter

Re: [PATCH] Delete GCJ

[Matthias Klose]

On 21.11.2016 17:23, Sandra Loosemore wrote:
> On 11/21/2016 05:57 AM, Matthias Klose wrote:
>>
>> --with-target-bdw-gc=/opt/bdw-gc,32=/opt/bdw-gc32
>>
>> sets the include and lib dirs by appending include and lib to the paths. If 
>> you
>> have options --with-target-bdw-gc-include= and --with-target-bdw-gc-lib= as
>> well, it overrides the settings done in --with-target-bdw-gc=. This is copied
>> from the setting of the gmp/mpfr options.
>>
>> Any of these options override the automatic discovery using pkg-config.
>>
>> Please suggest a better wording; I thought that was clear enough (and better
>> than the undocumented --enable-libobjc-gc anyway ;)
> 
> FAOD, my complaint about your patch is that it essentially said
> 
> "The options --with-foo and --with-foo must also be specified together and
> override --with-foo."
> 
> I'm sure you didn't mean exactly the same --with-foo in all 3 places, but I'm 
> a
> dummy about what you really intended to say here.

ahh, didn't see that :-/ Now fixed, is this clearer now?

The options @option{--with-target-bdw-gc-include} and
@option{--with-target-bdw-gc-lib} must always specified together for
each multilib variant and take precedence over
@option{--with-target-bdw-gc}.  If none of these options are
specified, the values are taken from the @command{pkg-config}
@samp{bdw-gc} module.

Matthias

Re: [PATCH] Delete GCJ

[Sandra Loosemore]

On 11/21/2016 05:57 AM, Matthias Klose wrote:


--with-target-bdw-gc=/opt/bdw-gc,32=/opt/bdw-gc32

sets the include and lib dirs by appending include and lib to the paths. If you
have options --with-target-bdw-gc-include= and --with-target-bdw-gc-lib= as
well, it overrides the settings done in --with-target-bdw-gc=. This is copied
from the setting of the gmp/mpfr options.

Any of these options override the automatic discovery using pkg-config.

Please suggest a better wording; I thought that was clear enough (and better
than the undocumented --enable-libobjc-gc anyway ;)


FAOD, my complaint about your patch is that it essentially said

"The options --with-foo and --with-foo must also be specified together 
and override --with-foo."


I'm sure you didn't mean exactly the same --with-foo in all 3 places, 
but I'm a dummy about what you really intended to say here.


-Sandra

Re: [PATCH] Delete GCJ

[Matthias Klose]

On 21.11.2016 11:23, Iain Sandoe wrote:
> 
>> On 20 Nov 2016, at 20:42, Matthias Klose  wrote:
>>
>> On 10.10.2016 09:58, Iain Sandoe wrote:
>>>
> 
>>> The point here was to simplify the dependent configury so that it only 
>>> needs to test something that the configuring user specifies (i.e. if they 
>>> specify objc-gc, then they need also to specify the place that the gc lib 
>>> can be found).
>>
>> So here is the next proposal, I hope the added documentation in install.texi
>> makes the usage clear.
> 
> thanks for working on this!
> 
>>
>> 
>>
>> 2016-11-19  Matthias Klose  
>>
>>  * Makefile.def: Remove reference to boehm-gc target module.
>>  * configure.ac: Include pkg.m4, check for --with-target-bdw-gc
>>  options and for the bdw-gc pkg-config module.
>>  * configure: Regenerate.
>>  * Makefile.in: Regenerate.
> 
> 
> +AC_ARG_ENABLE(objc-gc,
> +[AS_HELP_STRING([--enable-objc-gc],
> + [enable use of Boehm's garbage collector with the
> +  GNU Objective-C runtime])])
> +AC_ARG_WITH([target-bdw-gc],
> +[AS_HELP_STRING([--with-target-bdw-gc=PATHLIST],
> + [specify prefix directory for installed bdw-gc package.
> +  Equivalent to --with-bdw-gc-include=PATH/include
> +  plus --with-bdw-gc-lib=PATH/lib])])
> 
> missing “target” in the --with-bdw-gc-*

thanks, fixed.

>> gcc/
>>
>> 2016-11-19  Matthias Klose  
>>
>>  * doc/install.texi: Document configure options --enable-objc-gc
>>  and --with-target-bdw-gc.
> 
> As per Sandra’s comment,  should we understand the priority of options is
> 
> --with-target-bdw-gc-*
> 
> which overrides…
> 
> --with-target-bdw-gc=
> 
> which overrides automatic discovery using pkg_config?

--with-target-bdw-gc=/opt/bdw-gc,32=/opt/bdw-gc32

sets the include and lib dirs by appending include and lib to the paths. If you
have options --with-target-bdw-gc-include= and --with-target-bdw-gc-lib= as
well, it overrides the settings done in --with-target-bdw-gc=. This is copied
from the setting of the gmp/mpfr options.

Any of these options override the automatic discovery using pkg-config.

Please suggest a better wording; I thought that was clear enough (and better
than the undocumented --enable-libobjc-gc anyway ;)

Matthias

Re: [PATCH] Delete GCJ

[Iain Sandoe]

> On 20 Nov 2016, at 20:42, Matthias Klose  wrote:
> 
> On 10.10.2016 09:58, Iain Sandoe wrote:
>> 

>> The point here was to simplify the dependent configury so that it only needs 
>> to test something that the configuring user specifies (i.e. if they specify 
>> objc-gc, then they need also to specify the place that the gc lib can be 
>> found).
> 
> So here is the next proposal, I hope the added documentation in install.texi
> makes the usage clear.

thanks for working on this!

> 
> 
> 
> 2016-11-19  Matthias Klose  
> 
>   * Makefile.def: Remove reference to boehm-gc target module.
>   * configure.ac: Include pkg.m4, check for --with-target-bdw-gc
>   options and for the bdw-gc pkg-config module.
>   * configure: Regenerate.
>   * Makefile.in: Regenerate.


+AC_ARG_ENABLE(objc-gc,
+[AS_HELP_STRING([--enable-objc-gc],
+   [enable use of Boehm's garbage collector with the
+GNU Objective-C runtime])])
+AC_ARG_WITH([target-bdw-gc],
+[AS_HELP_STRING([--with-target-bdw-gc=PATHLIST],
+   [specify prefix directory for installed bdw-gc package.
+Equivalent to --with-bdw-gc-include=PATH/include
+plus --with-bdw-gc-lib=PATH/lib])])

missing “target” in the --with-bdw-gc-*

> 
> gcc/
> 
> 2016-11-19  Matthias Klose  
> 
>   * doc/install.texi: Document configure options --enable-objc-gc
>   and --with-target-bdw-gc.

As per Sandra’s comment,  should we understand the priority of options is

--with-target-bdw-gc-*

which overrides…

--with-target-bdw-gc=

which overrides automatic discovery using pkg_config?

Iain

Re: [PATCH] Delete GCJ

[Sandra Loosemore]

On 11/20/2016 01:42 PM, Matthias Klose wrote:


+The options @option{--with-target-bdw-gc-include} and
+@option{--with-target-bdw-gc-include} must always specified together for
+each multilib variant and take precedence over
+@option{--with-target-bdw-gc-include}.  If none of these options are
+specified, the values are taken from the @command{pkg-config}
+@samp{bdw-gc} module.


This paragraph makes no sense to me.  :-(

-Sandra

Re: [PATCH] Delete GCJ

[Matthias Klose]

On 10.10.2016 09:58, Iain Sandoe wrote:
> 
>> On 10 Oct 2016, at 05:03, Matthias Klose  wrote:
>>
>> On 07.10.2016 10:30, Iain Sandoe wrote:
>>>
 On 7 Oct 2016, at 00:58, Matthias Klose  wrote:

 On 06.10.2016 20:00, Mike Stump wrote:
> On Oct 6, 2016, at 9:56 AM, Rainer Orth  
> wrote:
>> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
>> warning.  The Objective-C maintainers may have other preferences, though.

 I think I can't do that in the top level make file very well (currently I 
 only
 have the pkg-config check there for an early failure, but that check 
 doesn't
 tell me if the library is present for all multilib variants). And I can't 
 check
 for multilibs because I don't know if the bootstrap compiler is multilib 
 aware.
>>>
>>> hrm, so perhaps we need a —with-target-boehm-gc= type arrangement, and it’s 
>>> the configurer’s responsibility to provide a path with appropriate 
>>> headers/libs for the multi-lib configuration being attempted.
>>
>> I don't understand what you are proposing here.
> 
> given that:
>  auto-detection of the capabilities could be quite difficult (or, in the 
> general case, unachievable) for the reasons you gave.
>  the chosen target libraries might be in a non-standard place.
> 
> making it an explicit requirement to point to them, and to ensure that the 
> versions/multi-libs provided are suitable, (by putting 
> —with-target-boehm-gc=/path/to/suitable/) would mean that the dependent 
> configury (for objc-gc) could be just conditional upon the  presence of the 
> "with-target-boehm-gc”.
> 
> I suppose that one could make "—with-target-boehm-gc” (no attached path) 
> declare that the library (and requisite mult-lib versions) will be found in 
> the sysroot without any additional work.
> 
> The point here was to simplify the dependent configury so that it only needs 
> to test something that the configuring user specifies (i.e. if they specify 
> objc-gc, then they need also to specify the place that the gc lib can be 
> found).

So here is the next proposal, I hope the added documentation in install.texi
makes the usage clear.



2016-11-19  Matthias Klose  

* Makefile.def: Remove reference to boehm-gc target module.
* configure.ac: Include pkg.m4, check for --with-target-bdw-gc
options and for the bdw-gc pkg-config module.
* configure: Regenerate.
* Makefile.in: Regenerate.

gcc/

2016-11-19  Matthias Klose  

* doc/install.texi: Document configure options --enable-objc-gc
and --with-target-bdw-gc.

config/

2016-11-19  Matthias Klose  

* pkg.m4: New file.

libobjc/

2016-11-19  Matthias Klose  

* configure.ac (--enable-objc-gc): Allow to configure with a
system provided boehm-gc.
* configure: Regenerate.
* Makefile.in (OBJC_BOEHM_GC_LIBS): Get value from configure.
* gc.c: Include system bdw-gc headers.
* memory.c: Likewise
* objects.c: Likewise

boehm-gc/

2016-11-19  Matthias Klose  

Remove





2016-11-19  Matthias Klose  

	* Makefile.def: Remove reference to boehm-gc target module.
  	* configure.ac: Include pkg.m4, check for --with-target-bdw-gc
	options and for the bdw-gc pkg-config module.
	* configure: Regenerate.
	* Makefile.in: Regenerate.

gcc/

2016-11-19  Matthias Klose  

	* doc/install.texi: Document configure options --enable-objc-gc
	and --with-target-bdw-gc.

config/

2016-11-19  Matthias Klose  

	* pkg.m4: New file.

libobjc/

2016-11-19  Matthias Klose  

	* configure.ac (--enable-objc-gc): Allow to configure with a
	system provided boehm-gc.
	* configure: Regenerate.
	* Makefile.in (OBJC_BOEHM_GC_LIBS): Get value from configure.
	* gc.c: Include system bdw-gc headers.
	* memory.c: Likewise
	* objects.c: Likewise

boehm-gc/

2016-11-19  Matthias Klose  

	Remove

Index: Makefile.def
===
--- Makefile.def	(revision 242638)
+++ Makefile.def	(working copy)
@@ -166,7 +166,6 @@
 target_modules = { module= libgloss; no_check=true; };
 target_modules = { module= libffi; no_install=true; };
 target_modules = { module= zlib; };
-target_modules = { module= boehm-gc; };
 target_modules = { module= rda; };
 target_modules = { module= libada; };
 target_modules = { module= libgomp; bootstrap= true; lib_path=.libs; };
@@ -543,7 +542,6 @@
 // a dependency on libgcc for native targets to configure.
 lang_env_dependencies = { module=libiberty; no_c=true; };
 
-dependencies = { module=configure-target-boehm-gc; on=all-target-libstdc++-v3; };
 dependencies = { module=configure-target-fastjar; on=configure-target-zlib; };
 dependencies = { 

Re: [PATCH] Delete GCJ

[Jakub Jelinek]

On Sat, Oct 29, 2016 at 09:07:42AM +, Bernd Edlinger wrote:
> > Things we may want to remove:
> > 
> > - references to java in contrib (download_ecj, gcc_update,
> >   patch_tester.sh, update-copyright.py)
> > - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
> > - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
> > - references to java in install.texi
> 
> Probably also gcc/jit/* and gcc/testsuite/jit.dg/* ?

??  gccjit has nothing to do with Java, it is a general purpose GIT for
whatever program wants to use it.

Jakub

Re: [PATCH] Delete GCJ

[Bernd Edlinger]

> Things we may want to remove:
> 
> - references to java in contrib (download_ecj, gcc_update,
>   patch_tester.sh, update-copyright.py)
> - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
> - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
> - references to java in install.texi

Probably also gcc/jit/* and gcc/testsuite/jit.dg/* ?

Bernd.

Re: [PATCH] Delete GCJ

[Eric Botcazou]

> Things we may want to remove:
> 
> - references to java in contrib (download_ecj, gcc_update,
>   patch_tester.sh, update-copyright.py)
> - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
> - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
> - references to java in install.texi

There are more references in sourcebuild.texi and install.texi.

-- 
Eric Botcazou

Re: [PATCH] Delete GCJ

[Iain Sandoe]

> On 10 Oct 2016, at 05:03, Matthias Klose  wrote:
> 
> On 07.10.2016 10:30, Iain Sandoe wrote:
>> 
>>> On 7 Oct 2016, at 00:58, Matthias Klose  wrote:
>>> 
>>> On 06.10.2016 20:00, Mike Stump wrote:
 On Oct 6, 2016, at 9:56 AM, Rainer Orth  
 wrote:
> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
> warning.  The Objective-C maintainers may have other preferences, though.
>>> 
>>> I think I can't do that in the top level make file very well (currently I 
>>> only
>>> have the pkg-config check there for an early failure, but that check doesn't
>>> tell me if the library is present for all multilib variants). And I can't 
>>> check
>>> for multilibs because I don't know if the bootstrap compiler is multilib 
>>> aware.
>> 
>> hrm, so perhaps we need a —with-target-boehm-gc= type arrangement, and it’s 
>> the configurer’s responsibility to provide a path with appropriate 
>> headers/libs for the multi-lib configuration being attempted.
> 
> I don't understand what you are proposing here.

given that:
 auto-detection of the capabilities could be quite difficult (or, in the 
general case, unachievable) for the reasons you gave.
 the chosen target libraries might be in a non-standard place.

making it an explicit requirement to point to them, and to ensure that the 
versions/multi-libs provided are suitable, (by putting 
—with-target-boehm-gc=/path/to/suitable/) would mean that the dependent 
configury (for objc-gc) could be just conditional upon the  presence of the 
"with-target-boehm-gc”.

I suppose that one could make "—with-target-boehm-gc” (no attached path) 
declare that the library (and requisite mult-lib versions) will be found in the 
sysroot without any additional work.

The point here was to simplify the dependent configury so that it only needs to 
test something that the configuring user specifies (i.e. if they specify 
objc-gc, then they need also to specify the place that the gc lib can be found).

 gcc historically is fairly weak at complex configurations.  I need the 32 
 bit libraries to support -m32, but, those libraries might not be present, 
 but do I build all the rest of my libraries, and if i do, do I test them 
 once build, but what is other dependent external libraries are missing.  
 Do I turn off the multilib, or do I not?
 
 I used to manage some of this by passing in configure flags to control 
 multilibbing based upon what libraries were install and then run testing 
 based upon that.  Of course, that's all external to gcc proper. Doesn't 
 really make gcc any easier to configure and build or advance gcc.
 
 We could smell the system at configure time, and turn on and off multilib 
 variants and things like objc gc. Target specific, but I think it helps to 
 ponder this in a target independent way.  This can then turn on and off 
 objc gc support directly.  To get it on, one would need to install the 
 needed libraries, and reconfigure and rebuild gcc.  I think I might like 
 that the best.  Has a nice easy of use about it, and then everything gcc 
 does is rather sane (no funny build errors when a needed library isn't 
 present).
 
 
 So, I think, if I understand what you propose, I'm fine with that.
>>> 
>>> So your proposal is to replace the ": dnl ..." line in libobjc/configure.ac 
>>> with
>>> a hard error message and leave it to the user to correctly configure GCC?  
>>> That
>>> would rely on the compiler to find the library in a system wide multilib 
>>> aware
>>> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32).  Is this the case 
>>> for
>>> Solaris and Darwin?
>> 
>> for Darwin, it’s not a default install (but then neither are the host deps 
>> such as gmp & friends) - so the toolchain builder on Darwin already needs to 
>> make some provisions outside the system.  It’s just that the only target 
>> provisions to date have been the sysroot (we haven’t yet made use of add-on 
>> target libs).
>> 
>>> I'm fine with that, it wouldn't affect configurations like x86_64-linux-gnu
>>> where multilib is the default (but objc-gc is not).
>>> 
>>> Looking back at libjava, I think everybody disabled multilibs for libjava,
>>> because nobody had a complete gtk2 stack for multilibs, however that was a
>>> complete subdir, not just a certain configuration in that subdir. Looking 
>>> back
>>> at libffi and separate released libffi's I first built multilib'ed libffi
>>> libraries from the libffi source for Debian/Ubuntu, then dropped these 
>>> because
>>> they were not used, and until today GCC internal and external libffi are
>>> hopelessly out of sync, so you couldn't use an external libffi to build 
>>> libjava.
>> 
>> Becase Darwin’s libjava does not depend on the gtk2 stack, actually normally 
>> libjava (and libffi, gc) were generally built and tested (by those who cared 
>> 

Re: [PATCH] Delete GCJ

[Matthias Klose]

On 07.10.2016 10:30, Iain Sandoe wrote:
> 
>> On 7 Oct 2016, at 00:58, Matthias Klose  wrote:
>>
>> On 06.10.2016 20:00, Mike Stump wrote:
>>> On Oct 6, 2016, at 9:56 AM, Rainer Orth  
>>> wrote:
 I wouldn't hard-fail, but completely disable objc-gc with an appropriate
 warning.  The Objective-C maintainers may have other preferences, though.
>>
>> I think I can't do that in the top level make file very well (currently I 
>> only
>> have the pkg-config check there for an early failure, but that check doesn't
>> tell me if the library is present for all multilib variants). And I can't 
>> check
>> for multilibs because I don't know if the bootstrap compiler is multilib 
>> aware.
> 
> hrm, so perhaps we need a —with-target-boehm-gc= type arrangement, and it’s 
> the configurer’s responsibility to provide a path with appropriate 
> headers/libs for the multi-lib configuration being attempted.

I don't understand what you are proposing here.

>>> gcc historically is fairly weak at complex configurations.  I need the 32 
>>> bit libraries to support -m32, but, those libraries might not be present, 
>>> but do I build all the rest of my libraries, and if i do, do I test them 
>>> once build, but what is other dependent external libraries are missing.  Do 
>>> I turn off the multilib, or do I not?
>>>
>>> I used to manage some of this by passing in configure flags to control 
>>> multilibbing based upon what libraries were install and then run testing 
>>> based upon that.  Of course, that's all external to gcc proper. Doesn't 
>>> really make gcc any easier to configure and build or advance gcc.
>>>
>>> We could smell the system at configure time, and turn on and off multilib 
>>> variants and things like objc gc. Target specific, but I think it helps to 
>>> ponder this in a target independent way.  This can then turn on and off 
>>> objc gc support directly.  To get it on, one would need to install the 
>>> needed libraries, and reconfigure and rebuild gcc.  I think I might like 
>>> that the best.  Has a nice easy of use about it, and then everything gcc 
>>> does is rather sane (no funny build errors when a needed library isn't 
>>> present).
>>>
>>>
>>> So, I think, if I understand what you propose, I'm fine with that.
>>
>> So your proposal is to replace the ": dnl ..." line in libobjc/configure.ac 
>> with
>> a hard error message and leave it to the user to correctly configure GCC?  
>> That
>> would rely on the compiler to find the library in a system wide multilib 
>> aware
>> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32).  Is this the case 
>> for
>> Solaris and Darwin?
> 
> for Darwin, it’s not a default install (but then neither are the host deps 
> such as gmp & friends) - so the toolchain builder on Darwin already needs to 
> make some provisions outside the system.  It’s just that the only target 
> provisions to date have been the sysroot (we haven’t yet made use of add-on 
> target libs).
> 
>> I'm fine with that, it wouldn't affect configurations like x86_64-linux-gnu
>> where multilib is the default (but objc-gc is not).
>>
>> Looking back at libjava, I think everybody disabled multilibs for libjava,
>> because nobody had a complete gtk2 stack for multilibs, however that was a
>> complete subdir, not just a certain configuration in that subdir. Looking 
>> back
>> at libffi and separate released libffi's I first built multilib'ed libffi
>> libraries from the libffi source for Debian/Ubuntu, then dropped these 
>> because
>> they were not used, and until today GCC internal and external libffi are
>> hopelessly out of sync, so you couldn't use an external libffi to build 
>> libjava.
> 
> Becase Darwin’s libjava does not depend on the gtk2 stack, actually normally 
> libjava (and libffi, gc) were generally built and tested (by those who cared 
> to do it) as multilibs [the default].
>>
>> In the past I looked at updating boehm-gc to recent sources but never 
>> finished
>> because libjava relied on internals.  Afaics this is not the case for 
>> objc-gc,
>> so maybe you could update boehm-gc. But I don't want to go this road myself …
> 
> .. and I don’t have cycles to volunteer to try this at present either.
> Iain
> 
> 
>>
>> Matthias
> 

Re: [PATCH] Delete GCJ

[Iain Sandoe]

> On 7 Oct 2016, at 00:58, Matthias Klose  wrote:
> 
> On 06.10.2016 20:00, Mike Stump wrote:
>> On Oct 6, 2016, at 9:56 AM, Rainer Orth  
>> wrote:
>>> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
>>> warning.  The Objective-C maintainers may have other preferences, though.
> 
> I think I can't do that in the top level make file very well (currently I only
> have the pkg-config check there for an early failure, but that check doesn't
> tell me if the library is present for all multilib variants). And I can't 
> check
> for multilibs because I don't know if the bootstrap compiler is multilib 
> aware.

hrm, so perhaps we need a —with-target-boehm-gc= type arrangement, and it’s the 
configurer’s responsibility to provide a path with appropriate headers/libs for 
the multi-lib configuration being attempted.
> 
>> gcc historically is fairly weak at complex configurations.  I need the 32 
>> bit libraries to support -m32, but, those libraries might not be present, 
>> but do I build all the rest of my libraries, and if i do, do I test them 
>> once build, but what is other dependent external libraries are missing.  Do 
>> I turn off the multilib, or do I not?
>> 
>> I used to manage some of this by passing in configure flags to control 
>> multilibbing based upon what libraries were install and then run testing 
>> based upon that.  Of course, that's all external to gcc proper. Doesn't 
>> really make gcc any easier to configure and build or advance gcc.
>> 
>> We could smell the system at configure time, and turn on and off multilib 
>> variants and things like objc gc. Target specific, but I think it helps to 
>> ponder this in a target independent way.  This can then turn on and off objc 
>> gc support directly.  To get it on, one would need to install the needed 
>> libraries, and reconfigure and rebuild gcc.  I think I might like that the 
>> best.  Has a nice easy of use about it, and then everything gcc does is 
>> rather sane (no funny build errors when a needed library isn't present).
>> 
>> 
>> So, I think, if I understand what you propose, I'm fine with that.
> 
> So your proposal is to replace the ": dnl ..." line in libobjc/configure.ac 
> with
> a hard error message and leave it to the user to correctly configure GCC?  
> That
> would rely on the compiler to find the library in a system wide multilib aware
> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32).  Is this the case for
> Solaris and Darwin?

for Darwin, it’s not a default install (but then neither are the host deps such 
as gmp & friends) - so the toolchain builder on Darwin already needs to make 
some provisions outside the system.  It’s just that the only target provisions 
to date have been the sysroot (we haven’t yet made use of add-on target libs).

> I'm fine with that, it wouldn't affect configurations like x86_64-linux-gnu
> where multilib is the default (but objc-gc is not).
> 
> Looking back at libjava, I think everybody disabled multilibs for libjava,
> because nobody had a complete gtk2 stack for multilibs, however that was a
> complete subdir, not just a certain configuration in that subdir. Looking back
> at libffi and separate released libffi's I first built multilib'ed libffi
> libraries from the libffi source for Debian/Ubuntu, then dropped these because
> they were not used, and until today GCC internal and external libffi are
> hopelessly out of sync, so you couldn't use an external libffi to build 
> libjava.

Becase Darwin’s libjava does not depend on the gtk2 stack, actually normally 
libjava (and libffi, gc) were generally built and tested (by those who cared to 
do it) as multilibs [the default].
> 
> In the past I looked at updating boehm-gc to recent sources but never finished
> because libjava relied on internals.  Afaics this is not the case for objc-gc,
> so maybe you could update boehm-gc. But I don't want to go this road myself …

.. and I don’t have cycles to volunteer to try this at present either.
Iain


> 
> Matthias

Re: [PATCH] Delete GCJ

[Matthias Klose]

On 06.10.2016 20:00, Mike Stump wrote:
> On Oct 6, 2016, at 9:56 AM, Rainer Orth  wrote:
>> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
>> warning.  The Objective-C maintainers may have other preferences, though.

I think I can't do that in the top level make file very well (currently I only
have the pkg-config check there for an early failure, but that check doesn't
tell me if the library is present for all multilib variants). And I can't check
for multilibs because I don't know if the bootstrap compiler is multilib aware.

> gcc historically is fairly weak at complex configurations.  I need the 32 bit 
> libraries to support -m32, but, those libraries might not be present, but do 
> I build all the rest of my libraries, and if i do, do I test them once build, 
> but what is other dependent external libraries are missing.  Do I turn off 
> the multilib, or do I not?
> 
> I used to manage some of this by passing in configure flags to control 
> multilibbing based upon what libraries were install and then run testing 
> based upon that.  Of course, that's all external to gcc proper.  Doesn't 
> really make gcc any easier to configure and build or advance gcc.
> 
> We could smell the system at configure time, and turn on and off multilib 
> variants and things like objc gc.  Target specific, but I think it helps to 
> ponder this in a target independent way.  This can then turn on and off objc 
> gc support directly.  To get it on, one would need to install the needed 
> libraries, and reconfigure and rebuild gcc.  I think I might like that the 
> best.  Has a nice easy of use about it, and then everything gcc does is 
> rather sane (no funny build errors when a needed library isn't present).
> 
> 
> So, I think, if I understand what you propose, I'm fine with that.

So your proposal is to replace the ": dnl ..." line in libobjc/configure.ac with
a hard error message and leave it to the user to correctly configure GCC?  That
would rely on the compiler to find the library in a system wide multilib aware
directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32).  Is this the case for
Solaris and Darwin?

I'm fine with that, it wouldn't affect configurations like x86_64-linux-gnu
where multilib is the default (but objc-gc is not).

Looking back at libjava, I think everybody disabled multilibs for libjava,
because nobody had a complete gtk2 stack for multilibs, however that was a
complete subdir, not just a certain configuration in that subdir. Looking back
at libffi and separate released libffi's I first built multilib'ed libffi
libraries from the libffi source for Debian/Ubuntu, then dropped these because
they were not used, and until today GCC internal and external libffi are
hopelessly out of sync, so you couldn't use an external libffi to build libjava.

In the past I looked at updating boehm-gc to recent sources but never finished
because libjava relied on internals.  Afaics this is not the case for objc-gc,
so maybe you could update boehm-gc. But I don't want to go this road myself ...

Matthias

Re: [PATCH] Delete GCJ

[Mike Stump]

On Oct 6, 2016, at 9:56 AM, Rainer Orth  wrote:
> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
> warning.  The Objective-C maintainers may have other preferences, though.

gcc historically is fairly weak at complex configurations.  I need the 32 bit 
libraries to support -m32, but, those libraries might not be present, but do I 
build all the rest of my libraries, and if i do, do I test them once build, but 
what is other dependent external libraries are missing.  Do I turn off the 
multilib, or do I not?

I used to manage some of this by passing in configure flags to control 
multilibbing based upon what libraries were install and then run testing based 
upon that.  Of course, that's all external to gcc proper.  Doesn't really make 
gcc any easier to configure and build or advance gcc.

We could smell the system at configure time, and turn on and off multilib 
variants and things like objc gc.  Target specific, but I think it helps to 
ponder this in a target independent way.  This can then turn on and off objc gc 
support directly.  To get it on, one would need to install the needed 
libraries, and reconfigure and rebuild gcc.  I think I might like that the 
best.  Has a nice easy of use about it, and then everything gcc does is rather 
sane (no funny build errors when a needed library isn't present).


So, I think, if I understand what you propose, I'm fine with that.

Re: [PATCH] Delete GCJ

[Iain Sandoe]

> On 6 Oct 2016, at 17:56, Rainer Orth  wrote:
> 

 this assumption may not hold, though: in Solaris 11+ where libgc is
 bundled, both 32 and 64-bit libs are present, as always.  I'd also claim
 that for multilib testing in general, it's bad to test different
 multilibs with different configurations, so I'd rather have people doing
 multilib testing obtain all variants of libgc.
>>> 
>>> likewise on Darwin, people may well build “fat” libraries, and I also
>>> would encourage testing of m32/m64,
>> 
>> so you both prefer to hard-fail if any of the libgc variants needed for the
>> multilibs is missing?  Maybe force this behaviour with --enable-objc-gc=yes, 
>> and
>> skip those which are not available with -enable-objc-gc=auto?
> 
> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
> warning.  The Objective-C maintainers may have other preferences, though.

that seems a reasonable strategy to me too (disable that capability when the 
library is not present) - I suspect that most people do not usually build with 
GC support anyway (but no firm statistics to back the hunch).

Iain

Re: [PATCH] Delete GCJ

[Rainer Orth]

Hi Matthias,

>>> this assumption may not hold, though: in Solaris 11+ where libgc is
>>> bundled, both 32 and 64-bit libs are present, as always.  I'd also claim
>>> that for multilib testing in general, it's bad to test different
>>> multilibs with different configurations, so I'd rather have people doing
>>> multilib testing obtain all variants of libgc.
>> 
>> likewise on Darwin, people may well build “fat” libraries, and I also
>> would encourage testing of m32/m64,
>
> so you both prefer to hard-fail if any of the libgc variants needed for the
> multilibs is missing?  Maybe force this behaviour with --enable-objc-gc=yes, 
> and
> skip those which are not available with -enable-objc-gc=auto?

I wouldn't hard-fail, but completely disable objc-gc with an appropriate
warning.  The Objective-C maintainers may have other preferences, though.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Delete GCJ

[Matthias Klose]

On 06.10.2016 18:46, Iain Sandoe wrote:
> 
>> On 6 Oct 2016, at 17:42, Rainer Orth  wrote:
>>
> 
 Here's what I tested. This requires a boehm-gc version 7.0 or later
 (having the
 header files in a gc subdirectory).  Depending on your available library, 
 it
 only builds the GC enabled library for the default multilib library, and 
 just
 skips over building the non-default multilib variants (assuming that most
 people
 won't have a libgc for that installed).  The --enable-objc-gc option is not
>>
>> this assumption may not hold, though: in Solaris 11+ where libgc is
>> bundled, both 32 and 64-bit libs are present, as always.  I'd also claim
>> that for multilib testing in general, it's bad to test different
>> multilibs with different configurations, so I'd rather have people doing
>> multilib testing obtain all variants of libgc.
> 
> likewise on Darwin, people may well build “fat” libraries, and I also would 
> encourage testing of m32/m64,

so you both prefer to hard-fail if any of the libgc variants needed for the
multilibs is missing?  Maybe force this behaviour with --enable-objc-gc=yes, and
skip those which are not available with -enable-objc-gc=auto?

Matthias

Re: [PATCH] Delete GCJ

[Iain Sandoe]

> On 6 Oct 2016, at 17:42, Rainer Orth  wrote:
> 

>>> Here's what I tested. This requires a boehm-gc version 7.0 or later
>>> (having the
>>> header files in a gc subdirectory).  Depending on your available library, it
>>> only builds the GC enabled library for the default multilib library, and 
>>> just
>>> skips over building the non-default multilib variants (assuming that most
>>> people
>>> won't have a libgc for that installed).  The --enable-objc-gc option is not
> 
> this assumption may not hold, though: in Solaris 11+ where libgc is
> bundled, both 32 and 64-bit libs are present, as always.  I'd also claim
> that for multilib testing in general, it's bad to test different
> multilibs with different configurations, so I'd rather have people doing
> multilib testing obtain all variants of libgc.

likewise on Darwin, people may well build “fat” libraries, and I also would 
encourage testing of m32/m64,
Iain

Re: [PATCH] Delete GCJ

[Rainer Orth]

Hi Matthias,

>> Here's what I tested. This requires a boehm-gc version 7.0 or later
>> (having the
>> header files in a gc subdirectory).  Depending on your available library, it
>> only builds the GC enabled library for the default multilib library, and just
>> skips over building the non-default multilib variants (assuming that most
>> people
>> won't have a libgc for that installed).  The --enable-objc-gc option is not

this assumption may not hold, though: in Solaris 11+ where libgc is
bundled, both 32 and 64-bit libs are present, as always.  I'd also claim
that for multilib testing in general, it's bad to test different
multilibs with different configurations, so I'd rather have people doing
multilib testing obtain all variants of libgc.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Delete GCJ

[Matthias Klose]

On 06.10.2016 18:14, Matthias Klose wrote:
> On 05.10.2016 18:28, Jeff Law wrote:
>> On 10/04/2016 12:39 PM, Iain Sandoe wrote:

 I don't know who wants to review it, but if people want me to, Ok.  The 
 idea
 is that if ObjC is the last remaining user in tree for boehm-gc, then
 reasonably I'm the last man standing.  Of course, if others want to review
 approve the patch, I'm fine with that.

 I'm fine with patches to externalize boehm-gc if people want to push that
 direction.
>>>
>>> +1
>> Works for me as well, particularly since we've been horrible at updating
>> boehm-gc.  I think the in-tree version is something like 10 years old at this
>> point -- and there's been over a dozen upstream releases since we last 
>> sync'd.
>>
>> Jeff
> 
> Here's what I tested. This requires a boehm-gc version 7.0 or later (having 
> the
> header files in a gc subdirectory).  Depending on your available library, it
> only builds the GC enabled library for the default multilib library, and just
> skips over building the non-default multilib variants (assuming that most 
> people
> won't have a libgc for that installed).  The --enable-objc-gc option is not
> documented, so I didn't update the documentation.
> 
> Matthias
> 
> 2016-10-06  Matthias Klose  
> 
> * boehm-gc: Remove
> * Makefile.def: Remove boehm-gc dependencies.
> * Makefile.in: Regenerate.
> * configure.ac: Include pkg.m4, check for bdw-gc pkg-config module.
> * configure: Regenerate.
> 
> config/
> 
> 2016-10-06  Matthias Klose  
> 
> * pkg.m4: New file.
> 
> libobjc/
> 
> 2016-10-06  Matthias Klose  
> 
> * configure.ac: Include pkg.m4, use bdw-gc pkg-config module.
> * configure: Regenerate.

and sending the attachment again without the boehm-gc removal ...



2016-10-06  Matthias Klose  

	* boehm-gc: Remove
	* Makefile.def: Remove boehm-gc dependencies.
	* Makefile.in: Regenerate.
	* configure.ac: Include pkg.m4, check for bdw-gc pkg-config module.
	* configure: Regenerate.

config/

2016-10-06  Matthias Klose  

	* pkg.m4: New file.

libobjc/

2016-10-06  Matthias Klose  

	* configure.ac: Include pkg.m4, use bdw-gc pkg-config module.
	* configure: Regenerate.
	* Makefile.in: Remove boehm-gc include, use system boehm-gc library.
	* gc.c, memory.c, objects.c: Include system boehm-gc headers.

Index: Makefile.def
===
--- Makefile.def	(revision 240829)
+++ Makefile.def	(working copy)
@@ -166,7 +166,6 @@
 target_modules = { module= libgloss; no_check=true; };
 target_modules = { module= libffi; no_install=true; };
 target_modules = { module= zlib; };
-target_modules = { module= boehm-gc; };
 target_modules = { module= rda; };
 target_modules = { module= libada; };
 target_modules = { module= libgomp; bootstrap= true; lib_path=.libs; };
@@ -544,7 +543,6 @@
 // a dependency on libgcc for native targets to configure.
 lang_env_dependencies = { module=libiberty; no_c=true; };
 
-dependencies = { module=configure-target-boehm-gc; on=all-target-libstdc++-v3; };
 dependencies = { module=configure-target-fastjar; on=configure-target-zlib; };
 dependencies = { module=all-target-fastjar; on=all-target-zlib; };
 dependencies = { module=configure-target-libgo; on=configure-target-libffi; };
@@ -552,8 +550,6 @@
 dependencies = { module=all-target-libgo; on=all-target-libbacktrace; };
 dependencies = { module=all-target-libgo; on=all-target-libffi; };
 dependencies = { module=all-target-libgo; on=all-target-libatomic; };
-dependencies = { module=configure-target-libobjc; on=configure-target-boehm-gc; };
-dependencies = { module=all-target-libobjc; on=all-target-boehm-gc; };
 dependencies = { module=configure-target-libstdc++-v3; on=configure-target-libgomp; };
 dependencies = { module=configure-target-liboffloadmic; on=configure-target-libgomp; };
 dependencies = { module=configure-target-libsanitizer; on=all-target-libstdc++-v3; };
Index: config/pkg.m4
===
--- config/pkg.m4	(nonexistent)
+++ config/pkg.m4	(working copy)
@@ -0,0 +1,275 @@
+dnl pkg.m4 - Macros to locate and utilise pkg-config.   -*- Autoconf -*-
+dnl serial 11 (pkg-config-0.29)
+dnl
+dnl Copyright © 2004 Scott James Remnant .
+dnl Copyright © 2012-2015 Dan Nicholson 
+dnl
+dnl This program is free software; you can redistribute it and/or modify
+dnl it under the terms of the GNU General Public License as published by
+dnl the Free Software Foundation; either version 2 of the License, or
+dnl (at your option) any later version.
+dnl
+dnl This program is distributed in the hope that it will be useful, but
+dnl WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU

Re: [PATCH] Delete GCJ

[Jeff Law]

On 10/04/2016 12:39 PM, Iain Sandoe wrote:


I don't know who wants to review it, but if people want me to, Ok.  The idea is 
that if ObjC is the last remaining user in tree for boehm-gc, then reasonably 
I'm the last man standing.  Of course, if others want to review approve the 
patch, I'm fine with that.

I'm fine with patches to externalize boehm-gc if people want to push that 
direction.


+1
Works for me as well, particularly since we've been horrible at updating 
boehm-gc.  I think the in-tree version is something like 10 years old at 
this point -- and there's been over a dozen upstream releases since we 
last sync'd.


Jeff

Re: [C++ PATCH] Delete GCJ - C++ part

[Jeff Law]

On 10/05/2016 03:07 AM, Jakub Jelinek wrote:

On Wed, Oct 05, 2016 at 11:04:05AM +0200, Andreas Schwab wrote:

FAIL: g++.dg/pr49847-2.C  -std=gnu++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:5:13: error: 
'__java_int' does not name a type
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:6:13: error: 
'__java_float' does not name a type; did you mean '__cpp_hex_float'?
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:18:12: error: language 
string '"Java"' not recognized
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:25:5: error: 
'jint' does not name a type; did you mean 'int'?
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:26:5: error: 
'jfloat' does not name a type; did you mean 'float'?
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:41:6: error: 
'jfloat' was not declared in this scope
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:42:13: error: 
expected ';' before 'value1'
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:43:10: error: 
'value1' was not declared in this scope
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:43:19: error: 
'value2' was not declared in this scope
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:43:41: error: 
'union _Jv_word' has no member named 'i'


Feel free to remove it.  I have no access to m68k.
No objections from me either. It was a test for a very obscure 
problem with cc0 targets and the setter/user getting separated.  Given 
we just want to verify compilation without hitting an ICE, we could 
probably create suitable types and save the test, but I doubt it's 
terribly important.


jeff

Re: [C++ PATCH] Delete GCJ - C++ part

[Jakub Jelinek]

On Wed, Oct 05, 2016 at 11:04:05AM +0200, Andreas Schwab wrote:
> FAIL: g++.dg/pr49847-2.C  -std=gnu++11 (test for excess errors)
> Excess errors:
> /daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:5:13: error: 
> '__java_int' does not name a type
> /daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:6:13: error: 
> '__java_float' does not name a type; did you mean '__cpp_hex_float'?
> /daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:18:12: error: 
> language string '"Java"' not recognized
> /daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:25:5: error: 
> 'jint' does not name a type; did you mean 'int'?
> /daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:26:5: error: 
> 'jfloat' does not name a type; did you mean 'float'?
> /daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:41:6: error: 
> 'jfloat' was not declared in this scope
> /daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:42:13: error: 
> expected ';' before 'value1'
> /daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:43:10: error: 
> 'value1' was not declared in this scope
> /daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:43:19: error: 
> 'value2' was not declared in this scope
> /daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:43:41: error: 
> 'union _Jv_word' has no member named 'i'

Feel free to remove it.  I have no access to m68k.

Jakub

Re: [C++ PATCH] Delete GCJ - C++ part

[Andreas Schwab]

FAIL: g++.dg/pr49847-2.C  -std=gnu++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:5:13: error: 
'__java_int' does not name a type
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:6:13: error: 
'__java_float' does not name a type; did you mean '__cpp_hex_float'?
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:18:12: error: 
language string '"Java"' not recognized
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:25:5: error: 
'jint' does not name a type; did you mean 'int'?
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:26:5: error: 
'jfloat' does not name a type; did you mean 'float'?
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:41:6: error: 
'jfloat' was not declared in this scope
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:42:13: error: 
expected ';' before 'value1'
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:43:10: error: 
'value1' was not declared in this scope
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:43:19: error: 
'value2' was not declared in this scope
/daten/aranym/gcc/gcc-20161005/gcc/testsuite/g++.dg/pr49847-2.C:43:41: error: 
'union _Jv_word' has no member named 'i'

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] Delete GCJ

[Iain Sandoe]

> On 4 Oct 2016, at 18:23, Mike Stump  wrote:
> 
> On Oct 4, 2016, at 1:41 AM, Andrew Haley  wrote:
>> 
>> On 04/10/16 09:39, Rainer Orth wrote:
>>> Hi Matthias,
>>> 
 On 05.09.2016 17:13, Andrew Haley wrote:
> As discussed.  I think I should ask a Global reviewer to approve this
> one.  For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> if anyone would like to try it.
 
 still breaks bootstraps when configured with --enable-objc-gc.
 
 the immediate step should be to fix the bootstrap failure, as an 
 additional step
 to remove boehm-gc from the gcc sources and be able to use an external 
 boehm-gc.
>>> 
>>> the first part is handled by my unreviewed patch
>>> 
>>> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html
>> 
>> Looks obvious to me, fixes bootstrap.  I think no-one will complain
>> if you check it in.
> 
> I don't know who wants to review it, but if people want me to, Ok.  The idea 
> is that if ObjC is the last remaining user in tree for boehm-gc, then 
> reasonably I'm the last man standing.  Of course, if others want to review 
> approve the patch, I'm fine with that.  
> 
> I'm fine with patches to externalize boehm-gc if people want to push that 
> direction.

+1

Iain

Re: [PATCH] Delete GCJ

[Andrew Pinski]

On Tue, Oct 4, 2016 at 10:23 AM, Mike Stump  wrote:
> On Oct 4, 2016, at 1:41 AM, Andrew Haley  wrote:
>>
>> On 04/10/16 09:39, Rainer Orth wrote:
>>> Hi Matthias,
>>>
 On 05.09.2016 17:13, Andrew Haley wrote:
> As discussed.  I think I should ask a Global reviewer to approve this
> one.  For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> if anyone would like to try it.

 still breaks bootstraps when configured with --enable-objc-gc.

 the immediate step should be to fix the bootstrap failure, as an 
 additional step
 to remove boehm-gc from the gcc sources and be able to use an external 
 boehm-gc.
>>>
>>> the first part is handled by my unreviewed patch
>>>
>>>  https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html
>>
>> Looks obvious to me, fixes bootstrap.  I think no-one will complain
>> if you check it in.
>
> I don't know who wants to review it, but if people want me to, Ok.  The idea 
> is that if ObjC is the last remaining user in tree for boehm-gc, then 
> reasonably I'm the last man standing.  Of course, if others want to review 
> approve the patch, I'm fine with that.

From a runtime maintainer position, I am also fine with this patch.

>
> I'm fine with patches to externalize boehm-gc if people want to push that 
> direction.

I am also ok with that too.

Thanks,
Andrew


>

Re: [PATCH] Delete GCJ

[Mike Stump]

On Oct 4, 2016, at 1:41 AM, Andrew Haley  wrote:
> 
> On 04/10/16 09:39, Rainer Orth wrote:
>> Hi Matthias,
>> 
>>> On 05.09.2016 17:13, Andrew Haley wrote:
 As discussed.  I think I should ask a Global reviewer to approve this
 one.  For obvious reasons I haven't included the diffs to the deleted
 gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
 is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
 if anyone would like to try it.
>>> 
>>> still breaks bootstraps when configured with --enable-objc-gc.
>>> 
>>> the immediate step should be to fix the bootstrap failure, as an additional 
>>> step
>>> to remove boehm-gc from the gcc sources and be able to use an external 
>>> boehm-gc.
>> 
>> the first part is handled by my unreviewed patch
>> 
>>  https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html
> 
> Looks obvious to me, fixes bootstrap.  I think no-one will complain
> if you check it in.

I don't know who wants to review it, but if people want me to, Ok.  The idea is 
that if ObjC is the last remaining user in tree for boehm-gc, then reasonably 
I'm the last man standing.  Of course, if others want to review approve the 
patch, I'm fine with that.  

I'm fine with patches to externalize boehm-gc if people want to push that 
direction.

Re: [C++ PATCH] Delete GCJ - C++ part

[Jason Merrill]

OK.

On Sun, Oct 2, 2016 at 3:58 PM, Jakub Jelinek  wrote:
> On Sun, Oct 02, 2016 at 03:27:09PM +0200, Andreas Schwab wrote:
>> Things we may want to remove:
>>
>> - references to java in contrib (download_ecj, gcc_update,
>>   patch_tester.sh, update-copyright.py)
>> - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
>> - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
>> - references to java in install.texi
>
> There is another thing, the Java extensions in the C++ FE, which are IMNSHO
> no longer needed after GCJ removal.
>
> Here is a C++ patch that removes that part, bootstrapped/regtested on
> x86_64-linux and i686-linux, ok for trunk?
>
> 2016-10-02  Jakub Jelinek  
>
> * doc/extend.texi (Java Exceptions): Remove.
> (java_interface): Remove.
> cp/
> * cp-tree.h (enum cp_tree_index): Remove CPTI_JAVA_*,
> CPTI_LANG_NAME_JAVA and CPTI_JCLASS.
> (java_byte_type_node, java_short_type_node, java_int_type_node,
> java_long_type_node, java_float_type_node, java_double_type_node,
> java_char_type_node, java_boolean_type_node, lang_name_java,
> jclass_node): Remove.
> (enum languages): Remove lang_java.
> (TYPE_FOR_JAVA): Remove.
> (struct lang_type_class): Remove java_interface bit-field.
> (TYPE_JAVA_INTERFACE): Remove.
> (pragma_java_exceptions): Remove.
> (check_java_method, build_java_class_ref): Remove prototypes.
> * name-lookup.c (pushtag_1): Don't set TYPE_FOR_JAVA.
> * decl2.c (acceptable_java_type, check_java_method): Remove.
> (import_export_decl): Remove TYPE_FOR_JAVA handling.
> (build_java_method_aliases): Remove.
> (c_parse_final_cleanups): Don't call build_java_method_aliases.
> (possibly_inlined_p): Don't test pragma_java_exceptions.
> * init.c (build_new_1): Remove TYPE_FOR_JAVA handling.
> (build_java_class_ref): Remove.
> * pt.c (maybe_new_partial_specialization, lookup_template_class_1,
> instantiate_class_template_1): Don't copy TYPE_FOR_JAVA.
> * except.c (eh_type_info): Remove java type handling.
> (decl_is_java_type, choose_personality_routine): Remove.
> (initialize_handler_parm): Don't call choose_personality_routine.
> (expand_start_catch_block): Don't handle java types.
> (build_throw): Likewise.
> * cp-lang.c (cp_eh_personality): Don't handle pragma_java_exceptions.
> * typeck.c (structural_comptypes): Don't compare TYPE_FOR_JAVA.
> * call.c (build_over_call): Don't handle TYPE_JAVA_INTERFACE.
> (java_iface_lookup_fn): Remove.
> (build_java_interface_fn_ref): Remove.
> * tree.c (cxx_attribute_table): Remove java_interface.
> (handle_java_interface_attribute): Remove.
> * lex.c (pragma_java_exceptions): Remove.
> (init_cp_pragma): Don't register GCC java_exceptions pragma.
> (handle_pragma_java_exceptions): Remove.
> (retrofit_lang_decl): Don't handle lang_name_java.
> * method.c (implicitly_declare_fn): Don't handle TYPE_FOR_JAVA.
> * error.c (language_to_string): Don't handle lang_java.
> * decl.c (record_builtin_java_type): Remove.
> (initialize_predefined_identifiers): Remove Java.
> (cxx_init_decl_processing): Remove java_*_type_node.
> (cp_finish_decl): Don't handle TYPE_FOR_JAVA.
> (grokfndecl): Likewise.
> (check_special_function_return_type): Likewise.
> (grokdeclarator): Don't set TYPE_FOR_JAVA.
> (grokparms): Don't handle TYPE_FOR_JAVA.
> (xref_basetypes): Likewise.
> (check_function_type): Likewise.
> (finish_constructor_body): Likewise.
> * mangle.c (write_builtin_type): Don't handle TYPE_FOR_JAVA
> and java_*_type_node.
> (write_bare_function_type): Don't handle TYPE_FOR_JAVA.
> (write_java_integer_type_codes): Remove.
> * class.c (add_method): Don't handle TYPE_FOR_JAVA.
> (add_implicitly_declared_members, determine_key_method,
> finish_struct_1): Likewise.
> (push_lang_context): Don't handle lang_name_java.
> testsuite/
> * g++.dg/other/java3.C: Remove.
> * g++.dg/other/java1.C: Remove.
> * g++.dg/other/error12.C: Remove.
> * g++.dg/other/java2.C: Remove.
> * g++.dg/warn/Wnvdtor.C: Remove.
> * g++.dg/lookup/java1.C: Remove.
> * g++.dg/lookup/java2.C: Remove.
> * g++.dg/ext/pr34829.C: Remove.
> * g++.dg/ext/java-3.C: Remove.
> * g++.dg/ext/java-1.C: Remove.
> * g++.dg/ext/java-2.C: Remove.
> * g++.old-deja/g++.oliva/dwarf2.C: Remove.
>
> --- gcc/doc/extend.texi.jj  2016-09-29 22:53:11.0 +0200
> +++ gcc/doc/extend.texi 2016-10-02 19:27:25.315410894 +0200
> @@ -21392,7 +21392,6 @@ Predefined Macros,cpp,The GNU C Preproce
>  

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 04/10/16 09:39, Rainer Orth wrote:
> Hi Matthias,
> 
>> On 05.09.2016 17:13, Andrew Haley wrote:
>>> As discussed.  I think I should ask a Global reviewer to approve this
>>> one.  For obvious reasons I haven't included the diffs to the deleted
>>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>>> if anyone would like to try it.
>>
>> still breaks bootstraps when configured with --enable-objc-gc.
>>
>> the immediate step should be to fix the bootstrap failure, as an additional 
>> step
>> to remove boehm-gc from the gcc sources and be able to use an external 
>> boehm-gc.
> 
> the first part is handled by my unreviewed patch
> 
>   https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html

Looks obvious to me, fixes bootstrap.  I think no-one will complain
if you check it in.

Andrew.

Re: [PATCH] Delete GCJ

[Rainer Orth]

Hi Matthias,

> On 05.09.2016 17:13, Andrew Haley wrote:
>> As discussed.  I think I should ask a Global reviewer to approve this
>> one.  For obvious reasons I haven't included the diffs to the deleted
>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>> if anyone would like to try it.
>
> still breaks bootstraps when configured with --enable-objc-gc.
>
> the immediate step should be to fix the bootstrap failure, as an additional 
> step
> to remove boehm-gc from the gcc sources and be able to use an external 
> boehm-gc.

the first part is handled by my unreviewed patch

https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Delete GCJ

[Matthias Klose]

On 05.09.2016 17:13, Andrew Haley wrote:
> As discussed.  I think I should ask a Global reviewer to approve this
> one.  For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> if anyone would like to try it.
> 
> Andrew.
> 

still breaks bootstraps when configured with --enable-objc-gc.

the immediate step should be to fix the bootstrap failure, as an additional step
to remove boehm-gc from the gcc sources and be able to use an external boehm-gc.

Thanks, Matthias

[C++ PATCH] Delete GCJ - C++ part

[Jakub Jelinek]

On Sun, Oct 02, 2016 at 03:27:09PM +0200, Andreas Schwab wrote:
> Things we may want to remove:
> 
> - references to java in contrib (download_ecj, gcc_update,
>   patch_tester.sh, update-copyright.py)
> - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
> - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
> - references to java in install.texi

There is another thing, the Java extensions in the C++ FE, which are IMNSHO
no longer needed after GCJ removal.

Here is a C++ patch that removes that part, bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?

2016-10-02  Jakub Jelinek  

* doc/extend.texi (Java Exceptions): Remove.
(java_interface): Remove.
cp/
* cp-tree.h (enum cp_tree_index): Remove CPTI_JAVA_*,
CPTI_LANG_NAME_JAVA and CPTI_JCLASS.
(java_byte_type_node, java_short_type_node, java_int_type_node,
java_long_type_node, java_float_type_node, java_double_type_node,
java_char_type_node, java_boolean_type_node, lang_name_java,
jclass_node): Remove.
(enum languages): Remove lang_java.
(TYPE_FOR_JAVA): Remove.
(struct lang_type_class): Remove java_interface bit-field.
(TYPE_JAVA_INTERFACE): Remove.
(pragma_java_exceptions): Remove.
(check_java_method, build_java_class_ref): Remove prototypes.
* name-lookup.c (pushtag_1): Don't set TYPE_FOR_JAVA.
* decl2.c (acceptable_java_type, check_java_method): Remove.
(import_export_decl): Remove TYPE_FOR_JAVA handling.
(build_java_method_aliases): Remove.
(c_parse_final_cleanups): Don't call build_java_method_aliases.
(possibly_inlined_p): Don't test pragma_java_exceptions.
* init.c (build_new_1): Remove TYPE_FOR_JAVA handling.
(build_java_class_ref): Remove.
* pt.c (maybe_new_partial_specialization, lookup_template_class_1,
instantiate_class_template_1): Don't copy TYPE_FOR_JAVA.
* except.c (eh_type_info): Remove java type handling.
(decl_is_java_type, choose_personality_routine): Remove.
(initialize_handler_parm): Don't call choose_personality_routine.
(expand_start_catch_block): Don't handle java types.
(build_throw): Likewise.
* cp-lang.c (cp_eh_personality): Don't handle pragma_java_exceptions.
* typeck.c (structural_comptypes): Don't compare TYPE_FOR_JAVA.
* call.c (build_over_call): Don't handle TYPE_JAVA_INTERFACE.
(java_iface_lookup_fn): Remove.
(build_java_interface_fn_ref): Remove.
* tree.c (cxx_attribute_table): Remove java_interface.
(handle_java_interface_attribute): Remove.
* lex.c (pragma_java_exceptions): Remove.
(init_cp_pragma): Don't register GCC java_exceptions pragma.
(handle_pragma_java_exceptions): Remove.
(retrofit_lang_decl): Don't handle lang_name_java.
* method.c (implicitly_declare_fn): Don't handle TYPE_FOR_JAVA.
* error.c (language_to_string): Don't handle lang_java.
* decl.c (record_builtin_java_type): Remove.
(initialize_predefined_identifiers): Remove Java.
(cxx_init_decl_processing): Remove java_*_type_node.
(cp_finish_decl): Don't handle TYPE_FOR_JAVA.
(grokfndecl): Likewise.
(check_special_function_return_type): Likewise.
(grokdeclarator): Don't set TYPE_FOR_JAVA.
(grokparms): Don't handle TYPE_FOR_JAVA.
(xref_basetypes): Likewise.
(check_function_type): Likewise.
(finish_constructor_body): Likewise.
* mangle.c (write_builtin_type): Don't handle TYPE_FOR_JAVA
and java_*_type_node.
(write_bare_function_type): Don't handle TYPE_FOR_JAVA.
(write_java_integer_type_codes): Remove.
* class.c (add_method): Don't handle TYPE_FOR_JAVA.
(add_implicitly_declared_members, determine_key_method,
finish_struct_1): Likewise.
(push_lang_context): Don't handle lang_name_java.
testsuite/
* g++.dg/other/java3.C: Remove.
* g++.dg/other/java1.C: Remove.
* g++.dg/other/error12.C: Remove.
* g++.dg/other/java2.C: Remove.
* g++.dg/warn/Wnvdtor.C: Remove.
* g++.dg/lookup/java1.C: Remove.
* g++.dg/lookup/java2.C: Remove.
* g++.dg/ext/pr34829.C: Remove.
* g++.dg/ext/java-3.C: Remove.
* g++.dg/ext/java-1.C: Remove.
* g++.dg/ext/java-2.C: Remove.
* g++.old-deja/g++.oliva/dwarf2.C: Remove.

--- gcc/doc/extend.texi.jj  2016-09-29 22:53:11.0 +0200
+++ gcc/doc/extend.texi 2016-10-02 19:27:25.315410894 +0200
@@ -21392,7 +21392,6 @@ Predefined Macros,cpp,The GNU C Preproce
 * Namespace Association:: Strong using-directives for namespace association.
 * Type Traits:: Compiler support for type traits.
 * C++ Concepts::Improved support for generic programming.
-* Java Exceptions:: Tweaking exception handling 

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 02/10/16 14:27, Andreas Schwab wrote:
> Things we may want to remove:
> 
> - references to java in contrib (download_ecj, gcc_update,
>   patch_tester.sh, update-copyright.py)
> - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
> - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
> - references to java in install.texi

Yes, that's true.  Thanks for doing the search.

Andrew.

Re: [PATCH] Delete GCJ

[Andreas Schwab]

Things we may want to remove:

- references to java in contrib (download_ecj, gcc_update,
  patch_tester.sh, update-copyright.py)
- GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
- LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
- references to java in install.texi

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 05/09/16 17:25, Gerald Pfeifer wrote:
> And here is the patch for the web pages.
> 
> Note I did not include all the removed java/* contents.  Is there
> anything particular you'd like to retain there?

No, please delete it all.

Thanks,

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 30/09/16 11:27, Marek Polacek wrote:
> Can we move forward with this patch, then?

I've been travelling for several weeks.  However, I'm back at my desk
now, so I can move this forward.  I have all the approvals and
everybody has had time to respond.  However, I'll need to pull some
more recent changes into my tree and merge again.

Andrew.

Re: [PATCH] Delete GCJ

[Marek Polacek]

On Sun, Sep 11, 2016 at 01:08:56PM +0100, Andrew Haley wrote:
> On 10/09/16 12:59, NightStrike wrote:
> > Could we at least reach out and see if there's someone else who could
> > be the maintainer?  I noticed gcj patches recently, so there's still
> > interest.
> 
> 1.  It's too late.  We have been discussing this for a long time, and
> we're now doing what we decided.
> 
> 2.  Maintaining GCJ requires a lot of knowledge of both Java and GCC
> internals.  There are very few people in the world with that
> knowledge, and I'm fairly sure I know them by name.
> 
> 3.  The Classpath library is very old and is unmaintained.  The only
> practical way to update GCJ would be to use the OpenJDK class
> libraries instead, but updating GCJ to use those class libraries is a
> very substantial job.
> 
> So, I cannot prevent anyone from coming along to maintain GCJ, and
> neither would I want to.  However, such a proposal would have to be
> credible.  It is a multi-engineer-year commitment, and not just any
> ordinary engineers.

Can we move forward with this patch, then?

Marek

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 10/09/16 12:59, NightStrike wrote:
> Could we at least reach out and see if there's someone else who could
> be the maintainer?  I noticed gcj patches recently, so there's still
> interest.

1.  It's too late.  We have been discussing this for a long time, and
we're now doing what we decided.

2.  Maintaining GCJ requires a lot of knowledge of both Java and GCC
internals.  There are very few people in the world with that
knowledge, and I'm fairly sure I know them by name.

3.  The Classpath library is very old and is unmaintained.  The only
practical way to update GCJ would be to use the OpenJDK class
libraries instead, but updating GCJ to use those class libraries is a
very substantial job.

So, I cannot prevent anyone from coming along to maintain GCJ, and
neither would I want to.  However, such a proposal would have to be
credible.  It is a multi-engineer-year commitment, and not just any
ordinary engineers.

Andrew.

Re: [PATCH] Delete GCJ

[NightStrike]

On Mon, Sep 5, 2016 at 11:13 AM, Andrew Haley  wrote:
> As discussed.  I think I should ask a Global reviewer to approve this
> one.  For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> if anyone would like to try it.
>
> Andrew.

For what little (to nothing) it's worth, I still use gcj, and I like
the ease of adding small bits of java to a project without involving
additional compilers.  It optimizes extremely well, is easy to use,
and adds to the completeness of the GNU Compiler *Collection*.

Could we at least reach out and see if there's someone else who could
be the maintainer?  I noticed gcj patches recently, so there's still
interest.

Re: [PATCH] Delete GCJ

[Ian Lance Taylor]

On Tue, Sep 6, 2016 at 2:06 AM, Richard Biener
 wrote:
> On Mon, Sep 5, 2016 at 6:17 PM, Andrew Haley  wrote:
>> On 05/09/16 17:15, Richard Biener wrote:
>>> On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley  
>>> wrote:
 As discussed.  I think I should ask a Global reviewer to approve this
 one.  For obvious reasons I haven't included the diffs to the deleted
 gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
 is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
 if anyone would like to try it.
>>>
>>> Isn't there also java specific C++ frontend parts?
>>
>> There certainly are, but deleting them without breaking anything else
>> is going to be rather delicate.  I'm trying to do this one step at a
>> time, rather cautiously.
>
> Ok, that sounds reasonable.
>
> You have my approval for this first part then.  Please wait until after the
> GNU Cauldron to allow other global reviewers to object.

I am fine with this.  It seems like the right move, alas.

Ian

Re: [PATCH] Delete GCJ

[Richard Earnshaw (lists)]

On 06/09/16 22:17, Jeff Law wrote:
> On 09/06/2016 03:08 AM, Jakub Jelinek wrote:
>> On Tue, Sep 06, 2016 at 11:06:36AM +0200, Richard Biener wrote:
>>> On Mon, Sep 5, 2016 at 6:17 PM, Andrew Haley  wrote:
 On 05/09/16 17:15, Richard Biener wrote:
> On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley
>  wrote:
>> As discussed.  I think I should ask a Global reviewer to approve this
>> one.  For obvious reasons I haven't included the diffs to the deleted
>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>> if anyone would like to try it.
>
> Isn't there also java specific C++ frontend parts?

 There certainly are, but deleting them without breaking anything else
 is going to be rather delicate.  I'm trying to do this one step at a
 time, rather cautiously.
>>>
>>> Ok, that sounds reasonable.
>>>
>>> You have my approval for this first part then.  Please wait until
>>> after the
>>> GNU Cauldron to allow other global reviewers to object.
>>
>> No objection from me.
> No objection from me either (I'm guessing that's not a surprise).
> 

Nor from me.

R.

> jeff

Re: [PATCH] Delete GCJ

[Jeff Law]

On 09/06/2016 03:08 AM, Jakub Jelinek wrote:

On Tue, Sep 06, 2016 at 11:06:36AM +0200, Richard Biener wrote:

On Mon, Sep 5, 2016 at 6:17 PM, Andrew Haley  wrote:

On 05/09/16 17:15, Richard Biener wrote:

On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley  wrote:

As discussed.  I think I should ask a Global reviewer to approve this
one.  For obvious reasons I haven't included the diffs to the deleted
gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
if anyone would like to try it.


Isn't there also java specific C++ frontend parts?


There certainly are, but deleting them without breaking anything else
is going to be rather delicate.  I'm trying to do this one step at a
time, rather cautiously.


Ok, that sounds reasonable.

You have my approval for this first part then.  Please wait until after the
GNU Cauldron to allow other global reviewers to object.


No objection from me.

No objection from me either (I'm guessing that's not a surprise).

jeff

Re: [PATCH] Delete GCJ

[Jakub Jelinek]

On Tue, Sep 06, 2016 at 11:06:36AM +0200, Richard Biener wrote:
> On Mon, Sep 5, 2016 at 6:17 PM, Andrew Haley  wrote:
> > On 05/09/16 17:15, Richard Biener wrote:
> >> On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley  
> >> wrote:
> >>> As discussed.  I think I should ask a Global reviewer to approve this
> >>> one.  For obvious reasons I haven't included the diffs to the deleted
> >>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
> >>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> >>> if anyone would like to try it.
> >>
> >> Isn't there also java specific C++ frontend parts?
> >
> > There certainly are, but deleting them without breaking anything else
> > is going to be rather delicate.  I'm trying to do this one step at a
> > time, rather cautiously.
> 
> Ok, that sounds reasonable.
> 
> You have my approval for this first part then.  Please wait until after the
> GNU Cauldron to allow other global reviewers to object.

No objection from me.

Jakub

Re: [PATCH] Delete GCJ

[Richard Biener]

On Mon, Sep 5, 2016 at 6:17 PM, Andrew Haley  wrote:
> On 05/09/16 17:15, Richard Biener wrote:
>> On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley  
>> wrote:
>>> As discussed.  I think I should ask a Global reviewer to approve this
>>> one.  For obvious reasons I haven't included the diffs to the deleted
>>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>>> if anyone would like to try it.
>>
>> Isn't there also java specific C++ frontend parts?
>
> There certainly are, but deleting them without breaking anything else
> is going to be rather delicate.  I'm trying to do this one step at a
> time, rather cautiously.

Ok, that sounds reasonable.

You have my approval for this first part then.  Please wait until after the
GNU Cauldron to allow other global reviewers to object.

Thanks,
Richard.

> Andrew.

Re: [PATCH] Delete GCJ

[Eric Gallager]

On 9/5/16, Bernd Edlinger  wrote:
> On 05.09.2016 17:13, Andrew Haley wrote:
>  > As discussed.  I think I should ask a Global reviewer to approve this
>  > one.  For obvious reasons I haven't included the diffs to the deleted
>  > gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>  > is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>  > if anyone would like to try it.
>  >
>  > Andrew.
>  >
>  >
>  > 2016-09-05  Andrew Haley  
>  >
>  >* Makefile.def: Remove libjava.
>  >* Makefile.tpl: Likewise.
>  >* Makefile.in: Regenerate.
>  >* configure.ac: Likewise.
>  >* configure: Likewise.
>  >* gcc/java: Remove.
>  >* libjava: Likewise.
>
>
> I think you can remove libffi as well, right?
>
>


I think Go uses libffi as well; for further discussion see bug 11660:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11660
(people there seem to think ObjC uses libffi, too, but I haven't
noticed it doing that myself)

Re: [PATCH] Delete GCJ

[Bernd Edlinger]

On 05.09.2016 17:13, Andrew Haley wrote:
 > As discussed.  I think I should ask a Global reviewer to approve this
 > one.  For obvious reasons I haven't included the diffs to the deleted
 > gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
 > is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
 > if anyone would like to try it.
 >
 > Andrew.
 >
 >
 > 2016-09-05  Andrew Haley  
 >
 >  * Makefile.def: Remove libjava.
 >  * Makefile.tpl: Likewise.
 >  * Makefile.in: Regenerate.
 >  * configure.ac: Likewise.
 >  * configure: Likewise.
 >  * gcc/java: Remove.
 >  * libjava: Likewise.


I think you can remove libffi as well, right?


Bernd.

Re: [PATCH] Delete GCJ

[Eric Gallager]

On 9/5/16, Gerald Pfeifer  wrote:
> On Mon, 5 Sep 2016, Andrew Haley wrote:
>> As discussed.  I think I should ask a Global reviewer to approve this
>> one.  For obvious reasons I haven't included the diffs to the deleted
>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>> if anyone would like to try it.
>
> And here is the patch for the web pages.
>
> Note I did not include all the removed java/* contents.  Is there
> anything particular you'd like to retain there?
>
> Gerald
>
> Index: index.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
> retrieving revision 1.1026
> diff -u -r1.1026 index.html
> --- index.html25 Aug 2016 10:55:41 -  1.1026
> +++ index.html5 Sep 2016 16:22:07 -
> @@ -15,8 +15,7 @@
>  C,
>  C++,
>  Objective-C, Fortran,
> -Java, Ada, and Go, as well as libraries for these
> -languages (libstdc++, libgcj,...).
> +Ada, and Go, as well as libraries for these languages (libstdc++,...).
>  GCC was originally written as the compiler for the   href="http://www.gnu.org/gnu/thegnuproject.html;>GNU operating system.
>  The GNU system was developed to be 100% free software, free in the sense
> Index: style.mhtml
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
> retrieving revision 1.131
> diff -u -r1.131 style.mhtml
> --- style.mhtml   23 Aug 2016 06:49:17 -  1.131
> +++ style.mhtml   5 Sep 2016 16:22:08 -
> @@ -10,15 +10,6 @@
>
>  >
>
> -;;; For the "java/" pages, we want the navigation bar.
> -
> - "java/[^/]*.html">
> -  -  
> -  
> - >
> ->
> -
>  ;;; Note that the  line really needs to start in the first
> column.
>
>  
> @@ -105,26 +96,6 @@
>
>
>
> -   "java/[^/]*.html">
> --
> -
> -
> -
> -
> -
> -GCJ Home
> -GCC Home
> -FAQ
> -Documentation
> -Contributing
> -Done with GCJ
> -
> -
> -
> -   >
> -  >
> -
>
>About GCC
>
>


I'd think something should go under the "Caveats" section of
https://gcc.gnu.org/gcc-7/changes.html
too, so people aren't surprised.
(There was never a deprecation notice in the equivalent page for GCC
6, by the way)

Re: [PATCH] Delete GCJ

[Eric Gallager]

On 9/5/16, Matthias Klose  wrote:
> On 05.09.2016 17:13, Andrew Haley wrote:
>> As discussed.  I think I should ask a Global reviewer to approve this
>> one.  For obvious reasons I haven't included the diffs to the deleted
>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>> if anyone would like to try it.
>>
>> Andrew.
>>
>>
>> 2016-09-05  Andrew Haley  
>>
>>  * Makefile.def: Remove libjava.
>>  * Makefile.tpl: Likewise.
>>  * Makefile.in: Regenerate.
>>  * configure.ac: Likewise.
>>  * configure: Likewise.
>>  * gcc/java: Remove.
>>  * libjava: Likewise.
>
> Please consider removing boehm-gc as well.  The only other user is
> --enable-objc-gc, which better should use an external boehm-gc.
>
> Matthias
>
>


How about a compromise to have it be downloaded with the
contrib/download_prerequisites script, instead of entirely keeping it,
or entirely deleting it?

Eric

Re: [PATCH] Delete GCJ

[Gerald Pfeifer]

On Mon, 5 Sep 2016, Andrew Haley wrote:
> As discussed.  I think I should ask a Global reviewer to approve this
> one.  For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> if anyone would like to try it.

And here is the patch for the web pages.

Note I did not include all the removed java/* contents.  Is there
anything particular you'd like to retain there?

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1026
diff -u -r1.1026 index.html
--- index.html  25 Aug 2016 10:55:41 -  1.1026
+++ index.html  5 Sep 2016 16:22:07 -
@@ -15,8 +15,7 @@
 C,
 C++,
 Objective-C, Fortran,
-Java, Ada, and Go, as well as libraries for these
-languages (libstdc++, libgcj,...).
+Ada, and Go, as well as libraries for these languages (libstdc++,...).
 GCC was originally written as the compiler for the http://www.gnu.org/gnu/thegnuproject.html;>GNU operating system.
 The GNU system was developed to be 100% free software, free in the sense
Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.131
diff -u -r1.131 style.mhtml
--- style.mhtml 23 Aug 2016 06:49:17 -  1.131
+++ style.mhtml 5 Sep 2016 16:22:08 -
@@ -10,15 +10,6 @@
   
 >
 
-;;; For the "java/" pages, we want the navigation bar.
-
- "java/[^/]*.html">
- 
-  
- >
->
-
 ;;; Note that the  line really needs to start in the first column.
 
 
@@ -105,26 +96,6 @@
   
   
 
-   "java/[^/]*.html">
-   
-
-
-
-
-
-GCJ Home
-GCC Home
-FAQ
-Documentation
-Contributing
-Done with GCJ
-
-
-
-   >
-  >
-
   
   About GCC
   

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 05/09/16 17:15, Richard Biener wrote:
> On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley  
> wrote:
>> As discussed.  I think I should ask a Global reviewer to approve this
>> one.  For obvious reasons I haven't included the diffs to the deleted
>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>> if anyone would like to try it.
> 
> Isn't there also java specific C++ frontend parts?

There certainly are, but deleting them without breaking anything else
is going to be rather delicate.  I'm trying to do this one step at a
time, rather cautiously.

Andrew.

RE: [PATCH] Delete GCJ

[Matthew Fortune]

Andrew Haley  writes:
> As discussed.  I think I should ask a Global reviewer to approve this
> one.  For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories.  The whole tree, post GCJ-deletion, is
> at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> if anyone would like to try it.

I hadn't realised libjava was earmarked for removal (and I have no
objection) but given I have an outstanding bug in libjava I wonder how
we will deal with bug fix backports when we can't commit to trunk first?

Matthew

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 05/09/16 16:29, Matthias Klose wrote:
> Please consider removing boehm-gc as well.  The only other user is
> --enable-objc-gc, which better should use an external boehm-gc.

I can do that, but I do not want to do so with this patch.

Andrew.

Re: [PATCH] Delete GCJ

[Matthias Klose]

On 05.09.2016 17:13, Andrew Haley wrote:
> As discussed.  I think I should ask a Global reviewer to approve this
> one.  For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> if anyone would like to try it.
> 
> Andrew.
> 
> 
> 2016-09-05  Andrew Haley  
> 
>   * Makefile.def: Remove libjava.
>   * Makefile.tpl: Likewise.
>   * Makefile.in: Regenerate.
>   * configure.ac: Likewise.
>   * configure: Likewise.
>   * gcc/java: Remove.
>   * libjava: Likewise.

Please consider removing boehm-gc as well.  The only other user is
--enable-objc-gc, which better should use an external boehm-gc.

Matthias

[PATCH] Delete GCJ

[Andrew Haley]

As discussed.  I think I should ask a Global reviewer to approve this
one.  For obvious reasons I haven't included the diffs to the deleted
gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
if anyone would like to try it.

Andrew.


2016-09-05  Andrew Haley  

* Makefile.def: Remove libjava.
* Makefile.tpl: Likewise.
* Makefile.in: Regenerate.
* configure.ac: Likewise.
* configure: Likewise.
* gcc/java: Remove.
* libjava: Likewise.

Index: Makefile.in
===
--- Makefile.in (revision 239988)
+++ Makefile.in (working copy)
@@ -322,8 +322,6 @@
 HOST_LIBELFLIBS = @libelflibs@
 HOST_LIBELFINC = @libelfinc@

-EXTRA_CONFIGARGS_LIBJAVA = @EXTRA_CONFIGARGS_LIBJAVA@
-
 # --
 # Programs producing files for the BUILD machine
 # --
@@ -1007,7 +1005,6 @@
 maybe-configure-target-winsup \
 maybe-configure-target-libgloss \
 maybe-configure-target-libffi \
-maybe-configure-target-libjava \
 maybe-configure-target-zlib \
 maybe-configure-target-boehm-gc \
 maybe-configure-target-rda \
@@ -1174,7 +1171,6 @@
 all-target: maybe-all-target-winsup
 all-target: maybe-all-target-libgloss
 all-target: maybe-all-target-libffi
-all-target: maybe-all-target-libjava
 all-target: maybe-all-target-zlib
 all-target: maybe-all-target-boehm-gc
 all-target: maybe-all-target-rda
@@ -1268,7 +1264,6 @@
 info-target: maybe-info-target-winsup
 info-target: maybe-info-target-libgloss
 info-target: maybe-info-target-libffi
-info-target: maybe-info-target-libjava
 info-target: maybe-info-target-zlib
 info-target: maybe-info-target-boehm-gc
 info-target: maybe-info-target-rda
@@ -1355,7 +1350,6 @@
 dvi-target: maybe-dvi-target-winsup
 dvi-target: maybe-dvi-target-libgloss
 dvi-target: maybe-dvi-target-libffi
-dvi-target: maybe-dvi-target-libjava
 dvi-target: maybe-dvi-target-zlib
 dvi-target: maybe-dvi-target-boehm-gc
 dvi-target: maybe-dvi-target-rda
@@ -1442,7 +1436,6 @@
 pdf-target: maybe-pdf-target-winsup
 pdf-target: maybe-pdf-target-libgloss
 pdf-target: maybe-pdf-target-libffi
-pdf-target: maybe-pdf-target-libjava
 pdf-target: maybe-pdf-target-zlib
 pdf-target: maybe-pdf-target-boehm-gc
 pdf-target: maybe-pdf-target-rda
@@ -1529,7 +1522,6 @@
 html-target: maybe-html-target-winsup
 html-target: maybe-html-target-libgloss
 html-target: maybe-html-target-libffi
-html-target: maybe-html-target-libjava
 html-target: maybe-html-target-zlib
 html-target: maybe-html-target-boehm-gc
 html-target: maybe-html-target-rda
@@ -1616,7 +1608,6 @@
 TAGS-target: maybe-TAGS-target-winsup
 TAGS-target: maybe-TAGS-target-libgloss
 TAGS-target: maybe-TAGS-target-libffi
-TAGS-target: maybe-TAGS-target-libjava
 TAGS-target: maybe-TAGS-target-zlib
 TAGS-target: maybe-TAGS-target-boehm-gc
 TAGS-target: maybe-TAGS-target-rda
@@ -1703,7 +1694,6 @@
 install-info-target: maybe-install-info-target-winsup
 install-info-target: maybe-install-info-target-libgloss
 install-info-target: maybe-install-info-target-libffi
-install-info-target: maybe-install-info-target-libjava
 install-info-target: maybe-install-info-target-zlib
 install-info-target: maybe-install-info-target-boehm-gc
 install-info-target: maybe-install-info-target-rda
@@ -1790,7 +1780,6 @@
 install-pdf-target: maybe-install-pdf-target-winsup
 install-pdf-target: maybe-install-pdf-target-libgloss
 install-pdf-target: maybe-install-pdf-target-libffi
-install-pdf-target: maybe-install-pdf-target-libjava
 install-pdf-target: maybe-install-pdf-target-zlib
 install-pdf-target: maybe-install-pdf-target-boehm-gc
 install-pdf-target: maybe-install-pdf-target-rda
@@ -1877,7 +1866,6 @@
 install-html-target: maybe-install-html-target-winsup
 install-html-target: maybe-install-html-target-libgloss
 install-html-target: maybe-install-html-target-libffi
-install-html-target: maybe-install-html-target-libjava
 install-html-target: maybe-install-html-target-zlib
 install-html-target: maybe-install-html-target-boehm-gc
 install-html-target: maybe-install-html-target-rda
@@ -1964,7 +1952,6 @@
 installcheck-target: maybe-installcheck-target-winsup
 installcheck-target: maybe-installcheck-target-libgloss
 installcheck-target: maybe-installcheck-target-libffi
-installcheck-target: maybe-installcheck-target-libjava
 installcheck-target: maybe-installcheck-target-zlib
 installcheck-target: maybe-installcheck-target-boehm-gc
 installcheck-target: maybe-installcheck-target-rda
@@ -2051,7 +2038,6 @@
 mostlyclean-target: maybe-mostlyclean-target-winsup
 mostlyclean-target: maybe-mostlyclean-target-libgloss
 mostlyclean-target: maybe-mostlyclean-target-libffi
-mostlyclean-target: maybe-mostlyclean-target-libjava
 mostlyclean-target: maybe-mostlyclean-target-zlib
 mostlyclean-target: