Re: Commit messages and the move to git

2019-12-20 Thread Joseph Myers
On Fri, 20 Dec 2019, Jonathan Wakely wrote: > On Fri, 20 Dec 2019 at 22:58, Joseph Myers wrote: > > > > On Fri, 20 Dec 2019, Jonathan Wakely wrote: > > > > > I've sent another pull request fixing another 20. Here is the list > > > with those 20 removed (and this still includes the libcpp vs > > >

Re: Commit messages and the move to git

2019-12-20 Thread Jonathan Wakely
On Fri, 20 Dec 2019 at 22:58, Joseph Myers wrote: > > On Fri, 20 Dec 2019, Jonathan Wakely wrote: > > > I've sent another pull request fixing another 20. Here is the list > > with those 20 removed (and this still includes the libcpp vs > > preprocessor ones that will be handled by the new alias).

Re: Does gcc automatically lower optimization level for very large routines?

2019-12-20 Thread Dmitry Mikushin
Yes, much more. When you traverse a CFG, the analysis develops into a tree (for example a tree of uses). That is, every basic block could be *recursively* a root of an individual linear iteration for up to all basic blocks. Sum them up, and you will get a polynomial expression. I don't insist that

Re: Commit messages and the move to git

2019-12-20 Thread Joseph Myers
On Fri, 20 Dec 2019, Jonathan Wakely wrote: > I've sent another pull request fixing another 20. Here is the list > with those 20 removed (and this still includes the libcpp vs > preprocessor ones that will be handled by the new alias). Thanks, merged. -- Joseph S. Myers jos...@codesourcery.com

Re: Does gcc automatically lower optimization level for very large routines?

2019-12-20 Thread Segher Boessenkool
On Fri, Dec 20, 2019 at 02:57:57AM +0100, Dmitry Mikushin wrote: > Trying to plan memory consumption ahead-of-work contradicts with the nature > of the graph traversal. Estimation may work very well for something simple > like linear or log-linear behavior. Almost everything we do is (almost) line

gcc-8-20191220 is now available

2019-12-20 Thread gccadmin
Snapshot gcc-8-20191220 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20191220/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8

Re: Commit messages and the move to git

2019-12-20 Thread Jonathan Wakely
On Fri, 20 Dec 2019 at 21:41, Joseph Myers wrote: > > On Fri, 20 Dec 2019, Jonathan Wakely wrote: > > > On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote: > > > > > > On Thu, 19 Dec 2019, Jonathan Wakely wrote: > > > > > > > I've attached an updated list to this mail, which removes the items > > >

Re: Commit messages and the move to git

2019-12-20 Thread Joseph Myers
On Fri, 20 Dec 2019, Jonathan Wakely wrote: > On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote: > > > > On Thu, 19 Dec 2019, Jonathan Wakely wrote: > > > > > I've attached an updated list to this mail, which removes the items > > > we've analysed. There are 531 remaining. > > > > With the current

Re: Commit messages and the move to git

