Re: [PATCH] Deprecate -frepo option.

2019-09-09 Thread Martin Liška
On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
>> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
>>> Ok, hopefully nobody is strongly against. I've just retested the
>>> patch and installed it as r275450.
>>
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
>>  Used in Fix-and-Continue mode to indicate that object files may be swapped 
>> in at runtime.
>>
>>  frepo
>> -C++ ObjC++
>> -Enable automatic template instantiation.
>> +C++ ObjC++ Deprecated
>> +Deprecated in GCC 10.  This switch has no effect.
> 
> The Deprecated keyword is just misnamed, I believe it does the same thing as
> Ignore, except that it also prints a warning that the switch is no longer
> supported, so kind like Ignore Warn(switch %<-frepo%> is no longer supported).
> The description should be just This switch has no effect. or
> Does nothing.  Preserved for backward compatibility.

I verified the description and it's fine to me:

frepo
C++ ObjC++ Deprecated
Deprecated in GCC 10.  This switch has no effect.

> 
>   Jakub
> 



Re: [PATCH] Deprecate -frepo option.

2019-09-09 Thread Jakub Jelinek
On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote:
> On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> > On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
> >> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> >>> Ok, hopefully nobody is strongly against. I've just retested the
> >>> patch and installed it as r275450.
> >>
> >> --- a/gcc/c-family/c.opt
> >> +++ b/gcc/c-family/c.opt
> >> @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
> >>  Used in Fix-and-Continue mode to indicate that object files may be 
> >> swapped in at runtime.
> >>
> >>  frepo
> >> -C++ ObjC++
> >> -Enable automatic template instantiation.
> >> +C++ ObjC++ Deprecated
> >> +Deprecated in GCC 10.  This switch has no effect.
> > 
> > The Deprecated keyword is just misnamed, I believe it does the same thing as
> > Ignore, except that it also prints a warning that the switch is no longer
> > supported, so kind like Ignore Warn(switch %<-frepo%> is no longer 
> > supported).
> > The description should be just This switch has no effect. or
> > Does nothing.  Preserved for backward compatibility.
> 
> I verified the description and it's fine to me:
> 
> frepo
> C++ ObjC++ Deprecated
> Deprecated in GCC 10.  This switch has no effect.

This first part looks wrong to me.
"deprecated
(computing) Obsolescent; said of a construct in a computing language considered 
old,
and planned to be phased out, but still available for use."
That is not the case here in GCC 10, the feature has been removed, it has
been deprecated in GCC 9.N for N >= 2 only.

Jakub


[PATCH] Update comment of removed options.

2019-09-09 Thread Martin Liška
On 9/9/19 1:08 PM, Jakub Jelinek wrote:
> On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote:
>> On 9/6/19 4:56 PM, Jakub Jelinek wrote:
>>> On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
 On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> Ok, hopefully nobody is strongly against. I've just retested the
> patch and installed it as r275450.

 --- a/gcc/c-family/c.opt
 +++ b/gcc/c-family/c.opt
 @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
  Used in Fix-and-Continue mode to indicate that object files may be 
 swapped in at runtime.

  frepo
 -C++ ObjC++
 -Enable automatic template instantiation.
 +C++ ObjC++ Deprecated
 +Deprecated in GCC 10.  This switch has no effect.
>>>
>>> The Deprecated keyword is just misnamed, I believe it does the same thing as
>>> Ignore, except that it also prints a warning that the switch is no longer
>>> supported, so kind like Ignore Warn(switch %<-frepo%> is no longer 
>>> supported).
>>> The description should be just This switch has no effect. or
>>> Does nothing.  Preserved for backward compatibility.
>>
>> I verified the description and it's fine to me:
>>
>> frepo
>> C++ ObjC++ Deprecated
>> Deprecated in GCC 10.  This switch has no effect.
> 
> This first part looks wrong to me.
> "deprecated
> (computing) Obsolescent; said of a construct in a computing language 
> considered old,
> and planned to be phased out, but still available for use."

You are right. What about the suggested patch?

Martin

> That is not the case here in GCC 10, the feature has been removed, it has
> been deprecated in GCC 9.N for N >= 2 only.
> 
>   Jakub
> 

>From ece8a83bdf6c2504bfe57dd033f6876cf2ffb9a2 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 9 Sep 2019 13:22:51 +0200
Subject: [PATCH] Update comment of removed options.

