Re: Implementing p0515 - spaceship operator

[Tim van Deurzen]

Will take care of it this evening then. If I get stuck or need some help 
I'll try the IRC channel or reply to this mail again :).


Tim.

On 11/5/18 8:40 AM, Jakub Jelinek wrote:

On Mon, Nov 05, 2018 at 08:36:44AM +0100, Tim van Deurzen wrote:

I've received a lot of good advice from Nathan, but haven't had an
opportunity to apply it yet. I'm happy, however, to show / commit what I
have so far (which covers the parsing of the operator). I've been working
from the git repository until now, but from the mailing list I gather that
this is not the main development RCS yet. How and/or where would you prefer
my changes to be sent to? Just as a patch to the mailing list or rather as a
new branch in the SVN repo? If the latter is the case I would need a bit of
assistance as it's been years since I've worked with SVN.

When exactly is the feature deadline?

The deadline is end of November 11th, timezone of your choice.
Patches should be just posted to gcc-patches at gcc dot gnu dot org mailing
list.  If you could do it today or tomorrow, it would be really appreciated.

Jakub

Poor code generation/optimisation in all versions of GCC x86-64 and x86-32

[Stefan Kanthak]

Hi @ll,

the following code snippets let GCC x86-64 generate rather
poor code (see ):

__int128 foo(__int128 n)
{
n <<= 1;
n += 1;
n |= 1;
return n;
}


__int128 bar(__int128 n)
{
n += n;
n += 1;
n |= 1;
return n;
}

With -O1:With -O2:

foo: foo:
mov   rax, rdi   mov   rax, rdi
mov   rdx, rsi   mov   rdx, rsi
shld  rdx, rdi, 1add   rax, rdi
add   rax, rdi   shld  rdx, rdi, 1
add   rax, 1 add   rax, 1
adc   rdx, 0 adc   rdx, 0
mov   rcx, rdx   orrax, 1
orrax, 1 mov   rcx, rdx
mov   rdx, rcx   mov   rdx, rcx
ret  ret
bar: bar:
mov   rax, rdi   mov   rax, rdi
mov   rdx, rsi   mov   rdx, rsi
shld  rdx, rdi, 1add   rax, rdi
add   rax, rdi   shld  rdx, rdi, 1
add   rax, 1 add   rax, 1
adc   rdx, 0 adc   rdx, 0
mov   rcx, rdx   orrax, 1
orrax, 1 mov   rcx, rdx
mov   rdx, rcx   mov   rdx, rcx
ret  ret

In all 4 examples, the last 4 instructions are superfluous!

1. the optimizer should be aware that both "n <<= 1;" and "n += n;"
   yield an even number, and thus a following "n += 1;" can't
   generate a carry.
   More general: after "n <<= x;" addition of any value less than
   1 << x can't generate a carry.

2. the optimzier should also be aware that addition of 1 to an even
   number yields an odd number, and thus a following "n |= 1;" is
   a no-op.
   More general: after "n <<= x;", the addition of any value less
   than 1 << x is equal to a logical or with the same value.

3. last, it should never create "mov rcx, rdx" followed by an
   inverse "mov rdx, rcx".

I also wonder why a shld is created here: at least for "n += n;"
I expect a more straightforward
add  rax, rax
adc  rdx, rdx

regards
Stefan Kanthak

PS: of course GCC x86-32 exhibits the same flaws with int64_t!

Re: how to build and test uClinux toolchains

[Max Filippov]

On Wed, Oct 31, 2018 at 8:43 AM Christophe Lyon
 wrote:
> I also built qemu from the branch you mentioned,
> and used the "run it on linux-user QEMU" section in the wiki
>
> I see many execution errors, now realizing that I didn't
> do what you said above: "apply gcc part of the xtensa overlay".
> But what is this?

It's a set of files that must be replaced in the toolchain source to configure
it for a specific xtensa core.
For gcc the config that you've built changes single file,
include/xtensa-config.h
and the change is the following:

--8<--
diff --git a/include/xtensa-config.h b/include/xtensa-config.h
index d6713d23a6b2..18899f827ea7 100644
--- a/include/xtensa-config.h
+++ b/include/xtensa-config.h
@@ -25,7 +25,7 @@
macros.  */

 #undef XCHAL_HAVE_BE
-#define XCHAL_HAVE_BE  1
+#define XCHAL_HAVE_BE  0

 #undef XCHAL_HAVE_DENSITY
 #define XCHAL_HAVE_DENSITY 1

