Stream: t-compiler

Topic: weekly meeting 2019-11-07 #54818


pnkfelix (Nov 07 2019 at 13:56, on Zulip):

Hi @T-compiler/meeting ; the triage meeting will be starting in 1 hour 4 minutes

pnkfelix (Nov 07 2019 at 13:57, on Zulip):

I will be doing pre-triage in a parallel topic

pnkfelix (Nov 07 2019 at 13:58, on Zulip):

This week we have scheduled checkins from WG-polonius and ... WG-rfc-2229

pnkfelix (Nov 07 2019 at 13:58, on Zulip):

(but the latter is paused for now, so it will just be WG-polonius)

pnkfelix (Nov 07 2019 at 15:01, on Zulip):

Hi @T-compiler/meeting! Add a :wave: emoji to show you're here :)

pnkfelix (Nov 07 2019 at 15:02, on Zulip):

so lets have five minutes for announcements

pnkfelix (Nov 07 2019 at 15:02, on Zulip):

Here's one: I'm moving to the USA 🇫🇷→🇺🇸

pnkfelix (Nov 07 2019 at 15:03, on Zulip):

Hopefully it won't disrupt my ability to run the meetings etc too much.

mw (Nov 07 2019 at 15:04, on Zulip):

Here's one: I'm moving to the USA

When are you moving and into what time zone?

nikomatsakis (Nov 07 2019 at 15:05, on Zulip):

/me kind of excited about this

pnkfelix (Nov 07 2019 at 15:05, on Zulip):

mid-december. Niko's timezone.

pnkfelix (Nov 07 2019 at 15:05, on Zulip):

gonna have to remove "ex-pat" from my twitter profile and what not.

nikomatsakis (Nov 07 2019 at 15:05, on Zulip):

oof, that one hurts

mw (Nov 07 2019 at 15:06, on Zulip):

good luck!

Wesley Wiser (Nov 07 2019 at 15:06, on Zulip):

I've been working on the constant propagation pass the last few months and it's finally in a place where it can be enabled by default. A recent perf run shows good across the board results so please weigh-in on the poll to decide if we should enable it by default. https://github.com/rust-lang/rust/pull/66074#issuecomment-550274874

nikomatsakis (Nov 07 2019 at 15:06, on Zulip):

That's awesome!

nikomatsakis (Nov 07 2019 at 15:06, on Zulip):

@Wesley Wiser once it lands, would make a good blog post hint hint

eddyb (Nov 07 2019 at 15:06, on Zulip):

those numbers are insane btw

eddyb (Nov 07 2019 at 15:07, on Zulip):

especially on crates that aren't outright stress tests filled with constants

mw (Nov 07 2019 at 15:07, on Zulip):

yes, really impressive!

Wesley Wiser (Nov 07 2019 at 15:07, on Zulip):

There's a bit more work that can be done but it would be nice to start reaping the benefits

pnkfelix (Nov 07 2019 at 15:08, on Zulip):

@Wesley Wiser regarding the poll: is the alternative to just turn it on in release mode alone?

centril (Nov 07 2019 at 15:08, on Zulip):

Oh wow, would you look at those perf numbers :tada:

Wesley Wiser (Nov 07 2019 at 15:08, on Zulip):

I don't think there's a current alternative proposed. The status quo is that it only runs when -Z mir-opt-level=2 which is basically never.

centril (Nov 07 2019 at 15:08, on Zulip):

Announcement: 1.39.0 release, including async/await is out
- https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html
- https://blog.rust-lang.org/2019/11/07/Async-await-stable.html

pnkfelix (Nov 07 2019 at 15:09, on Zulip):

(Does debug mode see the same benefit in compilation time? If so, why -- I would have assumed the relevant LLVM optimizations are not run)

eddyb (Nov 07 2019 at 15:09, on Zulip):

@centril oh yeah it's thursday already

Wesley Wiser (Nov 07 2019 at 15:09, on Zulip):

