Re: Feedback request on how best to handle recursion in concept satisfaction

[Nathan Sidwell]

On 10/29/19 4:46 PM, Jeff Chapman wrote:

Hello,




template
concept Foo = requires(T t) { foo(t); };

template
   requires Foo
int foo(T t) { return foo(t); }

Similar cases without concepts are handled with
-ftemplate-depth/max_tinst_depth but satisfaction on trunk does not currently
pass through anything that increments tinst_depth.


Why doesn't the std specify the satisfaction nesting limit in the same 
way as template instantiation? (at least that's what I infer from your 
question).


nathan

--
Nathan Sidwell

Re: GCC selftest improvements

[Pedro Alves]

On 10/26/19 11:46 PM, Eric Gallager wrote:

> Nicholas Krause was also wanting to move to C++11 recently:
> https://gcc.gnu.org/ml/gcc/2019-10/msg00110.html (this month)
> https://gcc.gnu.org/ml/gcc/2019-09/msg00228.html (last month)
> As I said in that thread, I'd want to try just toggling -Wnarrowing
> from off to on first before going full C++11. 

Why?  GDB went the other way when it moved to C++11.  It switched
to C++11, and for several months, used -Wno-narrowing to quiet
the thousands of warnings.

https://gcc.gnu.org/wiki/FAQ#Wnarrowing

> So, GCC 10 would be
> C++98 + -Wnarrowing, and then GCC 11 could be full C++11. Plus then
> the GCC version numbers would also line up with the version of C++
> being used.

Thanks,
Pedro Alves

Re: GCC selftest improvements

[Pedro Alves]

On 10/29/19 8:40 AM, Richard Biener wrote:
> On Mon, Oct 28, 2019 at 10:47 PM Jakub Jelinek  wrote:
>>

>> As discussed earlier, we gain most through C++11 support, there is no need
>> to jump to C++17 or C++20 as requirement.
> 
> Yes, I've agreed to raise the requirement to GCC 4.8 which provides
> C++11 support.
> 
> For convenience we could also provide a configure-time hint if the host 
> compiler
> doesn't have C++11 support or is older than 4.8.2 (I think .1 has some 
> issues).
> Rather than only running into some obscure errors later on.

FWIW, GDB uses a slightly modified AX_CXX_COMPILE_STDCXX to check for C++11
support at configure time, and add -std=gnu++11 if the necessary, adding nothing
if the compiler supports C++11 or later OOTB (so that you can still access
C++14-or-later features&optimizations conditionally).

 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/ax_cxx_compile_stdcxx.m4

 https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html

 https://sourceware.org/ml/gdb-patches/2016-10/msg00775.html

In practice, that returns "supports" for GCC 4.8 and above, which is
GDB's minimum requirement.  I'm not sure about 4.8.x patch level.

Thanks,
Pedro Alves

Re: BountySource campaign for gcc PR/91851

[Georg-Johann Lay]

Peter Bergner schrieb:

On 10/30/19 2:31 PM, Georg-Johann Lay wrote:

Hi, have the cc0 backends been deprecated?

I didn't follow the lists for some time...  At least neither v9 or v10
release notes caveats mention such deprecation, neither is there
respective PRs for the cc0 targets.


https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html

Peter


Ah, thanks.

So finally, the time has come to move to clang/llvm ?

Johann

Re: BountySource campaign for gcc PR/91851

[John Paul Adrian Glaubitz]

On 10/31/19 10:00 PM, Georg-Johann Lay wrote:
>>> I didn't follow the lists for some time...  At least neither v9 or v10
>>> release notes caveats mention such deprecation, neither is there
>>> respective PRs for the cc0 targets.
>>
>> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html
>>
>> Peter
> 
> Ah, thanks.
> 
> So finally, the time has come to move to clang/llvm ?

Not quite. Motorola 68k is currently not officially supported by LLVM/Clang.

There is a port that is half-finished though [1] and there is also one guy from
Czech Republic who wrote a Bachelor thesis on an m68k backend for LLVM [2]. I
have not been able to contact him though as his university address bounces.
I would love to see the code that was written there.