2019-12-20 Thread Jonathan Wakely
On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote: > > On Thu, 19 Dec 2019, Jonathan Wakely wrote: > > > I've attached an updated list to this mail, which removes the items > > we've analysed. There are 531 remaining. > > With the current version of the script (including the various whitelisted > c

Re: Commit messages and the move to git

2019-12-20 Thread Joseph Myers
On Thu, 19 Dec 2019, Jonathan Wakely wrote: > I've attached an updated list to this mail, which removes the items > we've analysed. There are 531 remaining. With the current version of the script (including the various whitelisted component pairs discussed) and with data freshly downloaded from

Re: C2X Proposal, merge '.' and '->' C operators

2019-12-20 Thread J Decker
On Fri, Dec 20, 2019 at 12:03 PM J Decker wrote: > > > On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote: > >> >> >> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer >> wrote: >> >>> * J. Decker: >>> >>> > Here's the gist of what I would propose... >>> > https://gist.github.com/d3x0r/f496d0032476ed

Re: C2X Proposal, merge '.' and '->' C operators

2019-12-20 Thread J Decker
On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote: > > > On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote: > >> * J. Decker: >> >> > Here's the gist of what I would propose... >> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da >> > >> > In C, there are two operators . and -> u

Re: C2X Proposal, merge '.' and '->' C operators

2019-12-20 Thread J Decker
On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote: > * J. Decker: > > > Here's the gist of what I would propose... > > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da > > > > In C, there are two operators . and -> used to access members of struct > and > > union types. These ope

Re: Proposal for the transition timetable for the move to GIT

2019-12-20 Thread Segher Boessenkool
Hi! On Wed, Dec 18, 2019 at 01:43:19PM -0700, Jeff Law wrote: > On Wed, 2019-12-18 at 13:50 -0600, Segher Boessenkool wrote: > > On Wed, Dec 18, 2019 at 11:07:11AM -0700, Jeff Law wrote: > > > > That isn't what I said. I said that freshly constructed complex > > > > software > > > > will have mo

Re: Does gcc automatically lower optimization level for very large routines?

2019-12-20 Thread Jonathan Wakely
On Fri, 20 Dec 2019 at 16:05, Qing Zhao wrote: > > Thanks a lot for all these help. > > So, currently, if GCC compilation aborts due to this reason, what’s the best > way for the user to resolve it? > I added “#pragma GCC optimize (“O1”) to the large routine in order to > workaround this issue. >

Re: Does gcc automatically lower optimization level for very large routines?

2019-12-20 Thread Qing Zhao
Thanks a lot for all these help. So, currently, if GCC compilation aborts due to this reason, what’s the best way for the user to resolve it? I added “#pragma GCC optimize (“O1”) to the large routine in order to workaround this issue. Is there other better way to do it? Is GCC planning to re

OpenACC regression and development pace

2019-12-20 Thread Thomas Koenig
Hi, I just saw this: FAIL: gfortran.dg/goacc/finalize-1.f -O scan-tree-dump-times gimple "(?n)#pragma omp target oacc_enter_exit_data map\\(delete:MEM\\[\\(c_char \\*\\)[^\\]]+\\] \\[len: [^\\]]+\\]\\) map\\(to:del_f_p \\[pointer set, len: [0-9]+\\]\\) map\\(alloc:del_f_p\\.data \\[pointe

Sign in and discover how to isolate “resting trends”, buy them, and watch them snap back to life

2019-12-20 Thread Garrett Richard
Hi There, Email: g...@gnu.org Our international company consists of around 25 Internet projects related to crypto currencies and ICO. Now we recruit staff from around the world. CHECK IT OUT HERE Primary salary $448k yearly e-workers needed! - No Special Skills Required - No Previous Job Exper

Re: Does gcc automatically lower optimization level for very large routines?

2019-12-20 Thread Richard Biener
On December 20, 2019 1:41:19 AM GMT+01:00, Jeff Law wrote: >On Thu, 2019-12-19 at 17:06 -0600, Qing Zhao wrote: >> Hi, Dmitry, >> >> Thanks for the responds. >> >> Yes, routine size only cannot determine the complexity of the >routine. Different compiler analysis might have different formula wi

Re: Need sanity check on DSE vs expander issue

2019-12-20 Thread Richard Biener
On December 20, 2019 8:25:18 AM GMT+01:00, Jeff Law wrote: >On Fri, 2019-12-20 at 08:09 +0100, Richard Biener wrote: >> On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law >wrote: >> > I need a sanity check here. >> > >> > Given this code: >> > >> > > typedef union { long double value; unsigned

Re: Executable file

2019-12-20 Thread Jonathan Wakely
On Mon, 16 Dec 2019 at 11:49, lindorx wrote:> I want to know how to cpmpile the specified executable format with GCC. I use GCC on the Windows platform.But I want to compile the ELF format file. You need a cross compiler. But this is the wrong mailing list for your question. Please use the gcc-

Re: Need sanity check on DSE vs expander issue

2019-12-20 Thread Jakub Jelinek
On Fri, Dec 20, 2019 at 08:09:26AM +0100, Richard Biener wrote: > >That (of course) only writes 80 bits of data because of XFmode, leaving > >48 bits uninitialized. We then read those bits, or-ing the > >uninitialized data into ored_words and all hell breaks loose later. > > > >Am I losing my mind