imp feedback: keep the limit

Feedback: use default instead of listing cases

The advantage of listing cases instead of using default would be that if another enum value ever gets added, then the compiler's warning about unhandled cases won't have been suppressed. But I agree it's uglier. I'll change it to default.

Closing this one as overcome-by-events. Opened D27897.

In D27886#623424, @mmel wrote:

In D27886#623414, @rlibby wrote:

In D27886#623242, @mmel wrote:

Good catch. It never occurred to me that we could have a bug in atomics on two architectures at the same time, so I wasn't looking for a problem in my own garden :) I will try to fix arm by myself.

Are you saying 32-bit ARM is also broken? Those are a little weirder, I think it uses sys/sys/_atomic_subword.h.

Yes, it is also broken. ARM uses its own implementation, which does not do modulo for the bit position.
See https://cgit.freebsd.org/src/tree/sys/arm/include/atomic-v6.h#n862.
I will commit proper fix in next hour or so...

You're right that 32-bit arm also has a bug though and needs more follow up.

In D27886#623414, @rlibby wrote:

In D27886#623242, @mmel wrote:

Good catch. It never occurred to me that we could have a bug in atomics on two architectures at the same time, so I wasn't looking for a problem in my own garden :) I will try to fix arm by myself.

Are you saying 32-bit ARM is also broken? Those are a little weirder, I think it uses sys/sys/_atomic_subword.h.

In D27886#623242, @mmel wrote:

Good catch. It never occurred to me that we could have a bug in atomics on two architectures at the same time, so I wasn't looking for a problem in my own garden :) I will try to fix arm by myself.

Actually atomic(9) says that it will do the mod:

atomic_testandset(p, v)
        bit = 1 << (v % (sizeof(*p) * NBBY));
        tmp = (*p & bit) != 0;
        *p |= bit;
        return (tmp);

Rebase, over

• r355746 / git 815db20425013129469fc0ebe9f8f00c88c58184
• r366377 / git 952c8964ba935937e396c8abc8d5629e59502e2d

I think r359311 / git ca0ec73c11a7bb9ed409466e514fa5c34b6c84b5 / D22963 (generic atomic_testand{set,clear}_long) satisfied the dependency I was worried about here so I'm going to go ahead with this. The only conflict in the rebase was the man doc date.

LGTM. The same construct is seen in other assignments to pointers from nr_body.

Resolved by @se's import of bc 3.2.4.

feedback: just link libcompiler_rt, which will now be no-SSP

Yep, just a friendly ping. I'm eager to finish the gcc work, but it is definitely not urgent. Thank you!

In D27736#620834, @kib wrote:

I think we should change compiler-rt to not compile with -fstack-protector, and then link it into rtld.

I realized that there is a (strong) argument to make the library not compiled with the flag. It is linked statically into binaries, because compiler support functions are not port of the OS ABI. So if compiler-rt is compiled with SSP, it is impossible to build a binary without SSP.

@se Now that vendor workflows are open for git, can we get upstream's fix in? Or do you prefer I just do a direct commit of upstream's fix as discussed above?

Here's the alternate where we just cross our fingers and link libcompiler_rt (no surprises):
https://github.com/rlibby/freebsd/commit/f61af4c21d62280d2b6e9c360606cae781d8f316

@wulf (sorry forgot to ask) Is it okay if I push this straight to current or would you prefer to route it through the upstream first?

@gnn did you want to take a look at this patch before it goes in? It is just turning down nuisance warnings for gcc compatibility.

In D27736#620002, @arichardson wrote:

I'm not particularly keen on building all of compiler-rt again without SSP just for the 2-3 files that rtld needs. I'd be surprised if those functions even use SSP with -fstack-protector-strong. Are there any functions in compiler-rt that would benefit from SSP?

Actually include all the changes

In D27730#619836, @melifaro wrote:

Ty for fixing this!

Is this specifically for LDBL_MAX?