I have also played around with Rust on m68k based on the LLVM code on [1], but
it doesn't really work yet. I think finishing LLVM for m68k would be another
idea for a Bountysource campaign.

Adrian

> [1] https://github.com/M680x0/M680x0-llvm/
> [2] https://www.vutbr.cz/en/students/final-thesis?zp_id=34902
> [3] https://github.com/glaubitz/rust/tree/m68k-linux

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

gcc-7-20191031 is now available

[gccadmin]

Snapshot gcc-7-20191031 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20191031/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch 
revision 277697

You'll find:

 gcc-7-20191031.tar.xzComplete GCC

  SHA256=d90eb5fa39f9b43d3b911a3361e43eff380a34637b23b6e408045600f0e69483
  SHA1=85e181484f65cbc51f7b3d5d1ff1cdc529c8164f

Diffs from 7-20191024 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: BountySource campaign for gcc PR/91851

[Georg-Johann Lay]

John Paul Adrian Glaubitz schrieb:

On 10/31/19 10:00 PM, Georg-Johann Lay wrote:

I didn't follow the lists for some time...  At least neither v9 or v10
release notes caveats mention such deprecation, neither is there
respective PRs for the cc0 targets.

https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html

Peter

Ah, thanks.

So finally, the time has come to move to clang/llvm ?


Not quite. Motorola 68k is currently not officially supported by LLVM/Clang.


For AVR -- an other port affected by cc0 removal -- there is a 
LLVM/Clang port.  It' not as mature as GCC's avr port, but what counts 
in the end is support / responsiveness from the community and an 
openness for the requirements of deeply embedded targets.  I had gcc 
patches rejected by global maintainers (just a no-op hook for other 
targets) because it appeared they didn't even understand what the patch 
is about (and kept proposing alternative "solutions" that totally missed 
the point).


And code quality is deteriorating from version to version.  Whatever you 
do in the backend to mitigate it, there's always global changes that 
shreds any improvements...


Btw, does GCC support clobbering registers in branches (or 
cbranch4 for that matter)?  This requirement would come up when 
transitioning avr to cc_mode because cbranches would live post reload.


Johann



There is a port that is half-finished though [1] and there is also one guy from
Czech Republic who wrote a Bachelor thesis on an m68k backend for LLVM [2]. I
have not been able to contact him though as his university address bounces.
I would love to see the code that was written there.

I have also played around with Rust on m68k based on the LLVM code on [1], but
it doesn't really work yet. I think finishing LLVM for m68k would be another
idea for a Bountysource campaign.

Adrian


[1] https://github.com/M680x0/M680x0-llvm/
[2] https://www.vutbr.cz/en/students/final-thesis?zp_id=34902
[3] https://github.com/glaubitz/rust/tree/m68k-linux

Re: Fixing cvs2svn branchpoints

[Joseph Myers]

Here are complete lists of reparentings I think should be done on the 
commits that start branches, along with my notes on branches with messy 
initial commits but where I don't think any reparenting should be done.  
The REPARENT: lines have the meaning I described in 
.

Of the 54 branches with suspicious branchpoints, I have 32 with 
automatically suggested or verified reparentings, meeting the criteria 
given in that message for the new parent not being suspicious, and 7 more 
I think should be reparented although the new parent is still suspicious 
in some ways (e.g. because of vendor branch issues or non-atomic 
branching).  The remaining 15 suspicious cases are ones where I think the 
existing branchpoint is the best one available.

Automatically suggested or verified reparentings:

REPARENT: /branches/GC_5_0_ALPHA_1 27860 /trunk 27852 /trunk 27855
REPARENT: /branches/apple-200511-release-branch 105574 /trunk 95082 
/branches/apple-local-200502-branch 105446
REPARENT: /branches/apple-gcc_os_35-branch 90607 
/branches/tree-ssa-20020619-branch 79740 /branches/apple-ppc-branch 90334
REPARENT: /branches/apple-tiger-release-branch 96595 
/branches/tree-ssa-20020619-branch 79740 /branches/apple-ppc-branch 96593
REPARENT: /branches/bje-unsw-branch 97591 /trunk 95529 /branches/gcc-4_0-branch 
97590
REPARENT: /branches/bounded-pointers-branch 3 /trunk 33317 /trunk 33062
REPARENT: /branches/cfg-branch 46945 /trunk 46940 /trunk 46941
REPARENT: /branches/csl-3_3_1-branch 70143 /trunk 60111 
/branches/gcc-3_3-branch 70142
REPARENT: /branches/csl-3_4-linux-branch 90110 /trunk 75991 
/branches/gcc-3_4-branch 90109
REPARENT: /branches/csl-3_4_0-hp-branch 80843 /trunk 75991 
/branches/gcc-3_4-branch 80842
REPARENT: /branches/csl-3_4_3-linux-branch 93879 /trunk 72971 
/branches/csl-arm-branch 92959
REPARENT: /branches/csl-arm-2004-q3-branch 90934 /trunk 72971 
/branches/csl-arm-branch 90933
REPARENT: /branches/csl-gxxpro-3_4-branch 102442 /trunk 72971 
/branches/csl-arm-branch 102441
REPARENT: /branches/csl-sol210-3_4-branch 87927 /trunk 75991 
/branches/gcc-3_4-branch 87903
REPARENT: /branches/cygming331 70683 /trunk 60111 /branches/gcc-3_3-branch 70142
REPARENT: /branches/cygming332 73014 /trunk 60111 /branches/cygming331 73013
REPARENT: /branches/cygwin-mingw-gcc-3_1-branch 53609 /trunk 50029 
/branches/gcc-3_1-branch 53596
REPARENT: /branches/cygwin-mingw-gcc-3_2-branch 55799 /trunk 50029 
/branches/cygwin-mingw-gcc-3_1-branch 55797
REPARENT: /branches/cygwin-mingw-gcc-3_2_1-branch 59662 /trunk 50029 
/branches/cygwin-mingw-gcc-3_2-branch 59368
REPARENT: /branches/cygwin-mingw-v2-branch 60175 /trunk 50029 
/branches/gcc-3_2-branch 59267
REPARENT: /branches/egcs_1_00_branch 16282 /branches/devo_gcc_testsuite 14842 
/trunk 16272
REPARENT: /branches/gcc-2_95_2_1-branch 30162 /trunk 26993 
/branches/gcc-2_95-branch 30160
REPARENT: /branches/gcc-3_2-branch 55785 /trunk 50029 /branches/gcc-3_1-branch 
55783
REPARENT: /branches/gcc-3_3-e500-branch 65902 /trunk 60111 
/branches/gcc-3_3-branch 65660
REPARENT: /branches/gcc-3_3-rhl-branch 66998 /trunk 60111 
/branches/gcc-3_3-branch 66832
REPARENT: /branches/gcc-3_4-e500-branch 89417 /trunk 75991 
/branches/gcc-3_4-branch 89410
REPARENT: /branches/gcc-3_4-rhl-branch 81014 /trunk 75991 
/branches/gcc-3_4-branch 80870
REPARENT: /branches/gcc-4_0-rhl-branch 95664 /trunk 95533 
/branches/gcc-4_0-branch 95655
REPARENT: /branches/gomp-01-branch 62579 /trunk 62499 
/branches/tree-ssa-20020619-branch 62392
REPARENT: /branches/libgcj-2_95-branch 27730 /branches/CYGNUS 26267 /trunk 27727
REPARENT: /branches/struct-reorg-branch 87007 
/branches/tree-ssa-20020619-branch 77756 /branches/tree-profiling-branch 86038
REPARENT: /branches/tree-cleanup-branch 87819 /trunk 87795 /trunk 87698

In the case of cfg-branch, the reparenting was suggested automatically
based on the branchpoint tag with a note of possible mismatch between
branch and branchpoint tag; that mismatch appears just to be a vendor
branch artifact and the reparenting seems correct.

Manually identified reparentings (not perfect matches, but seem the
best available and better than the existing parents):