-->8--

> And while writing this reply, I'm just realizing that buildroot builds
> for uclinux-uclibc-gcc, while the wiki uses linux-uclibc :(
> Does the wiki need an update wrt target name?

Yeah, I used it as an example. Let me update it so that it works
for uclinux without obscure modifications.

I was able to figure out why C++ exceptions didn't work: because
the target code was built as PIC by default and it's not supported
by the bFLT file format. I've posted a fix here:

  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00286.html

--
Thanks.
-- Max

Re: how to build and test uClinux toolchains

[Max Filippov]

On Fri, Nov 2, 2018 at 3:29 AM Christophe Lyon
 wrote:
> I re-ran the wiki instructions with --target=xtensa-buildroot-uclinux-uclibc
> and while gcc/g++ results looks mostly OK, the libstdc++ ones only show:
> Running ...f/trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ...
> ERROR: could not compile testsuite_abi.cc
> ERROR: tcl error 
> sourcing.../trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
> Running.../trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ...
> ERROR: could not compile testsuite_abi.cc
> etc...
>
> libstdc++.log show many instances of:
> .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc: In function
> 'symbols create_symbols(const char*)':^M
> .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc:565: note:
> non-delegitimized UNSPEC 3 found in variable location^M
> .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc: In function
> 'void examine_symbol(const char*, const char*)':^M
> .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc:355: note:
> non-delegitimized UNSPEC 3 found in variable location^M

"non-delegitimized UNSPEC 3 found" is a note, not an error.
There should also be an error.

> Do you know what the problem is in my setup? Or with GCC trunk?

I ran make check on gcc trunk from 2018-10-20, libstdc++ testsuite
works for me:

=== libstdc++ Summary ===

# of expected passes9889
# of unexpected failures89
# of unexpected successes   4
# of expected failures  79
# of unresolved testcases   17
# of unsupported tests  758

--
Thanks.
-- Max

Re: how to build and test uClinux toolchains

[Christophe Lyon]

On Mon, 5 Nov 2018 at 21:49, Max Filippov  wrote:
>
> On Fri, Nov 2, 2018 at 3:29 AM Christophe Lyon
>  wrote:
> > I re-ran the wiki instructions with --target=xtensa-buildroot-uclinux-uclibc
> > and while gcc/g++ results looks mostly OK, the libstdc++ ones only show:
> > Running ...f/trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ...
> > ERROR: could not compile testsuite_abi.cc
> > ERROR: tcl error 
> > sourcing.../trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
> > Running.../trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ...
> > ERROR: could not compile testsuite_abi.cc
> > etc...
> >
> > libstdc++.log show many instances of:
> > .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc: In function
> > 'symbols create_symbols(const char*)':^M
> > .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc:565: note:
> > non-delegitimized UNSPEC 3 found in variable location^M
> > .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc: In function
> > 'void examine_symbol(const char*, const char*)':^M
> > .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc:355: note:
> > non-delegitimized UNSPEC 3 found in variable location^M
>
> "non-delegitimized UNSPEC 3 found" is a note, not an error.
> There should also be an error.
>
That's what I thought, but I couldn't find it.

> > Do you know what the problem is in my setup? Or with GCC trunk?
>
> I ran make check on gcc trunk from 2018-10-20, libstdc++ testsuite
> works for me:
>
> === libstdc++ Summary ===
>
> # of expected passes9889
> # of unexpected failures89
> # of unexpected successes   4
> # of expected failures  79
> # of unresolved testcases   17
> # of unsupported tests  758
>

OK, thanks for the confirmation, I'm now re-building with the patches
from your previous email

> --
> Thanks.
> -- Max

Re: Implementing p0515 - spaceship operator

[Jason Merrill]

On Sun, Nov 4, 2018 at 11:36 PM Tim van Deurzen  wrote:
> I've received a lot of good advice from Nathan, but haven't had an
> opportunity to apply it yet. I'm happy, however, to show / commit what I
> have so far (which covers the parsing of the operator). I've been
> working from the git repository until now, but from the mailing list I
> gather that this is not the main development RCS yet. How and/or where
> would you prefer my changes to be sent to? Just as a patch to the
> mailing list or rather as a new branch in the SVN repo?

Patches against the git mirror is fine, I haven't touched the svn
client in quite a while either.

Jason