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

This is a view of the patch/diff... This is really just +6 lines... ` if( !flag_iso2xc) `{` `}` `attribute fallthrough` `if(flag_iso2cx)` `return ptr` https://github.com/gcc-mirror/gcc/pull/41/commits/915bcffdea0aa4fead66c41830b66aa3db212307 While the compiler does compile itself, and a simple

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

Joseph Myers : > I expect the next conversion run, started after that > one finishes, to include both parts of Richard's commit message > improvements, as well as an improvement to commit attribution extraction > from ChangeLog files (to include attributions from ChangeLog.

Re: Question about struct identifiers after modifications.

On Mon, Dec 16, 2019 at 3:24 PM Erick Ochoa wrote: > > Hello, > > I am working on a struct reorganization optimization pass. > I am able to identify which structs I want to reorganize > and I am also able to create new structs with these modifications. > The way the new structs are generated is th

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

Jeff Law : > So unless there's something Maxim's scripts are getting right that > aren't by reposurgeon, then reposurgeon is the right choice. It is still possible that the scripts could get things right that reposurgeon doesn't. But the reverse question is also valid. Can Maxim's scripts get eve

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

On Mon, 16 Dec 2019, Segher Boessenkool wrote: > We talked about it for days, and as far as I understand it Richard agreed. > > But, there is no way I can verify this yet, or is there? Is there a repo > we can look at? Something close to final. The conversion run I started this afternoon is no

Question about struct identifiers after modifications.

Hello, I am working on a struct reorganization optimization pass. I am able to identify which structs I want to reorganize and I am also able to create new structs with these modifications. The way the new structs are generated is the following code (I am keeping it high-level for conciseness but

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

Segher Boessenkool : > There is absolutely no reason to trust a system that supposedly was > already very mature, but that required lots of complex modifications, > and even a complete rewrite in a different language, that even has its > own bug tracker, to work without problems (although we all ha

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

On Mon, 16 Dec 2019, Segher Boessenkool wrote: > Hi, > > On Mon, Dec 16, 2019 at 05:07:48PM +, Joseph Myers wrote: > > Yes. It should be possible to confirm branch tip conversions and other > > properties of the repository (e.g. that all branch tips are properly > > descended from the firs

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

Hi! On Mon, Dec 16, 2019 at 03:13:49PM -0700, Jeff Law wrote: > On Mon, 2019-12-16 at 15:59 -0600, Segher Boessenkool wrote: > > In particular, we should look carefully at the commit > > > attributions in both conversions and Maxim's may well give ideas for > > > improving the reposurgeon change

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

On Mon, 2019-12-16 at 15:59 -0600, Segher Boessenkool wrote: > In particular, we should look carefully at the commit > > attributions in both conversions and Maxim's may well give ideas for > > improving the reposurgeon changelogs command (Richard came up with three > > ideas recently, which I'v

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

Hi, On Mon, Dec 16, 2019 at 05:07:48PM +, Joseph Myers wrote: > Yes. It should be possible to confirm branch tip conversions and other > properties of the repository (e.g. that all branch tips are properly > descended from the first commit on trunk except for the specific branches > that s

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

Joseph Myers : > * As we're part of the free software community as a whole rather than > something in isolation, choosing to make a general-purpose tool work for > our conversion is somewhat preferable to choosing an ad hoc approach > because it contributes something of value for other repositor

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

On December 16, 2019 5:39:06 PM GMT+01:00, Jeff Law wrote: >On Mon, 2019-12-16 at 13:53 +, Joseph Myers wrote: >> >> > > However, we should also note that stage 3 is intended to last two >months, >> > > ending with the move to git >> > > >

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

On Mon, 2019-12-16 at 09:36 -0600, Segher Boessenkool wrote: > On Mon, Dec 16, 2019 at 02:13:06PM +, Joseph Myers wrote: > > On Mon, 16 Dec 2019, Segher Boessenkool wrote: > > > > > Most of us are perfectly happy even with the current git mirror, for > > > old commits. We want "real" git to m

Git transition

Unfortunately a family emergency has cropped up and I can’t respond directly to the thread. I’m also unlikely to be able to follow up on this discussion in the next couple of days. I proposed the timetable back after the Cauldron to make it clear that we were serious about moving this release

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

On Mon, 16 Dec 2019, Jeff Law wrote: > On Mon, 2019-12-16 at 11:29 +, Joseph Myers wrote: > > On Mon, 16 Dec 2019, Mark Wielaard wrote: > > > > > Should we go with the gcc-reparent.git repo now? > > > > I think we should go with the reposurgeon conversion, with all Richard's > > improvement

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

On Mon, 2019-12-16 at 11:29 +, Joseph Myers wrote: > On Mon, 16 Dec 2019, Mark Wielaard wrote: > > > Should we go with the gcc-reparent.git repo now? > > I think we should go with the reposurgeon conversion, with all Richard's > improvements to commit messages. gcc-reparent.git has issues o

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

On Mon, Dec 16, 2019 at 11:27:56AM -0500, Eric S. Raymond wrote: > Joseph Myers : > > When we're talking about something to be used > > for the next 20 years we should make sure to get it right. > > Segher and others should note that I'm not in the habit of sinking mos

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

On Mon, 2019-12-16 at 11:37 -0500, Eric S. Raymond wrote: > Jeff Law : > > > It may not be my place to say, but...I think the stakes are pretty > > > high here. If I were a GCC developer, I think I'd want the best > > > possible conversion even if that takes a little longer. > > Well, I'm not sure

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

On Mon, 2019-12-16 at 13:53 +, Joseph Myers wrote: > > > > However, we should also note that stage 3 is intended to last two months, > > > ending with the move to git > > > > > > ;, and give

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

Jeff Law : > > It may not be my place to say, but...I think the stakes are pretty > > high here. If I were a GCC developer, I think I'd want the best > > possible conversion even if that takes a little longer. > Well, I'm not sure that's entirely true. OK, that's a policy choice the GCC project i

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

On Mon, 16 Dec 2019, Segher Boessenkool wrote: > And the current mirror is "right", already, as Jeff said at the Cauldron > (a minute before we unanymously decided to do the conversion soon; this > is over three months ago already). All the discussion at the Cauldron tells us is many people like

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

On Mon, 16 Dec 2019, Mark Wielaard wrote: > On Mon, 2019-12-16 at 13:56 +, Joseph Myers wrote: > > classpath-generics gcj/classpath-095-import-branch > > libstdcxx_so_7-2-branch st/binutils st/mono-based-binutils. > > The classpath "branches" should not be in the final git repo. Those > "bran

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

Joseph Myers : > When we're talking about something to be used > for the next 20 years we should make sure to get it right. Segher and others should note that I'm not in the habit of sinking most of a year of my time into problems that I don't think are extremely impor

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

On Mon, 2019-12-16 at 08:54 -0500, Eric S. Raymond wrote: > Segher Boessenkool : > > > Do people really want to keep tweaking the conversions and postpone the > > > git switchover? > > > > No. > > It may not be my place to say, but...I think the stakes are pretty > high here. If I were a GCC dev

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

On Mon, Dec 16, 2019 at 02:13:06PM +, Joseph Myers wrote: > On Mon, 16 Dec 2019, Segher Boessenkool wrote: > > > Most of us are perfectly happy even with the current git mirror, for > > old commits. We want "real" git to make the workflow for new commits > > better. > > > > No more delays, _

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

On Mon, 2019-12-16 at 13:56 +, Joseph Myers wrote: > classpath-generics gcj/classpath-095-import-branch > libstdcxx_so_7-2-branch st/binutils st/mono-based-binutils. The classpath "branches" should not be in the final git repo. Those "branches" are really separate from the actual gcc code tree

Re: Code bloat due to silly IRA cost model?

Georg-Johann Lay writes: > Am 11.12.19 um 18:55 schrieb Richard Sandiford: >> Georg-Johann Lay writes: >>> Hi, doesn't actually anybody know know to make memory more expensive >>> than registers when it comes to allocating registers? >>> >>> Whatever I am trying for TARGET_MEMORY_MOVE_COST and >>

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

On Mon, 16 Dec 2019, Segher Boessenkool wrote: > Most of us are perfectly happy even with the current git mirror, for > old commits. We want "real" git to make the workflow for new commits > better. > > No more delays, _please_. The timetable is a useful guideline. It should not be our master

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

On Mon, Dec 16, 2019 at 08:54:51AM -0500, Eric S. Raymond wrote: > Segher Boessenkool : > > > Do people really want to keep tweaking the conversions and postpone the > > > git switchover? > > > > No. > > It may not be my place to say, but...I think the stakes are pretty > high here. If I were a

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

On Mon, 16 Dec 2019, Segher Boessenkool wrote: > On Mon, Dec 16, 2019 at 01:43:48PM +0100, Mark Wielaard wrote: > > On Mon, 2019-12-16 at 11:29 +, Joseph Myers wrote: > > > On Mon, 16 Dec 2019, Mark Wielaard wrote: > > > > > > > Should we go with the gcc-reparent.git repo now? > > > > > > I

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

Segher Boessenkool : > > Do people really want to keep tweaking the conversions and postpone the > > git switchover? > > No. It may not be my place to say, but...I think the stakes are pretty high here. If I were a GCC developer, I think I'd want the best possible conversion even if that takes a

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

On Mon, 16 Dec 2019, Mark Wielaard wrote: > > I think we should go with the reposurgeon conversion, with all Richard's > > improvements to commit messages. gcc-reparent.git has issues of its own; > > at least, checking the list of branches shows some branches are missing. > > So both conversi

Re: Code bloat due to silly IRA cost model?

Am 11.12.19 um 18:55 schrieb Richard Sandiford: Georg-Johann Lay writes: Hi, doesn't actually anybody know know to make memory more expensive than registers when it comes to allocating registers? Whatever I am trying for TARGET_MEMORY_MOVE_COST and TARGET_REGISTER_MOVE_COST, ira-costs.c always

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

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 operators are specified such that they are always paired in usage; for example, if the left hand

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

On Mon, Dec 16, 2019 at 01:43:48PM +0100, Mark Wielaard wrote: > On Mon, 2019-12-16 at 11:29 +, Joseph Myers wrote: > > On Mon, 16 Dec 2019, Mark Wielaard wrote: > > > > > Should we go with the gcc-reparent.git repo now? > > > > I think we should go with the reposurgeon conversion, with all R

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

Hi! On Mon, Dec 16, 2019 at 10:53:05AM +0100, Mark Wielaard wrote: > On Fri, 2019-12-06 at 17:44 +0300, Maxim Kuvyrkov wrote: > > > On Sep 19, 2019, at 6:34 PM, Maxim Kuvyrkov > > > wrote: > > > > On Sep 17, 2019, at 3:02 PM, Richard Earnshaw (lists) > > > > wrote: > > > > > > > > Monday 16th

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

On Mon, 2019-12-16 at 11:29 +, Joseph Myers wrote: > On Mon, 16 Dec 2019, Mark Wielaard wrote: > > > Should we go with the gcc-reparent.git repo now? > > I think we should go with the reposurgeon conversion, with all Richard's > improvements to commit messages. gcc-reparent.git has issues o

Could I obtain the forms needed to make a contribution?

I want to add a compiler warning, if it will get accepted. It's a -Wlines warning. My employer bans the __LINE__ macro as well as the ones warned by the -Wdate-time warning, because there is a consensus that the addition of whitespace or comments should not yield different binary output for our pro

Executable file

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. In addition,why did the following information appear when compiling the ".c" file on Linux.But I can compile normally with MinGW-gcc. error: i

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

On Mon, 16 Dec 2019, Mark Wielaard wrote: > Should we go with the gcc-reparent.git repo now? I think we should go with the reposurgeon conversion, with all Richard's improvements to commit messages. gcc-reparent.git has issues of its own; at least, checking the list of branches shows some bran

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

Hi Maxim, On Fri, 2019-12-06 at 17:44 +0300, Maxim Kuvyrkov wrote: > > On Sep 19, 2019, at 6:34 PM, Maxim Kuvyrkov > > wrote: > > > On Sep 17, 2019, at 3:02 PM, Richard Earnshaw (lists) > > > wrote: > > > > > > Monday 16th December 2019 - cut off date for picking which git conversion > > > t