gcc/ChangeLog:

2019-09-09  Martin Liska  

	* config/i386/i386.opt: Update comment of removed
	options that are preserved only for backward
	compatibility.

gcc/c-family/ChangeLog:

2019-09-09  Martin Liska  

	* c.opt: Update comment of removed
	options that are preserved only for backward
	compatibility.
---
 gcc/c-family/c.opt   | 46 
 gcc/config/i386/i386.opt |  4 ++--
 2 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index ec546663029..c5804470d47 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -429,7 +429,7 @@ Warn about subscripts whose type is \"char\".
 
 Wchkp
 C ObjC C++ ObjC++ Warning Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 Wclobbered
 C ObjC C++ ObjC++ Var(warn_clobbered) Warning EnabledBy(Wextra)
@@ -1338,90 +1338,90 @@ and character literals.
 
 fcheck-pointer-bounds
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-check-incomplete-type
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-zero-input-bounds-for-main
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-first-field-has-own-bounds
 C ObjC C++ ObjC++ LTO Deprecated RejectNegative
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-narrow-bounds
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-narrow-to-innermost-array
 C ObjC C++ ObjC++ LTO Deprecated RejectNegative
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-flexible-struct-trailing-arrays
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-optimize
 C ObjC C++ ObjC++ LTO Deprecated
 
 fchkp-use-fast-string-functions
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-use-nochk-string-functions
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-use-static-bounds
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-use-static-const-bounds
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-treat-zero-dynamic-size-as-infinite
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This switch has no effect.
+Removed in GCC 9.  This switch has no effect.
 
 fchkp-check-read
 C ObjC C++ ObjC++ LTO Deprecated
-Deprecated in GCC 9.  This swit

Re: [PATCH] Update comment of removed options.

2019-09-09 Thread Jonathan Wakely
On Mon, 9 Sep 2019 at 12:24, Martin Liška  wrote:
>
> On 9/9/19 1:08 PM, Jakub Jelinek wrote:
> > On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote:
> >> On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> >>> On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
>  On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> > Ok, hopefully nobody is strongly against. I've just retested the
> > patch and installed it as r275450.
> 
>  --- a/gcc/c-family/c.opt
>  +++ b/gcc/c-family/c.opt
>  @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
>   Used in Fix-and-Continue mode to indicate that object files may be 
>  swapped in at runtime.
> 
>   frepo
>  -C++ ObjC++
>  -Enable automatic template instantiation.
>  +C++ ObjC++ Deprecated
>  +Deprecated in GCC 10.  This switch has no effect.
> >>>
> >>> The Deprecated keyword is just misnamed, I believe it does the same thing 
> >>> as
> >>> Ignore, except that it also prints a warning that the switch is no longer
> >>> supported, so kind like Ignore Warn(switch %<-frepo%> is no longer 
> >>> supported).
> >>> The description should be just This switch has no effect. or
> >>> Does nothing.  Preserved for backward compatibility.
> >>
> >> I verified the description and it's fine to me:
> >>
> >> frepo
> >> C++ ObjC++ Deprecated
> >> Deprecated in GCC 10.  This switch has no effect.
> >
> > This first part looks wrong to me.
> > "deprecated
> > (computing) Obsolescent; said of a construct in a computing language 
> > considered old,
> > and planned to be phased out, but still available for use."

I agree with this definition. If it's deprecated it still needs to be
available for use.


Re: [PATCH] Update comment of removed options.

2019-09-09 Thread Jakub Jelinek
On Mon, Sep 09, 2019 at 01:24:53PM +0200, Martin Liška wrote:
> You are right. What about the suggested patch?

Can you please quickly (say with svn blame) double check whether the
descriptions weren't actually right but misleading (an option could
be deprecated in N and removed in N+1 or so, so see if it has been actually
removed in the GCC release mentioned in there, rather than deprecated and
removed later)?

Ok with that.  Perhaps it would be desirable to also rename the Deprecated
keyword in *.opt to Removed and adjust documentation, but that can be
handled separately.

Jakub


Re: [PATCH] Update comment of removed options.

