Re: AArch64 patches for glibc master.

["Carlos O'Donell" <carlos at redhat dot com>]

On 12/09/2013 01:56 PM, Joseph S. Myers wrote:
> On Mon, 9 Dec 2013, Carlos O'Donell wrote:
> 
>> * Ran `make regen-ulps' and used that as the baseline for math failures
>>   with new hardware. New ULPS look OK. Not a problem, per se, but you 
>>   need to update ULPS.
> 
> They don't look OK.
> 
> * You're adding huge ulps for gamma/lgamma, up to 
> 48766098391324236335813626361678.

I missed these in my review. Granted I scrolled quickly looking
for any potential problems. Thanks for catching this.

> * You're adding ulps for sqrt, which should always be exact.

I wasn't aware that sqrt should always be exact. I'll try to
educate myself on that. Do you have any pointers on where I can
read about that?

> Those problems need investigating and fixing.

I agree.

>> * For llseek AArch64 doesn't provide its own llseek.c that does nothing
>>   so the default llseek tries to build and with the UAPI headers
>>   not defining __NR_llseek because compat is disabled it fails to build.
>>   I added code to check for this case. That is to say if it's a 64-bit
>>   machine with no llseek, it means that lseek is already 64-bit ready
>>   so use that.
> 
> llseek is part of the ABI in past releases so you can't just remove it - 
> I'd have expected ABI test failures to result.

I apologize for not being sufficiently clear. The wrapper in 
sysdeps/unix/sysv/linux/llseek.c is not used in this case.
Instead for a 64-bit system sysdeps/unix/sysv/linux/wordsize-64/syscalls.list
creates an assembly wrapper that exports lseek and llseek.

Therefore you either need to have an empty llseek.c or the hack I'm suggesting.
The hack I'm suggesting should allow us to remove the empty in
ports/sysdeps/unix/sysv/linux/mips/mips64/llseek.c if the UAPI defines work
out the same way.

I don't have a strong preference either way.

>> You should fix the build failures for 2.19 though. You have until the end
>> of December to get these fixes in place before the release code freeze.
>> After the freeze you can still get them in but you need explicit ACK from
>> the release manager (Allan McRae).
> 
> We do not expect release manager acks for architecture-specific patches 
> (fixing build failures, test failures, build warnings etc.) between freeze 
> and release.  The main point of the freeze is for such patches to go in as 
> a result of testing.

You are correct. Given that these are build failures they would not need
any ACK'ing just check them in for a build fix.

Cheers,
Carlos.