But running in release only is certainly a possible alternative if there are concerns about also running in debug.

eddyb (Nov 07 2019 at 15:09, on Zulip):

@pnkfelix in debug mode a lot of time is spent just generating code and stuff

eddyb (Nov 07 2019 at 15:09, on Zulip):

I remember pcwalton stressing about us ending up on the "happy path" of instruction selection

Wesley Wiser (Nov 07 2019 at 15:09, on Zulip):

@pnkfelix Yes, for example:

keccak-debug avg: -12.6%

pnkfelix (Nov 07 2019 at 15:10, on Zulip):

ah okay, and this avoids that codegen entirely. Makes sense.

pnkfelix (Nov 07 2019 at 15:10, on Zulip):

I had been assuming the performance gains were from avoiding LLVM trying to recreate the same work on its own

pnkfelix (Nov 07 2019 at 15:10, on Zulip):

but this makes total sense. Great.

mw (Nov 07 2019 at 15:10, on Zulip):

Now I just need a reason to use async/await somewhere :P

pnkfelix (Nov 07 2019 at 15:10, on Zulip):

@mw there's also "References to by-move bindings in match guards"

pnkfelix (Nov 07 2019 at 15:11, on Zulip):

which is the kind of thing that floats my balloon

Pietro Albini (Nov 07 2019 at 15:11, on Zulip):

well, landing a feature along with async/await is a good way to have everyone ignore it

pnkfelix (Nov 07 2019 at 15:12, on Zulip):

this is the sort of feature that I think people only "discover" because they suddenly realize they aren't seeing certain compiler errors any more

centril (Nov 07 2019 at 15:12, on Zulip):

@pnkfelix if they even realize it at all ^^ (I know I might not have)

pnkfelix (Nov 07 2019 at 15:12, on Zulip):

which is one of my favorite kinds of features: nothing to learn, just works as you expect

pnkfelix (Nov 07 2019 at 15:12, on Zulip):

Anyway, okay this is all great stuff

pnkfelix (Nov 07 2019 at 15:13, on Zulip):

My bad news: Not only did I fail to follow through with a P-high traversal last week, but I also didn't get to it this week either

pnkfelix (Nov 07 2019 at 15:13, on Zulip):

the good news is: the number of P-high bugs has nonehteless gone down. :)

centril (Nov 07 2019 at 15:13, on Zulip):

There's also #[cfg(windows)] slice: &[u16] :tada:

pnkfelix (Nov 07 2019 at 15:13, on Zulip):

(29 open P-high issues now, 15 of them unassigned.)

eddyb (Nov 07 2019 at 15:13, on Zulip):

@centril fn param or field?

centril (Nov 07 2019 at 15:14, on Zulip):

@eddyb param

pnkfelix (Nov 07 2019 at 15:14, on Zulip):

so lets see. We have a beta-nomination:

pnkfelix (Nov 07 2019 at 15:15, on Zulip):

beta backport nom: "Do not ICE with a precision flag in formatting str and no format arguments" #66093

pnkfelix (Nov 07 2019 at 15:16, on Zulip):

seems fine for beta backport

pnkfelix (Nov 07 2019 at 15:16, on Zulip):

so beta-accepted

pnkfelix (Nov 07 2019 at 15:16, on Zulip):

the same PR is also up for:

pnkfelix (Nov 07 2019 at 15:16, on Zulip):

stable backport nom: "Do not ICE with a precision flag in formatting str and no format arguments" #66093

pnkfelix (Nov 07 2019 at 15:17, on Zulip):