2019-09-09 Thread Martin Liška
On 9/9/19 1:39 PM, Jakub Jelinek wrote:
> On Mon, Sep 09, 2019 at 01:24:53PM +0200, Martin Liška wrote:
>> You are right. What about the suggested patch?
> 
> Can you please quickly (say with svn blame) double check whether the
> descriptions weren't actually right but misleading (an option could
> be deprecated in N and removed in N+1 or so, so see if it has been actually
> removed in the GCC release mentioned in there, rather than deprecated and
> removed later)?

Yes, majority of the changes are MPX-related options. There were really removed 
in GCC 9.x.
Then there's fcilkplus (really removed in GCC 8.x) and last one is -frepo, 
which I've just
removed (thus GCC 10).

Martin

> 
> Ok with that.  Perhaps it would be desirable to also rename the Deprecated
> keyword in *.opt to Removed and adjust documentation, but that can be
> handled separately.
> 
>   Jakub
> 



Re: [PATCH] Update comment of removed options.

2019-09-09 Thread Theodore Papadopoulo
On 9/9/19 1:34 PM, Jonathan Wakely wrote:

 frepo
 C++ ObjC++ Deprecated
 Deprecated in GCC 10.  This switch has no effect.
>>>
>>> This first part looks wrong to me.
>>> "deprecated
>>> (computing) Obsolescent; said of a construct in a computing language 
>>> considered old,
>>> and planned to be phased out, but still available for use."
> 
> I agree with this definition. If it's deprecated it still needs to be
> available for use.
> 

Pedantically, the flag is deprecated but the functionality is removed.
If the intent, is to remove the flag after a while, it might be nice to
say that the use of the flag is deprecated...




0x12BF16AD4F273D5D.asc
Description: application/pgp-keys


GNU Mes 0.20 released

2019-09-09 Thread Jan Nieuwenhuizen

We are pleased to announce the release of GNU Mes 0.20, representing
147 commits over 38 weeks.

Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap
a GNU/Linux system without binary GNU toolchain or equivalent).  It
should land in Guix master any day now: a big thank you to everyone who
helped, notably Ludovic and Mark.

This release is a step towards the upcoming Scheme-only bootstrap and
bringing Mes into NixOS and Debian.  This effort is now sponsored by
NLnet[12].

Next targets:

 - ARM support
 - Reduced Binary Seed bootstrap for ARM
 - Scheme-only bootstrap: use Guile and Gash to remove bash,
   coreutils&co, grep, sed, etc. from the Guix bootstrap binaries
 - mes-m2: port Mes.c to M2-Planet
 - Introduce Reduced Binaries Seed bootstrap to NixOS
 - Debian?
 - Hurd

Packages are available in Guix master.

* About

  GNU Mes[0] brings a Reduced Binary Seed bootstrap[1] to GNU Guix[2]
  and potentially to any other interested GNU/Linux distribution, and
  aims to help create a full source bootstrap as part of the
  bootstrappable builds[3] effort.

  It consists of a mutual self-hosting Scheme interpreter written in
  ~5,000 LOC of simple C and a Nyacc-based C compiler written in Scheme.
  This mes.c is being simplified[4] to be transpiled by M2-Planet[5].

  The Scheme interpreter (mes.c) has a Garbage Collector, a library of
  loadable Scheme modules-- notably Dominique Boucher's LALR[6], Pre-R6RS
  [portable syntax-case[7] with R7RS ellipsis, Matt Wette's Nyacc[8] --and test
  suite just barely enough to support a simple REPL and simple
  C-compiler: MesCC.

  Mes+MesCC can compile an only lightly patched TinyCC[9] that is
  self-hosting.  Using this tcc and the Mes C library we now have a
  Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5,
  binutils-2.20.1, gcc-2.95.3.  This is enough to bootstrap Guix for
  i686-linux and x86_64-linux.

  Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10] -- John
  McCarthy page 13, GNU Guix's source/binary packaging transparency and
  Jeremiah Orians's stage0[11] ~500 byte self-hosting hex assembler.

* Download

  git clone git://git.savannah.gnu.org/mes.git

  Here are the compressed sources and a GPG detached signature[*]:
https://ftp.gnu.org/gnu/mes/mes-0.20.tar.gz
https://ftp.gnu.org/gnu/mes/mes-0.20.tar.gz.sig

  Use a mirror for higher download bandwidth:
https://ftpmirror.gnu.org/mes/mes-0.20.tar.gz
https://ftpmirror.gnu.org/mes/mes-0.20.tar.gz.sig

  Here are the MD5 and SHA1 checksums:

  df839a83e4a2ad6c2a4accc5bf17b1a7  mes-0.20.tar.gz
  38d4cb3fa28fa1f5fc57fea9e046d4d8052bbb8c  mes-0.20.tar.gz

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

gpg --verify mes-0.20.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 
1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

  and rerun the 'gpg --verify' command.

* Changes in 0.20 since 0.19
 ** Core
 *** The build system has been simplified, again.
 Mes now builds ootb on Debian.
 *** Mes now supports -c EXPR.
 ** Divide by zero is now flagged.
 ** Language
 *** 1 new function:
 take-while.
 ** MesCC
 *** The C libraries have been exploded into one function per file.
 *** MesCC now has enhanced POSIX/gcc comand line support, e.g. -DFOO=1,
 -nodefaultlibs, -nostartfiles, -nostdlib.
 *** The archiver is now called `mesar'.
 *** MesCC now supports Nyacc-0.99.
 *** MesCC now depends on MesCC-Tools 0.6.0.
 *** 1 new function
 __mesabi_uldiv.
 ** Noteworthy bug fixes
 *** interger division has been fixed.
 *** isatty now looks at terminfo.
 *** signal now uses sigaction correctly for non-x86.
 *** string->number now support #x hex-prefix.
 *** ungetc now has a buffer per file handle.

Greetings,
janneke and Danny.

[0] https://www.gnu.org/software/mes
[1] http://joyofsource.com/reduced-binary-seed-bootstrap.html
[2] https://www.gnu.org/software/guix
[3] https://bootstrappable.org
[4] https://github.com/oriansj/mes-m2
[5] https://github.com/oriansj/m2-planet
[6] https://github.com/schemeway/lalr-scm
[7] https://www.cs.indiana.edu/chezscheme/syntax-case/old-psyntax.html
[8] https://www.nongnu.org/nyacc
[9] https://gitlab.com/janneke/tinycc
[10] 
http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf
[11] https://github.com/oriansj/stage0
[12] https://nlnet.nl/project/GNUMes

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com


signature.asc
Description: PGP signature


Is GIMPLE stable?

2019-09-09 Thread Mateus Carmo Martins de Freitas Barbosa
There's an ongoing discussion on the rustc forum
()
on implementing a GCC front-end for the Rust compiler, and the issue
of whether GIMPLE is stable was brought up. Namely, if a compiler
front-end were to output GIMPLE directly, how often (if at all) would
its codebase have to be changed to due to breaking changes from GCC?

I did find this reply
 which says:

>> ?^ It looks like GIMPLE is expected to change per version of gcc. Is there a 
>> time in >> the future when GIMPLE will be pretty stable?
>
> "Pretty stable" won't be enough, and I don't see us arriving there at
> the moment.

But this is fairly old (2011) so it seemed reasonable to ask if this
is still the case.


Re: Is GIMPLE stable?

2019-09-09 Thread Ian Lance Taylor via gcc
On Mon, Sep 9, 2019 at 8:09 PM Mateus Carmo Martins de Freitas Barbosa
 wrote:
>
> There's an ongoing discussion on the rustc forum
> ()
> on implementing a GCC front-end for the Rust compiler, and the issue
> of whether GIMPLE is stable was brought up. Namely, if a compiler
> front-end were to output GIMPLE directly, how often (if at all) would
> its codebase have to be changed to due to breaking changes from GCC?
>
> I did find this reply
>  which says:
>
> >> ?^ It looks like GIMPLE is expected to change per version of gcc. Is there 
> >> a time in >> the future when GIMPLE will be pretty stable?
> >
> > "Pretty stable" won't be enough, and I don't see us arriving there at
> > the moment.
>
> But this is fairly old (2011) so it seemed reasonable to ask if this
> is still the case.

GIMPLE is fairly stable but not 100% stable.  The way the Go frontend
handles this is that the file that converts between the Go frontend IR
and GIMPLE is part of the GCC tree (gcc/go/go-gcc.cc).  This file is
then routinely updated whenever three is a tree-wide GIMPLE change.
With that approach I very rarely have to change the GIMPLE generation
code myself.

Ian