GCC 9 web timeline dates incorrect?
Hi, On this link https://gcc.gnu.org/develop.html#timeline, I see the following: GCC 9 Stage 1 (starts 2018-04-25) GCC 8.1 release (2018-05-02) | \ |v | GCC 8.2 release (2018-07-26) GCC 9 Stage 3 (starts 2017-11-12) | GCC 9 Stage 4 (starts 2018-01-07) | v Are the dates for GCC 9 Stage 3 and Stage 4 correct? Thank you. -- Best regards, Tadeus
Re: GCC 9 web timeline dates incorrect?
On Wed, Jan 16, 2019 at 12:52 PM Richard Biener wrote: > > On Wed, Jan 16, 2019 at 10:40 AM Tadeus Prastowo > wrote: > > > > Hi, > > > > On this link https://gcc.gnu.org/develop.html#timeline, I see the following: > > > > GCC 9 Stage 1 (starts 2018-04-25) GCC 8.1 release (2018-05-02) > > | \ > > |v > > | GCC 8.2 release (2018-07-26) > > GCC 9 Stage 3 (starts 2017-11-12) > > | > > GCC 9 Stage 4 (starts 2018-01-07) > > | > > v > > > > Are the dates for GCC 9 Stage 3 and Stage 4 correct? > > Fixed. Ack for Stage 4's date. But, are you sure that Stage 3 should still be shown as below? GCC 9 Stage 3 (starts 2017-11-12) Thank you. -- Best regards, Tadeus
Re: GCC 9 web timeline dates incorrect?
On Wed, Jan 16, 2019 at 1:07 PM Richard Biener wrote: > > On Wed, Jan 16, 2019 at 12:55 PM Tadeus Prastowo > wrote: [...] > > Ack for Stage 4's date. But, are you sure that Stage 3 should still > > be shown as below? > > > > GCC 9 Stage 3 (starts 2017-11-12) > > Shows 2018 for me. Now I see "GCC 9 Stage 3 (starts 2018-11-12)". Thanks. -- Best regards, Tadeus
Re: RFC: Deprecate libstdc++ Policy-Based Data Structures
Hi, Knowing that Alex has stepped forward, I am interested in helping out in this matter as well if you think that will help. My experience in maintaining a C++ library can be seen at https://savannah.nongnu.org/projects/tice -- Best regards, Tadeus On Tue, Jul 23, 2019 at 6:50 PM Alexander Kulkov wrote: > > Sounds fair to me. Well, I personally might be interested in providing > fixes and improvements for the code. I might even try to find some other > people in community to contribute. > > PBDS is very well-thought library which I admired since the moment I saw > it, and the possibility that it may completely go to waste kind of > disappoints me, so I might put considerable effort to save it if that's > possible. The major issue, though, is that I don't really know even how to > start since I'm completely new to libstdc++ and have little experience with > such huge projects. Any help and/or advice here in how I may contribute > would be much appreciated. > > вт, 23 июл. 2019 г. в 19:21, Jonathan Wakely : > > > Sorry for the late reply that wasn't "tomorrow". > > > > On Tue, 9 Jul 2019 at 23:40, Alexander Kulkov wrote: > > > > > > Hi there! I hope, this message will go to where it's expected to go, > > since > > > I'm not really familiar with e-mail threads. > > > > > > I was the one who brought > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806 > > > issue about sub-optimal implementation of split function in pbds. The > > > reason why I did so is clearly described on this comment: > > > https://codeforces.com/blog/entry/10355?#comment-157883 > > > > > > So, a bit of story and context. Five years ago at codeforces.com > > > (competitive programming website) someone eventually pointed out that > > there > > > is order-statistics tree in SGI library. It turned out to be very useful > > in > > > competitions since it is quite common type of queries to count number of > > > elements less than k in set and unfortunately regular std::set doesn't > > > provide such possibility although it would be extremely useful in > > > competitions. > > > > > > I made two posts about pbds on codeforces to introduce them to community: > > > https://codeforces.com/blog/entry/11080 and > > > https://codeforces.com/blog/entry/13279. First one introduces > > structures in > > > general and second one describes how to modify them so they support > > custom > > > queries. Second one was not quite as popular, perhaps because it's not > > much > > > easier to comprehend and remember concept than simply write something > > like > > > cartesian tree on live contest. But the first one is pretty much alive, > > > most recent comment was only 8 days ago. > > > > > > There was also another post (https://codeforces.com/blog/entry/60737) > > > considering hash_map from pb_ds as a replacement for unordered_map since > > > hash_map clearly outperform unordered_map. This one is also quite popular > > > and well-known in competitive programming community. > > > > > > So speaking about "Do you actually use these containers?" I would say > > that > > > I often use tree_order_statistics_node_update in competitions, and in > > > general specifically tree_order_statistics_node_update and hash_map are > > > pretty popular in competitive programming community. > > > > > > Deprecating policy based data structures will deal much pain to some > > > competitors because problems in which it's possible to use pbds instead > > of > > > custom balanced binary trees occur quite often and so now we'll have to > > > implement bbst instead of using something out of the box. > > > > > > Not sure if you would consider this usage case as something "serious", > > but > > > well, I was asked, so I answered. > > > > Thanks for responding! > > > > I don't really care about this use case, sorry. If the programming > > competition community were providing fixes or improvements for this > > code I might be more inclined to keep supported it, but it seems like > > we're just carrying around a huge chunk of code because it saves > > people some time in some competitions. Presumably the competition code > > is not reused, so there's no backwards compatibility issue here > > either. > >
Re: C2X Proposal, merge '.' and '->' C operators
On Fri, Dec 27, 2019 at 7:23 AM J Decker wrote: > would you suggest I go? It doesn't look like C standards, unlike > es-discuss for ecma script, I couldn't find a open forum to discuss such > things... or even a github group like... https://github.com/tc39/proposals You can table the proposal at the C++ standard discussion mailing list: https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion > J -- Best regards, Tadeus
Re: How to pack small type to big type without memory load/store ?
On Tue, Aug 4, 2020 at 5:10 AM Jojo R wrote:
>
> Hi,
>
> Form My ABI, float register is used by function call,
> I want to pack float a and b into double v without any memory load/store,
>
> The flowing is my demo:
>
> Typedef union {
> float ff[2];
> double v;
> } double_u;
>
> Double pack_float (float a, float b) {
>
> double_u tmp;
>
> tmp.ff[0] = a;
> tmp.ff[1] = b;
>
> return tmp.v;
> }
>
> There is memory store in these statement:
>
> tmp.ff[0] = a;
> tmp.ff[1] = b;
>
> Could someone give me some hints to avoid memory load/store ?
Use inline assembly
(https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html)
because AFAIK, C/C++ cannot force its compiler to place a variable in
a register.
> Jojo
--
Best regards,
Tadeus
Re: Build reproducibility of gcc @ NixOS
Hi Arthur, On Fri, Apr 2, 2021 at 5:56 AM Arthur Gautier wrote: > > Dear GCC development team, > > We've been trying to build reproducibly the minimal NixOS image, and > gcc was one of the last issues we had. > We found that disabling profiled bootstrap compilation of GCC allowed > us to get a reproducible build of gcc. > Our efforts can be followed here: https://github.com/NixOS/nixpkgs/pull/112928 > > But I measured disabling this optimization to cost around 7-12% > depending on the build. That is expected as mentioned in the manual: https://gcc.gnu.org/install/build.html#Building-with-profile-feedback And, I have reproduced it as well as reported here: https://gcc.gnu.org/ml/gcc-help/2019-05/msg00118.html, the last questions that remain being here: https://gcc.gnu.org/legacy-ml/gcc-help/2019-07/msg00053.html > Because of this performance regression, we're trying to find a middle > ground. Ideally we'd like to keep the performance of gcc as untouched > as possible (even if that costs us on compilation time of gcc itself). > > Compiling gcc twice on the same machine gets us the same output, but > compiling on a different architecture gets us a different result. > Reading the documentation, it would seem that autoprofiledback > bootstrap would use machine metrics and injects them in the build (and > we don't use autoprofiledback), But I would not expect the stagetrain > of profiledbootstrap to do that. > I tried disabling concurrency of the stagetrain without luck. > > It feels like I'm missing something. > Would anyone have any idea what could inject the host's behavior here? Since an optimized build is likely to be machine-dependent regardless of any intended injection (e.g., different instructions used in GCC binaries depending on /proc/cpuinfo), I don't understand why an optimized build should be reproducible on different machines, unless of course every channel that GCC uses to find out about the machine (e.g., /proc/cpuinfo) is under your total control. So, do you mean to ask a list of all channels that GCC uses to find out about the machine? > Thank you for your help! No worries. > Best, > -- > Arthur -- Best regards, Tadeus
Re: Build reproducibility of gcc @ NixOS
Hi Arthur, On Fri, Apr 2, 2021 at 5:04 PM Arthur Gautier wrote: > > Hi Tadeus, > > On Fri, Apr 2, 2021 at 9:07 AM Tadeus Prastowo > wrote: [...] > > Since an optimized build is likely to be machine-dependent regardless > > of any intended injection (e.g., different instructions used in GCC > > binaries depending on /proc/cpuinfo), I don't understand why an > > optimized build should be reproducible on different machines, unless > > of course every channel that GCC uses to find out about the machine > > (e.g., /proc/cpuinfo) is under your total control. So, do you mean to > > ask a list of all channels that GCC uses to find out about the > > machine? > > This is where I'm getting confused. According to the manual, > stagetrain only record branch statistics. By "the manual", do you refer to https://gcc.gnu.org/install/build.html#Building-with-profile-feedback ? Quoting the page: When ‘make profiledbootstrap’ is run, it will first build a stage1 compiler. This compiler is used to build a stageprofile compiler instrumented to collect execution counts of instruction and branch probabilities. Training run is done by building stagetrain compiler. Finally a stagefeedback compiler is built using the information collected. End quote. Based on the quote, a reproducible build is to expected for the following compilers: 1. The stage1 compiler. 2. The stageprofile compiler, which is built by the stage1 compiler. 3. The stagetrain compiler, which is built by the stageprofile compiler. Then, a reproducible build is expected for the stagefeedback compiler on the condition that the same information, which was collected by the stageprofile compiler when building the stagegrain compiler, is used. Do you agree with that reasoning? > And I would expect, given > the same input provided in the same order, two different architectures > to take the same branch, and not observe any difference. In other words, you expect that branch statistics depends only on the given source code. Correct? > I understand > that with autoprofiled builds, the local architecture behavior is > injected in the build, but I don't use that. > I'm not using any -march in the build either (as far as I can > understand/tell). So I do not expect the build to change its > instruction set either. > > Is that normal that two different architectures would issue two > different "execution counts of instruction and branch probabilities"? I guess that it would be the case. > Or is there something more? Perhaps you can have the reproducible build that you want by first isolating the information that is collected by the stageprofile compiler when building the stagegrain compiler and then reusing the same information when building every other stagefeedback compiler. > Thank you for your reply! My pleasure. > -- > Arthur -- Best regards, Tadeus
Re: Build reproducibility of gcc @ NixOS
Hi Arthur, On Fri, Apr 2, 2021 at 6:45 PM Arthur Gautier wrote: > > On Fri, Apr 2, 2021 at 4:32 PM Tadeus Prastowo > wrote: > > > > Hi Arthur, > > > > On Fri, Apr 2, 2021 at 5:04 PM Arthur Gautier > > wrote: > > > > > > Hi Tadeus, > > > > > > On Fri, Apr 2, 2021 at 9:07 AM Tadeus Prastowo > > > wrote: > [...] > > > > By "the manual", do you refer to > > https://gcc.gnu.org/install/build.html#Building-with-profile-feedback > > ? > yes > > > > Quoting the page: > > When ‘make profiledbootstrap’ is run, it will first build a stage1 > > compiler. > > This compiler is used to build a stageprofile compiler instrumented > > to collect execution counts of instruction and branch probabilities. > > Training run is done by building stagetrain compiler. > > Finally a stagefeedback compiler is built using the information collected. > > End quote. > > > > Based on the quote, a reproducible build is to expected for the > > following compilers: > > 1. The stage1 compiler. > > 2. The stageprofile compiler, which is built by the stage1 compiler. > > 3. The stagetrain compiler, which is built by the stageprofile compiler. > > > > Then, a reproducible build is expected for the stagefeedback compiler > > on the condition that the same information, which was collected by the > > stageprofile compiler when building the stagegrain compiler, is used. > > > > Do you agree with that reasoning? > Yes, and as far as I can tell, up to the stageprofile I get the same result. > Only the output of the stagetrain compilation changes, which affects > the stagefeedback compilation. By saying "up to the stageprofile I get the same result", do you mean that you obtain the same stageprofile compilers on two different architectures? Or, do you mean that you obtain the same stageprofile compilers on the same machine by building GCC one after another in different build directories? And by saying "the output of the stagetrain compilation changes", do you mean that the stageprofile compiler __running on the same machine__ produces different stagetrain compilers? Or, do you mean that the stageprofile compiler running on the same machine obtains different statistics that will later be used to build the stagefeedback compiler? Or, something else? > > > And I would expect, given > > > the same input provided in the same order, two different architectures > > > to take the same branch, and not observe any difference. > > > > In other words, you expect that branch statistics depends only on the > > given source code. Correct? > That would be my understanding (although very limited). Could you tell me what you actually mean by the word "architectures", please? It is because in my understanding different architectures mean different instruction sets. > What I'm trying to understand is: what "local behavior" is injected in > my build, and see if I could get rid of that, and only keep branch > statistics/execution counts, which I expect to be reproducible. That currently I don't know because I haven't fully understood your actual situation. > > > I understand > > > that with autoprofiled builds, the local architecture behavior is > > > injected in the build, but I don't use that. > > > I'm not using any -march in the build either (as far as I can > > > understand/tell). So I do not expect the build to change its > > > instruction set either. > > > > > > Is that normal that two different architectures would issue two > > > different "execution counts of instruction and branch probabilities"? > > > > I guess that it would be the case. > > > > > Or is there something more? > > > > Perhaps you can have the reproducible build that you want by first > > isolating the information that is collected by the stageprofile > > compiler when building the stagegrain compiler and then reusing the > > same information when building every other stagefeedback compiler. > > Yeah, but said information is not reproducible itself (that would > defeat the purpose of the effort). I expect that running the same stageprofile compiler on the same machine twice, once to build stagetrain compiler A and and then once again to build stagetrain compiler B, should obtain A = B. While you imply that it was not the case, I am not sure because you don't say whether in your case you did the same (i.e., running the same stageprofile compiler on the same machine twice to obtain A and B). -- Best regards, Tadeus
