*ping*

• Remove hasHiddenLTOVisibility from CXXRecordDecl and rename the flag to -frelative-c++-abi-vtables

Update to current working version without needing LTO

@rjmccall @ebevhan @bjope *ping* any other comments on this patch?

In D58321#1407362, @pcc wrote:

Can we start with a patch that just exposes a flag that enables the relative ABI unconditionally, and remove all the platform ABI compatibility stuff?

Hi @pcc , I'm working on revisiting this to see if this could help when building Fuchsia (D58321) and had a few questions I left inline.

LGTM. Everything still seems to work on my end after applying this diff.

*ping* @bevinh @rjmccall @bjope Any other comments on this patch?

Oh I forgot to submit these inline comments

In D57793#1403308, @chandlerc wrote:

In D57793#1403303, @leonardchan wrote:

Will need to be rebased after rC353985. Should this also include tsan, unless this is just for msan specifically?

Yeah, I suspect so. If you want, maybe take this over? Would be great to get this landed.

Addressed in rC353985

Addressed in rC353985

Will need to be rebased after rC353985. Should this also include tsan?

LGTM. Doesn't seem to break anything as far as I can see.

In D56470#1391644, @philip.pfaffe wrote:

It's still missing the O0 part. I forgot adding it for msan and tsan, but we should do asan correctly from the start.

Fixed mistake related to saturation during expansion. When we promote the operand and result type widths, this also changes the saturation width and affects the min/max values we compare against. This is easily solved by also shifting one of the operands after extension.

*ping* @philip.pfaffe Any last comments on this?

In D57553#1388493, @ebevhan wrote:

In D57553#1381920, @leonardchan wrote:

In regards to solving the problem of resizing for int conversions, I'm starting to think that we will need that initial resize since if we want to retain the min-max pattern for all conversions, then it would be necessary to extend and shift when converting from an int to fixed point. Otherwise, I think we'd have the initial pattern I proposed where we check against the source value, but not have this pattern.

Yes, I'm starting to think so too. It's just not possible to not resize and keep the minmax pattern at the same time. We can't upshift without resizing first (because any bits above the scale can affect saturation), and if we wanted to saturate purely on the non-rescaled value, then the (mandatory) rescaling after saturation could destroy the possibly saturated result (since it would shift in zeroes from the right if upscaling, which breaks the result if it saturated to max).

Sorry for going down this path, that was rather pointless.

Updated. Before submitting, @chandlerc would you mind taking one last look at this to make sure everything is in order? I wouldn't want to accidentally cause another ASan related timeout.

Updated and rebased

In D57553#1380157, @ebevhan wrote:

This doesn't seem to address the particular case in the integer conversion patch. In fact, I don't see those conversions at all.

Updated and rebased

Updated and rebased