Re: branch prediction not correctly applied to an if statement in an inline with multiple conditoins
> Am 30.11.2024 um 08:19 schrieb Mateusz Guzik via Gcc :
>
> Tested with gcc 14.2 and the Linux kernel compiling for amd64. This is
> at Linux next-20241127. This was already the case on gcc 13 (no idea
> about earlier versions), I tested 14 to see if the problem is gone.
>
> In the particular case I ran into a prediction concerning the return
> value of __access_ok is not correctly acted upon.
>
> #define access_ok(addr, size) likely(__access_ok(addr, size))
>
> then in __access_ok:
> return valid_user_address(sum) && sum >= (__force unsigned long)ptr;
>
> The expected asm contains 2 branches both with a jump towards the end
> of the function in the failing case. Instead jumps are emitted if
> everything works out.
I would suggest you Open a bugreport Witz a complete compilable Testcase.
Richard
> Interestingly the issue fixes itself if I split the if statement like so:
> - return valid_user_address(sum) && sum >= (__force
> unsigned long)ptr;
> + if (!valid_user_address(sum))
> + return false;
> + return sum >= (__force unsigned long)ptr;
>
> Routine at hand (trimmed):
> static inline __must_check unsigned long
> _inline_copy_to_user(void __user *to, const void *from, unsigned long n)
> {
> if (access_ok(to, n)) {
> instrument_copy_to_user(to, from, n);
> n = raw_copy_to_user(to, from, n);
> }
> return n;
> }
>
> Bad asm:
> Dump of assembler code for function _copy_to_user:
> 0x819713c0 <+0>: endbr64
> 0x819713c4 <+4>: mov%rdx,%rcx
> 0x819713c7 <+7>: mov%rdx,%rax
> 0x819713ca <+10>:xor%edx,%edx
> 0x819713cc <+12>:add%rdi,%rcx
> 0x819713cf <+15>:setb %dl
> 0x819713d2 <+18>:movabs $0x123456789abcdef,%r8
> 0x819713dc <+28>:test %rdx,%rdx
> 0x819713df <+31>:jne0x819713e6 <_copy_to_user+38>
>
> this jumps to the exit
>
> 0x819713e1 <+33>:cmp%rcx,%r8
> 0x819713e4 <+36>:jae0x819713eb <_copy_to_user+43>
>
> this jumps over exiting the func to do the actual work, even though
> doing the compiler is hinted this is the expected state
>
> 0x819713e6 <+38>:jmp0x8206b160 <__x86_return_thunk>
> 0x819713eb <+43>:nop
> 0x819713ec <+44>:nop
> 0x819713ed <+45>:nop
> 0x819713ee <+46>:mov%rax,%rcx
> 0x819713f1 <+49>:rep movsb %ds:(%rsi),%es:(%rdi)
> 0x819713f3 <+51>:nop
> 0x819713f4 <+52>:nop
> 0x819713f5 <+53>:nop
> 0x819713f6 <+54>:mov%rcx,%rax
> 0x819713f9 <+57>:nop
> 0x819713fa <+58>:nop
> 0x819713fb <+59>:nop
> 0x819713fc <+60>:jmp0x8206b160 <__x86_return_thunk>
>
> Good asm:
> Dump of assembler code for function _copy_to_user:
> 0x819713f0 <+0>: endbr64
> 0x819713f4 <+4>: xor%r8d,%r8d
> 0x819713f7 <+7>: mov%rdx,%rax
> 0x819713fa <+10>:add%rdi,%rdx
> 0x819713fd <+13>:setb %r8b
> 0x81971401 <+17>:movabs $0x123456789abcdef,%rcx
> 0x8197140b <+27>:cmp%rdx,%rcx
> 0x8197140e <+30>:jb 0x81971426 <_copy_to_user+54>
>
> this only jumps if the condition failed (where the prediction is that it wont)
>
> 0x81971410 <+32>:test %r8,%r8
> 0x81971413 <+35>:jne0x81971426 <_copy_to_user+54>
>
> ditto
>
> 0x81971415 <+37>:nop
> 0x81971416 <+38>:nop
> 0x81971417 <+39>:nop
> 0x81971418 <+40>:mov%rax,%rcx
> 0x8197141b <+43>:rep movsb %ds:(%rsi),%es:(%rdi)
> 0x8197141d <+45>:nop
> 0x8197141e <+46>:nop
> 0x8197141f <+47>:nop
> 0x81971420 <+48>:mov%rcx,%rax
> 0x81971423 <+51>:nop
> 0x81971424 <+52>:nop
> 0x81971425 <+53>:nop
> 0x81971426 <+54>:jmp0x8206b1a0 <__x86_return_thunk>
>
> --
> Mateusz Guzik
Re: building gcc 14 with gcc 14 ?
On Sat, 30 Nov 2024 at 10:10, Jakub Jelinek wrote: > > On Sat, Nov 30, 2024 at 09:54:02AM +, Jonathan Wakely via Gcc wrote: > > On Sat, 30 Nov 2024, 09:01 David H. Lynch Jr. via Gcc, > > wrote: > > > > > Is it possible to build gcc 13 with gcc 14 ? > > > > > > > Yes > > Note, there are some exceptions, I think e.g. Ada needs the same or older > major version of gnat and doesn't work well with newer Ada (but if you don't > need Ada, that is a non-issue). > Also, if building very old gcc with very new gcc (one year difference is > fine, but 10 or 30 could be), one can run into the newer compiler erroring > on something that hasn't been fixed in the old compiler, etc. Some things > can be easily worked around e.g. by using -std=gnu89 when GCC was written in > C, for some things one might need to patch certain minor things. These branches can help with that https://github.com/jwakely/gcc/branches/all?query=renovated But I haven't created a branch for building gcc-13 with gcc-14 because that should Just Work.
Re: building gcc 14 with gcc 14 ?
On Sat, 30 Nov 2024, 09:01 David H. Lynch Jr. via Gcc, wrote: > Is it possible to build gcc 13 with gcc 14 ? > Yes > My system updated to gcc 14 and I am doing some private development for > hardware stesting of a new memory addressing paradigm using the GCC 13 > code base. > Now I can't compile. > > Do I need to revert my base compiler to gcc 13 ? > No, you can just build your own cot of GCC 13 and install it to a separate location e.g. under your home directory. Just don't install it to the same --prefix=DIR as the system compiler or you'll break things.
Re: building gcc 14 with gcc 14 ?
On Sat, 30 Nov 2024, 09:54 Jonathan Wakely, wrote: > > > On Sat, 30 Nov 2024, 09:01 David H. Lynch Jr. via Gcc, > wrote: > >> Is it possible to build gcc 13 with gcc 14 ? >> > > Yes > > >> My system updated to gcc 14 and I am doing some private development for >> hardware stesting of a new memory addressing paradigm using the GCC 13 >> code base. >> Now I can't compile. >> >> Do I need to revert my base compiler to gcc 13 ? >> > > No, you can just build your own cot > Sorry for the typo, that was meant to be "copy" of GCC 13 and install it to a separate location e.g. under your home > directory. Just don't install it to the same --prefix=DIR as the system > compiler or you'll break things. > > >
Re: building gcc 14 with gcc 14 ?
On Sat, Nov 30, 2024 at 09:54:02AM +, Jonathan Wakely via Gcc wrote: > On Sat, 30 Nov 2024, 09:01 David H. Lynch Jr. via Gcc, > wrote: > > > Is it possible to build gcc 13 with gcc 14 ? > > > > Yes Note, there are some exceptions, I think e.g. Ada needs the same or older major version of gnat and doesn't work well with newer Ada (but if you don't need Ada, that is a non-issue). Also, if building very old gcc with very new gcc (one year difference is fine, but 10 or 30 could be), one can run into the newer compiler erroring on something that hasn't been fixed in the old compiler, etc. Some things can be easily worked around e.g. by using -std=gnu89 when GCC was written in C, for some things one might need to patch certain minor things. Jakub
Re: building gcc 14 with gcc 14 ?
On Nov 30 2024, Jakub Jelinek via Gcc wrote: > Note, there are some exceptions, I think e.g. Ada needs the same or older > major version of gnat and doesn't work well with newer Ada (but if you don't > need Ada, that is a non-issue). That may also be an issue for D. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
building gcc 14 with gcc 14 ?
Is it possible to build gcc 13 with gcc 14 ? My system updated to gcc 14 and I am doing some private development for hardware stesting of a new memory addressing paradigm using the GCC 13 code base. Now I can't compile. Do I need to revert my base compiler to gcc 13 ?
gcc-14-20241130 is now available
Snapshot gcc-14-20241130 is now available on https://gcc.gnu.org/pub/gcc/snapshots/14-20241130/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 14 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-14 revision dd1d74cb548428f5928c10f7d3ba2b3cdd5ddc80 You'll find: gcc-14-20241130.tar.xz Complete GCC SHA256=2db6e0582999e302766056a06ef0471daa1a43435822fd8cd1fe3466a30f6060 SHA1=3892453990aeaf1d5a5573b3d266bcb6f5dfc891 Diffs from 14-20241123 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-14 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
