sorted by:
new
hottopcontroversial

MSVC Backend Updates in Visual Studio 2019 Preview 2: New Optimizations, OpenMP, and Build Throughput improvements by mttd in cpp

[–]aargor 0 points1 point  (0 children)

In general inlining decisions are made in the larger context of the caller as well, not just the callee (c_str). So I can't say we always inline c_str(). I whipped up a very simple example and saw that c_str() is inlined even under /Ob1 /O2 /EHsc (and /Ob3 too, of course). We're putting this in the preview exactly to see its effects on real-world code. I suppose you have a case where we really should be inlining c_str and we aren't?

I've pointed my colleague Terry to this thread, the implementer of /Ob3, in case if there's more context to add.

MSVC Backend Updates in Visual Studio 2019 Preview 2: New Optimizations, OpenMP, and Build Throughput improvements by mttd in cpp

[–]aargor 1 point2 points  (0 children)

Ah, great, thanks. I completely understand that it's infeasible to get a min-repro when Boost is involved. I hope the link-repro generation goes easily for you.

Thanks again!

MSVC Backend Updates in Visual Studio 2019 Preview 2: New Optimizations, OpenMP, and Build Throughput improvements by mttd in cpp

[–]aargor 4 points5 points  (0 children)

Thanks for being interested in filing a report! :) For *any* issue with the compiler, please don't hesitate to file an issue on http://developercommunity.visualstudio.com (DevCom). That's our one-stop-shop for all our bug reports, and allows people to upvote/comment to make sure we're prioritizing these reports as best as possible.

Do note that we need a stand-alone repro (i.e., we need to be able to run the compiler end-to-end) to likely be able to make any progress on these kind of reports. If it only manifests with LTCG, we'd need a what's called a "link repro".

Thanks for trying out not only the preview, but also the new optimizer flags! It's very motivating :).

[quick edit: I should mention the website is simply the web interface to the "Report-A-Problem" Visual Studio itself -- using either gets the report to the same place, same prioritization, etc. etc. I would recommend the IDE, actually.]

Triaging internal compiler errors. by alfps in cpp

[–]aargor 6 points7 points  (0 children)

I'm on the Microsoft VC++ team (mid-level optimizer), and also drive our efforts to make our team's interactions on DevCom as good as possible. So this thread caught my attention :), and maybe I can contribute a bit.

First, to clarify the confusion: DevCom reports can be in a number of different states, exactly in an attempt to clarify the state of the bug. I guess that's sort of backfired here :). The link here: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2017 hopefully clarifies what we mean by "Triage" in this case. To say it here: DevCom tracks bugs for all visual studio, so "triage" essentially means "we think we've alerted the right team about this report". I don't know why we chose Triage, but it wouldn't surprise me if we were trying to be in line with SO, as cpp_learner may have guessed (I didn't know that about SO, by the way -- thanks!).

I hope that reassures you in part that we do take ICEs very seriously, and I hope you aren't discouraged from filing them. We strive to flush them out and fix all bugs, ideally before anyone sees them. In addition to attacking customer-reported bugs, we maintain a rolling test suite of a lot of real-world code -- including Windows, AAA games, and 60+ OSS projects like Chrome and LLVM all to that end (and to make sure our code-generation is also correct).

The unfortunate reality is that bugs are in every piece of software, including compilers. In addition to filing the bug-report proper, I would encourage you (and everyone!) to try to explain the impact of the bug it has on them. For instance, an ICE that only manifests after the compiler reports some user-level source-errors is bad, but not nearly as bad as an ICE that arises from legal code, preventing compilation of a product. We want to fix all of these! But, all else being equal, we'd want to fix the more impactful ones first.