REPARENT: /branches/apple-200508-beta-branch 102941 /trunk 95082 
/branches/apple-local-200502-branch 102940
REPARENT: /branches/bnw-simple-branch 56621 /trunk 54811 
/branches/tree-ssa-20020619-branch 56620
REPARENT: /branches/egcs_gc_branch 19641 /branches/devo_gcc_testsuite 14842 
/trunk 19615
REPARENT: /branches/ffixinc-branch 23624 /branches/devo_gcc_testsuite 14842 
/trunk 23622
REPARENT: /branches/gcc-3_2-rhl8-branch 57454 /trunk 50029 
/branches/gcc-3_2-branch 56747
REPARENT: /branches/gnu-win32-b20-branch 22525 /branches/devo_gcc_testsuite 
14842 /branches/egcs_1_1_branch 22523
REPARENT: /branches/structure-aliasing-branch 87042 /trunk 86982 /trunk 86980

My notes on branches with imperfect parents to leave as-is, as
considered good-enough after analysis (even whe

Re: BountySource campaign for gcc PR/91851

[Segher Boessenkool]

On Thu, Oct 31, 2019 at 11:46:27PM +0100, Georg-Johann Lay wrote:
> For AVR -- an other port affected by cc0 removal -- there is a 
> LLVM/Clang port.  It' not as mature as GCC's avr port, but what counts 
> in the end is support / responsiveness from the community and an 
> openness for the requirements of deeply embedded targets.

And you think you find that less in GCC?  Huh.

> I had gcc 
> patches rejected by global maintainers (just a no-op hook for other 
> targets) because it appeared they didn't even understand what the patch 
> is about (and kept proposing alternative "solutions" that totally missed 
> the point).

Please point me to that.  In private mail, if you prefer.

> And code quality is deteriorating from version to version.  Whatever you 
> do in the backend to mitigate it, there's always global changes that 
> shreds any improvements...

I don't see that.  Things that aren't maintained and have no good tripwire
tests for code quality can (and will) degrade naturally, of course.  But
maintained targets do not normally have a hard time keeping up.

> Btw, does GCC support clobbering registers in branches (or 
> cbranch4 for that matter)?  This requirement would come up when 
> transitioning avr to cc_mode because cbranches would live post reload.

Of course.  You cannot have *reloads* on branches, that is all.


Segher

Error

[pen1979871192]

Why i can not search anything in Goole Search 

Re: Fixing cvs2svn branchpoints

[Eric S. Raymond]

Joseph Myers :
> Here are complete lists of reparentings I think should be done on the 
> commits that start branches, along with my notes on branches with messy 
> initial commits but where I don't think any reparenting should be done.  
> The REPARENT: lines have the meaning I described in 
> .

Please leave this as an issue on the gcc-conversion bugtracker.

Your timing is interesting.  Happens I got my first full conversion
with the Go port of reposurgeon earlier today.  I'm trying to verify
the conversion against the Subversion repository, but a full checkout
filled a filesystem on the EC2 instance I'm using. Recovery is
underway.

I'll do real benchmarks when I'm not staring at a deadline, but the
Go port is at least 20x faster than the Python was.  That makes
the conversion practical, though it turns out the 128GB on my 
desktop machine isn't enough to support it - hence the EC2 instance.

The first full conversion took eight hours.  Turns out the single most
computationally expensive part of the surgery is data-mining ChangeLog
files for commit attributions.  Today I threw massive parallelism at
the problem, that being something far easier to do in Go than in Python
- I think that might cut as much as two hours from the next run.

By going to the cloud I've gotten a larger working-set capacity at the
cost of some memory-access speed.  Didn't want to do that, but 
your repo is just too damn big for it to be otherwise, unless somebody
wants to drop cash on me to double the RAM in the Great Beast.

Your pile of requests is tricky but should be doable.

You had previously written:

>There are also cases where cvs2svn found a good branchpoint, but
>represented the branch-creation commit in a superfluously complicated
>way, replacing lots of files and subdirectories by copies of different
>revisions.

Yes, reposurgeon has logic to detect and deal with this automatically.
The assumption it makes is that the branch should root to the most
recent revision that CVS did a copy from. This is simple and seems to
give satisfactory results.

Which reminds me. I found a bunch of "svnmerge-integrated" properites
in the history. Should I treat those as though they were mergeinfo
properies and make branch merges from them?
-- 
http://www.catb.org/~esr/";>Eric S. Raymond