(my personal inclination is that this doesn't really meet the bar for a stable backport. but I guess my attitude is mostly a shrug.)

pnkfelix (Nov 07 2019 at 15:18, on Zulip):

unless this is a stable-to-stable regression ... ?

centril (Nov 07 2019 at 15:18, on Zulip):

(Release team will separately decide if the sum total of the stable backports merit a point release)

pnkfelix (Nov 07 2019 at 15:18, on Zulip):

I guess it is a stable-to-stable regression. But even then

nikomatsakis (Nov 07 2019 at 15:18, on Zulip):

(my personal inclination is that this doesn't really meet the bar for a stable backport. but I guess my attitude is mostly a shrug.)

I think we're just judging the technical merits

nikomatsakis (Nov 07 2019 at 15:18, on Zulip):

this seems "safe" to backport

pnkfelix (Nov 07 2019 at 15:18, on Zulip):

yes that is fair

Esteban Küber (Nov 07 2019 at 15:19, on Zulip):

The reason I put stable to stable ices like this one up for stable backport is because they can bring the rls down.

pnkfelix (Nov 07 2019 at 15:19, on Zulip):

every time I hear that, the back of my mind thinks "that sounds like an architectural problem with the rls"

Esteban Küber (Nov 07 2019 at 15:19, on Zulip):

With full understanding that they are unlikely to actually end up in the current stable release

pnkfelix (Nov 07 2019 at 15:19, on Zulip):

but maybe by "down" you just mean "fails to produce useful results until the problem is addressed.

centril (Nov 07 2019 at 15:20, on Zulip):

@Esteban Küber worth noting that on the PR for the benefit of the release team ^^

eddyb (Nov 07 2019 at 15:20, on Zulip):

it will restart itself like 5 times then give up AFAIK

pnkfelix (Nov 07 2019 at 15:20, on Zulip):

@eddyb even in the face of further changes to the input source code?

Esteban Küber (Nov 07 2019 at 15:20, on Zulip):

This one is insidious because it is very easy to hit when writing code.

eddyb (Nov 07 2019 at 15:21, on Zulip):

@pnkfelix I'm not sure exactly what the failure mode looks like but there's always Ctrl+Shift+P "restart RLS" once you've fixed the input

pnkfelix (Nov 07 2019 at 15:21, on Zulip):

okay well this probably is not the right moment to get into details of RLS architecture.

eddyb (Nov 07 2019 at 15:21, on Zulip):

there used to be a lot of these issues due to librustc_save_analysis bugs

centril (Nov 07 2019 at 15:22, on Zulip):

Aside: I cannot recommend rust-analyzer + VSCode enough for hacking on rustc; it works super smoothly, even when using a networked filesystem

eddyb (Nov 07 2019 at 15:22, on Zulip):

/me is too stubborn to switch to the winning team

nikomatsakis (Nov 07 2019 at 15:23, on Zulip):

/me doesn't like that framing :)

nikomatsakis (Nov 07 2019 at 15:23, on Zulip):

(though I'm sure you're joking ;)

pnkfelix (Nov 07 2019 at 15:24, on Zulip):

okay, lets quickly skim over the open stable-to-beta regressions

pnkfelix (Nov 07 2019 at 15:24, on Zulip):

(some of which I assume need to now be reclassified as stable-to-stable regressions)

pnkfelix (Nov 07 2019 at 15:25, on Zulip):

1/4: "non-empty glob statement regression 1.39" #65523

pnkfelix (Nov 07 2019 at 15:25, on Zulip):

was this resolved by #65539 ?

centril (Nov 07 2019 at 15:25, on Zulip):

believe so, can be closed

pnkfelix (Nov 07 2019 at 15:26, on Zulip):

2/4: "bindgen changes in 1.39" #65520

pnkfelix (Nov 07 2019 at 15:26, on Zulip):

the "remaining work" here was to look at the affected crates to try to confirm if this is just expected fallout

pnkfelix (Nov 07 2019 at 15:27, on Zulip):

I spent my time on other bugs though

centril (Nov 07 2019 at 15:27, on Zulip):

So looking for volunteers iow

nikomatsakis (Nov 07 2019 at 15:27, on Zulip):

I did do some of that

nikomatsakis (Nov 07 2019 at 15:27, on Zulip):

er, wait, maybe not on that issue

pnkfelix (Nov 07 2019 at 15:27, on Zulip):

yeah I think a bunch of these end up being bindgen but they were put into separate buckets

nikomatsakis (Nov 07 2019 at 15:27, on Zulip):

but the ones I tested all proved to be bindgen

pnkfelix (Nov 07 2019 at 15:27, on Zulip):

so my question is: Do we bother keeping this open?

nikomatsakis (Nov 07 2019 at 15:27, on Zulip):

I thnk we can assume it is

pnkfelix (Nov 07 2019 at 15:28, on Zulip):

I don't think its worth spending more time on at this point. The investigation is worthwhile if it can catch a bug before release itself

nikomatsakis (Nov 07 2019 at 15:28, on Zulip):

hmm

nikomatsakis (Nov 07 2019 at 15:28, on Zulip):

I'm skimming the logs

pnkfelix (Nov 07 2019 at 15:28, on Zulip):

but now that release is out, I think we might as well just let people file more specific tickets?

nikomatsakis (Nov 07 2019 at 15:28, on Zulip):

I can try to do some testing during meeting but anyway I think I agree

nikomatsakis (Nov 07 2019 at 15:28, on Zulip):

the logs are a bit more varied than I expected

pnkfelix (Nov 07 2019 at 15:30, on Zulip):

I think the three scenarios that arise in the logs there (failure to impl Copy, failure to impl PartialEq, and failure to impl fmt::Debug) all can arise as fallout from the bindgen thing

pnkfelix (Nov 07 2019 at 15:30, on Zulip):

but that is based on a very rough memory from when I last looked into the issues here

pnkfelix (Nov 07 2019 at 15:32, on Zulip):

3/4: 'ICE: "Tried to access field 0 of union with 0 fields"' #65462

eddyb (Nov 07 2019 at 15:32, on Zulip):

I dropped the ball here :/

pnkfelix (Nov 07 2019 at 15:32, on Zulip):

nah its a collective fail, @eddyb

pnkfelix (Nov 07 2019 at 15:33, on Zulip):

anyway we'll get to it.

pnkfelix (Nov 07 2019 at 15:33, on Zulip):

Should I reassign this bug to you @eddyb , or should I go ahead and try to puzzle it out myself?

eddyb (Nov 07 2019 at 15:33, on Zulip):

well, to be fair, someone else failed to track it down to @oli's change, neither of us saw the issue until weeks later and then @oli went on vacation while I forgot about it further :P

pnkfelix (Nov 07 2019 at 15:33, on Zulip):

I'll let @eddyb decide on their own whether they want to reassign it to themselves

eddyb (Nov 07 2019 at 15:33, on Zulip):

@pnkfelix elsewhere @oli said that they want to backport removing the assertion and then try to fix the actual problem on nightly

pnkfelix (Nov 07 2019 at 15:34, on Zulip):

i see. okay.

eddyb (Nov 07 2019 at 15:34, on Zulip):

but they can't be here today because travel

nikomatsakis (Nov 07 2019 at 15:34, on Zulip):

is this on beta now?

pnkfelix (Nov 07 2019 at 15:34, on Zulip):

@nikomatsakis yeah

centril (Nov 07 2019 at 15:34, on Zulip):

yep

nikomatsakis (Nov 07 2019 at 15:34, on Zulip):

removing the asseron seems like an easy PR to make

pnkfelix (Nov 07 2019 at 15:34, on Zulip):

yep

centril (Nov 07 2019 at 15:34, on Zulip):

shouldn't the assertion and the actual problem be addressed in the same PR?

pnkfelix (Nov 07 2019 at 15:35, on Zulip):

not necessarily

centril (Nov 07 2019 at 15:35, on Zulip):

or... to rephrase... what is the "actual problem"? :P

nikomatsakis (Nov 07 2019 at 15:36, on Zulip):

Yeah I don't know, I'm not sure how hard the actual fix is either, I imagine @eddyb is best positioned to answer

nikomatsakis (Nov 07 2019 at 15:36, on Zulip):

since they seemed familiar with the bug

nikomatsakis (Nov 07 2019 at 15:36, on Zulip):

I'd definitely prefer we don't just remove the assertion and leave it at that (assuming the assertion is correct of course)

eddyb (Nov 07 2019 at 15:36, on Zulip):

I have no idea what it's from, @oli fixed one thing that was affecting miri

nikomatsakis (Nov 07 2019 at 15:37, on Zulip):

I wonder if it's realted to the changes we made around ZSTs

eddyb (Nov 07 2019 at 15:37, on Zulip):

note that the regression is from a somewhat useless assertion being copied from miri to the general version of the code

pnkfelix (Nov 07 2019 at 15:37, on Zulip):

at this point I think the only question is whether someone else wants to take the lead on the follow-on work or not.

nikomatsakis (Nov 07 2019 at 15:37, on Zulip):

seems like we should assign someone to dig in.?

pnkfelix (Nov 07 2019 at 15:37, on Zulip):

If so, please work-steal from me

eddyb (Nov 07 2019 at 15:37, on Zulip):

the underlying issue is likely years old

eddyb (Nov 07 2019 at 15:37, on Zulip):

just assign @oli they said they want to look into this

centril (Nov 07 2019 at 15:38, on Zulip):

Oliver is back, so assign to them? :point_up:

pnkfelix (Nov 07 2019 at 15:38, on Zulip):

Okay. Its P-high so presumably I'll see it again next week if @oli doesn't get around to it.

pnkfelix (Nov 07 2019 at 15:39, on Zulip):

stable-to-beta regression 4/4: "Undefined symbol _fltused when compiling to x86_64-unknown-uefi" #62785

pnkfelix (Nov 07 2019 at 15:39, on Zulip):

oh man I keep looking at this every week

pnkfelix (Nov 07 2019 at 15:40, on Zulip):

and every week I follow the chain

pnkfelix (Nov 07 2019 at 15:40, on Zulip):

until I get to PR rust-lang/compiler-builtins#317

nikomatsakis (Nov 07 2019 at 15:40, on Zulip):

we need a :deja vu: emoji

eddyb (Nov 07 2019 at 15:41, on Zulip):

:upside_down:

pnkfelix (Nov 07 2019 at 15:41, on Zulip):

I think its time for me to post a note there

mw (Nov 07 2019 at 15:42, on Zulip):

we need a :deja vu: emoji

That :cat: is obviously the cat in the stairwell from Matrix

pnkfelix (Nov 07 2019 at 15:42, on Zulip):

okay that's all the stable-to-beta regressions

pnkfelix (Nov 07 2019 at 15:42, on Zulip):

the only stable-to-nightly regression we haven't already discussed is also a nominated issue

pnkfelix (Nov 07 2019 at 15:42, on Zulip):

so lets just jump to the nominated issues/PR's

pnkfelix (Nov 07 2019 at 15:42, on Zulip):

nominations: https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-nominated+label%3AT-compiler

pnkfelix (Nov 07 2019 at 15:43, on Zulip):

there are four

pnkfelix (Nov 07 2019 at 15:43, on Zulip):

nom 1/4: "ICE in const fn evaluation - Disagreement between legacy and dataflow-based const validators when a const fn takes &mut self" #66167

pnkfelix (Nov 07 2019 at 15:43, on Zulip):

here we have an ICE because there's some sort of consistency check between new and old const-checking

pnkfelix (Nov 07 2019 at 15:43, on Zulip):

that is failing for this input

eddyb (Nov 07 2019 at 15:44, on Zulip):

looks like it's "ICE on top of error", not just ICE for non-erroring code?

pnkfelix (Nov 07 2019 at 15:44, on Zulip):

right

pnkfelix (Nov 07 2019 at 15:44, on Zulip):

so there are a couple things here

pnkfelix (Nov 07 2019 at 15:44, on Zulip):
  1. @ecstatic-morse has already weighed in saying they are not inclined to bother fixing this
pnkfelix (Nov 07 2019 at 15:44, on Zulip):

based on argument that the problem will go away once the old const-check goes away

eddyb (Nov 07 2019 at 15:45, on Zulip):

the timeframe is likely a week or two btw, judging from my discussions with them

pnkfelix (Nov 07 2019 at 15:45, on Zulip):

so my question in response to that: Do we have an ETA for the old const-check to go away?

pnkfelix (Nov 07 2019 at 15:45, on Zulip):

ah okay

pnkfelix (Nov 07 2019 at 15:45, on Zulip):

if its really just a week or two, then this is fine

pnkfelix (Nov 07 2019 at 15:46, on Zulip):

I'm coming at this from the NLL effort where we had a much different timeline.

eddyb (Nov 07 2019 at 15:46, on Zulip):

I think we're already landing removing parts of the old code for this

eddyb (Nov 07 2019 at 15:46, on Zulip):

yeah this is an order or two of magnitude less implementation logic to worry about

pnkfelix (Nov 07 2019 at 15:46, on Zulip):

okay that's fine then.

pnkfelix (Nov 07 2019 at 15:46, on Zulip):

lets move along

pnkfelix (Nov 07 2019 at 15:47, on Zulip):

nom 2/4: "[WIP] Make a table of trait object type_ids and vtable pointers available to programs" #66113

pnkfelix (Nov 07 2019 at 15:47, on Zulip):

there was some discussion of this at end of pre-triage

eddyb (Nov 07 2019 at 15:48, on Zulip):

I've done this sort of thing by hand with macros for opt-in, my personal opinion is that rustc shouldn't do this for you, but I'd prefer leaving that debate to an RFC

centril (Nov 07 2019 at 15:48, on Zulip):

imo this is too fresh to discuss now (same for lang team meeting also really)

pnkfelix (Nov 07 2019 at 15:48, on Zulip):

I think most people present in that conversation were inclined to say that a change like this should probably go through the RFC process. (And I separately wondered about a design meeting)

nikomatsakis (Nov 07 2019 at 15:48, on Zulip):

Hmm. My first reaction is that I would want this to go forward only in the context of a larger effort. It's the usual tension, though, that this effort is likely not on our priority list just now.

pnkfelix (Nov 07 2019 at 15:49, on Zulip):

So I just wanted to see if anyone in this meeting wanted to argue against pushing for RFC here

centril (Nov 07 2019 at 15:49, on Zulip):

I wouldn't; but imo in a week we would all be better read in to provide a more thorough answer

pnkfelix (Nov 07 2019 at 15:50, on Zulip):

(feel free to interrupt later in meeting if you want to make such an argument. but for now I'll move along.)

pnkfelix (Nov 07 2019 at 15:50, on Zulip):

I wouldn't; but imo in a week we would all be better read in to provide a more thorough answer

I'm not sure I understand: Are you saying we/I should wait a week in any case before posting a response on that PR ?

centril (Nov 07 2019 at 15:50, on Zulip):

basically yes; I'm sorta arguing for "procrastination" ^^

eddyb (Nov 07 2019 at 15:51, on Zulip):

they could spend that week writing an RFC tbh

pnkfelix (Nov 07 2019 at 15:51, on Zulip):

because ... some of us will read the PR and change our minds about whether it needs an RFC?

centril (Nov 07 2019 at 15:51, on Zulip):

@pnkfelix I don't think that would be the outcome, but it would be "needs an RFC + context" instead of just "needs an RFC"

eddyb (Nov 07 2019 at 15:51, on Zulip):

even if the implementation is non-invasive, the feature likely warrants some wider discussion

pnkfelix (Nov 07 2019 at 15:51, on Zulip):

(or maybe its just a matter of needing time to read the description on that PR. Because it is a beast,I'll admit)

pnkfelix (Nov 07 2019 at 15:52, on Zulip):

I see, this is more about fine-tuning the feedback so that the PR author gets the right impression

centril (Nov 07 2019 at 15:52, on Zulip):

yeah something like that, I think

pnkfelix (Nov 07 2019 at 15:53, on Zulip):

Okay well I guess I'll leave it nominated and we can talk about it again next week. Though I do think @eddyb has a point that early feedback may be better in terms of how people choose to invest their time...

pnkfelix (Nov 07 2019 at 15:53, on Zulip):

okay next up

pnkfelix (Nov 07 2019 at 15:53, on Zulip):

nom 3/4: "Some features can no longer be controlled by conditional compilation" #65860

pnkfelix (Nov 07 2019 at 15:53, on Zulip):

I think you all remember our discussion about this from last week

pnkfelix (Nov 07 2019 at 15:54, on Zulip):

the reason its still nominated (even though follow-up PR's landed to remove the regressive behavior from beta) ...

pnkfelix (Nov 07 2019 at 15:54, on Zulip):

... is because there is still a general sense from some stake-holders that we need a conversation about the approach here

pnkfelix (Nov 07 2019 at 15:56, on Zulip):

the question in my mind is whether (1) its the sort of discussion we can hope to have either (1a) asynchronously or (1b) very quickly in THursday meeting ...

pnkfelix (Nov 07 2019 at 15:56, on Zulip):

or if (2) it needs a design meeting slot on Friday

pnkfelix (Nov 07 2019 at 15:56, on Zulip):

I don't have an answer to that question. So I'm raising it here.

nikomatsakis (Nov 07 2019 at 15:56, on Zulip):

I don't think we can discuss it in this meeting

pnkfelix (Nov 07 2019 at 15:57, on Zulip):

I think I agree with that

centril (Nov 07 2019 at 15:57, on Zulip):

(4 min left, so agreed)

pnkfelix (Nov 07 2019 at 15:57, on Zulip):

We'll leave the nominated tag on it

nikomatsakis (Nov 07 2019 at 15:57, on Zulip):

I think it's probably worth having some comments asynchronously

pnkfelix (Nov 07 2019 at 15:57, on Zulip):

nom 4/4: "PowerPC C ABI fixes" #64259

pnkfelix (Nov 07 2019 at 15:57, on Zulip):

to be frank I have no clue what's going on with this PR

pnkfelix (Nov 07 2019 at 15:57, on Zulip):

@eddyb can you clue us (or me) in ?

nagisa (Nov 07 2019 at 15:58, on Zulip):

I think this should land.

pnkfelix (Nov 07 2019 at 15:58, on Zulip):

the first commit was factored out. But @nagisa , you're saying the whole thing should also land?

eddyb (Nov 07 2019 at 15:58, on Zulip):

I've stalled the PR originally because the author generalized some existing checks for targets that have weird ZST behavior

pnkfelix (Nov 07 2019 at 15:58, on Zulip):

(first commit factored PR is "Fix C aggregate-passing ABI on powerpc" #66050)

eddyb (Nov 07 2019 at 15:58, on Zulip):

I'm not opposed to adding PPC32 as another special-case for the weird ZST behavior

eddyb (Nov 07 2019 at 15:59, on Zulip):

I've spent some time with @gnzlbg discussing the overall behavior in GCC and they've opened some bug reports for GCC, I think, but I don't know what the status of that is

pnkfelix (Nov 07 2019 at 16:02, on Zulip):

(moved conversation to other topic)

pnkfelix (Nov 07 2019 at 16:02, on Zulip):

okay, thanks for coming everyone in @T-compiler/meeting !!!

Last update: Nov 16 2019 at 01:50UTC