Re: [PATCH] __atomic_test_and_set: Fall back to library, not non-atomic code

[Hans-Peter Nilsson]

> From: Christophe Lyon 
> Date: Tue, 3 Oct 2023 15:20:39 +0200

> The patch passed almost all our CI configurations, except arm-eabi when
> testing with
>  -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
> where is causes these failures:
> FAIL: 29_atomics/atomic_flag/clear/1.cc -std=gnu++17 (test for excess
> errors)
> UNRESOLVED: 29_atomics/atomic_flag/clear/1.cc -std=gnu++17 compilation
> failed to produce executable
> FAIL: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++20 (test for
> excess errors)
> UNRESOLVED: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++20
> compilation failed to produce executable
> FAIL: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++26 (test for
> excess errors)
> UNRESOLVED: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++26
> compilation failed to produce executable
> FAIL: 29_atomics/atomic_flag/test_and_set/explicit.cc -std=gnu++17 (test
> for excess errors)
> UNRESOLVED: 29_atomics/atomic_flag/test_and_set/explicit.cc -std=gnu++17
> compilation failed to produce executable
> FAIL: 29_atomics/atomic_flag/test_and_set/implicit.cc -std=gnu++17 (test
> for excess errors)
> UNRESOLVED: 29_atomics/atomic_flag/test_and_set/implicit.cc -std=gnu++17
> compilation failed to produce executable

For which set of multilibs in that set, do you get these
errors?  I'm guessing -march=armv6s-m, but I'm checking.

> The linker error is:
> undefined reference to `__atomic_test_and_set'

I read that as you're saying you have a multilib combination
where you currently don't emit __sync_synchronize but also
don't emit anything for __atomic_test_and_set.

> Maybe we need a new variant of dg-require-thread-fence ?

Perhaps.  Unless of course, there's a multilib combination
for which you *can* emit the proper atomic spell; missing it
because the need for it, has been hidden!

(At first I thought it was related to caching the
thread-fence property across multilib testing, but I don't
think that was correct.)

> 
> Thanks,
> 
> Christophe
> 
> 
> Ok to commit?

ENOPATCH

brgds, H-P

[PATCH 1/2] testsuite: Add dg-require-atomic-exchange non-atomic code

[Hans-Peter Nilsson]

> From: Christophe Lyon 
> Date: Tue, 3 Oct 2023 15:20:39 +0200

> Maybe we need a new variant of dg-require-thread-fence ?

Yes: many of the dg-require-thread-fence users need
something stronger.  Tested arm-eabi together with the next
patch (2/2) with
RUNTESTFLAGS=--target_board=arm-sim/-mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto\
conformance.exp=29_atomics/\*

(Incidentally, in the patch context is seen
dg-require-atomic-builtins which is a misnomer: it should
rather be named "dg-require-lock-atomic-builtins-free".)

Ok to commit?

-- >8 --
Some targets (armv6) support inline atomic load and store,
i.e. dg-require-thread-fence matches, but not atomic like
atomic exchange.  This directive will replace uses of
dg-require-thread-fence where an atomic exchange operation
is actually used.

* testsuite/lib/dg-options.exp (dg-require-atomic-exchange): New proc.
* testsuite/lib/libstdc++.exp (check_v3_target_atomic_exchange): Ditto.
---
 libstdc++-v3/testsuite/lib/dg-options.exp |  9 ++
 libstdc++-v3/testsuite/lib/libstdc++.exp  | 35 +++
 2 files changed, 44 insertions(+)

diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
b/libstdc++-v3/testsuite/lib/dg-options.exp
index 84ad0c65330b..b13c2f244c63 100644
--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -133,6 +133,15 @@ proc dg-require-thread-fence { args } {
 return
 }
 
+proc dg-require-atomic-exchange { args } {
+if { ![ check_v3_target_atomic_exchange ] } {
+   upvar dg-do-what dg-do-what
+   set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
+   return
+}
+return
+}
+
 proc dg-require-atomic-builtins { args } {
 if { ![ check_v3_target_atomic_builtins ] } {
upvar dg-do-what dg-do-what
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 608056e5068e..481f81711074 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1221,6 +1221,41 @@ proc check_v3_target_thread_fence { } {
 }]
 }
 
+proc check_v3_target_atomic_exchange { } {
+return [check_v3_target_prop_cached et_atomic_exchange {
+   global cxxflags
+   global DEFAULT_CXXFLAGS
+
+   # Set up and link a C++11 test program that depends
+   # on atomic exchange be available for "int".
+   set src atomic_exchange[pid].cc
+
+   set f [open $src "w"]
+   puts $f "
+int i, j, k;
+   int main() {
+   __atomic_exchange (&i, &j, &k, __ATOMIC_SEQ_CST);
+   return 0;
+   }"
+   close $f
+
+   set cxxflags_saved $cxxflags
+   set cxxflags "$cxxflags $DEFAULT_CXXFLAGS -Werror -std=gnu++11"
+
+   set lines [v3_target_compile $src /dev/null executable ""]
+   set cxxflags $cxxflags_saved
+   file delete $src
+
+   if [string match "" $lines] {
+   # No error message, linking succeeded.
+   return 1
+   } else {
+   verbose "check_v3_target_atomic_exchange: compilation failed" 2
+   return 0
+   }
+}]
+}
+
 # Return 1 if atomics_bool and atomic_int are always lock-free, 0 otherwise.
 proc check_v3_target_atomic_builtins { } {
 return [check_v3_target_prop_cached et_atomic_builtins {
-- 
2.30.2


> 
> Thanks,
> 
> Christophe
> 
> 
> Ok to commit?
> >
> > -- >8 --
> > Make __atomic_test_and_set consistent with other __atomic_ and __sync_
> > builtins: call a matching library function instead of emitting
> > non-atomic code when the target has no direct insn support.
> >
> > There's special-case code handling targetm.atomic_test_and_set_trueval
> > != 1 trying a modified maybe_emit_sync_lock_test_and_set.  Previously,
> > if that worked but its matching emit_store_flag_force returned NULL,
> > we'd segfault later on.  Now that the caller handles NULL, gcc_assert
> > here instead.
> >
> > While the referenced PR:s are ARM-specific, the issue is general.
> >
> > PR target/107567
> > PR target/109166
> > * builtins.cc (expand_builtin) :
> > Handle failure from expand_builtin_atomic_test_and_set.
> > * optabs.cc (expand_atomic_test_and_set): When all attempts fail to
> > generate atomic code through target support, return NULL
> > instead of emitting non-atomic code.  Also, for code handling
> > targetm.atomic_test_and_set_trueval != 1, gcc_assert result
> > from calling emit_store_flag_force instead of returning NULL.
> > ---
> >  gcc/builtins.cc |  5 -
> >  gcc/optabs.cc   | 22 +++---
> >  2 files changed, 11 insertions(+), 16 deletions(-)
> >
> > diff --git a/gcc/builtins.cc b/gcc/builtins.cc
> > index 6e4274bb2a4e..40dfd36a3197 100644
> > --- a/gcc/builtins.cc
> > +++ b/gcc/builtins.cc
> > @@ -8387,7 +8387,10 @@ expand_builtin (tree exp, rtx target, rtx
> > subtarget, machine_mode mode,
> >break;
> >
> >  case BUILT_IN_ATOMIC

[PATCH 2/2] testsuite: Replace many dg-require-thread-fence with dg-require-atomic-exchange

[Hans-Peter Nilsson]

> From: Christophe Lyon 
> Date: Tue, 3 Oct 2023 15:20:39 +0200

> The patch passed almost all our CI configurations, except arm-eabi when
> testing with
>  -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
> where is causes these failures:
> FAIL: 29_atomics/atomic_flag/clear/1.cc -std=gnu++17 (test for excess
> errors)
> UNRESOLVED: 29_atomics/atomic_flag/clear/1.cc -std=gnu++17 compilation
> failed to produce executable
> FAIL: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++20 (test for
> excess errors)
> UNRESOLVED: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++20
> compilation failed to produce executable
> FAIL: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++26 (test for
> excess errors)
> UNRESOLVED: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++26
> compilation failed to produce executable
> FAIL: 29_atomics/atomic_flag/test_and_set/explicit.cc -std=gnu++17 (test
> for excess errors)
> UNRESOLVED: 29_atomics/atomic_flag/test_and_set/explicit.cc -std=gnu++17
> compilation failed to produce executable
> FAIL: 29_atomics/atomic_flag/test_and_set/implicit.cc -std=gnu++17 (test
> for excess errors)
> UNRESOLVED: 29_atomics/atomic_flag/test_and_set/implicit.cc -std=gnu++17
> compilation failed to produce executable
> 
> The linker error is:
> undefined reference to `__atomic_test_and_set'

Here's 2/2, fixing those regressions by, after code
inspection, gating those test-case users of
dg-require-thread-fence that actually use not just
atomic-load/store functionality, but a form of
compare-exchange, including the test-and-set cases listed
above as testsuite regressions.  That neatly includes the
regressions above.

Again, other libstdc++ test-cases should likely also use
this gate, from what I see of "undefined references" in
libstdc++.log.

Tested together with 1/2.
Ok to commit?

(N.B. there was a stray suffix "non-atomic code" in the
subject of 1/2; that's just a typo which will not be
committed.)

-- >8 --
These tests actually use a form of atomic exchange, not just
atomic loading and storing.  Some target have the latter,
but not the former, yielding linker errors for missing
library functions (and not supported by libatomic).

This change is just for existing uses of
dg-require-thread-fence.  It does not fix any other tests
that should also be gated on dg-require-atomic-exchange.

* testsuite/29_atomics/atomic/compare_exchange_padding.cc,
testsuite/29_atomics/atomic_flag/clear/1.cc,
testsuite/29_atomics/atomic_flag/cons/value_init.cc,
testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc,
testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc,
testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc,
testsuite/29_atomics/atomic_ref/generic.cc,
testsuite/29_atomics/atomic_ref/integral.cc,
testsuite/29_atomics/atomic_ref/pointer.cc: Replace
dg-require-thread-fence with dg-require-atomic-exchange.
---
 .../testsuite/29_atomics/atomic/compare_exchange_padding.cc | 2 +-
 libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc| 2 +-
 .../testsuite/29_atomics/atomic_flag/cons/value_init.cc | 2 +-
 .../testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc   | 2 +-
 .../testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc   | 2 +-
 .../testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc | 2 +-
 libstdc++-v3/testsuite/29_atomics/atomic_ref/generic.cc | 2 +-
 libstdc++-v3/testsuite/29_atomics/atomic_ref/integral.cc| 2 +-
 libstdc++-v3/testsuite/29_atomics/atomic_ref/pointer.cc | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git 
a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
index 01f7475631e6..14698bb82456 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
@@ -1,5 +1,5 @@
 // { dg-do run { target c++20 } }
-// { dg-require-thread-fence "" }
+// { dg-require-atomic-exchange "" }
 // { dg-add-options libatomic }
 
 #include 
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
index 89ed381fe057..0d8a11899ef1 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
@@ -1,5 +1,5 @@
 // { dg-do run { target c++11 } }
-// { dg-require-thread-fence "" }
+// { dg-require-atomic-exchange "" }
 
 // Copyright (C) 2009-2023 Free Software Foundation, Inc.
 //
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
index f3f38b54dbcd..f95818532107 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons

Re: [PATCH 2/2] testsuite: Replace many dg-require-thread-fence with dg-require-atomic-exchange

[Hans-Peter Nilsson]

> From: Jonathan Wakely 
> Date: Wed, 4 Oct 2023 09:29:43 +0100

> The new dg-require proc checks for __atomic_exchange, which is not the
> same as compare-exchange, and not the same as test-and-set on
> atomic_flag. Does it just happen to be true for arm that the presence
> of __atomic_exchange also implies the other atomic operations?

I missed pointing out that if the target implements
something that emits actual insns for __atomic_exchange
(and/or __atomic_compare_exchange), it has also implemented
test-and-set.  Cf. optabs.cc:expand_atomic_test_and_set (at
r14-4395-g027a94cf32be0b).

Similarly a insn-level __atomic_compare_exchange
implementation (atomic_compare_and_swapM) also does it for
__atomic_exchange.

> The new proc also only tests it for int, which presumably means none
> of these tests rely on atomics for long long being present. Some of
> the tests use atomics on pointers, which should work for ILP32 targets
> if atomics work on int, but the new dg-require-atomic-exchange isn't
> sufficient to check that it will work for pointers on LP64 targets.

Right, I'll amend to test a uintptr_t...

> Maybe it happens to work today for the targets where we have issues,
> but we seem to be assuming that there will be no LP64 targets where
> these atomics are absent for 64-bit pointers. Are there supported
> risc-v ISA subsets where that isn't true?

...but generally, I'd like to leave future amendments like
that to the Next Guy, just like the Previous Guy left
dg-require-thread-fence for me (us) to split up.  But,
perhaps we can prepare for such amendments by giving it a
more specific name: suggesting
dg-require-atomic-cmpxchg-word (bikeshedding opportunity),
testing __atomic_compare_exchange.

IOW, I don't think we should make a distinction, looking for
other operations and sizes at this time.

> And we're assuming that
> __atomic_exchange being present implies all other ops are present,
> which seems like a bad assumption to me. I would be more confident
> testing for __atomic_compare_exchange, because with a wait-free CAS
> you can implement any other atomic operation, but the same isn't true
> for __atomic_exchange.

Yes, I switched them around.

New version coming up.

brgds, H-P

[PATCH v2 1/2] testsuite: Add dg-require-atomic-cmpxchg-word

[Hans-Peter Nilsson]

> From: Hans-Peter Nilsson 
> Date: Wed, 4 Oct 2023 17:15:28 +0200

> New version coming up.

Using pointer-sized int instead of int,
__atomic_compare_exchange instead of __atomic_exchange,
renamed to atomic-cmpxchg-word from atomic-exchange, and
updating a comment that already seemed reasonably well
placed.

Tested as with v1 1/2.

Ok to commit?

-- >8 --
Some targets (armv6-m) support inline atomic load and store,
i.e. dg-require-thread-fence matches, but not atomic operations like
compare and exchange.

This directive can be used to replace uses of dg-require-thread-fence
where an atomic operation is actually used.

* testsuite/lib/dg-options.exp (dg-require-atomic-cmpxchg-word):
New proc.
* testsuite/lib/libstdc++.exp (check_v3_target_atomic_cmpxchg_word):
Ditto.
---
 libstdc++-v3/testsuite/lib/dg-options.exp |  9 ++
 libstdc++-v3/testsuite/lib/libstdc++.exp  | 37 +++
 2 files changed, 46 insertions(+)

diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
b/libstdc++-v3/testsuite/lib/dg-options.exp
index 84ad0c65330b..850442b6b7c1 100644
--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -133,6 +133,15 @@ proc dg-require-thread-fence { args } {
 return
 }
 
+proc dg-require-atomic-cmpxchg-word { args } {
+if { ![ check_v3_target_atomic_cmpxchg_word ] } {
+   upvar dg-do-what dg-do-what
+   set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
+   return
+}
+return
+}
+
 proc dg-require-atomic-builtins { args } {
 if { ![ check_v3_target_atomic_builtins ] } {
upvar dg-do-what dg-do-what
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 608056e5068e..4bedb36dc6f9 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1221,6 +1221,43 @@ proc check_v3_target_thread_fence { } {
 }]
 }
 
+proc check_v3_target_atomic_cmpxchg_word { } {
+return [check_v3_target_prop_cached et_atomic_cmpxchg_word {
+   global cxxflags
+   global DEFAULT_CXXFLAGS
+
+   # Set up and link a C++11 test program that depends on
+   # atomic-compare-exchange being available for a pointer-sized
+   # integer.  It should be sufficient as gcc can derive all
+   # other operations when a target implements this operation.
+   set src atomic_cmpxchg_word[pid].cc
+
+   set f [open $src "w"]
+   puts $f "
+   __UINTPTR_TYPE__ i, j, k;
+   int main() {
+   __atomic_compare_exchange (&i, &j, &k, 1, __ATOMIC_SEQ_CST, 
__ATOMIC_SEQ_CST);
+   return 0;
+   }"
+   close $f
+
+   set cxxflags_saved $cxxflags
+   set cxxflags "$cxxflags $DEFAULT_CXXFLAGS -Werror -std=gnu++11"
+
+   set lines [v3_target_compile $src /dev/null executable ""]
+   set cxxflags $cxxflags_saved
+   file delete $src
+
+   if [string match "" $lines] {
+   # No error message, linking succeeded.
+   return 1
+   } else {
+   verbose "check_v3_target_atomic_cmpxchg_word: compilation failed" 2
+   return 0
+   }
+}]
+}
+
 # Return 1 if atomics_bool and atomic_int are always lock-free, 0 otherwise.
 proc check_v3_target_atomic_builtins { } {
 return [check_v3_target_prop_cached et_atomic_builtins {
-- 
2.30.2

[PATCH v2 2/2] testsuite: Replace many dg-require-thread-fence with dg-require-atomic-cmpxchg-word

[Hans-Peter Nilsson]

s/atomic-exchange/atomic-cmpxchg-word/g.
Tested as v1.

Ok to commit?
-- >8 --
These tests actually use a form of atomic compare and exchange
operation, not just atomic loading and storing.  Some targets (not
supported by e.g. libatomic) have atomic loading and storing, but not
compare and exchange, yielding linker errors for missing library
functions.

This change is just for existing uses of
dg-require-thread-fence.  It does not fix any other tests
that should also be gated on dg-require-atomic-cmpxchg-word.

* testsuite/29_atomics/atomic/compare_exchange_padding.cc,
testsuite/29_atomics/atomic_flag/clear/1.cc,
testsuite/29_atomics/atomic_flag/cons/value_init.cc,
testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc,
testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc,
testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc,
testsuite/29_atomics/atomic_ref/generic.cc,
testsuite/29_atomics/atomic_ref/integral.cc,
testsuite/29_atomics/atomic_ref/pointer.cc: Replace
dg-require-thread-fence with dg-require-atomic-cmpxchg-word.
---
 .../testsuite/29_atomics/atomic/compare_exchange_padding.cc | 2 +-
 libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc| 2 +-
 .../testsuite/29_atomics/atomic_flag/cons/value_init.cc | 2 +-
 .../testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc   | 2 +-
 .../testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc   | 2 +-
 .../testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc | 2 +-
 libstdc++-v3/testsuite/29_atomics/atomic_ref/generic.cc | 2 +-
 libstdc++-v3/testsuite/29_atomics/atomic_ref/integral.cc| 2 +-
 libstdc++-v3/testsuite/29_atomics/atomic_ref/pointer.cc | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git 
a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
index 01f7475631e6..859629e625f8 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
@@ -1,5 +1,5 @@
 // { dg-do run { target c++20 } }
-// { dg-require-thread-fence "" }
+// { dg-require-atomic-cmpxchg-word "" }
 // { dg-add-options libatomic }
 
 #include 
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
index 89ed381fe057..2e154178dbd7 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
@@ -1,5 +1,5 @@
 // { dg-do run { target c++11 } }
-// { dg-require-thread-fence "" }
+// { dg-require-atomic-cmpxchg-word "" }
 
 // Copyright (C) 2009-2023 Free Software Foundation, Inc.
 //
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
index f3f38b54dbcd..6439873be133 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
@@ -16,7 +16,7 @@
 // .
 
 // { dg-do run { target c++20 } }
-// { dg-require-thread-fence "" }
+// { dg-require-atomic-cmpxchg-word "" }
 
 #include 
 #include 
diff --git 
a/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc
index 6f723eb5f4e7..6cb1ae2b6dda 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc
@@ -1,5 +1,5 @@
 // { dg-do run { target c++11 } }
-// { dg-require-thread-fence "" }
+// { dg-require-atomic-cmpxchg-word "" }
 
 // Copyright (C) 2008-2023 Free Software Foundation, Inc.
 //
diff --git 
a/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc
index 6f723eb5f4e7..6cb1ae2b6dda 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc
@@ -1,5 +1,5 @@
 // { dg-do run { target c++11 } }
-// { dg-require-thread-fence "" }
+// { dg-require-atomic-cmpxchg-word "" }
 
 // Copyright (C) 2008-2023 Free Software Foundation, Inc.
 //
diff --git 
a/libstdc++-v3/testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc
index 2a3d1d468c22..25ccd2e94336 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc
@@ -1,5 +1,5 @@
 // { dg-do run { target c++20 } }
-// { dg-require-thread-fence "" }
+// { dg-require-atomic-cmpxchg-word "" }
 // { dg-add-options libatomic }
 
 #include 
diff -

Ping: [PATCH v2 1/2] testsuite: Add dg-require-atomic-cmpxchg-word

[Hans-Peter Nilsson]

Ping.

> From: Hans-Peter Nilsson 
> Date: Wed, 4 Oct 2023 19:04:55 +0200
> 
> > From: Hans-Peter Nilsson 
> > Date: Wed, 4 Oct 2023 17:15:28 +0200
> 
> > New version coming up.
> 
> Using pointer-sized int instead of int,
> __atomic_compare_exchange instead of __atomic_exchange,
> renamed to atomic-cmpxchg-word from atomic-exchange, and
> updating a comment that already seemed reasonably well
> placed.
> 
> Tested as with v1 1/2.
> 
> Ok to commit?
> 
> -- >8 --
> Some targets (armv6-m) support inline atomic load and store,
> i.e. dg-require-thread-fence matches, but not atomic operations like
> compare and exchange.
> 
> This directive can be used to replace uses of dg-require-thread-fence
> where an atomic operation is actually used.
> 
>   * testsuite/lib/dg-options.exp (dg-require-atomic-cmpxchg-word):
>   New proc.
>   * testsuite/lib/libstdc++.exp (check_v3_target_atomic_cmpxchg_word):
>   Ditto.
> ---
>  libstdc++-v3/testsuite/lib/dg-options.exp |  9 ++
>  libstdc++-v3/testsuite/lib/libstdc++.exp  | 37 +++
>  2 files changed, 46 insertions(+)
> 
> diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
> b/libstdc++-v3/testsuite/lib/dg-options.exp
> index 84ad0c65330b..850442b6b7c1 100644
> --- a/libstdc++-v3/testsuite/lib/dg-options.exp
> +++ b/libstdc++-v3/testsuite/lib/dg-options.exp
> @@ -133,6 +133,15 @@ proc dg-require-thread-fence { args } {
>  return
>  }
>  
> +proc dg-require-atomic-cmpxchg-word { args } {
> +if { ![ check_v3_target_atomic_cmpxchg_word ] } {
> + upvar dg-do-what dg-do-what
> + set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
> + return
> +}
> +return
> +}
> +
>  proc dg-require-atomic-builtins { args } {
>  if { ![ check_v3_target_atomic_builtins ] } {
>   upvar dg-do-what dg-do-what
> diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
> b/libstdc++-v3/testsuite/lib/libstdc++.exp
> index 608056e5068e..4bedb36dc6f9 100644
> --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> +++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
> @@ -1221,6 +1221,43 @@ proc check_v3_target_thread_fence { } {
>  }]
>  }
>  
> +proc check_v3_target_atomic_cmpxchg_word { } {
> +return [check_v3_target_prop_cached et_atomic_cmpxchg_word {
> + global cxxflags
> + global DEFAULT_CXXFLAGS
> +
> + # Set up and link a C++11 test program that depends on
> + # atomic-compare-exchange being available for a pointer-sized
> + # integer.  It should be sufficient as gcc can derive all
> + # other operations when a target implements this operation.
> + set src atomic_cmpxchg_word[pid].cc
> +
> + set f [open $src "w"]
> + puts $f "
> + __UINTPTR_TYPE__ i, j, k;
> + int main() {
> + __atomic_compare_exchange (&i, &j, &k, 1, __ATOMIC_SEQ_CST, 
> __ATOMIC_SEQ_CST);
> + return 0;
> + }"
> + close $f
> +
> + set cxxflags_saved $cxxflags
> + set cxxflags "$cxxflags $DEFAULT_CXXFLAGS -Werror -std=gnu++11"
> +
> + set lines [v3_target_compile $src /dev/null executable ""]
> + set cxxflags $cxxflags_saved
> + file delete $src
> +
> + if [string match "" $lines] {
> + # No error message, linking succeeded.
> + return 1
> + } else {
> + verbose "check_v3_target_atomic_cmpxchg_word: compilation failed" 2
> + return 0
> + }
> +}]
> +}
> +
>  # Return 1 if atomics_bool and atomic_int are always lock-free, 0 otherwise.
>  proc check_v3_target_atomic_builtins { } {
>  return [check_v3_target_prop_cached et_atomic_builtins {
> -- 
> 2.30.2
> 

Ping: [PATCH v2 2/2] testsuite: Replace many dg-require-thread-fence with dg-require-atomic-cmpxchg-word

[Hans-Peter Nilsson]

Ping.

> From: Hans-Peter Nilsson 
> Date: Wed, 4 Oct 2023 19:08:16 +0200
> 
> s/atomic-exchange/atomic-cmpxchg-word/g.
> Tested as v1.
> 
> Ok to commit?
> -- >8 --
> These tests actually use a form of atomic compare and exchange
> operation, not just atomic loading and storing.  Some targets (not
> supported by e.g. libatomic) have atomic loading and storing, but not
> compare and exchange, yielding linker errors for missing library
> functions.
> 
> This change is just for existing uses of
> dg-require-thread-fence.  It does not fix any other tests
> that should also be gated on dg-require-atomic-cmpxchg-word.
> 
>   * testsuite/29_atomics/atomic/compare_exchange_padding.cc,
>   testsuite/29_atomics/atomic_flag/clear/1.cc,
>   testsuite/29_atomics/atomic_flag/cons/value_init.cc,
>   testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc,
>   testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc,
>   testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc,
>   testsuite/29_atomics/atomic_ref/generic.cc,
>   testsuite/29_atomics/atomic_ref/integral.cc,
>   testsuite/29_atomics/atomic_ref/pointer.cc: Replace
>   dg-require-thread-fence with dg-require-atomic-cmpxchg-word.
> ---
>  .../testsuite/29_atomics/atomic/compare_exchange_padding.cc | 2 +-
>  libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc| 2 +-
>  .../testsuite/29_atomics/atomic_flag/cons/value_init.cc | 2 +-
>  .../testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc   | 2 +-
>  .../testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc   | 2 +-
>  .../testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc | 2 +-
>  libstdc++-v3/testsuite/29_atomics/atomic_ref/generic.cc | 2 +-
>  libstdc++-v3/testsuite/29_atomics/atomic_ref/integral.cc| 2 +-
>  libstdc++-v3/testsuite/29_atomics/atomic_ref/pointer.cc | 2 +-
>  9 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git 
> a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc 
> b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> index 01f7475631e6..859629e625f8 100644
> --- a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> +++ b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> @@ -1,5 +1,5 @@
>  // { dg-do run { target c++20 } }
> -// { dg-require-thread-fence "" }
> +// { dg-require-atomic-cmpxchg-word "" }
>  // { dg-add-options libatomic }
>  
>  #include 
> diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc 
> b/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
> index 89ed381fe057..2e154178dbd7 100644
> --- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
> +++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
> @@ -1,5 +1,5 @@
>  // { dg-do run { target c++11 } }
> -// { dg-require-thread-fence "" }
> +// { dg-require-atomic-cmpxchg-word "" }
>  
>  // Copyright (C) 2009-2023 Free Software Foundation, Inc.
>  //
> diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc 
> b/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
> index f3f38b54dbcd..6439873be133 100644
> --- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
> +++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
> @@ -16,7 +16,7 @@
>  // <http://www.gnu.org/licenses/>.
>  
>  // { dg-do run { target c++20 } }
> -// { dg-require-thread-fence "" }
> +// { dg-require-atomic-cmpxchg-word "" }
>  
>  #include 
>  #include 
> diff --git 
> a/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc 
> b/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc
> index 6f723eb5f4e7..6cb1ae2b6dda 100644
> --- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc
> +++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc
> @@ -1,5 +1,5 @@
>  // { dg-do run { target c++11 } }
> -// { dg-require-thread-fence "" }
> +// { dg-require-atomic-cmpxchg-word "" }
>  
>  // Copyright (C) 2008-2023 Free Software Foundation, Inc.
>  //
> diff --git 
> a/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc 
> b/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc
> index 6f723eb5f4e7..6cb1ae2b6dda 100644
> --- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc
> +++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc
> @@ -1,5 +1,5 @@
>  // { dg-do run { target c++11 } }
> -// { dg-require-thre

Re: [RFC] expr: don't clear SUBREG_PROMOTED_VAR_P flag for a promoted subreg [target/111466]

[Hans-Peter Nilsson]

> From: Vineet Gupta 
> Date: Thu, 28 Sep 2023 14:43:41 -0700

Please forgive my daftness, but...

> ```
> foo2:
>   sext.w  a6,a1 <-- this goes away
>   beq a1,zero,.L4
>   li  a5,0
>   li  a0,0
> .L3:
>   addwa4,a2,a5
>   addwa5,a3,a5
>   addwa0,a4,a0
>   bltua5,a6,.L3
>   ret
> .L4:
>   li  a0,0
>   ret
> ```

...if your patch gets rid of that sign-extension above...

> diff --git a/gcc/testsuite/gcc.target/riscv/pr111466.c 
> b/gcc/testsuite/gcc.target/riscv/pr111466.c
> new file mode 100644
> index ..007792466a51
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/pr111466.c
> @@ -0,0 +1,15 @@
> +/* Simplified varaint of gcc.target/riscv/zba-adduw.c.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gc_zba_zbs -mabi=lp64" } */
> +/* { dg-skip-if "" { *-*-* } { "-O0" } } */
> +
> +int foo2(int unused, int n, unsigned y, unsigned delta){
> +  int s = 0;
> +  unsigned int x = 0;
> +  for (;x +s += x+y;
> +  return s;
> +}
> +
> +/* { dg-final { scan-assembler "\msext\M" } } */

...then why test for the presence of a sign-extension
instruction in the test-case?

IOW, shouldn't that be a scan-assember-not?

(What am I missing?)

brgds, H-P
PS. sorry I missed the Cauldron this year.  Hope to see you all next year!

Re: [committed] RISC-V: Fix INSN costing and more zicond tests

[Hans-Peter Nilsson]

> Date: Fri, 29 Sep 2023 16:37:21 -0600
> From: Jeff Law 

> So this ends up looking a lot like the bits that I had to revert several 
> weeks ago :-)
> 
> The core issue we have is given an INSN the generic code will cost the 
> SET_SRC and SET_DEST and sum them.  But that's far from ideal on a RISC 
> target.
> 
> For a register destination, the cost can be determined be looking at 
> just the SET_SRC.  Which is precisely what this patch does.  When the 
> outer code is an INSN and we're presented with a SET we take one of two 
> paths.
> 
> If the destination is a register, then we recurse just on the SET_SRC 
> and we're done.  Otherwise we fall back to the existing code which sums 
> the cost of the SET_SRC and SET_DEST.

Ackchyually...  that "otherwise" happens for calls to
set_rtx_cost (et al), but not calls to insn_cost.

IOW, with that patch, it seems you're mimicking insn_cost
behavior also for set_rtx_cost (et al).  You're likely aware
of this, but when seeing these target cost functions tweaked
for reasons that appear somewhat empirical, I felt compelled
to point out the related rabbit-hole.

While I'm ranting, these slightly different cost api:s,
somewhat arbitrarily, (or empirically) picked by callers, is
a problem by itself.  Not to mention that the default use of
set_rtx_cost means you get hit by another problem; the
default cost of 0 for registers is also a magic number to
pattern_cost to set the cost to INSN_COSTS (1).

The default insn_cost implementation, which RISC-V uses as
opposed to implementing the TARGET_INSN_COST hook, only
looks at the SET_SRC for calls to insn_cost for single-sets.
See pattern_cost.  I believe that's a bug.  Fixing that was
attempted in 2016 (by Bernd S.), a patch which was later
reverted: cf. commits r7-4866-g334442f282a9d6 and
r7-4930-g03612f25277590.  Hence rabbit-hole.  (And no,
implementing TARGET_INSN_COST doesn't automatically fix
things.  Too much of the gcc middle-end appears tuned to the
default behavior.)

Sorry for the rant; have a nice day and a better week-end.

>  That fallback path isn't great 
> and probably could be further improved (just costing SET_DEST in that 
> case is probably quite reasonable).
> 
> The difference between this version and the bits that slipped through by 
> accident several weeks ago is that old version mis-used the API due to a 
> thinko on my part.
> 
> This tightens up various zicond tests to avoid undesirable matching.
> 
> This has been tested on rv64gc -- the only difference it makes on the 
> testsuite is the new tests (included in this patch) flip from failing to 
> passing.
> 
> Pushed to the trunk.
> 
> Jeff

brgds, H-P

Re: [PATCH] aarch64: testsuite: symbol-range compile only

[Hans-Peter Nilsson]

On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote:
> +proc check_effective_target_two_plus_gigs { } {
> +return [check_no_compiler_messages two_plus_gigs executable {
> + int dummy[0x8000];

Don't you mean "char" as in "char dummy[0x8000]"?

Or else the effective predicate is effectively eight_plus_gigs
(for targets where sizeof(int) == 4, i.e. most).

brgds, H-P

Re: [PATCH v2 1/7] config: use $EGREP instead of egrep

[Hans-Peter Nilsson]

On Mon, 27 Jun 2022, Xi Ruoyao via Gcc-patches wrote:
> egrep has been deprecated in favor of grep -E for a long time, and the
> next GNU grep release (3.8 or 4.0) will print a warning if egrep is used.
> Unfortunately, old hosts with non-GNU grep may lack the support for -E
> option.  Use AC_PROG_EGREP and $EGREP variable so we'll work fine on
> both old and new platforms.
>
> ChangeLog:
>
>   * configure.ac: Call AC_PROG_EGREP, and use $EGREP instead of
>   egrep.

Nit of the day:

> diff --git a/config/lib-link.m4 b/config/lib-link.m4
> index 20e281fd323..5bbbd999de0 100644
> --- a/config/lib-link.m4
> +++ b/config/lib-link.m4
> @@ -99,8 +99,10 @@ AC_DEFUN([AC_LIB_RPATH],
>AC_REQUIRE([AC_LIB_PROG_LD])dnl we use $LD, $with_gnu_ld
>AC_REQUIRE([AC_CANONICAL_HOST]) dnl we use $host
>AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT]) dnl we use $ac_aux_dir
> +  AC_REQUIRE([AC_PROG_EGREP]) dnl we use $GREP

Shouldn't that be "we use $EGREP"?

brgds, H-P

Re: Mips: Fix kernel_stat structure size

[Hans-Peter Nilsson]

On Fri, 1 Jul 2022, Dimitrije Milosevic wrote:

> Fix kernel_stat structure size for non-Android 32-bit Mips.
> LLVM currently has this value for the kernel_stat structure size,
> as per compiler-rt/lib/sanitizer-common/sanitizer_platform_limits_posix.h.
> This also resolves one of the build issues for non-Android 32-bit Mips.

I insist that PR105614 comment #7 is the way to go, i.e. fix
the merge error, avoiding the faulty include that it
reintroduced.  Was this tested on O32?

>
> libsanitizer/ChangeLog:
>
> * sanitizer_common/sanitizer_platform_limits_posix.h: Fix
> kernel_stat structure size for non-Android 32-bit Mips.
>
> ---
>
>  libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
> b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> index 89772a7e5c0..62a99035db3 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> @@ -83,7 +83,7 @@ const unsigned struct_kernel_stat64_sz = 104;
>  #elif defined(__mips__)
>  const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID
> ? FIRST_32_SECOND_64(104, 128)
> -   : FIRST_32_SECOND_64(144, 216);
> +   : FIRST_32_SECOND_64(160, 216);
>  const unsigned struct_kernel_stat64_sz = 104;
>  #elif defined(__s390__) && !defined(__s390x__)
>  const unsigned struct_kernel_stat_sz = 64;
>
> ---

Re: Mips: Fix kernel_stat structure size

[Hans-Peter Nilsson]

On Sat, 9 Jul 2022, Xi Ruoyao wrote:

> On Fri, 2022-07-08 at 21:42 -0400, Hans-Peter Nilsson wrote:
> > On Fri, 1 Jul 2022, Dimitrije Milosevic wrote:
> >
> > > Fix kernel_stat structure size for non-Android 32-bit Mips.
> > > LLVM currently has this value for the kernel_stat structure size,
> > > as per compiler-rt/lib/sanitizer-
> > > common/sanitizer_platform_limits_posix.h.
> > > This also resolves one of the build issues for non-Android 32-bit
> > > Mips.
> >
> > I insist that PR105614 comment #7 is the way to go, i.e. fix
> > the merge error, avoiding the faulty include that it
> > reintroduced.? Was this tested on O32?
>
> I'm pretty sure it is *not* the way to go.
>
> Sanitizer does not really intercept system call.  It intercepts libc
> stat() or lstat() etc. calls.  So you need to keep struct_kernel_stat_sz
> same as the size of struct stat in libc, i. e. "the size of buffer which
> *libc* stat()-like functions writing into".
>
> The "kernel_" in the name is just misleading.

You make a sound argument, and I just refer to my old commit
9f943b2446f2d0a.  Either way, the proof is in the pussing: was
this tested for O32 or not?

> And, if you still think it should be the way to go, let's submit the
> change to LLVM and get it reviewed properly.

Sorry, I've no longer interest in mips besides I'd like to see
un-broken what I helped getting in a working state (support ASAN
in gcc for mips O32).

brgds, H-P

Re: Mips: Fix kernel_stat structure size

[Hans-Peter Nilsson]

On Tue, 12 Jul 2022, Dimitrije Milosevic wrote:
> Hi Hans-Peter,
> You're right, this is not ok for the O32 ABI. Your change however, broke the 
> functionality
> for the N32 ABI.

That's just not true.  There was no mips support for ASAN in
gcc, hence nothing to break for N32.  Maybe an anachronism?

Or maybe you mean plain backporting to LLVM?  Perhaps it needs
adjustments for their _FILE_OFFSET_BITS=64 builds?  On the other
hand, that struct_kernel_stat_sz shouldn't be affected by that -
unless that's a misnomer or they get the includes wrong - but
then again, the include part was fixed by the patch.  Unless
mis-merged, as in gcc currently.

> AFAIK, the changes like this should go through LLVM first
> (yours didn't),

As I recall, and judging from the mentioned commit, this would
have given them no benefit; no visible error to fix, as they're
always building the runtime with for 64-bit file size.  But yes,
it should have been submitted there eventually.

> so I will send out a review, covering both 32 ABIs, meaning that both O32 and 
> N32 ABIs
> will be working properly.

Very good.  Thank you in advance.

> As for this change, I'm not sure what should be done?
> Should this be committed now, while the LLVM change is cherry-picked once 
> it's committed.
> Best regards,
> Dimitrije Milosevic
>
>
> From: Hans-Peter Nilsson 
> Sent: Saturday, July 9, 2022 4:44 PM
> To: Xi Ruoyao 
> Cc: Dimitrije Milosevic ; Djordje Todorovic 
> ; gcc-patches@gcc.gnu.org 
> 
> Subject: Re: Mips: Fix kernel_stat structure size
> ?
> On Sat, 9 Jul 2022, Xi Ruoyao wrote:
>
> > On Fri, 2022-07-08 at 21:42 -0400, Hans-Peter Nilsson wrote:
> > > On Fri, 1 Jul 2022, Dimitrije Milosevic wrote:
> > >
> > > > Fix kernel_stat structure size for non-Android 32-bit Mips.
> > > > LLVM currently has this value for the kernel_stat structure size,
> > > > as per compiler-rt/lib/sanitizer-
> > > > common/sanitizer_platform_limits_posix.h.
> > > > This also resolves one of the build issues for non-Android 32-bit
> > > > Mips.
> > >
> > > I insist that PR105614 comment #7 is the way to go, i.e. fix
> > > the merge error, avoiding the faulty include that it
> > > reintroduced.? Was this tested on O32?
> >
> > I'm pretty sure it is *not* the way to go.
> >
> > Sanitizer does not really intercept system call.? It intercepts libc
> > stat() or lstat() etc. calls.? So you need to keep struct_kernel_stat_sz
> > same as the size of struct stat in libc, i. e. "the size of buffer which
> > *libc* stat()-like functions writing into".
> >
> > The "kernel_" in the name is just misleading.
>
> You make a sound argument, and I just refer to my old commit
> 9f943b2446f2d0a.? Either way, the proof is in the pussing: was
> this tested for O32 or not?
>
> > And, if you still think it should be the way to go, let's submit the
> > change to LLVM and get it reviewed properly.
>
> Sorry, I've no longer interest in mips besides I'd like to see
> un-broken what I helped getting in a working state (support ASAN
> in gcc for mips O32).
>
> brgds, H-P

Re: [committed] Enable LRA on several ports

[Hans-Peter Nilsson]

On Mon, 1 May 2023, Jeff Law wrote:

> 
> Spurred by Segher's RFC, I went ahead and tested several ports with LRA
> enabled.  Not surprisingly, many failed, but a few built their full set of
> libraries successful and of those a few even ran their testsuites with no
> regressions.  In fact, enabling LRA fixes a small number of failures on the
> iq2000 port.
> 
> This patch converts the ports which built their libraries and have test
> results that are as good as or better than without LRA.There may be minor
> code quality regressions or there may be minor code quality improvements --
> I'm leaving that for the port maintainers to own going forward.

How do you configure your builds?  Perhaps your cross-builds 
exclude C++?  I found that this (r14-383) broke MMIX building 
libstdc++-v3 from that commit up to and including r14-3180.
See commit r14-3187.

Thankfully there was just one single gotcha.  I temporarily 
reverted the LRA change for MMIX so that I can get honest 
repeatable baseline results.  There seems to have been one 
test-case regressing from the LRA switch (PR53948), thus I 
re-enabled LRA for MMIX again.  Sorry for the late reaction.

brgds, H-P

[committed] Disable LRA for MMIX.

[Hans-Peter Nilsson]

Since the change r14-383-gfaf8bea79b6256 "Enable LRA on
several ports", mmix has been broken building libstdc++-v3:

libtool: compile: /obj/./gcc/xgcc -shared-libgcc -B/obj/./gcc
-nostdinc++ -L/obj/mmix/libstdc++-v3/src
-L/obj/mmix/libstdc++-v3/src/.libs
-L/obj/mmix/libstdc++-v3/libsupc++/.libs -nostdinc -B/obj/mmix/newlib/
-isystem /obj/mmix/newlib/targ-include -isystem
/gcctop/newlib/libc/include -B/obj/mmix/libgloss/mmix
-L/obj/mmix/libgloss/libnosys -L/gcctop/libgloss/mmix
-B/home/hp/tmp/mmix230811-00/pre/mmix/bin/
-B/home/hp/tmp/mmix230811-00/pre/mmix/lib/ -isystem
/home/hp/tmp/mmix230811-00/pre/mmix/include -isystem
/home/hp/tmp/mmix230811-00/pre/mmix/sys-include
-I/gcctop/libstdc++-v3/../libgcc -I/obj/mmix/libstdc++-v3/include/mmix
-I/obj/mmix/libstdc++-v3/include -I/gcctop/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=eh_type.lo -g -O2 -c
/gcctop/libstdc++-v3/libsupc++/eh_type.cc -o eh_type.o
/gcctop/libstdc++-v3/libsupc++/eh_terminate.cc: In function 'void
__cxxabiv1::__terminate(std::terminate_handler)':
/gcctop/libstdc++-v3/libsupc++/eh_terminate.cc:53:1: error: unable to
generate reloads for:

   53 | }
  | ^
(insn 31 36 44 4 (parallel [
(unspec_volatile [
(plus:DI (reg/f:DI 253 $253)
(const_int 24 [0x18]))
] 1)
(clobber (reg:DI 275))
(clobber (reg:DI 259 rJ))
]) "/gcctop/libstdc++-v3/libsupc++/eh_terminate.cc":51:3
 discrim 1 63 {*nonlocal_goto_receiver_expanded}
 (expr_list:REG_UNUSED (reg:DI 275)
(expr_list:REG_UNUSED (reg:DI 259 rJ)
(nil
during RTL pass: reload
/gcctop/libstdc++-v3/libsupc++/eh_terminate.cc:53:1:
internal compiler error: in curr_insn_transform, at lra-constraints.cc:4281

This commit temporarily reverts the MMIX part of
r14-383-gfaf8bea79b6256 back to reload.

* config/mmix/mmix.cc: Disable LRA for MMIX.
---
 gcc/config/mmix/mmix.cc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/mmix/mmix.cc b/gcc/config/mmix/mmix.cc
index 347430927499..5160794d9d03 100644
--- a/gcc/config/mmix/mmix.cc
+++ b/gcc/config/mmix/mmix.cc
@@ -274,6 +274,9 @@ static HOST_WIDE_INT mmix_starting_frame_offset (void);
 #undef TARGET_PREFERRED_OUTPUT_RELOAD_CLASS
 #define TARGET_PREFERRED_OUTPUT_RELOAD_CLASS mmix_preferred_output_reload_class
 
+#undef TARGET_LRA_P
+#define TARGET_LRA_P hook_bool_void_false
+
 #undef TARGET_LEGITIMATE_ADDRESS_P
 #define TARGET_LEGITIMATE_ADDRESS_Pmmix_legitimate_address_p
 #undef TARGET_LEGITIMATE_CONSTANT_P
-- 
2.30.2

[committed] MMIX: Handle LRA FP-to-SP-elimination oddity

[Hans-Peter Nilsson]

When LRA is in progress, it can try and validate insns
half-way through frame-pointer (FP) to stack-pointer (SP)
elimination.  Operands have then been substituted where the
offset is from the SP elimination but the register is the
(hard) frame-pointer:

lra-eliminations.cc:lra_eliminate_regs_1:370:
 rtx to = subst_p ? ep->to_rtx : ep->from_rtx;

In this regard reload played nicely.  Unfortunately, the
frame_pointer_operand predicate in mmix/predicates.md barfs
on such an address.  This broke the use of the MMIX
frame_pointer_operand predicate (and the Yf constraint),
used only in the nonlocal_goto_receiver expansion (which is
used in e.g. code generated for C++ "catch").

Force MMIX frame_pointer_operand to accept an FP+offset for
the duration of lra_in_progress.

* config/mmix/predicates.md (frame_pointer_operand): Handle FP+offset
when lra_in_progress.
---
 gcc/config/mmix/predicates.md | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/gcc/config/mmix/predicates.md b/gcc/config/mmix/predicates.md
index 4a9b0177a786..64e77fa92d00 100644
--- a/gcc/config/mmix/predicates.md
+++ b/gcc/config/mmix/predicates.md
@@ -171,4 +171,14 @@ (define_predicate "frame_pointer_operand"
 (match_code "plus")
 (match_code "reg" "0")
 (match_code "const_int" "1")
-(match_test "XEXP (op, 0) == stack_pointer_rtx"
+(ior
+ (match_test "XEXP (op, 0) == stack_pointer_rtx")
+ ;; We can temporarily have a FP+offset here, where we (for FP)
+ ;; accept only FP and the equivalent elimination of SP+offset.
+ ;; See lra_eliminate_regs_1 in lra-eliminations.cc c:a line 370:
+ ;;  "rtx to = subst_p ? ep->to_rtx : ep->from_rtx;"
+ (and
+  (match_test "lra_in_progress")
+  (ior
+   (match_test "XEXP (op, 0) == hard_frame_pointer_rtx")
+   (match_test "XEXP (op, 0) == frame_pointer_rtx")))
-- 
2.30.2

[committed] MMIX: Re-enable LRA

[Hans-Peter Nilsson]

After fixing the one problem for MMIX, there's just one 
test-case regressing between reload and LRA.
-- 8< --

* config/mmix/mmix.cc: Re-enable LRA.
---
 gcc/config/mmix/mmix.cc | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/gcc/config/mmix/mmix.cc b/gcc/config/mmix/mmix.cc
index 5160794d9d03..347430927499 100644
--- a/gcc/config/mmix/mmix.cc
+++ b/gcc/config/mmix/mmix.cc
@@ -274,9 +274,6 @@ static HOST_WIDE_INT mmix_starting_frame_offset (void);
 #undef TARGET_PREFERRED_OUTPUT_RELOAD_CLASS
 #define TARGET_PREFERRED_OUTPUT_RELOAD_CLASS mmix_preferred_output_reload_class
 
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
 #undef TARGET_LEGITIMATE_ADDRESS_P
 #define TARGET_LEGITIMATE_ADDRESS_Pmmix_legitimate_address_p
 #undef TARGET_LEGITIMATE_CONSTANT_P
-- 
2.30.2

[committed] MMIX: Switch to lra_in_progress

[Hans-Peter Nilsson]

This is just a mechanical update.
It fixes no observed problems for LRA.

* config/mmix/predicates.md (mmix_address_operand): Use
lra_in_progress, not reload_in_progress.
---
 gcc/config/mmix/predicates.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/mmix/predicates.md b/gcc/config/mmix/predicates.md
index 64e77fa92d00..3c98f2686aa8 100644
--- a/gcc/config/mmix/predicates.md
+++ b/gcc/config/mmix/predicates.md
@@ -158,7 +158,7 @@ (define_predicate "mmix_reg_or_8bit_operand"
 ;; See also comment above the "*call_real" pattern.
 
 (define_predicate "mmix_address_operand"
-  (if_then_else (match_test "reload_in_progress || reload_completed")
+  (if_then_else (match_test "lra_in_progress || reload_completed")
 (match_test "strict_memory_address_p (Pmode, op)")
 (match_test "memory_address_p (Pmode, op)")))
 
-- 
2.30.2

Re: [PATCH, rs6000] Add two peephole2 patterns for mr. insn

[Hans-Peter Nilsson]

On Tue, 30 May 2023, HAO CHEN GUI via Gcc-patches wrote:

> +++ b/gcc/config/rs6000/rs6000.md
> @@ -7891,6 +7891,36 @@ (define_insn "*mov_internal2"
> (set_attr "dot" "yes")
> (set_attr "length" "4,4,8")])
> 
> +(define_peephole2
> +  [(set (match_operand:CC 2 "cc_reg_operand" "")
> + (compare:CC (match_operand:P 1 "int_reg_operand" "")
> + (const_int 0)))
> +   (set (match_operand:P 0 "int_reg_operand" "")

A random comment from the sideline: I'd suggest to remove the 
(empty) constraints string from your peephole2's.

It can be a matter of port-specific-taste but it seems removing 
them would be consistent with the other peephole2's in 
rs6000.md.

(In this matter, I believe the examples in md.texi are bad.)

brgds, H-P

Re: [PATCH v2] Implement new RTL optimizations pass: fold-mem-offsets.

[Hans-Peter Nilsson]

On Thu, 15 Jun 2023, Manolis Tsamis wrote:

> This is a new RTL pass that tries to optimize memory offset calculations
> by moving them from add immediate instructions to the memory loads/stores.
> For example it can transform this:
> 
>   addi t4,sp,16
>   add  t2,a6,t4
>   shl  t3,t2,1
>   ld   a2,0(t3)
>   addi a2,1
>   sd   a2,8(t2)
> 
> into the following (one instruction less):
> 
>   add  t2,a6,sp
>   shl  t3,t2,1
>   ld   a2,32(t3)
>   addi a2,1
>   sd   a2,24(t2)
> 
> Although there are places where this is done already, this pass is more
> powerful and can handle the more difficult cases that are currently not
> optimized. Also, it runs late enough and can optimize away unnecessary
> stack pointer calculations.

It punts on all "use" insns that are not SET.
Why not use single_set there too?

brgds, H-P

Re: [PATCH v2] Implement new RTL optimizations pass: fold-mem-offsets.

[Hans-Peter Nilsson]

On Sun, 9 Jul 2023, Hans-Peter Nilsson wrote:

> On Thu, 15 Jun 2023, Manolis Tsamis wrote:
> 
> > This is a new RTL pass that tries to optimize memory offset calculations
> > by moving them from add immediate instructions to the memory loads/stores.

> It punts on all "use" insns that are not SET.
> Why not use single_set there too?

Also, I don't see insn costs considered?
(Also: typo "immidiate".)

brgds, H-P

Re: Enable top-level recursive 'autoreconf'

[Hans-Peter Nilsson]

> From: Thomas Schwinge 
> Date: Thu, 19 Oct 2023 12:42:26 +0200

> It's just GCC and Binutils/GDB, or are the top-level files also shared
> with additional projects?

Not sure if that counts as "shared", but I regularly drop
in* newlib to build simulator targets (*-elf, *-newabi).
That's git://sourceware.org/git/newlib-cygwin.git but I
extract tarballs for the merging.

"Drop in" is actually the other way round, starting with a
newlib tarball, so gcc files overwrite newlib ones.

(FWIW, I never drop in binutils like that; they're better
built separately.  "Better" for your long-term sanity.)

brgds, H-P

Re: [PATCH] recog/reload: Remove old UNARY_P operand support

[Hans-Peter Nilsson]

> From: Richard Sandiford 
> Date: Tue, 24 Oct 2023 11:14:20 +0100

> reload and constrain_operands had some old code to look through unary
> operators.  E.g. an operand could be (sign_extend (reg X)), and the
> constraints would match the reg rather than the sign_extend.
> 
> This was previously used by the MIPS port.  But relying on it was a
> recurring source of problems, so Eric and I removed it in the MIPS
> rewrite from ~20 years back.  I don't know of any other port that used it.

The SH did.  I remember this being one of the ugliest warts
of reload.  IIRC, there was a bit of a discourse involving
me and Joern way-back (also IIRC some 20 years ago, at least
before IRA and LRA).  The conclusion was that removing this
misfeature would be ok, as already at that time, there was
no de-facto beneficial effect for sh, likely due to code
rot.  However, no action was taken; no code changed.

Thanks for removing the last(?) bits!

brgds, H-P

Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension

[Hans-Peter Nilsson]

On Fri, 24 Feb 2023, Christoph Muellner wrote:
> diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> index 158e9124c3a..2c684885850 100644
> --- a/gcc/config/riscv/thead.md
> +++ b/gcc/config/riscv/thead.md
> @@ -29,3 +29,14 @@ (define_insn "*th_addsl"
>"th.addsl\t%0,%3,%1,%2"
>[(set_attr "type" "bitmanip")
> (set_attr "mode" "")])
> +
> +;; XTheadBs
> +
> +(define_insn "*th_tst"
> +  [(set (match_operand:X 0 "register_operand" "=r")
> + (zero_extract:X (match_operand:X 1 "register_operand" "r")
> + (const_int 1)
> + (match_operand 2 "immediate_operand" "i")))]

(Here and same elsewhere.)

You're unlikely to get other constant operands in that pattern, 
but FWIW, the actual matching pair for just CONST_INT is 
"const_int_operand" for the predicate and "n" for the 
constraint.  Using the right predicate and constraint will also 
help the generated part of recog be a few nanoseconds faster. ;)

brgds, H-P

Re: [Patch] gcc.c-torture/compile/103818.c: enable for llp64 too

[Hans-Peter Nilsson]

On Sun, 26 Feb 2023, Jonathan Yong via Gcc-patches wrote:

> Patch OK for master branch? I did not see any obvious issues to exclude LLP64
> specifically.

I see "lp64 || lp64" in that patch (which should preferably have 
been sent inline, as it's harder to quote an attached patch, 
QED).  Sending the wrong version?  Don't forget to test it.

brgds, H-P

Re: [Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64

[Hans-Peter Nilsson]

On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote:

> This test is for LP64 only, exclude LLP64 too.
> Patch OK?

I may be confused, but you're not making use of the "llp64" 
effective target, there instead excluding/including lp64 / 
ilp32 in sets that not obviously mean "exclude LLP64".

To wit, how is "! ilp32" -> "lp64" and "ilp32" -> "! lp64" 
expressing "! llp64"?

brgds, H-P

Re: [Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64

[Hans-Peter Nilsson]

On Tue, 28 Feb 2023, Jonathan Yong wrote:

> On 2/28/23 03:06, Hans-Peter Nilsson wrote:
> > 
> > On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote:
> > 
> > > This test is for LP64 only, exclude LLP64 too.
> > > Patch OK?
> > 
> > I may be confused, but you're not making use of the "llp64"
> > effective target, there instead excluding/including lp64 /
> > ilp32 in sets that not obviously mean "exclude LLP64".
> > 
> > To wit, how is "! ilp32" -> "lp64" and "ilp32" -> "! lp64"
> > expressing "! llp64"?
> > 
> > brgds, H-P
> 
> Attached new version, hopefully it is clearer.
> 

Yes, thank you!  (Not an approver; not an approval.)

brgds, H-P

Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension

[Hans-Peter Nilsson]

On Tue, 28 Feb 2023, Christoph Müllner wrote:

> On Sun, Feb 26, 2023 at 12:42 AM Hans-Peter Nilsson  wrote:
> >
> > On Fri, 24 Feb 2023, Christoph Muellner wrote:
> > > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> > > index 158e9124c3a..2c684885850 100644
> > > --- a/gcc/config/riscv/thead.md
> > > +++ b/gcc/config/riscv/thead.md
> > > @@ -29,3 +29,14 @@ (define_insn "*th_addsl"
> > >"th.addsl\t%0,%3,%1,%2"
> > >[(set_attr "type" "bitmanip")
> > > (set_attr "mode" "")])
> > > +
> > > +;; XTheadBs
> > > +
> > > +(define_insn "*th_tst"
> > > +  [(set (match_operand:X 0 "register_operand" "=r")
> > > + (zero_extract:X (match_operand:X 1 "register_operand" "r")
> > > + (const_int 1)
> > > + (match_operand 2 "immediate_operand" "i")))]
> >
> > (Here and same elsewhere.)
> >
> > You're unlikely to get other constant operands in that pattern,
> > but FWIW, the actual matching pair for just CONST_INT is
> > "const_int_operand" for the predicate and "n" for the
> > constraint.  Using the right predicate and constraint will also
> > help the generated part of recog be a few nanoseconds faster. ;)
> 
> Thank you for that comment!
> I think what you mean would look like this:
> 
> (define_insn "*th_tst"
>   [(set (match_operand:X 0 "register_operand" "=r")
> (zero_extract:X (match_operand:X 1 "register_operand" "r")
> (match_operand 3 "const_int_operand" "n")
> (match_operand 2 "immediate_operand" "i")))]

No; misunderstanding.  Keep the (const_int 1) but replace
(match_operand 2 "immediate_operand" "i") with
(match_operand 2 "const_int_operand" "n")

brgds, H-P

Re: [PATCH 4/5] barrier: use int instead of unsigned char for the phase state

[Hans-Peter Nilsson]

On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> ints can be used in futexes. chars can't.

Shouldn't that be an atomic type instead of a bare int then?

> ---
>  libstdc++-v3/include/std/barrier | 21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/barrier 
> b/libstdc++-v3/include/std/barrier
> index e09212dfcb9..ae058bd3dc3 100644
> --- a/libstdc++-v3/include/std/barrier
> +++ b/libstdc++-v3/include/std/barrier
> @@ -70,7 +70,7 @@ It looks different from literature pseudocode for two main 
> reasons:
>
>  */
>
> -  enum class __barrier_phase_t : unsigned char { };
> +  enum class __barrier_phase_t : int { };

brgds, H-P

Re: [PATCH 1/5] std::latch: reduce internal implementation from ptrdiff_t to int

[Hans-Peter Nilsson]

On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:

> On Friday, 26 February 2021 11:31:00 PST Andreas Schwab wrote:
> > On Feb 26 2021, Thiago Macieira wrote:
> > > On Friday, 26 February 2021 10:14:42 PST Andreas Schwab wrote:
> > >> On Feb 26 2021, Thiago Macieira via Gcc-patches wrote:
> > >> > -alignas(__alignof__(ptrdiff_t)) ptrdiff_t _M_a;
> > >> > +alignas(__alignof__(int)) int _M_a;
> > >>
> > >> Futexes must be aligned to 4 bytes.
> > >
> > > Agreed, but doesn't this accomplish that?
> >
> > No.  It uses whatever alignment the type already has, and is an
> > elaborate no-op.
>
> I thought so too when I read the original line. But I expected it was written
> like that for a reason, especially since the same pattern appears in other
> places.
>
> I can change to "alignas(4)" (which is a GCC extension, I believe). Is that
> the correct solution?

IMNSHO make use of the corresponding atomic type.  Then there'd
be no need for separate what's-the-right-align-curse games.

brgds, H-P

Re: [PATCH 1/5] std::latch: reduce internal implementation from ptrdiff_t to int

[Hans-Peter Nilsson]

On Wed, 3 Mar 2021, Jonathan Wakely wrote:
> For int, there shouldn't be any need to force the alignment. I don't
> think any ABI supported by GCC allows int members to be aligned to
> less than __alignof__(int).

(sizeof(int) last)

The CRIS ABI does as in default packed, and ISTR there was some
other gcc port too, but I don't recall whether that (too) had no
(current) Linux port.

brgds, H-P

[PATCH] libstdc++: Tweak timeout for testsuite/std/ranges/iota/max_size_type.cc

[Hans-Peter Nilsson]

A simulator can easily spend more than 10 minutes running this
test-case, and the default timeout is at 5 minutes. Better allow
even slower machines; use 4 as the factor.

Regarding relative runtime numbers (very local; mmixware simulator for
mmix-knuth-mmixware): test01 and test05 finish momentarily; test02 at
about 2 minutes, and test03 about 2m30, but test04 itself runs for
more than 6 minutes and so timed out.

Not sure if it's better to split up this test, as the excessive
runtime may be unintended, but this seemed simplest.

Ok to commit?

libstdc++-v3:
* testsuite/std/ranges/iota/max_size_type.cc: Set
dg-timeout-factor to 4.
---
 libstdc++-v3/testsuite/std/ranges/iota/max_size_type.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libstdc++-v3/testsuite/std/ranges/iota/max_size_type.cc 
b/libstdc++-v3/testsuite/std/ranges/iota/max_size_type.cc
index 983bdfbdaa6c..a52e8e6231aa 100644
--- a/libstdc++-v3/testsuite/std/ranges/iota/max_size_type.cc
+++ b/libstdc++-v3/testsuite/std/ranges/iota/max_size_type.cc
@@ -17,6 +17,7 @@

 // { dg-options "-std=gnu++2a" }
 // { dg-do run { target c++2a } }
+// { dg-timeout-factor 4 }

 #include 
 #include 
-- 
2.20.1

Re: [committed][testsuite] Require non_strict_align in pr94600-{1,3}.c

[Hans-Peter Nilsson]

On Thu, 24 Sep 2020, Tom de Vries wrote:

> Hi,
>
> With the nvptx target, we run into:
> ...
> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(mem/v" 6
> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(set \\(mem/v" 6
> FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(mem/v" 1
> FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(set \\(mem/v" 1
> ...
> The scans attempt to check for volatile stores, but on nvptx we have memcpy
> instead.
>
> This is due to nvptx being a STRICT_ALIGNMENT target, which has the effect
> that the TYPE_MODE for the store target is set to BKLmode in
> compute_record_mode.
>
> Fix the FAILs by requiring effective target non_strict_align.

No, that's wrong.  There's more than that at play; it worked for
the strict-alignment targets where it was tested at the time.

The test is a valuable canary for this kind of bug.  You now
disabled it for strict-alignment targets.

Please revert and add your target specifier instead, if you
don't feel like investigating further.

brgds, H-P

> Tested on nvptx.
>
> Committed to trunk.
>
> Thanks,
> - Tom
>
> [testsuite] Require non_strict_align in pr94600-{1,3}.c
>
> gcc/testsuite/ChangeLog:
>
> 2020-09-24  Tom de Vries  
>
>   * gcc.dg/pr94600-1.c: Require effective target non_strict_align for
>   scan-rtl-dump-times.
>   * gcc.dg/pr94600-3.c: Same.
>
> ---
>  gcc/testsuite/gcc.dg/pr94600-1.c | 4 ++--
>  gcc/testsuite/gcc.dg/pr94600-3.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/pr94600-1.c 
> b/gcc/testsuite/gcc.dg/pr94600-1.c
> index b5913a0939c..38f939a98cb 100644
> --- a/gcc/testsuite/gcc.dg/pr94600-1.c
> +++ b/gcc/testsuite/gcc.dg/pr94600-1.c
> @@ -32,5 +32,5 @@ foo(void)
>  }
>
>  /* The only volatile accesses should be the obvious writes.  */
> -/* { dg-final { scan-rtl-dump-times {\(mem/v} 6 "final" } } */
> -/* { dg-final { scan-rtl-dump-times {\(set \(mem/v} 6 "final" } } */
> +/* { dg-final { scan-rtl-dump-times {\(mem/v} 6 "final" { target { 
> non_strict_align } } } } */
> +/* { dg-final { scan-rtl-dump-times {\(set \(mem/v} 6 "final" { target { 
> non_strict_align } } } } */
> diff --git a/gcc/testsuite/gcc.dg/pr94600-3.c 
> b/gcc/testsuite/gcc.dg/pr94600-3.c
> index 7537f6cb797..e8776fbdb28 100644
> --- a/gcc/testsuite/gcc.dg/pr94600-3.c
> +++ b/gcc/testsuite/gcc.dg/pr94600-3.c
> @@ -31,5 +31,5 @@ foo(void)
>  }
>
>  /* The loop isn't unrolled. */
> -/* { dg-final { scan-rtl-dump-times {\(mem/v} 1 "final" } } */
> -/* { dg-final { scan-rtl-dump-times {\(set \(mem/v} 1 "final" } } */
> +/* { dg-final { scan-rtl-dump-times {\(mem/v} 1 "final" { target { 
> non_strict_align } } } } */
> +/* { dg-final { scan-rtl-dump-times {\(set \(mem/v} 1 "final" { target { 
> non_strict_align } } } } */
>

Re: [committed][testsuite] Re-enable pr94600-{1,3}.c tests for arm

[Hans-Peter Nilsson]

On Wed, 30 Sep 2020, Tom de Vries wrote:

> [ was: Re: [committed][testsuite] Require non_strict_align in
> pr94600-{1,3}.c ]
>
> On 9/30/20 4:53 AM, Hans-Peter Nilsson wrote:
> > On Thu, 24 Sep 2020, Tom de Vries wrote:
> >
> >> Hi,
> >>
> >> With the nvptx target, we run into:
> >> ...
> >> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(mem/v" 6
> >> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(set \\(mem/v" 6
> >> FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(mem/v" 1
> >> FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(set \\(mem/v" 1
> >> ...
> >> The scans attempt to check for volatile stores, but on nvptx we have memcpy
> >> instead.
> >>
> >> This is due to nvptx being a STRICT_ALIGNMENT target, which has the effect
> >> that the TYPE_MODE for the store target is set to BKLmode in
> >> compute_record_mode.
> >>
> >> Fix the FAILs by requiring effective target non_strict_align.
> >
> > No, that's wrong.  There's more than that at play; it worked for
> > the strict-alignment targets where it was tested at the time.
> >
>
> Hi,
>
> thanks for letting me know.
>
> > The test is a valuable canary for this kind of bug.  You now
> > disabled it for strict-alignment targets.
> >
> > Please revert and add your target specifier instead, if you
> > don't feel like investigating further.
>
> I've analyzed the compilation on strict-alignment target arm-eabi, and

An analysis should result in more than that statement.

> broadened the effective target to (non_strict_align ||
> pcc_bitfield_type_matters).

That's *also* not right.  I'm guessing your nvptx fails because
it has 64-bit alignment requirement, but no 32-bit writes.
...um, no that can't be it, nvptx seems to have them.  Costs?
Yes, probably your #define MOVE_RATIO(SPEED) 4.

The writes are to 32-bit aligned addresses which gcc can deduce
(also for strict-alignment targets) because it's a literal,
where it isn't explicitly declared to be attribute-aligned

You should have noticed the weirness in that you "only" needed
to tweak pr94600-1.c and -3.c, not even pr94600-2.c, which
should be the case if it was just the test-case getting the
predicates wrong.  This points at your MOVE_RATIO, together with
middle-end not applying it consistently for -2.c.

Again, please just skip for nvptx (don't mix-n-match general
predicates) unless you really look into the reason you don't get
6 single 32-bit-writes only in *some* of the cases.

brgds, H-P

Re: [committed][testsuite] Enable pr94600-{1,3}.c tests for nvptx

[Hans-Peter Nilsson]

On Thu, 1 Oct 2020, Tom de Vries wrote:

> [ was: Re: [committed][testsuite] Re-enable pr94600-{1,3}.c tests for arm ]
>
> On 10/1/20 7:38 AM, Hans-Peter Nilsson wrote:
> > On Wed, 30 Sep 2020, Tom de Vries wrote:
> >> I've analyzed the compilation on strict-alignment target arm-eabi, and
> >
> > An analysis should result in more than that statement.
> >
>
> Well, it refers to the analysis in the commit log of the patch, sorry if
> that was not obvious.

Aha, I think I only saw your first commit, thanks.  Yes, that
looked more appropriate, but I would have preferred a proper
review to a commit-as-obvious (assuming that was the track when
nothing else was stated), since this was more than just target
gating or *trivial* missing predicates.

> Thanks for the pointer to pr94600-2.c.  I've compared the behaviour
> between pr94600-1.c and pr94600-2.c and figured out why in one case we
> get the load/store pair, and in the other the memcpy.  See rationale in
> commit below.

You may be on the right track judging from the commit log, and I
see my hunch about MOVE_RATIO wasn't far off either.  I guess I
should look into it too with rested eyes, but I'm happy with
this direction; not disabling the test for many targets.

Thanks for looking into it again.

brgds, H-P

Re: [PATCH v2] builtins: rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

[Hans-Peter Nilsson]

Please excuse a comment from the gallery:

On Mon, 28 Sep 2020, will schmidt via Gcc-patches wrote:
> On Fri, 2020-09-04 at 12:52 -0300, Raoni Fassina Firmino via Gcc-patches 
> wrote:

> > 2020-08-13  Raoni Fassina Firmino  
> >
> > gcc/ChangeLog:

> > * config/rs6000/rs6000.md (fegetroundsi): New pattern.
> > (feclearexceptsi): New Pattern.
> > (feraiseexceptsi): New Pattern.

> > +(define_expand "feraiseexceptsi"
> > +  [(use (match_operand:SI 1 "const_int_operand" "n"))
> > +   (set (match_operand:SI 0 "gpc_reg_operand")
> > +   (const_int 0))]
> > +  "TARGET_HARD_FLOAT"
> > +{
> > +  switch (INTVAL (operands[1]))
> > +{
> > +case 0x200:  /* FE_INEXACT */
> > +case 0x400:  /* FE_DIVBYZERO */
> > +case 0x800:  /* FE_UNDERFLOW */
> > +case 0x1000: /* FE_OVERFLOW */
> > +  break;
> > +default:
> > +  FAIL;
> > +}
> > +
> > +  rtx tmp = gen_rtx_CONST_INT (SImode, __builtin_clz (INTVAL 
> > (operands[1])));

This doesn't appear to be very portable, to any-cxx11-compiler
that doesn't pretend to be gcc-intrinsics-compatible.

If the valid values had been more complicated, there'd be
bitmap.c:bitmap_last_set_bit to follow for a suitable portable
pattern.  It conditionalizes like:
#if GCC_VERSION >= 3004
  gcc_assert (sizeof (long) == sizeof (word));
  bit_no += BITMAP_WORD_BITS - __builtin_clzl (word) - 1;
#else
...
#endif

Better, there's "ffs".

brgds, H-P
PS. No less than four targets fail like that.  Meh.

Re: [PATCH v3] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

[Hans-Peter Nilsson]

On Thu, 3 Feb 2022, David Seifert via Gcc-patches wrote:

> On Thu, 2022-02-03 at 12:50 +0100, Jakub Jelinek wrote:
> > On Thu, Feb 03, 2022 at 12:30:11PM +0100, David Seifert wrote:
> > > * `-Werror` can cause issues when a more recent version of GCC
> > > compiles
> > > ? an older version:
> > > ? - https://bugs.gentoo.org/229059
> > > ? - https://bugs.gentoo.org/475350
> > > ? - https://bugs.gentoo.org/667104
> > >
> > > libatomic/ChangeLog:
> > >
> > > ??? * libatomic/configure.ac: Support --disable-werror.
> > > ??? * libatomic/configure: Regenerate.
> > >
> > > libbacktrace/ChangeLog:
> > >
> > > ??? * libbacktrace/configure.ac: Support --disable-werror.
> > > ??? * libbacktrace/configure: Regenerate.
> > >
> > > libgo/ChangeLog:
> > >
> > > ??? * libgo/configure.ac: Support --disable-werror.
> > > ??? * libgo/configure: Regenerate.
> > >
> > > libgomp/ChangeLog:
> > >
> > > ??? * libgomp/configure.ac: Support --disable-werror.
> > > ??? * libgomp/configure: Regenerate.
> > >
> > > libitm/ChangeLog:
> > >
> > > ??? * libitm/configure.ac: Support --disable-werror.
> > > ??? * libitm/configure: Regenerate.
> > >
> > > libsanitizer/ChangeLog:
> > >
> > > ??? * libsanitizer/configure.ac: Support --disable-werror.
> > > ??? * libsanitizer/libbacktrace/Makefile.am (WARN_FLAGS):
> > > Remove.
> >
> > As Jonathan wrote, if you don't have a copyright assignment on file,
> > we need either that copyright assignment or the patch needs to be
> > submitted according to https://gcc.gnu.org/dco.html?which is
> > expressed by Signed-off-by line in the mail and commit message.
> >
>
> I have an FSF copyright assignment, is there anything you need me to do
> to this end?

Perhaps that assignment is still being processed, or under
another name not matching Seifert?  I couldn't find an entry
case-insensitively matching that in a freshly retrieved
copyright.list.

brgds, H-P

Re: [committed] libstdc++: Fix test failures at -O0

[Hans-Peter Nilsson]

On Fri, 11 Feb 2022, Jonathan Wakely via Gcc-patches wrote:
> diff --git 
> a/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc 
> b/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
> index c81344a20e4..25e5ce63b58 100644
> --- a/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
> +++ b/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
> @@ -281,10 +281,13 @@ test07()
>std::pmr::unsynchronized_pool_resource upr(&cr);
>try
>{
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Walloc-size-larger-than="
>  // Try to allocate a ridiculous size (and use a large extended alignment
>  // so that careful_resource::do_allocate can distinguish this allocation
>  // from any required for the pool resource's internal data structures):
>  void* p = upr.allocate(std::size_t(-2), 1024);
> +#pragma GCC distinguish pop

Isn't it a bug that you (presumably) didn't get an error for
that misspelling?  Or a diagnostic to distinguish it?  8-}

brgds, H-P

Re: [PATCH] Add condition coverage profiling

[Hans-Peter Nilsson]

On Wed, 12 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag.

I'd love improvements in this area.

But this is a serious concern:

> gcov --conditions:
> 
> 3:   17:void fn (int a, int b, int c, int d) {
> 3:   18:if ((a && (b || c)) && d)
> condition outcomes covered 3/8
> condition  0 not covered (true false)
> condition  1 not covered (true)
> condition  2 not covered (true)
> condition  3 not covered (true)
> 1:   19:x = 1;
> -:   20:else
> 2:   21:x = 2;
> 3:   22:}

Is this the suggested output from gcov?

Sorry, but this is too hard to read; I can't read this.  What 
does it mean?  What's 0 and what's 1 and which are the 8 
conditions?  (Why not 16 or more; which are redundant?)  Or to 
wit, a glance, which parts of (a && (b || c)) && d are actually 
covered?

There has got to be a better *intuitively* understandable 
presentation format than this. If you please forgive the errors 
in not matching the partal expressions like in your proposal and 
focus on the presentation format, I'd suggest something like, 
for a one-time run with a=true, b=false, c=true, d=false:

"With:
 3:   18:if ((a && (b || c)) && d)
0:   ^^^
1:  ^
2:^
3: 
4:  ^
5:   ^
condition  0 not covered (false)
condition  1 not covered (true)
condition  2 not covered (false)
condition  3 not covered (false)
condition  4 not covered (true)
condition  5 not covered (false)"
(etc)

Possibly with each partial expression repeated above its 
underscoring for readability, because of the increasing distance 
between the underscoring and referred source.

Actually, a separate indexed table like that isn't the best 
choice either.  Perhaps better quoting the source:

"condition (a && (b || c)) false not covered
condition d false not covered
condition (b || c) false not covered
condition b true not covered
condition c false not covered"

Or, just underscoring as instead of quoting the source:
"3:   18:if ((a && (b || c)) && d)

In condition:^^^
false not covered"
(etc)

It is possible I completely misunderstand your proposal, but 
there has to be something from the above to pick.  I'd hate to 
see this go down because of usability problems.  Hope this was 
constructive.

brgds, H-P

Re: [PATCH] Add pattern to convert vector shift + bitwise and + multiply to vector compare in some cases.

[Hans-Peter Nilsson]

On Sat, 13 Aug 2022, mtsamis wrote:
> When using SWAR (SIMD in a register) techniques a comparison operation within

*within

> such a register can be made by using a combination of shifts, bitwise and and
> multiplication. If code using this scheme is vectorized then there is 
> potential
> to replace all these operations with a single vector comparison, by 
> reinterpreting
> the vector types to match the width of the SWAR register.

Hadn't it been for "all" modern processors these days having
SIMD instructions, adding general SWAR handling to the
vectorizer would be worth promoting to someones favorite
decision-maker.  (This is a wonderful first step.)

Random typo spotted:

> +++ b/gcc/match.pd
> @@ -301,6 +301,63 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  (view_convert (bit_and:itype (view_convert @0)
>(ne @1 { build_zero_cst (type); })))
>
> +/* In SWAR (SIMD in a register) code a comparison of packed data can
> +   be consturcted with a particular combination of shift, bitwise and,

*constructed

brgds, H-P

Re: [PATCH v6] LoongArch: add addr_global attribute

[Hans-Peter Nilsson]

On Mon, 15 Aug 2022, Xi Ruoyao via Gcc-patches wrote:

> Can we make a final solution to this soon?  Now the merge window of
> Linux 6.0 is closed and we have two Linux kernel releases not possible
> to be built with Binutils or GCC with new relocation types.  This is
> just ugly...
>
> On Fri, 2022-08-12 at 17:17 +0800, Xi Ruoyao via Gcc-patches wrote:
> > v5 -> v6:
> >
> > * still use "addr_global" as we don't have a better name.

"far"?

brgds, H-P

Re: [wwwdocs] readings.html - "Porting GCC for Dunces" is gone

[Hans-Peter Nilsson]

> From: Gerald Pfeifer 
> Date: Sun, 10 Nov 2019 14:53:23 +0100

> Hi H-P,
> 
> it appears this download is gone. Do you have an alternate location?

Wha...?  No, not at the moment.

>http://ftp.axis.se/pub/users/hp/pgccfd/";>

While I could certainly enter a ticket and hope to get it
reinstated that way, I guess it's time to just take the hint.

Can it be hosted on gcc.gnu.org?  From my point of view, that
seems appropriate.

brgds, H-P

Re: [PATCH 1/2] Introduce dg-require-target-object-format

[Hans-Peter Nilsson]

On Thu, 7 Nov 2019, Egeyar Bagcioglu wrote:
> On 11/7/19 8:47 AM, Segher Boessenkool wrote:
> > On Wed, Nov 06, 2019 at 06:21:33PM +0100, Egeyar Bagcioglu wrote:
> > > +proc dg-require-target-object-format { args } {
> > > +if { [gcc_target_object_format] == [lindex $args 1] } {
> > > + return
> > > +}
> > "==" for strings is dangerous.  Use "eq" or "string equal"?
>
> I see many "string match"es. I will make the change.

Please instead use "string equal".

Code in target-supports-dg.exp is not a trustworthy reference.
I suggest RTFM , where you can see that
"string match" does a glob compare.

brgds, H-P

Re: [00/32] C++ 20 Modules

[Hans-Peter Nilsson]

On Tue, 3 Nov 2020, Nathan Sidwell wrote:

> Here is the implementation of C++20 modules that I have been developing on the
> devel/c++-modules branch over the last few years.

Ow.

> I have bootstrapped and tested on:
> x86_64-linux
> aarch64-linux
> powerpc8le-linux
> powerpc8-aix
>
> Iain Sandoe has been regularly bootstrapping on x86_64-darwin.  Joseph Myers
> graciously built for i686-mingw host.  We eventually ran into compilation
> errors in the analyzer, as it seemed unprepared for an IL32P64 host.

(So not actually tested there.)

Are any of the powerpc targets you tested ILP32, such that the
patchset is completely tested for such a target?

brgds, H-P

Re: [PATCH] "used" attribute saves decl from linker garbage collection

[Hans-Peter Nilsson]

On Wed, 4 Nov 2020, Jozef Lawrynowicz wrote:
> I personally do not see the problem with the .retain attribute, however
> if it is going to be a barrier to getting the functionality committed, I
> am happy to change it, since I really just want the functionality in
> upstream sources.
>
> If a global maintainer would comment on whether any of the proposed
> approaches are acceptable, then I will try to block out time from other
> deadlines so I can work on the fixups and submit a patch in time for the
> GCC 11 freeze.
>
> Thanks,
> Jozef

I'm not much more than a random voice, but an assembly directive
that specifies the symbol (IIUC your .retain directive) to
adjust a symbol attribute sounds cleaner to me, than requiring
gcc to know that this requires it to adjust what it knows about
section flags (again, IIUC).

brgds, H-P

Re: [PATCH] "used" attribute saves decl from linker garbage collection

[Hans-Peter Nilsson]

On Wed, 4 Nov 2020, H.J. Lu wrote:
> On Wed, Nov 4, 2020 at 10:09 AM Hans-Peter Nilsson  wrote:
> >
> > On Wed, 4 Nov 2020, Jozef Lawrynowicz wrote:
> > > I personally do not see the problem with the .retain attribute, however
> > > if it is going to be a barrier to getting the functionality committed, I
> > > am happy to change it, since I really just want the functionality in
> > > upstream sources.
> > >
> > > If a global maintainer would comment on whether any of the proposed
> > > approaches are acceptable, then I will try to block out time from other
> > > deadlines so I can work on the fixups and submit a patch in time for the
> > > GCC 11 freeze.
> > >
> > > Thanks,
> > > Jozef
> >
> > I'm not much more than a random voice, but an assembly directive
> > that specifies the symbol (IIUC your .retain directive) to
>
> But .retain directive DOES NOT adjust symbol attribute.  Instead, it sets
> the SHF_GNU_RETAIN bit on the section which contains the symbol
> definition.  The same section can have many unrelated symbols.

That's an implementation detail *left to the assembler and
linker*.  It's not something the compiler needs to know, and
teoretically it could even change.

> > adjust a symbol attribute sounds cleaner to me, than requiring
> > gcc to know that this requires it to adjust what it knows about
> > section flags (again, IIUC).
> >
> > brgds, H-P
>
>
>
> --
> H.J.
>

Re: [PATCH] "used" attribute saves decl from linker garbage collection

[Hans-Peter Nilsson]

On Wed, 4 Nov 2020, H.J. Lu wrote:

> On Wed, Nov 4, 2020 at 1:03 PM Hans-Peter Nilsson  wrote:
> >
> > On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > On Wed, Nov 4, 2020 at 10:09 AM Hans-Peter Nilsson  
> > > wrote:
> > > >
> > > > On Wed, 4 Nov 2020, Jozef Lawrynowicz wrote:
> > > > > I personally do not see the problem with the .retain attribute, 
> > > > > however
> > > > > if it is going to be a barrier to getting the functionality 
> > > > > committed, I
> > > > > am happy to change it, since I really just want the functionality in
> > > > > upstream sources.
> > > > >
> > > > > If a global maintainer would comment on whether any of the proposed
> > > > > approaches are acceptable, then I will try to block out time from 
> > > > > other
> > > > > deadlines so I can work on the fixups and submit a patch in time for 
> > > > > the
> > > > > GCC 11 freeze.
> > > > >
> > > > > Thanks,
> > > > > Jozef
> > > >
> > > > I'm not much more than a random voice, but an assembly directive
> > > > that specifies the symbol (IIUC your .retain directive) to
> > >
> > > But .retain directive DOES NOT adjust symbol attribute.

I see I missed to point out that I was speaking about the *gcc
symbol* attribute "used".

> > > Instead, it sets
> > > the SHF_GNU_RETAIN bit on the section which contains the symbol
> > > definition.  The same section can have many unrelated symbols.
> >
> > That's an implementation detail *left to the assembler and
> > linker*.  It's not something the compiler needs to know, and
> > teoretically it could even change.
> >
>
> The ELF extension is SHF_GNU_RETAIN.  .retain directive is a hack
> which I strongly objected and showed that it wasn't needed to implement
> SHF_GNU_RETAIN in binutils.

It's still an implementation detail better kept in the
assembler, that the mechanism used to retain a symbol for the
compiler, happens to map to a section attribute.  Some may call
*that* a hack.

It's cleaner to the compiler if it can pass on to the assembler
the specific symbol that needs to be kept.

brgds, H-P

Re: [PATCH] "used" attribute saves decl from linker garbage collection

[Hans-Peter Nilsson]

On Wed, 4 Nov 2020, H.J. Lu wrote:
> On Wed, Nov 4, 2020 at 1:56 PM Hans-Peter Nilsson  wrote:
> > On Wed, 4 Nov 2020, H.J. Lu wrote:
> >
> > > On Wed, Nov 4, 2020 at 1:03 PM Hans-Peter Nilsson  
> > > wrote:
> > > >
> > > > On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > > > On Wed, Nov 4, 2020 at 10:09 AM Hans-Peter Nilsson 
> > > > >  wrote:
> > > > > > I'm not much more than a random voice, but an assembly directive
> > > > > > that specifies the symbol (IIUC your .retain directive) to
> > > > >
> > > > > But .retain directive DOES NOT adjust symbol attribute.
> >
> > I see I missed to point out that I was speaking about the *gcc
> > symbol* attribute "used".
>
> There is no such corresponding symbol attribute in ELF.

I have not missed that, nor that SHF_GNU_RETAIN is so new that
it's not in binutils master.  I have also not missed that gcc
caters to other object formats too.  A common symbol-specific
directive such as .retain, would be better than messing with
section attributes, for gcc.

> > It's cleaner to the compiler if it can pass on to the assembler
> > the specific symbol that needs to be kept.
> >
>
> SHF_GNU_RETAIN is for section and GCC should place the symbol,
> which should be kept, in the SHF_GNU_RETAIN section directly, not
> through .retain directive.

This is where opinions differ.  Anyway, this is now repetition;
I'm done.

brgds, H-P

Re: [PATCH] "used" attribute saves decl from linker garbage collection

[Hans-Peter Nilsson]

On Wed, 4 Nov 2020, H.J. Lu wrote:
> .retain is ill-defined.   For example,
>
> [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
> static int xyzzy __attribute__((__used__));
> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon
> [hjl@gnu-cfl-2 gcc]$ cat x.s
> .file "x.c"
> .text
> .retain xyzzy  < What does it do?
> .local xyzzy
> .comm xyzzy,4,4
> .ident "GCC: (GNU) 11.0.0 20201103 (experimental)"
> .section .note.GNU-stack,"",@progbits
> [hjl@gnu-cfl-2 gcc]$

To answer that question: it's up to the assembler, but for ELF
and SHF_GNU_RETAIN, it seems obvious it'd tell the assembler to
set SHF_GNU_RETAIN for the section where the symbol ends up.
We both know this isn't rocket science with binutils.

brgds, H-P

(VAX) cc0 anyone? (was: [PATCH 0/2] Fixes for old version NetBSD targets)

[Hans-Peter Nilsson]

On Sun, 15 Nov 2020, Maciej W. Rozycki wrote:

> Hi,
>
>  In the course of my recent VAX backend modernisation effort

Hi.  That reminds me that VAX is "still" a cc0 target.

Are you aware of anyone planning on that level of modernization?

More than a year ago, there was a major heads-up that all
remaining cc0 targets would be "retired" in the next release.

Now, I'm thinking that was just an empty threat. 0:-)

brgds, H-P
PS. not volunteering, sorry.

Re: V2 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

[Hans-Peter Nilsson]

On Fri, 13 Nov 2020, H.J. Lu via Gcc-patches wrote:
> Done.  Here is the updated patch.

Hi.  I see a test-case for this kind of construct:

 int foo __attribute__((__used__, __section__ (".bar"))) = 42;

and IIUC that it's handled as I'd hope (setting "R" on the named
section, not another derived section), good.

Could you also add a test-case that the same construct
*without* a specific initializer is handled the same way?
I.e.:
 int foo __attribute__((__used__, __section__ (".bar")));

Thanks in advance.

brgds, H-P

[COMMITTED] contrib/gcc_update: Insert "tformat:" for git log --pretty=tformat:%p:%t:%H

[Hans-Peter Nilsson]

Really old git versions (like 1.6.0) require
"git log --pretty=tformat:%p:%t:%H"
or else we see:

Updating GIT tree
Current branch master is up to date.
fatal: invalid --pretty format: %p:%t:%H
Adjusting file timestamps
Touching gcc/config.in...
Touching gcc/config/arm/arm-tune.md...

...and an empty revision in LAST_UPDATED and gcc/REVISION.
In its absence, for newer git versions, "tformat" is the default
qualifier, documented as such default for at least git-2.11.0.

Committed as obvious.

diff --git a/contrib/ChangeLog b/contrib/ChangeLog
index 16d0667..4e89b8d 100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,8 @@
+2020-01-17  Hans-Peter Nilsson  
+
+   * gcc_update : Use git log "--pretty=tformat:%p:%t:%H",
+   not "--pretty=%p:%t:%H".
+
 2020-01-16  Andreas Schwab  
 
* gcc-git-customization.sh: Avoid double expansion.
diff --git a/contrib/gcc_update b/contrib/gcc_update
index 5df3297..8c980b1 100755
--- a/contrib/gcc_update
+++ b/contrib/gcc_update
@@ -330,7 +330,7 @@ case $vcs_type in
 exit 1
fi
 
-   revision=`$GCC_GIT log -n1 --pretty=%p:%t:%H`
+   revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H`
branch=`$GCC_GIT name-rev --name-only HEAD || :`
;;
 
brgds, H-P

[PATCH] testsuite: effective_target_march_option: support checking for -march=*

[Hans-Peter Nilsson]

testsuite:
* lib/target-supports.exp (effective_target_march_option): New.

I see no (other) way to, depending on the absence of an option,
add an option for a specific target.  Specifically, I don't see
how to do this with dg-skip-if and its friends.

For gcc.dg/torture/pr26515.c and cris-elf, you get an error for
supplying multiple (different) -march=... options (and that
error is desirable), like testing cris-elf with
RUNTESTFLAGS=--target_board=cris-sim/arch=v8, where otherwise
-march=v10 and -march=v8 will both be given, and the test would
fail.

See example last.

Ok to commit the below?

---
 gcc/testsuite/lib/target-supports.exp | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 629b454..565cb62 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2463,6 +2463,10 @@ proc check_effective_target_ti_c64xp { } {
 }]
 }
 
+# Check if a -march=... option is given, as part of (earlier) options.
+proc check_effective_target_march_option { } {
+return [check-flags [list "" { *-*-* } { "-march=*" } { "" } ]]
+}
 
 proc check_alpha_max_hw_available { } {
 return [check_runtime alpha_max_hw_available {
-- 
2.11.0

Example usage (one of several similar, which will be committed
together with the above, if approved):

diff --git a/gcc/testsuite/gcc.dg/torture/pr26515.c 
b/gcc/testsuite/gcc.dg/torture/pr26515.c
index a051e2e..ff765ba 100644
--- a/gcc/testsuite/gcc.dg/torture/pr26515.c
+++ b/gcc/testsuite/gcc.dg/torture/pr26515.c
@@ -1,4 +1,4 @@
-/* { dg-options "-march=v10" { target cris*-*-* } } */
+/* { dg-options "-march=v10" { target { cris*-*-* && { ! march_option } } } } 
*/
 struct i
 {
   long long i_size;

brgds, H-P

[COMMITTED] config.gcc : Add crisv32-*-* and cris-*-linux*

[Hans-Peter Nilsson]

I'm sorry to say that there's no incentive to maintain
crisv32-*-* and cris-*-linux* configurations beyond nostalgia,
(and I'm out of that for the moment).  Support in the Linux
kernel for either applicable CRIS variant (CRIS v10 and CRIS
v32) is gone since 2018.  Their related part of the cc0
transition workload would be noticable.  Note that cris-elf
remains, but crisv32-elf and the CRIS v32 multilib will be
removed, at least for now.

I'm not completely happy about the message (the next-next line
after the context) "*** unless a maintainer comes forward"
because it'd have to be at an infinitesimal maintenance cost to
the cris-elf support.  Still, I'm not bothered enough to add
another case construct or means for "planned obsolescence".

Since we're very late at the gcc-10 cycle, maybe best to commit
the cc0 transition for CRIS to "gcc-11" instead, and leave these
targets enabled-but-obsoleted in gcc-10.  I believe that's the
formally more correct way to go, even if pragmatically no-one
cares.  I think I'll put that work on a branch for now.

---
 gcc/ChangeLog  | 4 
 gcc/config.gcc | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 423899d3988..b4c45a45087 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2020-01-17  Hans-Peter Nilsson  
+
+   * config.gcc : Add crisv32-*-* and cris-*-linux*
+
 2020-01-17  Richard Sandiford  
 
* gimplify.c (gimplify_return_expr): Use poly_int_tree_p rather
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5a2f1730477..5532a7be6ac 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -248,6 +248,8 @@ md_file=
 # Obsolete configurations.
 case ${target} in
   tile*-*-*\
+ | crisv32-*-* \
+ | cris-*-linux*   \
  )
 if test "x$enable_obsolete" != xyes; then
   echo "*** Configuration ${target} is obsolete." >&2
-- 
2.11.0

brgds, H-P

[COMMITTED] libgcc: cris: config/cris/arit.c (DS): Apply attribute __fallthrough__.

[Hans-Peter Nilsson]

libgcc:
* config/cris/arit.c (DS): Apply attribute __fallthrough__.

Without this, there are, for each compilation of arit.c, 30ish
occurrences of "this statement may fall through
[-Wimplicit-fallthrough=]", for lines that look like
case 32: DS; case 31: DS; case 30: DS; case 29: DS;

Noticed while working on the cc0 transition.  Looks like I don't
inspect the logs often.

Adding -Werror to libgcc build-options should perhaps be
considered?

---
 libgcc/config/cris/arit.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libgcc/config/cris/arit.c b/libgcc/config/cris/arit.c
index ba1c1e7..3369559 100644
--- a/libgcc/config/cris/arit.c
+++ b/libgcc/config/cris/arit.c
@@ -128,7 +128,8 @@ do_31div (unsigned long a, unsigned long b)
  i.e. "a - (b - 1) == (a - b) + 1".  */
   b--;
 
-#define DS __asm__ ("dstep %2,%0" : "=r" (a) : "0" (a), "r" (b))
+#define DS __asm__ ("dstep %2,%0" : "=r" (a) : "0" (a), "r" (b)); \
+ __attribute__ ((__fallthrough__))
 
   switch (quot_digits)
 {
-- 
2.11.0

brgds, H-P

[committed] testsuite: Make use of effective-target march_option for cris

[Hans-Peter Nilsson]

With march_option in place, here's the rest.  (And yes, that
cris-linux line in the last context goes away in the patchset
putting that target down.)

gcc/testsuite:
* gcc.dg/torture/pr26515.c (cris*-*-*): Conditionalize
-march=v10 option on target ! march_option.
* gcc.target/cris/asm-v10.S, gcc.target/cris/inasm-v10.c,
gcc.target/cris/sync-1-v10.c: Similar.
---
 gcc/testsuite/gcc.dg/torture/pr26515.c | 2 +-
 gcc/testsuite/gcc.target/cris/asm-v10.S| 2 +-
 gcc/testsuite/gcc.target/cris/inasm-v10.c  | 2 +-
 gcc/testsuite/gcc.target/cris/sync-1-v10.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/torture/pr26515.c 
b/gcc/testsuite/gcc.dg/torture/pr26515.c
index a051e2e..ff765ba 100644
--- a/gcc/testsuite/gcc.dg/torture/pr26515.c
+++ b/gcc/testsuite/gcc.dg/torture/pr26515.c
@@ -1,4 +1,4 @@
-/* { dg-options "-march=v10" { target cris*-*-* } } */
+/* { dg-options "-march=v10" { target { cris*-*-* && { ! march_option } } } } 
*/
 struct i
 {
   long long i_size;
diff --git a/gcc/testsuite/gcc.target/cris/asm-v10.S 
b/gcc/testsuite/gcc.target/cris/asm-v10.S
index c85ebe2..8bb0c29 100644
--- a/gcc/testsuite/gcc.target/cris/asm-v10.S
+++ b/gcc/testsuite/gcc.target/cris/asm-v10.S
@@ -1,5 +1,5 @@
 /* { dg-do assemble } */
-/* { dg-options "-DOTHER_ISA=10 -march=v10" } */
+/* { dg-options "-DOTHER_ISA=10 -march=v10" { target { ! march_option } } } */
 
 /* Check that -march=v10 is also recognized.  */
 
diff --git a/gcc/testsuite/gcc.target/cris/inasm-v10.c 
b/gcc/testsuite/gcc.target/cris/inasm-v10.c
index 75379b3..774cd03 100644
--- a/gcc/testsuite/gcc.target/cris/inasm-v10.c
+++ b/gcc/testsuite/gcc.target/cris/inasm-v10.c
@@ -1,5 +1,5 @@
 /* { dg-do assemble } */
-/* { dg-options "-DOTHER_ISA=10 -march=v10" } */
+/* { dg-options "-DOTHER_ISA=10 -march=v10" { target { ! march_option } } } */
 
 /* Check that -march=v10 is also recognized.  */
 
diff --git a/gcc/testsuite/gcc.target/cris/sync-1-v10.c 
b/gcc/testsuite/gcc.target/cris/sync-1-v10.c
index 6c8dd1a..861fc8c 100644
--- a/gcc/testsuite/gcc.target/cris/sync-1-v10.c
+++ b/gcc/testsuite/gcc.target/cris/sync-1-v10.c
@@ -1,5 +1,5 @@
 /* Check that we can assemble both base atomic variants.  */
 /* { dg-do assemble } */
-/* { dg-options "-O2 -march=v10" } */
+/* { dg-options "-O2 -march=v10" { target { ! march_option } } } */
 /* { dg-additional-options "-mno-unaligned-atomic-may-use-library" { target 
cris*-*-linux* } } */
 #include "sync-1.c"
-- 
2.11.0

brgds, H-P

Re: [v2] contrib: New remotes structure for vendor and personal refs

[Hans-Peter Nilsson]

> From: "Richard Earnshaw (lists)" 
> Date: Fri, 17 Jan 2020 12:21:07 +0100

> As far as possible, I've made the script automatically restructure any 
> existing fetch or push lines that earlier versions of the scripts may 
> have created - the gcc-git-customization.sh script will convert all 
> vendor refs that it can find, so it is not necessary to re-add any 
> vendors you've already added.

I fail, using these instructions, trying to create a
vendor-branch named axis/cris-decc0, using git-2.11.0 from
Debian 9.

> You might, however, want to run
>git remote prune 
> after running to clean up any stale upstream-refs that might still be in 
> your local repo, and then
>git fetch vendors/
> or
>git fetch 
> to re-populate the remotes/ structures.

(I did not use gcc-git-customization.sh or git-fetch-vendor.sh before
XX, so there's presumably nothing to clean up.)

I've done
$ ./contrib/gcc-git-customization.sh
and
$ ./contrib/git-fetch-vendor.sh --enable-push axis

> Also, for any branch you already have that tracks a personal or vendor 
> branch upstream, you might need to run
>git config branch..remote 
> 
> so that merges and pushes go to the right place (I haven't attempted to 
> automate this last part).
> 
> For vendors, the new structure means that
> 
>git checkout -b / remotes/vendors//
> 
> will correctly set up a remote tracking branch.

On master, doing

$ git checkout -b axis/cris-decc0 remotes/vendors/axis/cris-decc0
fatal: Cannot update paths and switch to branch 'axis/cris-decc0' at the same 
time.
Did you intend to checkout 'remotes/vendors/axis/cris-decc0' which can not be 
resolved as commit?

My .git/config looks like this after the gcc-descr and
gcc-undescr lines:

[diff "md"]
xfuncname = ^\\(define.*$
[gcc-config]
upstream = origin
user = hp
userpfx = me
[remote "me"]
url = git+ssh://gcc.gnu.org/git/gcc.git
fetch = +refs/users/hp/heads/*:refs/remotes/me/*
fetch = +refs/users/hp/tags/*:refs/tags/me/*
push = refs/heads/me/*:refs/users/hp/heads/*
[remote "vendors/axis"]
url = git+ssh://gcc.gnu.org/git/gcc.git
fetch = +refs/vendors/axis/heads/*:refs/remotes/vendors/axis/*
fetch = +refs/vendors/axis/tags/*:refs/tags/vendors/axis/*
push = refs/heads/axis/*:refs/vendors/axis/heads/*

Bug in script (undiscovered because e.g. everybody else uses an
existing vendor or branch) or PEBKAC?

I'm past git 101, maybe even intermediate, for some definition
thereof, but this refs-configury is way beyond my
error-correction capabilities; I can't tell typos.

I'm about to create a devel/ branch instead, as that seems way
simpler than playing hide-and-seek like this, but that will make
everyone else fetch an additional blob that may be several
kilobytes (compressed).  Probably much larger than this email. :)

brgds, H-P

Re: [v2] contrib: New remotes structure for vendor and personal refs

[Hans-Peter Nilsson]

> From: Hans-Peter Nilsson 
> Date: Tue, 21 Jan 2020 02:47:57 +0100

> (I did not use gcc-git-customization.sh or git-fetch-vendor.sh before
> XX, so there's presumably nothing to clean up.)

Bah; "before 24b178184f260a6ec1516cfb8bb8876874a078a7".

brgds, H-P

testsuite: More uses of effective-target march_option for cris

[Hans-Peter Nilsson]

gcc/testsuite:
* gcc.target/cris/asm-v8.S, gcc.target/cris/inasm-v8.c,
gcc.target/cris/sync-1.c: Apply effective_target_march_option.

Oops.  A few stragglers, same as recent update: differing
-march=... options is an error, noticed with e.g.
"make check RUNTESTFLAGS=--target_board=cris-sim/arch=v10"

diff --git a/gcc/testsuite/gcc.target/cris/asm-v8.S 
b/gcc/testsuite/gcc.target/cris/asm-v8.S
index 3fba3188454..8946ba916a1 100644
--- a/gcc/testsuite/gcc.target/cris/asm-v8.S
+++ b/gcc/testsuite/gcc.target/cris/asm-v8.S
@@ -1,5 +1,5 @@
 /* { dg-do assemble } */
-/* { dg-options "-DOTHER_ISA=8 -march=v8" } */
+/* { dg-options "-DOTHER_ISA=8 -march=v8" { target { ! march_option } } } */
 
 /* Check that -march=v8 is also recognized.  */
 
diff --git a/gcc/testsuite/gcc.target/cris/inasm-v8.c 
b/gcc/testsuite/gcc.target/cris/inasm-v8.c
index b2fb3053c40..f8f15e8cf60 100644
--- a/gcc/testsuite/gcc.target/cris/inasm-v8.c
+++ b/gcc/testsuite/gcc.target/cris/inasm-v8.c
@@ -1,5 +1,5 @@
 /* { dg-do assemble } */
-/* { dg-options "-DOTHER_ISA=8 -march=v8" } */
+/* { dg-options "-DOTHER_ISA=8 -march=v8" { target { ! march_option } } } */
 
 /* Check that -march=v8 is also recognized.  */
 
diff --git a/gcc/testsuite/gcc.target/cris/sync-1.c 
b/gcc/testsuite/gcc.target/cris/sync-1.c
index 1bc9a674c3b..bf080174e56 100644
--- a/gcc/testsuite/gcc.target/cris/sync-1.c
+++ b/gcc/testsuite/gcc.target/cris/sync-1.c
@@ -1,6 +1,6 @@
 /* Check that we can assemble both base atomic variants, for v0.  */
 /* { dg-do assemble } */
-/* { dg-options "-O2 -march=v0" } */
+/* { dg-options "-O2 -march=v0" { target { ! march_option } } } */
 
 #ifndef type
 #define type char
-- 
2.11.0

brgds, H-P

Re: [patch] contrib: script to create a new vendor branch

[Hans-Peter Nilsson]

> From: "Richard Earnshaw (lists)" 
> Date: Tue, 21 Jan 2020 14:36:32 +0100

> Correction, the branch should be named /, so the push 
> should be
> 
> git push vendors/ /
> 
> For example, for the ARM vendor, the push would be
> 
> git push vendors/ARM ARM/
> 
> R.
> 
> > will work as expected.
> > 
> > Run the script as
> > 
> > contrib/git-add-vendor-branch.sh / 
> > 
> > the  space must have previously been set up in the way 
> > git-fetch-vendor.sh expects.
> > 
> >  * git-add-vendor-bransh.sh: New file.

(typo "bransh")

Thanks, this and your previous reply certainly helped!

Any chance of a git-add-user-branch.sh too, while you're at it?
Or maybe it's just the corresponding push command in there,
that's needed.

brgds, H-P

[0/9] simplification and decc0ration of CRIS port

[Hans-Peter Nilsson]

This patchset is applied to vendors/axis/cris-decc0.

The intent is to apply it myself to master, once master opens
for stage 1, before the planned destruction of cc0 targets that
was announced last September.  I've earlier obsoleted the
crisv32-* and cris-*-linux* sub-ports as no longer relevant (not
counting retrocomputing), and all but the last parts of the
patchset consist of that removal.

If a global maintainer feels trigger-happy about getting rid of
cc0 before I can apply the patchset myself, then please consider
merging it; it should rebase cleanly at any point.  ChangeLog
entries are in the commit-log.

I intend to rebase the branch now and then, and also improve the
decc0rated CRIS port, which is currently over-simplified to
avoiding early fallout from the decc0ration, but also suffering
from long-time bit-rot from generic changes like changes in rtx
cost, register allocator, various rtl canonicalization changes,
mult->shift in address-like expressions, to name a few causes.

brgds, H-P

[cris-decc0 1/9] config.gcc: Remove support for crisv32-*-* and cris-*-linux*.

[Hans-Peter Nilsson]

gcc:
* config.gcc: Remove support for crisv32-*-* and cris-*-linux*.

Or really, move from the obsolete targets section, to
unsupported targets section, and remove crisv32-*-* and
cris-*-linux* from the rest.
---
 gcc/config.gcc | 28 ++--
 1 file changed, 2 insertions(+), 26 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5532a7be6ac..f899b149183 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -248,8 +248,6 @@ md_file=
 # Obsolete configurations.
 case ${target} in
   tile*-*-*\
- | crisv32-*-* \
- | cris-*-linux*   \
  )
 if test "x$enable_obsolete" != xyes; then
   echo "*** Configuration ${target} is obsolete." >&2
@@ -273,6 +271,8 @@ case ${target} in
  | arm*-*-elf  \
  | arm*-*-linux*   \
  | arm*-*-uclinux* \
+ | cris-*-linux*   \
+ | crisv32-*-* \
  | i[34567]86-go32-*   \
  | i[34567]86-*-go32*  \
  | m68k-*-uclinuxoldabi*   \
@@ -365,9 +365,6 @@ bfin*-*)
 bpf-*-*)
cpu_type=bpf
;;
-crisv32-*)
-   cpu_type=cris
-   ;;
 frv*)  cpu_type=frv
extra_options="${extra_options} g.opt"
;;
@@ -1500,14 +1497,6 @@ cr16-*-elf)
 tmake_file="${tmake_file} cr16/t-cr16 "
 use_collect2=no
 ;;
-crisv32-*-elf | crisv32-*-none)
-   tm_file="dbxelf.h elfos.h newlib-stdint.h ${tm_file}"
-   tmake_file="cris/t-cris"
-   target_cpu_default=32
-   gas=yes
-   extra_options="${extra_options} cris/elf.opt"
-   use_gcc_stdint=wrap
-   ;;
 cris-*-elf | cris-*-none)
tm_file="dbxelf.h elfos.h newlib-stdint.h ${tm_file}"
tmake_file="cris/t-cris cris/t-elfmulti"
@@ -1515,19 +1504,6 @@ cris-*-elf | cris-*-none)
extra_options="${extra_options} cris/elf.opt"
use_gcc_stdint=wrap
;;
-crisv32-*-linux* | cris-*-linux*)
-   tm_file="dbxelf.h elfos.h ${tm_file} gnu-user.h linux.h glibc-stdint.h 
cris/linux.h"
-   tmake_file="${tmake_file} cris/t-cris cris/t-linux"
-   extra_options="${extra_options} cris/linux.opt"
-   case $target in
- cris-*-*)
-   target_cpu_default=10
-   ;;
- crisv32-*-*)
-   target_cpu_default=32
-   ;;
-   esac
-   ;;
 csky-*-*)
if test x${with_endian} != x; then
case ${with_endian} in
-- 
2.11.0

[cris-decc0 2/9] gcc: cris: Remove from gcc/config/cris: t-linux, linux.h, linux.opt

[Hans-Peter Nilsson]

gcc:
* config/cris/t-linux, config/cris/linux.h, config/cris/linux.opt:
Remove.

Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains).
---
 gcc/config/cris/linux.h   | 150 --
 gcc/config/cris/linux.opt |  33 --
 gcc/config/cris/t-linux   |   5 --
 3 files changed, 188 deletions(-)
 delete mode 100644 gcc/config/cris/linux.h
 delete mode 100644 gcc/config/cris/linux.opt
 delete mode 100644 gcc/config/cris/t-linux

diff --git a/gcc/config/cris/linux.h b/gcc/config/cris/linux.h
deleted file mode 100644
index 3bb6f68a13d..000
--- a/gcc/config/cris/linux.h
+++ /dev/null
@@ -1,150 +0,0 @@
-/* Definitions for GCC.  Part of the machine description for CRIS.
-   Copyright (C) 2001-2020 Free Software Foundation, Inc.
-   Contributed by Axis Communications.  Written by Hans-Peter Nilsson.
-
-This file is part of GCC.
-
-GCC is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3, or (at your option)
-any later version.
-
-GCC is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with GCC; see the file COPYING3.  If not see
-<http://www.gnu.org/licenses/>.  */
-
-
-/* After the first "Node:" comment comes all preprocessor directives and
-   attached declarations described in the info files, the "Using and
-   Porting GCC" manual (uapgcc), in the same order as found in the "Target
-   macros" section in the gcc-2.9x CVS edition of 2000-03-17.  FIXME: Not
-   really, but needs an update anyway.
-
-   There is no generic copy-of-uapgcc comment, you'll have to see uapgcc
-   for that.  If applicable, there is a CRIS-specific comment.  The order
-   of macro definitions follow the order in the manual.  Every section in
-   the manual (node in the info pages) has an introductory `Node:
-   ' comment.  If no macros are defined for a section, only
-   the section-comment is present.  */
-
-/* This file defines the macros for cris-axis-linux-gnu that are not
-   covered by cris.h, elfos.h and (config/)linux.h.  */
-
-/* Make sure we have a valid TARGET_CPU_DEFAULT, so we can assume it
-   and take shortcuts below.  */
-#ifndef TARGET_CPU_DEFAULT
-#error "TARGET_CPU_DEFAULT not defined"
-#elif (TARGET_CPU_DEFAULT+0) != 10 && (TARGET_CPU_DEFAULT+0) != 32
-#error "TARGET_CPU_DEFAULT must be 10 or 32, or this file be updated"
-#endif
-
-/* Node: Instruction Output */
-
-#undef USER_LABEL_PREFIX
-#define USER_LABEL_PREFIX ""
-
-/* Node: Driver */
-/* These macros are CRIS-specific, but used in target driver macros.  */
-
-#undef CRIS_CPP_SUBTARGET_SPEC
-#if TARGET_CPU_DEFAULT == 32
-# define CRIS_CPP_SUBTARGET_SPEC \
-  "%{pthread:-D_REENTRANT}\
-   %{!march=*:%{!mcpu=*:-D__arch_v32 -D__CRIS_arch_version=32}}"
-#else
-# define CRIS_CPP_SUBTARGET_SPEC \
-  "%{pthread:-D_REENTRANT}\
-   %{!march=*:%{!mcpu=*:-D__arch_v10 -D__CRIS_arch_version=10}}"
-#endif
-
-#undef CRIS_CC1_SUBTARGET_SPEC
-#if TARGET_CPU_DEFAULT == 32
-# define CRIS_CC1_SUBTARGET_SPEC \
- "%{!march=*:%{!mcpu=*:-march=v32}}"
-#define CRIS_SUBTARGET_DEFAULT_ARCH MASK_AVOID_GOTPLT
-#else
-# define CRIS_CC1_SUBTARGET_SPEC \
- "%{!march=*:%{!mcpu=*:-march=v10}}"
-#define CRIS_SUBTARGET_DEFAULT_ARCH 0
-#endif
-
-#undef CRIS_ASM_SUBTARGET_SPEC
-#if TARGET_CPU_DEFAULT == 32
-# define CRIS_ASM_SUBTARGET_SPEC \
- "--em=criself \
-  %{!march=*:%{!mcpu=*:--march=v32}} \
-  %{!fleading-underscore:--no-underscore}\
-  %{" FPIE_OR_FPIC_SPEC ": --pic}"
-#else
-# define CRIS_ASM_SUBTARGET_SPEC \
- "--em=criself \
-  %{!march=*:%{!mcpu=*:--march=v10}} \
-  %{!fleading-underscore:--no-underscore}\
-  %{" FPIE_OR_FPIC_SPEC ": --pic}"
-#endif
-
-/* Previously controlled by target_flags.  */
-#undef TARGET_LINUX
-#define TARGET_LINUX 1
-
-#undef CRIS_SUBTARGET_DEFAULT
-#define CRIS_SUBTARGET_DEFAULT \
-  (MASK_SVINTO \
-   + MASK_ETRAX4_ADD   \
-   + MASK_ALIGN_BY_32  \
-   + CRIS_SUBTARGET_DEFAULT_ARCH)
-
-#undef CRIS_DEFAULT_CPU_VERSION
-#define CRIS_DEFAULT_CPU_VERSION CRIS_CPU_NG
-
-#define GLIBC_DYNAMIC_LINKER "/lib/ld.so.1"
-
-#undef CRIS_LINK_SUBTARGET_SPEC
-#define CRIS_LINK_SUBTARGET_SPEC \
- "-mcrislinux\
-  %{shared} %{static}\
-  %{symbolic:-Bdynamic} %{static:-Bstatic}\
-  %{!shared:%{!static:\
-  %{rdynamic:-export-dynamic}\
-  -dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}\
-  %{!r

[cris-decc0 3/9] libgcc: cris: Remove support for crisv32-*-* and cris*-*-linux

[Hans-Peter Nilsson]

libgcc:
* config.host: Remove support for crisv32-*-* and cris*-*-linux.
* config/cris/libgcc-glibc.ver, config/cris/t-linux: Remove.

Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains).
---
 libgcc/config.host  | 9 -
 libgcc/config/cris/libgcc-glibc.ver | 7 ---
 libgcc/config/cris/t-linux  | 2 --
 3 files changed, 18 deletions(-)
 delete mode 100644 libgcc/config/cris/libgcc-glibc.ver
 delete mode 100644 libgcc/config/cris/t-linux

diff --git a/libgcc/config.host b/libgcc/config.host
index 8f0ea90af57..5146422a263 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -112,9 +112,6 @@ bpf-*-*)
 ;;
 cr16-*-*)
;;
-crisv32-*-*)
-   cpu_type=cris
-   ;;
 csky*-*-*)
cpu_type=csky
;;
@@ -577,15 +574,9 @@ cr16-*-elf)
tmake_file="${tmake_file} cr16/t-cr16 cr16/t-crtlibid t-fdpbit"
extra_parts="$extra_parts crti.o crtn.o crtlibid.o"
 ;;
-crisv32-*-elf)
-   tmake_file="$tmake_file cris/t-cris t-softfp-sfdf t-softfp"
-   ;;
 cris-*-elf)
tmake_file="$tmake_file cris/t-cris t-softfp-sfdf t-softfp 
cris/t-elfmulti"
;;
-cris-*-linux* | crisv32-*-linux*)
-   tmake_file="$tmake_file cris/t-cris t-softfp-sfdf t-softfp cris/t-linux"
-   ;;
 csky-*-elf*)
tmake_file="csky/t-csky t-fdpbit"
extra_parts="$extra_parts crti.o crtn.o"
diff --git a/libgcc/config/cris/libgcc-glibc.ver 
b/libgcc/config/cris/libgcc-glibc.ver
deleted file mode 100644
index e35de83100f..000
--- a/libgcc/config/cris/libgcc-glibc.ver
+++ /dev/null
@@ -1,7 +0,0 @@
-GCC_4.3 {
- __Mul
- __Div
- __Udiv
- __Mod
- __Umod
-}
diff --git a/libgcc/config/cris/t-linux b/libgcc/config/cris/t-linux
deleted file mode 100644
index 8c7f4d44249..000
--- a/libgcc/config/cris/t-linux
+++ /dev/null
@@ -1,2 +0,0 @@
-# Override t-linux default.
-SHLIB_MAPFILES = libgcc-std.ver $(srcdir)/config/cris/libgcc-glibc.ver
-- 
2.11.0

[cris-decc0 4/9] gcc/testsuite: gcc.target/cris: Remove crisv32-* and cris-linux-* tests.

[Hans-Peter Nilsson]

32
-   addoq 42,$r1,$acr
-#else
+#ifdef OTHER_ISA
 0:
move.d [$r2=$r0+42],$r1
bwf 0b
diff --git a/gcc/testsuite/gcc.target/cris/asmreg-1.c 
b/gcc/testsuite/gcc.target/cris/asmreg-1.c
index f430fafbeea..d77d1514667 100644
--- a/gcc/testsuite/gcc.target/cris/asmreg-1.c
+++ b/gcc/testsuite/gcc.target/cris/asmreg-1.c
@@ -3,7 +3,7 @@
 /* { dg-final { scan-assembler "\\\.ifnc \\\$r9-\\\$r10-\\\$r11-\\\$r12" } } */
 
 /* Sanity check for asm register operands in syscall failed for
-   cris-axis-linux-gnu due to regmove bug.
+   cris-axis-linux-gnu due to a regmove bug.
Hans-Peter Nilsson .  */
 
 extern void lseek64 (int, long long, int);
diff --git a/gcc/testsuite/gcc.target/cris/cris.exp 
b/gcc/testsuite/gcc.target/cris/cris.exp
index c85c849e860..386ff3790b3 100644
--- a/gcc/testsuite/gcc.target/cris/cris.exp
+++ b/gcc/testsuite/gcc.target/cris/cris.exp
@@ -18,7 +18,7 @@
 # looping over tests.
 
 # Exit immediately if this isn't a CRIS target.
-if { ![istarget cris-*-*] && ![istarget crisv32-*-*] } then {
+if { ![istarget cris-*-*] } then {
   return
 }
 
diff --git a/gcc/testsuite/gcc.target/cris/inasm-other.c 
b/gcc/testsuite/gcc.target/cris/inasm-other.c
index c1c043f56d3..deeb09d8df6 100644
--- a/gcc/testsuite/gcc.target/cris/inasm-other.c
+++ b/gcc/testsuite/gcc.target/cris/inasm-other.c
@@ -1,6 +1,6 @@
 /* { dg-do assemble } */
-/* { dg-options "-DOTHER_ISA=0 -march=v0" { target crisv32-*-* } } */
-/* { dg-options "-DOTHER_ISA=32 -march=v32" { target cris-*-* } } */
+/* The base test-case is sort-of-disabled or rather made
+   always-pass, but remains included by other tests. */
 
 /* Make sure we can (generate code and) assemble for the "other"
variant, with the twist that the gcc option -march=v0 isn't
@@ -13,9 +13,7 @@
 
 void f(void)
 {
-#if OTHER_ISA == 32
-  asm volatile ("addoq 42,$r11,$acr");
-#else
+#ifdef OTHER_ISA
   asm volatile ("0: move.d [$r12=$sp+42],$r10\n\t"
"bwf 0b\n\t"
"nop");
diff --git a/gcc/testsuite/gcc.target/cris/sync-1-v10.c 
b/gcc/testsuite/gcc.target/cris/sync-1-v10.c
index 861fc8c538d..fd88f2125e8 100644
--- a/gcc/testsuite/gcc.target/cris/sync-1-v10.c
+++ b/gcc/testsuite/gcc.target/cris/sync-1-v10.c
@@ -1,5 +1,4 @@
 /* Check that we can assemble both base atomic variants.  */
 /* { dg-do assemble } */
 /* { dg-options "-O2 -march=v10" { target { ! march_option } } } */
-/* { dg-additional-options "-mno-unaligned-atomic-may-use-library" { target 
cris*-*-linux* } } */
 #include "sync-1.c"
diff --git a/gcc/testsuite/gcc.target/cris/sync-1-v32.c 
b/gcc/testsuite/gcc.target/cris/sync-1-v32.c
deleted file mode 100644
index 3c1d076ab78..000
--- a/gcc/testsuite/gcc.target/cris/sync-1-v32.c
+++ /dev/null
@@ -1,5 +0,0 @@
-/* Check that we can assemble both base atomic variants.  */
-/* { dg-do assemble } */
-/* { dg-options "-O2 -march=v32" } */
-/* { dg-additional-options "-mno-unaligned-atomic-may-use-library" { target 
cris*-*-linux* } } */
-#include "sync-1.c"
diff --git a/gcc/testsuite/gcc.target/cris/sync-2i.c 
b/gcc/testsuite/gcc.target/cris/sync-2i.c
index d491d3c0869..e43aa5356f5 100644
--- a/gcc/testsuite/gcc.target/cris/sync-2i.c
+++ b/gcc/testsuite/gcc.target/cris/sync-2i.c
@@ -2,7 +2,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -Dop -Dtype=int" } */
 /* { dg-additional-options "-mtrap-using-break8 -mtrap-unaligned-atomic" { 
target cris-*-elf } } */
-/* { dg-additional-options "-mno-unaligned-atomic-may-use-library" { target 
cris*-*-linux* } } */
 /* { dg-final { scan-assembler "\tbreak 8" } } */
 /* { dg-final { scan-assembler "\tbtstq \\(2-1\\)," } } */
 /* { dg-final { scan-assembler-not "\tand" } } */
diff --git a/gcc/testsuite/gcc.target/cris/sync-2s.c 
b/gcc/testsuite/gcc.target/cris/sync-2s.c
index 06ff98a2769..9be7dc6bcb5 100644
--- a/gcc/testsuite/gcc.target/cris/sync-2s.c
+++ b/gcc/testsuite/gcc.target/cris/sync-2s.c
@@ -2,7 +2,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -Dop -Dtype=short" } */
 /* { dg-additional-options "-mtrap-using-break8 -mtrap-unaligned-atomic" { 
target cris-*-elf } } */
-/* { dg-additional-options "-mno-unaligned-atomic-may-use-library" { target 
cris*-*-linux* } } */
 /* { dg-final { scan-assembler "\tbreak 8" } } */
 /* { dg-final { scan-assembler "\tbtstq \\(1-1\\)," } } */
 /* { dg-final { scan-assembler-not "\tand" } } */
diff --git a/gcc/testsuite/gcc.target/cris/sync-3i.c 
b/gcc/testsuite/gcc.target/cris/sync-3i.c
index 9e67d61cb35..114e0a846e8 100644
--- a/gcc/testsuite/gcc.target/cris/sync-3i.c
+++ b/gcc/testsuite/gcc.target/cris/sync-3i.c
@@ -4,7 +4,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -Dxchg -Dtype=int" } */
 /* { dg-additional-options "-mt

[cris-decc0 5/9] gcc/testsuite: Remove traces of crisv32-* outside gcc.target/cris

[Hans-Peter Nilsson]

testsuite:
* gcc.dg/20020919-1.c, gcc.dg/pr31866.c, gcc.dg/pr46647.c,
gcc.dg/sibcall-10.c, gcc.dg/sibcall-3.c, gcc.dg/sibcall-4.c,
gcc.dg/sibcall-9.c, gcc.dg/torture/cris-asm-mof-1.c,
gcc.dg/torture/cris-volatile-1.c, gcc.dg/torture/pr38948.c,
gcc.dg/tree-ssa/20040204-1.c, gcc.dg/tree-ssa/loop-1.c,
gcc.dg/weak/typeof-2.c, lib/target-supports.exp: Remove remaining
traces of crisv32-*.

Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains).
Uses of "cris*" (as opposed to "cris") are deliberately left unadjusted.
---
 gcc/testsuite/gcc.dg/20020919-1.c  | 2 +-
 gcc/testsuite/gcc.dg/pr31866.c | 2 +-
 gcc/testsuite/gcc.dg/pr46647.c | 4 ++--
 gcc/testsuite/gcc.dg/sibcall-10.c  | 2 +-
 gcc/testsuite/gcc.dg/sibcall-3.c   | 2 +-
 gcc/testsuite/gcc.dg/sibcall-4.c   | 2 +-
 gcc/testsuite/gcc.dg/sibcall-9.c   | 2 +-
 gcc/testsuite/gcc.dg/torture/cris-asm-mof-1.c  | 2 +-
 gcc/testsuite/gcc.dg/torture/cris-volatile-1.c | 2 +-
 gcc/testsuite/gcc.dg/torture/pr38948.c | 1 -
 gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c | 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/loop-1.c | 2 +-
 gcc/testsuite/gcc.dg/weak/typeof-2.c   | 1 -
 gcc/testsuite/lib/target-supports.exp  | 5 ++---
 14 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/20020919-1.c 
b/gcc/testsuite/gcc.dg/20020919-1.c
index 1dcf75e8ff6..38add3a45f0 100644
--- a/gcc/testsuite/gcc.dg/20020919-1.c
+++ b/gcc/testsuite/gcc.dg/20020919-1.c
@@ -8,7 +8,7 @@
You must be this tall ---> fit two long longs in asm-declared registers
to enter this amusement.  */
 
-/* { dg-do compile { target alpha*-*-* cris-*-* crisv32-*-* i?86-*-* mmix-*-* 
powerpc*-*-* rs6000-*-* x86_64-*-* } } */
+/* { dg-do compile { target alpha*-*-* cris-*-* i?86-*-* mmix-*-* powerpc*-*-* 
rs6000-*-* x86_64-*-* } } */
 /* { dg-options "-O2" } */
 
 /* Constructed examples; input/output (same register), output, input, and
diff --git a/gcc/testsuite/gcc.dg/pr31866.c b/gcc/testsuite/gcc.dg/pr31866.c
index 4081c0e6ad9..d6a2ab05690 100644
--- a/gcc/testsuite/gcc.dg/pr31866.c
+++ b/gcc/testsuite/gcc.dg/pr31866.c
@@ -1,5 +1,5 @@
 /* PR tree-optimization/31866 */
-/* { dg-do compile { target alpha*-*-* cris-*-* crisv32-*-* i?86-*-* mmix-*-* 
powerpc*-*-* rs6000-*-* x86_64-*-* } } */
+/* { dg-do compile { target alpha*-*-* cris-*-* i?86-*-* mmix-*-* powerpc*-*-* 
rs6000-*-* x86_64-*-* } } */
 /* { dg-options "-O2" } */
 
 #if defined (__alpha__)
diff --git a/gcc/testsuite/gcc.dg/pr46647.c b/gcc/testsuite/gcc.dg/pr46647.c
index d7ada9650dc..7eefc6e336a 100644
--- a/gcc/testsuite/gcc.dg/pr46647.c
+++ b/gcc/testsuite/gcc.dg/pr46647.c
@@ -25,5 +25,5 @@ func3 (void)
   return 0;
 }
 
-/* The xfail for avr, cris-* and crisv32-* is due to PR53535.  */
-/* { dg-final { scan-tree-dump-not "memset" "optimized" { xfail avr-*-* 
cris-*-* crisv32-*-* } } } */
+/* The xfail for avr and cris-* is due to PR53535.  */
+/* { dg-final { scan-tree-dump-not "memset" "optimized" { xfail avr-*-* 
cris-*-* } } } */
diff --git a/gcc/testsuite/gcc.dg/sibcall-10.c 
b/gcc/testsuite/gcc.dg/sibcall-10.c
index 3d58036b468..4ac2ee45fbf 100644
--- a/gcc/testsuite/gcc.dg/sibcall-10.c
+++ b/gcc/testsuite/gcc.dg/sibcall-10.c
@@ -5,7 +5,7 @@
Copyright (C) 2002 Free Software Foundation Inc.
Contributed by Hans-Peter Nilsson*/
 
-/* { dg-do run { xfail { { amdgcn*-*-* cris-*-* crisv32-*-* csky-*-* h8300-*-* 
hppa*64*-*-* m32r-*-* mcore-*-* mn10300-*-* msp430*-*-* nds32*-*-* 
xstormy16-*-* v850*-*-* vax-*-* xtensa*-*-* } || { arm*-*-* && { ! arm32 } } } 
} } */
+/* { dg-do run { xfail { { amdgcn*-*-* cris-*-* csky-*-* h8300-*-* 
hppa*64*-*-* m32r-*-* mcore-*-* mn10300-*-* msp430*-*-* nds32*-*-* 
xstormy16-*-* v850*-*-* vax-*-* xtensa*-*-* } || { arm*-*-* && { ! arm32 } } } 
} } */
 /* -mlongcall disables sibcall patterns.  */
 /* { dg-skip-if "" { powerpc*-*-* } { "-mlongcall" } { "" } } */
 /* -msave-restore disables sibcall patterns.  */
diff --git a/gcc/testsuite/gcc.dg/sibcall-3.c b/gcc/testsuite/gcc.dg/sibcall-3.c
index eafe8dd8456..9962b641298 100644
--- a/gcc/testsuite/gcc.dg/sibcall-3.c
+++ b/gcc/testsuite/gcc.dg/sibcall-3.c
@@ -5,7 +5,7 @@
Copyright (C) 2002 Free Software Foundation Inc.
Contributed by Hans-Peter Nilsson*/
 
-/* { dg-do run { xfail { { cris-*-* crisv32-*-* h8300-*-* hppa*64*-*-* 
m32r-*-* mcore-*-* mn10300-*-* msp430*-*-* nds32*-*-* xstormy16-*-* v850*-*-* 
vax-*-* xtensa*-*-* } || { arm*-*-* && { ! arm32 } } } } } */
+/* { dg-do run { xfail { { cris-*-* h8300-*-* hppa*64*-*-* m32r-*-* mcore-*-* 
mn10300-*-* msp430*-*-* nds32*-*-* xstormy16-*-* v850*-*-* vax-*-* xtensa*-*-* 
} || { arm*-*-* && { ! arm32 } } } } } */
 /* -mlongcall disables sibcall patterns.  */
 /* { dg-skip-if "&q

[cris-decc0 6/9] config/cris/t-elfmulti: Remove crisv32 multilib.

[Hans-Peter Nilsson]

gcc:
* config/cris/t-elfmulti: Remove crisv32 multilib.

Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains).
---
 gcc/config/cris/t-elfmulti | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/gcc/config/cris/t-elfmulti b/gcc/config/cris/t-elfmulti
index 3c749c46377..84eb7a70825 100644
--- a/gcc/config/cris/t-elfmulti
+++ b/gcc/config/cris/t-elfmulti
@@ -16,8 +16,8 @@
 # along with GCC; see the file COPYING3.  If not see
 # .
 
-MULTILIB_OPTIONS = march=v8/march=v10/march=v32
-MULTILIB_DIRNAMES = v8 v10 v32
+MULTILIB_OPTIONS = march=v8/march=v10
+MULTILIB_DIRNAMES = v8 v10
 MULTILIB_MATCHES = \
march?v8=mcpu?v8 \
march?v10=mcpu?etrax100lx \
@@ -26,6 +26,5 @@ MULTILIB_MATCHES = \
march?v10=march?ng \
march?v10=march?v11 \
march?v10=mcpu?v11 \
-   march?v10=mcpu?v10 \
-   march?v32=mcpu?v32
+   march?v10=mcpu?v10
 MULTILIB_EXTRA_OPTS = mbest-lib-options
-- 
2.11.0

[cris-decc0 7/9] gcc/config/cris: Remove shared-library and CRIS v32 support.

[Hans-Peter Nilsson]

gcc:
* config/cris: Remove shared-library and CRIS v32 support.

Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains).

Essentially everything is gone, including functions and
target-specific definitions and most obvious knock-on effects,
like removing unused functions and arguments.

There's one exception: the register-class effects of the CRIS v32
ACR register are deliberately excluded and left in (i.e.  its
use by-number is removed and the ACE_REGS regclass is always
unusable - but present).  Changing register class definitions to
remove ACR_REGS and related classes (folding their uses into
remaining classes), causes extra register moves in libgcc (as an
immediate observation; actual net effect unknown), which is
unwanted both for performance reasons and also causing extra
work comparing before/after cc0-machinery-conversion changes
ahead.  The actual cause and solution for these negative effects
of cleaing up the register-classes will at the moment have to
remain to-be-investigated.

If CRIS v32 support is reinstated, consider doing the .md part
not as separate patterns with opposite conditions but merged
patterns with necessarily-different alternatives using the
"enabled" attribute (which was not invented back then).

Also, a single ACR-related RTL-dump example in a cris.md
comment, related to a strict_low_part issue is kept, but marked
as obsolete.

Note that the "b" register-constraint (non-ACR registers; can be
used for post-increment) is left in, as that may have extant
uses outside of gcc.  Its availability is tested by
gcc.target/cris/asm-b-1.c.  When ACR register classes are
removed, it's probably best to make it equal to GENERAL_REGS.
---
 gcc/config/cris/constraints.md |   24 +-
 gcc/config/cris/cris-protos.h  |8 -
 gcc/config/cris/cris.c |  854 ++---
 gcc/config/cris/cris.h |  114 +---
 gcc/config/cris/cris.md| 1376 
 gcc/config/cris/cris.opt   |4 -
 gcc/config/cris/predicates.md  |   60 +-
 gcc/config/cris/sync.md|   39 +-
 8 files changed, 203 insertions(+), 2276 deletions(-)

diff --git a/gcc/config/cris/constraints.md b/gcc/config/cris/constraints.md
index 7e35083459d..e177a3c10fd 100644
--- a/gcc/config/cris/constraints.md
+++ b/gcc/config/cris/constraints.md
@@ -18,9 +18,6 @@
 ;; .
 
 ;; Register constraints.
-(define_register_constraint "a" "ACR_REGS"
-  "@internal")
-
 (define_register_constraint "b" "GENNONACR_REGS"
   "@internal")
 
@@ -106,7 +103,7 @@ (define_constraint "R"
;; A [reg] or (int) [reg], maybe with post-increment.
(match_test "cris_bdap_index_p (op, reload_in_progress
   || reload_completed)")
-   (match_test "cris_constant_index_p (op)")))
+   (match_test "CONSTANT_P (op)")))
 
 (define_constraint "T"
   "Memory three-address operand."
@@ -118,14 +115,14 @@ (define_constraint "T"
   reload_in_progress
   || reload_completed)"))
;; Just an explicit indirect reference: [const]?
-   (match_test "CRIS_CONSTANT_P (XEXP (op, 0))")
+   (match_test "CONSTANT_P (XEXP (op, 0))")
;; Something that is indexed; [...+...]?
(and (match_code "plus" "0")
  ;; A BDAP constant: [reg+(8|16|32)bit offset]?
 (ior (and (match_test "cris_base_p (XEXP (XEXP (op, 0), 0),
 reload_in_progress
 || reload_completed)")
-  (match_test "cris_constant_index_p (XEXP (XEXP (op, 
0), 1))"))
+  (match_test "CONSTANT_P (XEXP (XEXP (op, 0), 1))"))
  ;; A BDAP register: [reg+[reg(+)].S]?
  (and (match_test "cris_base_p (XEXP (XEXP (op, 0), 0),
 reload_in_progress
@@ -149,18 +146,3 @@ (define_constraint "T"
   (match_test "cris_biap_index_p (XEXP (XEXP (op, 0), 
0),
   reload_in_progress
   || 
reload_completed)")))
-
-(define_constraint "S"
-  "PIC-constructs for symbols."
-  (and (match_test "flag_pic")
-   (match_code "const")
-   (match_test "cris_valid_pic_const (op, false)")))
-
-(define_constraint "U"
-  "@internal"
-  (and (match_test "flag_pic")
-   ;; We're just interested in the ..._or_callable_symbol part.
-   ;; (Using CRIS_CONSTANT_P would exclude that too.)
-   (match_test "CONSTANT_P (op)")
-   (match_operand 0 "cris_nonmemory_operand_or_callable_symbol")))
-
diff --git a/gcc/config/cris/cris-protos.h b/gcc/config/cris/cris-protos.h
index 2105256cc78..98b24a26bb0 100644
--- a/gcc/config/cris/c

[cris-decc0 9/9] testsuite: cris: xfail parts of gcc.target/cris/sync-2i.c, sync-2s.c

[Hans-Peter Nilsson]

PR target/93372
* gcc.target/cris/sync-2s.c, gcc.target/cris/sync-2i.c: XFAIL.

Unfortunately, some assembly-code-matches have to be xfailed
until the port is improved to use other than straight
compare-insns.
---
 gcc/testsuite/gcc.target/cris/sync-2i.c | 5 +++--
 gcc/testsuite/gcc.target/cris/sync-2s.c | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.target/cris/sync-2i.c 
b/gcc/testsuite/gcc.target/cris/sync-2i.c
index e43aa5356f5..f69675cd9de 100644
--- a/gcc/testsuite/gcc.target/cris/sync-2i.c
+++ b/gcc/testsuite/gcc.target/cris/sync-2i.c
@@ -3,7 +3,8 @@
 /* { dg-options "-O2 -Dop -Dtype=int" } */
 /* { dg-additional-options "-mtrap-using-break8 -mtrap-unaligned-atomic" { 
target cris-*-elf } } */
 /* { dg-final { scan-assembler "\tbreak 8" } } */
-/* { dg-final { scan-assembler "\tbtstq \\(2-1\\)," } } */
-/* { dg-final { scan-assembler-not "\tand" } } */
+/* { dg-final { scan-assembler "\tbtstq \\(2-1\\)," { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not "\tand" { xfail *-*-* } } } */
 /* { dg-final { scan-assembler-not "\t\[jb\]sr" } } */
+/* The xfails are due to pr93372 (regression-tracker for cris cc0 transition). 
*/
 #include "sync-1.c"
diff --git a/gcc/testsuite/gcc.target/cris/sync-2s.c 
b/gcc/testsuite/gcc.target/cris/sync-2s.c
index 9be7dc6bcb5..f31d3210dd8 100644
--- a/gcc/testsuite/gcc.target/cris/sync-2s.c
+++ b/gcc/testsuite/gcc.target/cris/sync-2s.c
@@ -3,7 +3,8 @@
 /* { dg-options "-O2 -Dop -Dtype=short" } */
 /* { dg-additional-options "-mtrap-using-break8 -mtrap-unaligned-atomic" { 
target cris-*-elf } } */
 /* { dg-final { scan-assembler "\tbreak 8" } } */
-/* { dg-final { scan-assembler "\tbtstq \\(1-1\\)," } } */
-/* { dg-final { scan-assembler-not "\tand" } } */
+/* { dg-final { scan-assembler "\tbtstq \\(1-1\\)," { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not "\tand" { xfail *-*-* } } } */
 /* { dg-final { scan-assembler-not "\t\[jb\]sr" } } */
+/* The xfails are due to pr93372 (regression-tracker for cris cc0 transition). 
*/
 #include "sync-1.c"
-- 
2.11.0

[PATCH] doc: target.def (flags_regnum): Mention effect on delay slot filling.

[Hans-Peter Nilsson]

gcc:
* target.def (flags_regnum): Also mention effect on delay slot filling.
* doc/tm.texi: Regenerate.

Noticed the "hard way" dealing with performance fallout for the
CRIS decc0ration.

Previously, the documentation blurb only mentioned an effect on
compare elimination.  The technical contents is obvious but I'm
more worried about grammar.  I don't see hyphenation elsewhere
when referring to delay slot filling, but then again the term
used for dbr-scheduling isn't consistent in that part of the
documentation.  Note also that it's not just branches, says the
code in reorg.c.

Dvi and info results inspected for sanity.

Ok to commit?

---
 gcc/doc/tm.texi | 4 +++-
 gcc/target.def  | 8 
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 4aec468..19985ad 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -6532,7 +6532,9 @@ returns @code{VOIDmode}.
 @end deftypefn
 
 @deftypevr {Target Hook} {unsigned int} TARGET_FLAGS_REGNUM
-If the target has a dedicated flags register, and it needs to use the 
post-reload comparison elimination pass, then this value should be set 
appropriately.
+If the target has a dedicated flags register, and it needs to use the
+post-reload comparison elimination pass, or the delay slot filler pass,
+then this value should be set appropriately.
 @end deftypevr
 
 @node Costs
diff --git a/gcc/target.def b/gcc/target.def
index 81cea0d..b5e82ff 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -3716,10 +3716,10 @@ of spill registers and print a fatal error message.",
target is constrainted to use post-reload comparison elimination.  */
 DEFHOOKPOD
 (flags_regnum,
- "If the target has a dedicated flags register, and it needs to use the\
- post-reload comparison elimination pass, then this value should be set\
- appropriately.",
- unsigned int, INVALID_REGNUM)
+ "If the target has a dedicated flags register, and it needs to use the\n\
+post-reload comparison elimination pass, or the delay slot filler pass,\n\
+then this value should be set appropriately.",
+unsigned int, INVALID_REGNUM)
 
 /* Compute a (partial) cost for rtx X.  Return true if the complete
cost has been computed, and false if subexpressions should be
-- 
2.11.0

brgds, H-P

[PATCH] dbr: Filter-out TARGET_FLAGS_REGNUM from end_of_function_needs.

[Hans-Peter Nilsson]

Compared to the cc0 version, I noticed a regression in
delay-slot-filling for CRIS for several functions in libgcc with
a similar layout, one being lshrdi3, where with cc0 all
delay-slots were filled, as exposed by the test-case.  I ended
up including the thankfully-small lshrdi3 as-is, for simplicity
of testing, after failing to cook up an artificial test-case.

There's one slot that fails to be filled for the decc0rated CRIS
port.  A gdb session shows it is because of the automatic
inclusion of TARGET_FLAGS_REGNUM in "registers needed at the end
of the function" because there are insns in the epilogue that
clobber the condition-code register.  I'm not trying to tell a
clobber from a set, as parallels with set instead of clobber
seems likely to happen too, for targets with TARGET_FLAGS_REGNUM
set.

Other targets with delay-slots and one dedicated often-clobbered
condition-code-register should consider defining
TARGET_FLAGS_REGNUM.  I noticed it improved delay-slot-filling
also in other situations than this.  (Author of introduction of
TARGET_FLAGS_REGNUM use in dbr is CC:ed.)

Tested cris-elf.

Ok to commit or perhaps wait to gcc11?

(The test-case goes in either way, as it passes with cc0-CRIS.)

gcc:
* resource.c (init_resource_info): Filter-out TARGET_FLAGS_REGNUM
from end_of_function_needs.

gcc/testsuite:
* gcc.target/cris/pr93372-1.c: New.

---
 gcc/resource.c|  6 +++
 gcc/testsuite/gcc.target/cris/pr93372-1.c | 62 +++
 2 files changed, 68 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-1.c

diff --git a/gcc/resource.c b/gcc/resource.c
index d26217c..62a69c0 100644
--- a/gcc/resource.c
+++ b/gcc/resource.c
@@ -21,6 +21,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
+#include "target.h"
 #include "rtl.h"
 #include "df.h"
 #include "memmodel.h"
@@ -1214,6 +1215,11 @@ init_resource_info (rtx_insn *epilogue_insn)
   if (return_insn_p (epilogue_insn))
break;
 }
+  
+  /* Filter-out the flags register from those additionally required
+ registers. */
+  if (targetm.flags_regnum != INVALID_REGNUM)
+CLEAR_HARD_REG_BIT (end_of_function_needs.regs, targetm.flags_regnum);
 
   /* Allocate and initialize the tables used by mark_target_live_regs.  */
   target_hash_table = XCNEWVEC (struct target_info *, TARGET_HASH_PRIME);
diff --git a/gcc/testsuite/gcc.target/cris/pr93372-1.c 
b/gcc/testsuite/gcc.target/cris/pr93372-1.c
new file mode 100644
index 000..b625eda
--- /dev/null
+++ b/gcc/testsuite/gcc.target/cris/pr93372-1.c
@@ -0,0 +1,62 @@
+/* Check that all more-or-less trivially fillable delayed-branch-slots
+   are filled. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-not "\tnop" } } */
+
+void *f(void **p)
+{
+  /* Supposedly the memory read finds its way into the "ret"
+ delay-slot. */
+  return *p;
+}
+
+int g(int *x, int *y, char *v, int n)
+{
+  int z = *x;
+  int w = *v + 31;
+
+  /* Two branch and two return slots, all filled. */
+  if (z != 23 && z != n+1)
+return *x+*y+24+w;
+  return *y+24+w;
+}
+
+/* No problem with the two examples above, but with a more involved
+   example, the epilogue contents matter (the condition-code register
+   clobber was mistaken for a register that needed to be alive). */
+
+struct DWstruct {int low, high;};
+typedef unsigned long long DItype;
+typedef unsigned int USItype;
+
+typedef union
+{
+  struct DWstruct s;
+  DItype ll;
+} DWunion;
+
+unsigned long long
+xlshrdi3 (DItype u, unsigned int b)
+{
+  if (b == 0)
+return u;
+
+  const DWunion uu = {.ll = u};
+  const int bm = (4 * 8) - b;
+  DWunion w;
+
+  if (bm <= 0)
+{
+  w.s.high = 0;
+  w.s.low = (USItype) uu.s.high >> -bm;
+}
+  else
+{
+  const USItype carries = (USItype) uu.s.high << bm;
+  w.s.high = (USItype) uu.s.high >> b;
+  w.s.low = ((USItype) uu.s.low >> b) | carries;
+}
+
+  return w.ll;
+}
-- 
2.11.0

brgds, H-P

Re: Deprecating cc0 (and consequently cc0 targets)

[Hans-Peter Nilsson]

> From: Jeff Law 
> Date: Fri, 20 Sep 2019 17:38:38 +0200

Hi.  I'm not going to question

> The first step in that process is to drop support for cc0.

but could you please elaborate on...

> [cc0 support in gcc core]
> code is broken in various ways,

> particularly WRT exceptions.

...that last part?

If you mean asynchronous exceptions then perhaps in theory,
except there's no need to (and no state to) "unwind" to
in-between cc0 setter and user.  But I guess that goes for
"MODE_CC" targets too; exception information isn't that precise.

> This patch deprecates the affected targets.

(Not applied yet?  Before the gcc-10 branch?  Can you please
consider dropping cris* from that part when rebasing it, as per
contents on master and my pledge to merge axis/cris-decc0?)

> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 69d0a024d85..0c1637e8be1 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -248,6 +248,12 @@ md_file=
>  # Obsolete configurations.
>  case ${target} in
>tile*-*-*  \
> +  avr*-*-*   \
> +  h8300*-*-* \
> +  cris*-*-*  \
> +  m68k*-*-*  \
> +  vax*-*-*   \
> +  cr16*-*-*  \
>   )
>  if test "x$enable_obsolete" != xyes; then
>echo "*** Configuration ${target} is obsolete." >&2
> @@ -273,7 +279,6 @@ case ${target} in
>   | arm*-*-uclinux*   \
>   | i[34567]86-go32-* \
>   | i[34567]86-*-go32*\
> - | m68k-*-uclinuxoldabi* \
>   | mips64orion*-*-rtems* \
>   | pdp11-*-bsd   \
>   | powerpc*-*-linux*paired*  \
> @@ -294,7 +299,6 @@ case ${target} in
>   | *-*-solaris2.[0-9].*  \
>   | *-*-solaris2.10*  \
>   | *-*-sysv* \
> - | vax-*-vms*\
>   )
> echo "*** Configuration ${target} not supported" 1>&2
> exit 1

Beware, the two last hunks shouldn't be applied, else the patch
will actually make m68k-*-uclinuxoldabi* andvax-*-vms* available
(by --enable-obsolete).

That part would go in when actually removing the targets.

I may have lost track of the conversation that followed; maybe
the patch was itself obsoleted.

brgds, H-P

Re: [cris-decc0 8/9] cris: Move trivially from cc0 to reg:CC model, removing most optimizations.

[Hans-Peter Nilsson]

> From: Segher Boessenkool 
> Date: Mon, 27 Jan 2020 23:52:21 +0100

> Hi!
> 
> On Wed, Jan 22, 2020 at 07:11:27AM +0100, Hans-Peter Nilsson wrote:
> > I intend to put back as many as I find use for, of those
> > anonymous patterns in a controlled manner, with self-contained
> > test-cases proving their usability, rather than symmetry with
> > other instructions and similar addressing modes, which guided
> > the original introduction.  I've entered prX to track code
> > performance regressions related to this transition, with focus
> > on target-side causes and fixes; besides the function prologue
> > special-case, there were some checking presence of the bit-test
> > (btstq) instruction.
> 
> That's PR93372 (not X :-) ).

(Wow, someone read the log!)

Doh!  Thanks, will fix at next rebase.  (FWIW, I just added a
mail-send-hook to at least stop (and ask) me from sending email
with that kind of placeholder in the body. :)

> Do you have any estimate how much removing cc0 this way costs in
> performance (or code size, or any other metric)?

Not yet, by any quantifiable metrics, but I plan to do that once
I'm happy with compare-elim.c doing its job for the most glaring
cases.

Still, looking at differences to the cc0 version for libgcc, it
might even be an improvement due to better register allocation
(fewer saved registers and register moves and the like).  To
wit, that effect has a good chance of dominating over negative
fallout from missed compare-elimination opportunities and other
simplifications, just judging from initial observations.
Film at 11.

brgds, H-P

committed: fix typo in define_subst example, md.texi

[Hans-Peter Nilsson]

Committed as obvious.

gcc:
* md.texi (Define Subst): Match closing paren in example.

diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index cec74ea78..66c5eea3b 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -10545,7 +10545,7 @@ generated with the following @code{define_subst}:
   ""
   [(set (match_dup 0)
 (match_dup 1))
-   (clobber (reg:CC FLAGS_REG))]
+   (clobber (reg:CC FLAGS_REG))])
 @end smallexample
 
 This @code{define_subst} can be applied to any RTL pattern containing
-- 
2.11.0

brgds, H-P

[0/6 CRIS cc0-preparations]

[Hans-Peter Nilsson]

Stuff I broke out from the CRIS decc0ration work;
compare-decanonicalization and tests that would be regressions
in a future timeline, but fixed later on.

Besides the first patch, nothing you'd normally care about, and
perhaps for people doing CC0 work: the test-cases and the cc0
effective-target may be of use to you.

brgds, H-P

[1/6 CRIS cc0-preparations] try to generate zero-based comparisons

[Hans-Peter Nilsson]

* config/cris/cris.c (cris_reduce_compare): New function.
* config/cris/cris-protos.h  (cris_reduce_compare): Add prototype.
* config/cris/cris.md ("cbranch4", "cbranchdi4", "cstoredi4")
(cstore4"): Apply cris_reduce_compare in expanders.

The decc0ration work of the CRIS port made me look closer at the
code for trivial comparisons, as in the condition for branches
and conditional-stores, like in:

void g(short int a, short int b)
{
  short int c = a + b;

  if (c >= 0)
foo ();
}

At -O2, the cc0 version of the CRIS port has an explicit
*uneliminated* compare instruction ("cmp.w -1,$r10") instead of
an (eliminated) compare against 0 (which below I'll call a
zero-compare).  This for the CRIS-cc0 version, but I see this
also for a much older gcc, at 4.7.  For the decc0rated port, the
compare *is* a test against 0, eventually eliminated.  To wit,
for cc0 (mind the delay-slot):

_g:
subq 4,$sp
add.w $r11,$r10
cmp.w -1,$r10
ble .L9
move $srp,[$sp]

jsr _foo
.L9:
jump [$sp+]

The compare instruction is expected to be eliminated, i.e.  the
following diff to the above is desired, modulo the missing
sibling call, which corresponds to what I get from 4.7 and for
the decc0rated port:

!--- a  Wed Feb  5 15:22:27 2020
!+++ b  Wed Feb  5 15:22:51 2020
!@@ -1,8 +1,7 @@
! _g:
!subq 4,$sp
!add.w $r11,$r10
!-  cmp.w -1,$r10
!-  ble .L9
!+  bmi .L9
!move $srp,[$sp]
!
!jsr _foo

Tracking this difference, I see that for both cc0-CRIS and the
decc0rated CRIS, the comparison actually starts out as a compare
against -1 at "expand" time, but is transformed for decc0rated
CRIS to a zero-compare in "cse1".

For CRIS-cc0 "cse1" does try to replace the compare with a
zero-compare, but fails because at the same time it tries to
replace the c operand with (a + b).  Or some such; it fails and
no other pass succeeds.  I was not into fixing cc0-handling in
core gcc, so I didn't look closer.

BTW, at first, I was a bit surprised to see that for compares
against a constant, a zero-compare is not canonical RTX for
*all* conditions, and that instead only a subset of all RTX
conditions against a constant are canonical, transforming one
condition to the canonical one by adding 1 or -1 to the
constant.  It does makes sense at a closer look, but still not
so much when emitting RTL.

There are several places that mention in comments that emitting
RTX as zero-compare is preferable, but nothing is done about it.
Some generic code instead seems confused that the *target* is
helped by seeing canonical RTX, or perhaps it (its authors) like
me, confused about what a canonical comparison is.  For example,
prepare_cmp_insn calls canonicalize_comparison last before
emitting the actual instructions.  I see most ports for various
port-specific reasons does their own massaging in their cbranch
and cstore expanders.  Still, the suboptimal compares *should*
be fixed at expand time; better start out right than just
relying on later optimizations.

This kind of change is not acceptable in the current gcc
development stage, at least as a change in generic code.
However, it's problematic enough that I chose to fix this right
now in the CRIS port.  For that, I claim a possibly
long-standing regression.  After this, code before and after
decc0ration is similar enough that I can spot
compare-elimination-efforts and apply regression test-cases
without them drowning in cc0-specific xfailing.

I hope to eventually lift out cris_reduce_compare (renamed) into
say expmed.c, called in e.g. emit_store_flag_1 (replacing the
in-line code) and prepare_cmp_insn.  Later.
---
 gcc/config/cris/cris-protos.h |  1 +
 gcc/config/cris/cris.c| 57 +++
 gcc/config/cris/cris.md   |  6 +++--
 3 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/gcc/config/cris/cris-protos.h b/gcc/config/cris/cris-protos.h
index 2105256cc..6f6d81567 100644
--- a/gcc/config/cris/cris-protos.h
+++ b/gcc/config/cris/cris-protos.h
@@ -38,6 +38,7 @@ extern bool cris_constant_index_p (const_rtx);
 extern bool cris_base_p (const_rtx, bool);
 extern bool cris_base_or_autoincr_p (const_rtx, bool);
 extern bool cris_bdap_index_p (const_rtx, bool);
+extern void cris_reduce_compare (rtx *, rtx *, rtx *);
 extern bool cris_biap_index_p (const_rtx, bool);
 extern bool cris_legitimate_address_p (machine_mode, rtx, bool);
 extern bool cris_store_multiple_op_p (rtx);
diff --git a/gcc/config/cris/cris.c b/gcc/config/cris/cris.c
index 01388b3d0..91cb63c01 100644
--- a/gcc/config/cris/cris.c
+++ b/gcc/config/cris/cris.c
@@ -3053,6 +3053,63 @@ cris_split_movdx (rtx *operands)
   return val;
 }
 
+/* Try to change a comparison against a constant to be against zero, and
+   an unsigned compare against zero to be an equality test.  Beware:
+   only valid for compares of integer-type operands.  Also, note that we
+   don't use operand 0 at the moment.  */
+
+void
+cris_

[2/6 CRIS cc0-preparations] gcc.target/cris/cris.exp (check_effective_target_cc0): New.

[Hans-Peter Nilsson]

To simplify separating the cc0-specific xfails, let's have an
effective-target.

This likely fits all targets.
---
 gcc/testsuite/gcc.target/cris/cris.exp | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/gcc/testsuite/gcc.target/cris/cris.exp 
b/gcc/testsuite/gcc.target/cris/cris.exp
index c85c849e8..52164514d 100644
--- a/gcc/testsuite/gcc.target/cris/cris.exp
+++ b/gcc/testsuite/gcc.target/cris/cris.exp
@@ -25,6 +25,17 @@ if { ![istarget cris-*-*] && ![istarget crisv32-*-*] } then {
 # Load support procs.
 load_lib gcc-dg.exp
 
+# For the time being, provide a means to tell whether the target is "cc0".
+# Some targets may split cbranch and cstore late, but for a cc0-target,
+# all the fun happens at "final" time, so this should be a safe time for
+# a scan.
+proc check_effective_target_cc0 { } {
+return [check_no_messages_and_pattern cc0 "\\(cc0\\)" rtl-final {
+   extern void g (void);
+   void f (int *p, int *q) { *q = *p == 42; if (*p == 7) g (); }
+}]
+}
+
 # If a testcase doesn't have special options, use these.
 global DEFAULT_CFLAGS
 if ![info exists DEFAULT_CFLAGS] then {
-- 
2.11.0

brgds, H-P

[3/6 CRIS cc0-preparations] gcc.target/cris/pr93372-1.c: New test.

[Hans-Peter Nilsson]

This test was separated from the posted and approved patch named
"dbr: Filter-out TARGET_FLAGS_REGNUM from end_of_function_needs"
and applied: it doesn't fail yet.  It differs from the posted
version in that function "g" is commented-out; see the added
comment.
---
 gcc/testsuite/gcc.target/cris/pr93372-1.c | 72 +++
 1 file changed, 72 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-1.c

diff --git a/gcc/testsuite/gcc.target/cris/pr93372-1.c 
b/gcc/testsuite/gcc.target/cris/pr93372-1.c
new file mode 100644
index 0..20aa65e8d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/cris/pr93372-1.c
@@ -0,0 +1,72 @@
+/* Check that all more-or-less trivially fillable delayed-branch-slots
+   are filled. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-not "\tnop" } } */
+
+void *f(void **p)
+{
+  /* Supposedly the memory read finds its way into the "ret"
+ delay-slot. */
+  return *p;
+}
+
+#if 0
+/* Until the negative effects of g:897a73086b2 a.k.a. r10-6395
+   a.k.a. "One more fix for PR 91333 - suboptimal register allocation
+   for inline asm", which appears to have caused a "nop" (unfilled
+   delay-slot) to appear for this function for CRIS-decc0rated (but not
+   CRIS-cc0) and increasing one execution-path by one instruction (and
+   the size of the whole function), it's left out.  It was but a mere
+   attempt to expose the flaw better noticed with xlshrdi3.  It exposes
+   a real issue, just less important.  FIXME: extract to separate test.  */
+int g(int *x, int *y, char *v, int n)
+{
+  int z = *x;
+  int w = *v + 31;
+
+  /* Two branch and two return slots, all filled. */
+  if (z != 23 && z != n+1)
+return *x+*y+24+w;
+  return *y+24+w;
+}
+#endif
+
+/* No problem with the two examples above, but with a more involved
+   example, the epilogue contents matter (the condition-code register
+   clobber was mistaken for a register that needed to be alive). */
+
+struct DWstruct {int low, high;};
+typedef unsigned long long DItype;
+typedef unsigned int USItype;
+
+typedef union
+{
+  struct DWstruct s;
+  DItype ll;
+} DWunion;
+
+unsigned long long
+xlshrdi3 (DItype u, unsigned int b)
+{
+  if (b == 0)
+return u;
+
+  const DWunion uu = {.ll = u};
+  const int bm = (4 * 8) - b;
+  DWunion w;
+
+  if (bm <= 0)
+{
+  w.s.high = 0;
+  w.s.low = (USItype) uu.s.high >> -bm;
+}
+  else
+{
+  const USItype carries = (USItype) uu.s.high << bm;
+  w.s.high = (USItype) uu.s.high >> b;
+  w.s.low = ((USItype) uu.s.low >> b) | carries;
+}
+
+  return w.ll;
+}
-- 
2.11.0

brgds, H-P

[4/6 CRIS cc0-preparations] gcc.target/cris/pr93372-2.c, -5.c, -8.c: New tests.

[Hans-Peter Nilsson]

* gcc.target/cris/pr93372-2.c, gcc.target/cris/pr93372-5.c,
gcc.target/cris/pr93372-8.c: New tests.

These tests fails miserably both at being an example of cc0
eliminating compare instructions, and post-cc0-CRIS at showing a
significant improvement.  They're here to track suboptimal
comparison code for CRIS.
---
 gcc/testsuite/gcc.target/cris/pr93372-2.c | 19 +++
 gcc/testsuite/gcc.target/cris/pr93372-5.c | 19 +++
 gcc/testsuite/gcc.target/cris/pr93372-8.c | 16 
 3 files changed, 54 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-2.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-5.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-8.c

diff --git a/gcc/testsuite/gcc.target/cris/pr93372-2.c 
b/gcc/testsuite/gcc.target/cris/pr93372-2.c
new file mode 100644
index 0..912069c01
--- /dev/null
+++ b/gcc/testsuite/gcc.target/cris/pr93372-2.c
@@ -0,0 +1,19 @@
+/* Check that eliminable compare-instructions are eliminated. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-not "\tcmp|\ttest" { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not "\tnot" { xfail cc0 } } } */
+/* { dg-final { scan-assembler-not "\tlsr" { xfail cc0 } } } */
+
+int f(int a, int b, int *d)
+{
+  int c = a - b;
+
+  /* Whoops!  We get a cmp.d with the original operands here. */
+  *d = (c == 0);
+
+  /* Whoops!  While we don't get a test.d for the result here for cc0,
+ we get a sequence of insns: a move, a "not" and a shift of the
+ subtraction-result, where a simple "spl" would have done. */
+  return c >= 0;
+}
diff --git a/gcc/testsuite/gcc.target/cris/pr93372-5.c 
b/gcc/testsuite/gcc.target/cris/pr93372-5.c
new file mode 100644
index 0..351764c6c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/cris/pr93372-5.c
@@ -0,0 +1,19 @@
+/* Check that eliminable compare-instructions are eliminated. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-not "\tcmp|\ttest|\tor" { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not "\tnot" { xfail cc0 } } } */
+/* { dg-final { scan-assembler-not "\tlsr" { xfail cc0 } } } */
+
+int f(long long int a, long long int b, int *d)
+{
+  long long int c = a - b;
+
+  *d = (c == 0LL);
+
+  /* See pr93372-2.c; we have the same problem for DImode, but it's
+ worsened by the generic double-word "optimizations"; or:ing
+ together the DI parts and then testing the result for the equality
+ test.  */
+  return c >= 0LL;
+}
diff --git a/gcc/testsuite/gcc.target/cris/pr93372-8.c 
b/gcc/testsuite/gcc.target/cris/pr93372-8.c
new file mode 100644
index 0..95abc4b6b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/cris/pr93372-8.c
@@ -0,0 +1,16 @@
+/* Check that eliminable compare-instructions are eliminated. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* See pr93372-5.c regarding the xfails.  */
+/* { dg-final { scan-assembler-not "\tcmp|\ttest|\tor" { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not "\tnot" { xfail cc0 } } } */
+/* { dg-final { scan-assembler-not "\tlsr" { xfail cc0 } } } */
+
+int f(long long int a, long long int b, int *d)
+{
+  long long int c = a + b;
+
+  *d = (c == 0);
+
+  return c >= 0;
+}
-- 
2.11.0

brgds, H-P

[5/6 CRIS cc0-preparations] gcc.target/cris/pr93372-3.c, -4.c...-35.c: New tests.

[Hans-Peter Nilsson]

PR target/93372
* gcc.target/cris/pr93372-3.c, gcc.target/cris/pr93372-4.c,
gcc.target/cris/pr93372-6.c, gcc.target/cris/pr93372-7.c,
gcc.target/cris/pr93372-9.c, gcc.target/cris/pr93372-10.c,
gcc.target/cris/pr93372-11.c, gcc.target/cris/pr93372-12.c,
gcc.target/cris/pr93372-13.c, gcc.target/cris/pr93372-14.c,
gcc.target/cris/pr93372-15.c, gcc.target/cris/pr93372-16.c,
gcc.target/cris/pr93372-17.c, gcc.target/cris/pr93372-18.c,
gcc.target/cris/pr93372-19.c, gcc.target/cris/pr93372-20.c,
gcc.target/cris/pr93372-21.c, gcc.target/cris/pr93372-22.c,
gcc.target/cris/pr93372-23.c, gcc.target/cris/pr93372-24.c,
gcc.target/cris/pr93372-25.c, gcc.target/cris/pr93372-26.c,
gcc.target/cris/pr93372-27.c, gcc.target/cris/pr93372-28.c,
gcc.target/cris/pr93372-29.c, gcc.target/cris/pr93372-30.c,
gcc.target/cris/pr93372-31.c, gcc.target/cris/pr93372-32.c,
gcc.target/cris/pr93372-33.c, gcc.target/cris/pr93372-34.c,
gcc.target/cris/pr93372-35.c: New tests.

Check that somewhat-trivially eliminable compare-instructions
are eliminated, for all instructions.  Note that pr93372-23.c
and pr93372-24.c are xfailed with cc0.
---
 gcc/testsuite/gcc.target/cris/pr93372-10.c |  9 
 gcc/testsuite/gcc.target/cris/pr93372-11.c | 46 
 gcc/testsuite/gcc.target/cris/pr93372-12.c |  7 +++
 gcc/testsuite/gcc.target/cris/pr93372-13.c | 18 +++
 gcc/testsuite/gcc.target/cris/pr93372-14.c | 13 +
 gcc/testsuite/gcc.target/cris/pr93372-15.c | 15 ++
 gcc/testsuite/gcc.target/cris/pr93372-16.c | 42 +++
 gcc/testsuite/gcc.target/cris/pr93372-17.c |  7 +++
 gcc/testsuite/gcc.target/cris/pr93372-18.c | 24 +
 gcc/testsuite/gcc.target/cris/pr93372-19.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-20.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-21.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-22.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-23.c | 21 
 gcc/testsuite/gcc.target/cris/pr93372-24.c | 19 +++
 gcc/testsuite/gcc.target/cris/pr93372-25.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-26.c |  7 +++
 gcc/testsuite/gcc.target/cris/pr93372-27.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-28.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-29.c | 40 ++
 gcc/testsuite/gcc.target/cris/pr93372-3.c  | 15 ++
 gcc/testsuite/gcc.target/cris/pr93372-30.c | 31 +++
 gcc/testsuite/gcc.target/cris/pr93372-31.c | 33 
 gcc/testsuite/gcc.target/cris/pr93372-32.c | 10 
 gcc/testsuite/gcc.target/cris/pr93372-33.c | 10 
 gcc/testsuite/gcc.target/cris/pr93372-34.c | 45 
 gcc/testsuite/gcc.target/cris/pr93372-35.c | 49 +
 gcc/testsuite/gcc.target/cris/pr93372-4.c  | 12 +
 gcc/testsuite/gcc.target/cris/pr93372-6.c  | 18 +++
 gcc/testsuite/gcc.target/cris/pr93372-7.c  | 85 ++
 gcc/testsuite/gcc.target/cris/pr93372-9.c  |  9 
 31 files changed, 641 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-10.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-11.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-12.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-13.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-14.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-15.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-16.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-17.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-18.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-19.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-20.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-21.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-22.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-23.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-24.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-25.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-26.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-27.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-28.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-29.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-3.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-30.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-31.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-32.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-33.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-34.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-35.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-4.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-6.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-7.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-9.c

diff --git a/gcc/testsuite/gcc.target/cris/pr93372-10.c 
b/gcc/testsuite/gcc.target/cris/pr93372-10.c
ne

[6/6 CRIS cc0-preparations] gcc.target/cris/dbr-1.c: New test.

[Hans-Peter Nilsson]

Random spotting.  Exposes the missed benefit for delay-slot
filling of a splitter for indexed addressing mode (the [rN+M]
one).  To be considered for common instructions and perhaps only
for suitable M; at least +-63 is obious (when there's a register
available) as both the original and the add fit in delay-slots.

I forgot to mention that all previously posted patches have been
regression-tested for cris-elf and all are committed.

---
 gcc/testsuite/gcc.target/cris/dbr-1.c | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/cris/dbr-1.c

diff --git a/gcc/testsuite/gcc.target/cris/dbr-1.c 
b/gcc/testsuite/gcc.target/cris/dbr-1.c
new file mode 100644
index 0..9f79a7627
--- /dev/null
+++ b/gcc/testsuite/gcc.target/cris/dbr-1.c
@@ -0,0 +1,11 @@
+/* Check that delayed-branch-slot is able to fill a trivially fillable
+   slot.  The xfail is due to the "move.d [$r10+4],$r10" not being split
+   up into "addq 4,$r10" and "move.d [$r10],$r10"; both slottable and of
+   the same actual cost in size and cycles as the unsplit insn.  */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-not "\tnop" { xfail *-*-* } } } */
+void *f(void **p)
+{
+  return p[1];
+}
-- 
2.11.0

brgds, H-P

[PATCH] regalloc/debug: fix buggy print_hard_reg_set

[Hans-Peter Nilsson]

I was using ira-conflicts.c:print_hard_reg_set with a local
patch to gdbinit.in in a debug-session, and noticed the
erroneous output.  I see there's an almost identical function in
ira-color.c and on top of that, there's another function by the
same name and with similar semantics in sel-sched-dump.c, but
the last one doesn't try to print ranges.

I'm guessing the dump functions have been used with targets that
have "impossible" registers at FIRST_PSEUDO_REGISTER - 1.  CRIS
happens to have the condition-code register at
FIRST_PSEUDO_REGISTER - 1; not allocatable but appears a lot in
(clobbered) register sets after decc0ration.

Before, for a target with FIRST_PSEUDO_REGISTER 20, you'd get
"19-18" for (1<<19).  For (1<<18)|(1<<19), you'd get "18".

The diff is unfortunately hairy, but I hope you agree the code
is a bit clearer.  I'm deliberately not consolidating the dump
functions as IMHO that's too much a matter of taste.

* ira-conflicts.c (print_hard_reg_set): Correct output for sets
including FIRST_PSEUDO_REGISTER - 1.
* ira-color.c (print_hard_reg_set): Ditto.

Ok to commit?

---
 gcc/ira-color.c | 22 --
 gcc/ira-conflicts.c | 22 --
 2 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index 4a726dc7c..0d88c1efe 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -478,24 +478,26 @@ first_common_ancestor_node (allocno_hard_regs_node_t 
first,
 static void
 print_hard_reg_set (FILE *f, HARD_REG_SET set, bool new_line_p)
 {
-  int i, start;
+  int i, start, end;
 
-  for (start = -1, i = 0; i < FIRST_PSEUDO_REGISTER; i++)
+  for (start = end = -1, i = 0; i < FIRST_PSEUDO_REGISTER; i++)
 {
-  if (TEST_HARD_REG_BIT (set, i))
+  bool reg_included = TEST_HARD_REG_BIT (set, i);
+
+  if (reg_included)
{
- if (i == 0 || ! TEST_HARD_REG_BIT (set, i - 1))
+ if (start == -1)
start = i;
+ end = i;
}
-  if (start >= 0
- && (i == FIRST_PSEUDO_REGISTER - 1 || ! TEST_HARD_REG_BIT (set, i)))
+  if (start >= 0 && (!reg_included || i == FIRST_PSEUDO_REGISTER - 1))
{
- if (start == i - 1)
+ if (start == end)
fprintf (f, " %d", start);
- else if (start == i - 2)
-   fprintf (f, " %d %d", start, start + 1);
+ else if (start == end + 1)
+   fprintf (f, " %d %d", start, end);
  else
-   fprintf (f, " %d-%d", start, i - 1);
+   fprintf (f, " %d-%d", start, end);
  start = -1;
}
 }
diff --git a/gcc/ira-conflicts.c b/gcc/ira-conflicts.c
index 11d3a86dc..0220e725e 100644
--- a/gcc/ira-conflicts.c
+++ b/gcc/ira-conflicts.c
@@ -611,25 +611,27 @@ build_conflicts (void)
 static void
 print_hard_reg_set (FILE *file, const char *title, HARD_REG_SET set)
 {
-  int i, start;
+  int i, start, end;
 
   fputs (title, file);
-  for (start = -1, i = 0; i < FIRST_PSEUDO_REGISTER; i++)
+  for (start = end = -1, i = 0; i < FIRST_PSEUDO_REGISTER; i++)
 {
-  if (TEST_HARD_REG_BIT (set, i))
+  bool reg_included = TEST_HARD_REG_BIT (set, i);
+
+  if (reg_included)
{
- if (i == 0 || ! TEST_HARD_REG_BIT (set, i - 1))
+ if (start == -1)
start = i;
+ end = i;
}
-  if (start >= 0
- && (i == FIRST_PSEUDO_REGISTER - 1 || ! TEST_HARD_REG_BIT (set, i)))
+  if (start >= 0 && (!reg_included || i == FIRST_PSEUDO_REGISTER - 1))
{
- if (start == i - 1)
+ if (start == end)
fprintf (file, " %d", start);
- else if (start == i - 2)
-   fprintf (file, " %d %d", start, start + 1);
+ else if (start == end + 1)
+   fprintf (file, " %d %d", start, end);
  else
-   fprintf (file, " %d-%d", start, i - 1);
+   fprintf (file, " %d-%d", start, end);
  start = -1;
}
 }
-- 
2.11.0

brgds, H-P

[cris-decc0 0/14] A set of compare-elimination-fixes.

[Hans-Peter Nilsson]

I just rebased and updated the vendors/axis branch
axis/cris-decc0 with the following commits, which should bring
back compare-elimination results to that of cc0 on master.

With the exception of the bit-test patterns (btst / btstq which
is more of a "combine" matter), everything is centered around
working together with the "cmpelim" pass with the help of
define_subst attributes.  Regression test-cases have already
been committed to master (the recently committed pr93372-*
tests), covering all patterns but not all CCmodes or conditions.
All patches regtested for cris-elf, at a smaller granularity
than these partially squashed commits, but naturally with
regressions for the pr93372-* testcases until the last one of
these commits.

No performance tests yet though, but I expect axis/cris-decc0 to
be a win over master, since as I've mentioned before, I see
improvements in register-allocation already in libgcc, which
should get back what's lost in all the special patterns I
deleted.  I haven't looked into the cause, but it shouldn't
surprise anyone that there's some noticeable goodies inside
something to the effect of #ifndef HAVE_cc0, even with IRA.
(Conversion to LRA is way down on the TODO list.)

It's a bit unfortunate that so many pattern names are now
obfuscated with the define_subst_attr attributes (like
"zero_extendsi2"
instead of "zero_extendsi2"), but I'll take that single
line change in patterns over duplicated or triplicated patterns.

brgds, H-P

[cris-decc0 1/14] cris: Emit trivial btstq expected by gcc.target/cris/sync-2i.c, sync-2c.c

[Hans-Peter Nilsson]

PR target/93372
* config/cris/cris.md (zcond): New code_iterator.
("*cbranch4_btstq"): New insn_and_split.

As the added FIXME says, the new insn_and_split generates only a
small subset of the bit-tests that can be matched by "*btst" and
that were emitted by the undecc0rated cris.md at combine-time,
but it's naturally separable from a general variant by being
just what's needed for the test-cases that were previously
xfailed, and that no additional CCmodes are required.
---
 gcc/config/cris/cris.md | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index 7690d7f06..0b42197a9 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -178,6 +178,7 @@ (define_code_iterator shiftrt [ashiftrt lshiftrt])
 (define_code_attr shlr [(ashiftrt "ashr") (lshiftrt "lshr") (ashift "ashl")])
 (define_code_attr slr [(ashiftrt "asr") (lshiftrt "lsr") (ashift "lsl")])
 
+(define_code_iterator zcond [eq ne])
 (define_code_iterator ncond [eq ne gtu ltu geu leu])
 (define_code_iterator ocond [gt le])
 (define_code_iterator rcond [lt ge])
@@ -1934,6 +1935,32 @@ (define_insn_and_split "*cbranch4"
  (pc)))]
   "")
 
+;; FIXME: this matches only a subset of what the "*btst" pattern can handle.
+(define_insn_and_split "*cbranch4_btstq"
+  [(set (pc)
+   (if_then_else
+(zcond
+ (zero_extract:BWD
+  (match_operand:BWD 0 "register_operand" "r")
+  (match_operand 1 "const_int_operand" "Kc")
+  (const_int 0))
+ (const_int 0))
+(label_ref (match_operand 2 ""))
+(pc)))
+   (clobber (reg:CC CRIS_CC0_REGNUM))]
+  ""
+  "#"
+  "&& reload_completed"
+  [(set (reg:CC CRIS_CC0_REGNUM)
+   (compare:CC
+(zero_extract:SI (match_dup 0) (match_dup 1) (const_int 0))
+(const_int 0)))
+   (set (pc)
+   (if_then_else (zcond (reg:CC CRIS_CC0_REGNUM) (const_int 0))
+ (label_ref (match_dup 3))
+ (pc)))]
+  "")
+
 
 ;; We suffer from the same overflow-bit-gets-in-the-way problem as
 ;; e.g. m68k, so we have to check if overflow bit is set on all "signed"
-- 
2.11.0

brgds, H-P

[cris-decc0 2/14] cris: Define TARGET_FLAGS_REGNUM.

[Hans-Peter Nilsson]

* config/cris/cris.c (TARGET_FLAGS_REGNUM): Define.

This made a whole lot of difference regarding regressions in the
delay-slot filling.  Before this, comparing __lshrdi3 for v10
before/after decc0ration and other nearby functions was worse by
several missing delay-slot fills; now down to 1.

Also, add a comment about *not* defining
TARGET_FIXED_CONDITION_CODE_REGS.
---
 gcc/config/cris/cris.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/gcc/config/cris/cris.c b/gcc/config/cris/cris.c
index 9fdabe2ac..eecda8384 100644
--- a/gcc/config/cris/cris.c
+++ b/gcc/config/cris/cris.c
@@ -219,6 +219,16 @@ int cris_cpu_version = CRIS_DEFAULT_CPU_VERSION;
 #undef TARGET_PREFERRED_RELOAD_CLASS
 #define TARGET_PREFERRED_RELOAD_CLASS cris_preferred_reload_class
 
+/* We don't define TARGET_FIXED_CONDITION_CODE_REGS, as at the time of
+   this writing, it has an effect only on pre-reload CSE and when
+   scheduling (and for "macro fusion" at that).  Neither applies for
+   CRIS so don't waste compilation cycles on enabling a pass that does
+   nothing.  Beware of changes to its usage; it may make sense to enable
+   "later".  */
+
+#undef TARGET_FLAGS_REGNUM
+#define TARGET_FLAGS_REGNUM CRIS_CC0_REGNUM
+
 #undef TARGET_REGISTER_MOVE_COST
 #define TARGET_REGISTER_MOVE_COST cris_register_move_cost
 #undef TARGET_MEMORY_MOVE_COST
-- 
2.11.0

brgds, H-P

[cris-decc0 3/14] config/cris/cris.h (REVERSIBLE_CC_MODE): Define to true.

[Hans-Peter Nilsson]

* config/cris/cris.h (REVERSIBLE_CC_MODE): Define to true.

For some reason (like a buglet in the user in jump.c), defining this makes
a beneficial difference in ledf2, thus this is separated to its own commit.
Also, add comment on (not defining) REVERSE_CONDITION.
---
 gcc/config/cris/cris.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/cris/cris.h b/gcc/config/cris/cris.h
index e721d12d0..bc07dd541 100644
--- a/gcc/config/cris/cris.h
+++ b/gcc/config/cris/cris.h
@@ -701,6 +701,9 @@ struct cum_args {int regs;};
 /* FIXME: Maybe define TARGET_CANONICALIZE_COMPARISON later, when
playing with optimizations.  Definitely define SELECT_CC_MODE.  */
 
+#define REVERSIBLE_CC_MODE(MODE) true
+
+/* No known need to define REVERSE_CONDITION, the default is good.  */
 
 /* Node: Costs */
 
-- 
2.11.0


brgds, H-P

[cris-decc0 4/14] cris.md: Post-reload, split/generate clobberless memory destination moves

[Hans-Peter Nilsson]

* config/cris/cris.md ("movsi"): For memory destination
post-reload, generate clobberless variant.
("*mov_tomem_split"): New split.
("*mov_tomem"): New insn.
("enabled", mov_tomem_enabled): Define and use to exclude "x" ->
"Q>m" for less-than-SImode.

In preparation for compare-elimination (for it to be obviously
useful), we have to have some common insn in-between that
doesn't clobber condition-codes.  A move to memory is an obvious
choice.  Note the FIXME: we can do this for a zero source too;
later.
---
 gcc/config/cris/cris.md | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index 0b42197a9..3de2f5a13 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -147,6 +147,7 @@ (define_delay (eq_attr "slottable" "has_return_slot")
(not (match_test "dead_or_set_regno_p (insn, CRIS_SRP_REGNUM)")))
(nil) (nil)])
 
+(define_attr "enabled" "no,yes" (const_string "yes"))
 
 ;; Iterator definitions.
 
@@ -445,6 +446,15 @@ (define_expand "movsi"
   && operands[1] != const0_rtx
   && can_create_pseudo_p ())
 operands[1] = force_reg (SImode, operands[1]);
+
+   /* At post-reload time, we'll get here for e.g. split multi-mode insns
+  with a memory destination.  Go directly to the clobber-less variant.
+  FIXME: Also applies to zero source.  */
+   if (MEM_P (operands[0]) && reload_completed)
+ {
+emit_insn (gen_rtx_SET (operands[0], operands[1]));
+DONE;
+ }
 })
 
 (define_insn "*movsi_internal"
@@ -650,6 +660,43 @@ (define_insn "movsf"
move %1,%0
move %1,%0"
   [(set_attr "slottable" 
"yes,yes,yes,yes,yes,no,no,no,yes,yes,yes,no,yes,no")])
+
+;; Post-reload, for memory destinations, split the clobber-variant and
+;; get rid of the clobber.
+
+(define_split ;; "*mov_tomem_split"
+  [(set (match_operand:BWD 0 "memory_operand")
+   (match_operand:BWD 1 "nonmemory_operand"))
+   (clobber (reg:CC CRIS_CC0_REGNUM))]
+  "reload_completed"
+  [(set (match_dup 0) (match_dup 1))]
+  "")
+
+;; Exclude moving special-registers to memory from matching for
+;; less-than-SImode, as they are SImode only (or actually, the size of
+;; the register, but the ones free for "x" are naturally SImode; see
+;; special measures taken for reload).
+;; This might be a belt-and-suspenders thing, as a move from special
+;; register to memory in less-than-SImode should not have made it here.
+
+(define_mode_attr mov_tomem_enabled
+  [(SI "yes,yes,yes,yes,yes,yes")
+   (HI "yes,yes,no,yes,yes,no")
+   (QI "yes,yes,no,yes,yes,no")])
+
+(define_insn "*mov_tomem"
+  [(set (match_operand:BWD 0 "memory_operand"   "=Q>,Q>,Q>,m,m,m")
+   (match_operand:BWD 1 "nonmemory_operand" "M, r, x, M,r,x"))]
+  "reload_completed"
+  "@
+   clear %0
+   move %1,%0
+   move %1,%0
+   clear %0
+   move %1,%0
+   move %1,%0"
+  [(set_attr "slottable" "yes,yes,yes,no,no,no")
+   (set_attr "enabled" "")])
 
 ;; Movem patterns.  Primarily for use in function prologue and epilogue.
 ;; Unfortunately, movem stores R0 in the highest memory location, thus
-- 
2.11.0

brgds, H-P

[cris-decc0 5/14] cris.md: Post-reload, split/generate clobberless zero source moves

[Hans-Peter Nilsson]

* config/cris/cris.md ("movsi"): For a zero-source post-reload,
generate a clobberless variant.
("*mov_fromzero_split"): New split.
("*mov_fromzero"): New insn.

A separated follow-up to the previous change: Also emit moves
from zero as not clobbering condition-codes.
---
 gcc/config/cris/cris.md | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index 3de2f5a13..bf2cf9663 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -449,8 +449,9 @@ (define_expand "movsi"
 
/* At post-reload time, we'll get here for e.g. split multi-mode insns
   with a memory destination.  Go directly to the clobber-less variant.
-  FIXME: Also applies to zero source.  */
-   if (MEM_P (operands[0]) && reload_completed)
+  FIXME: Also applies to special-register source or destination.  */
+   if (reload_completed
+   && (MEM_P (operands[0]) || operands[1] == const0_rtx))
  {
 emit_insn (gen_rtx_SET (operands[0], operands[1]));
 DONE;
@@ -697,6 +698,20 @@ (define_insn "*mov_tomem"
move %1,%0"
   [(set_attr "slottable" "yes,yes,yes,no,no,no")
(set_attr "enabled" "")])
+
+(define_split ;; "*mov_fromzero_split"
+  [(set (match_operand:BWD 0 "register_operand") (const_int 0))
+   (clobber (reg:CC CRIS_CC0_REGNUM))]
+  "reload_completed
+   && REGNO(operands[0]) <= CRIS_LAST_GENERAL_REGISTER"
+  [(set (match_dup 0) (const_int 0))]
+  "")
+
+(define_insn "*mov_fromzero"
+  [(set (match_operand:BWD 0 "register_operand" "=r") (const_int 0))]
+  "reload_completed"
+  "clear %0"
+  [(set_attr "slottable" "yes")])
 
 ;; Movem patterns.  Primarily for use in function prologue and epilogue.
 ;; Unfortunately, movem stores R0 in the highest memory location, thus
-- 
2.11.0

brgds, H-P

[cris-decc0 6/14] cris: Introduce CC_NZVCmode and CC_NZmode.

[Hans-Peter Nilsson]

Prepare for cmpelim pass to eliminate redundant compare insns.
* config/cris/cris-modes.def: New file.
* config/cris/cris-protos.h (cris_select_cc_mode): Declare.
(cris_notice_update_cc): Remove left-over declaration.
* config/cris/cris.c (TARGET_CC_MODES_COMPATIBLE): Define.
(cris_select_cc_mode, cris_cc_modes_compatible): New functions.
* config/cris/cris.h (SELECT_CC_MODE): Define.
* config/cris/cris.md (NZSET, NZUSE, NZVCSET, NZVCUSE): New
mode_iterators.
(cond): New code_iterator.
(nzcond): Replacement for incorrect ncond.  All callers changed.
(nzvccond): Replacement for ocond.  All callers changed.
(rnzcond): Replacement for rcond.  All callers changed.
(xCC): New code_attr.
(cmp_op1c, cmp_op0c): Renumber from cmp_op1c and cmp_op2c.  All
users changed.
("*cmpdi"): Rename from "*cmpdi".  Replace
CCmode with iteration over NZVCSET.
("*cmp_ext"): Similarly; rename from
"*cmp_ext".
("*cmpsi"): Similarly, from "*cmpsi".
("*cmp"): Similarly from "*cmp".
("*btst"): Similarly, from "*btst".
("*cbranch4"): Rename from "*cbranch4",
iterating over cond instead of matching the comparison with
ordered_comparison_operator.
("*cbranch4_btstq"): Correct label operand number.
("b"): Rename from "b", iterating
over NZUSE.
("b"): Similarly from "b", over
NZVCUSE.  Remove FIXME.
("*b_reversed"): Similarly from
"*b_reversed", over NZUSE.
("*b_reversed"): Similarly from
"*b_reversed", over NZVCUSE.  Remove FIXME.
("b"): Similarly from "b",
over NZUSE.  Reinstate "b" vs. "b" mnemonic choice,
depending on CC_NZmode vs. CCmode.  Remove FIXME.
("*b_reversed"): Similarly from
"*b_reversed", over NZUSE.
("*cstore4"): Rename from "*cstore4",
iterating over cond instead of matching the comparison with
ordered_comparison_operator.
("*s"): Rename from "*s",
iterating over NZUSE.
("*s"): Similar from "*s", over
NZUSE.  Reinstate "b" vs. "b" mnemonic choice,
depending on CC_NZmode vs. CCmode.
("*s"): Simlar from "*s", over
NZVCUSE.  Remove FIXME.

This is just the framework bits of splitting CCmode into classes
where the cc-setter can merge mode (CCmode), classes where the
cc-setter must set V and C "usefully" (as well as N and Z flags)
and classes where the cc-setter is something like an arithmetic
instruction, where N and Z are valid but C and V reflect the
operation rather than a compare of the result with zero.  This
should yield identical or near-identical code.

The old split of conditions into the ncond and ocond sets took
into account the transformations done by final.c:alter_cond from
cc_status.flags & CC_NO_OVERFLOW, and wasn't a reflection of the
hardware description of the conditions (i.e. whether V mattered
or not).
---
 gcc/config/cris/cris-modes.def |  54 +
 gcc/config/cris/cris-protos.h  |   2 +-
 gcc/config/cris/cris.c |  71 
 gcc/config/cris/cris.h |   4 +-
 gcc/config/cris/cris.md| 178 +
 5 files changed, 237 insertions(+), 72 deletions(-)
 create mode 100644 gcc/config/cris/cris-modes.def

diff --git a/gcc/config/cris/cris-modes.def b/gcc/config/cris/cris-modes.def
new file mode 100644
index 0..b0e426159
--- /dev/null
+++ b/gcc/config/cris/cris-modes.def
@@ -0,0 +1,54 @@
+/* Definitions of target machine for GNU compiler, for CRIS.
+   Copyright (C) 2002-2020 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/* Node: Condition Code */
+
+/* The mode used for condition-codes depends on both the way the
+   condition-codes are generated (the CC-setter, typically the compare
+   instruction), and used (the CC-user, typically a branch).  For CRIS, we
+   have ordinary compares and incidental condition-code settings from
+   preceding instructions, setting a subset of N, Z, V and C to usable
+   values, from the perspective of comparing the result against zero
+   (fpcraz).  The two subsets meaningful to gcc are all of N, Z, V, C
+   versus just N, Z; some CC-users care only about N and/or Z and some
+   that care about at least one of those flags together with V and/or C.
+   (FIXME: the result of testing a single bit using the btst instruction
+   should be described as a separate mode.)
+
+   The plain "CC_MODE (CC)" (which is always present in gcc), is used to
+   reflect the "unoptimized" state, where the CC-setter is a compare
+   against zero and the CC-user is any branch or s instruction,
+   before 

[cris-decc0 7/14] cris: Enable *movsi_internal to set condition codes.

[Hans-Peter Nilsson]

* config/cris/cris.md ("cc"): Comment on new use.
("cc_enabled"): New attribute.
("enabled"): Make default fall back to cc_enabled.
("setnz", "ccnz", "setnzvc", "ccnzvc", "setcc", ""): New
default_subst_attrs.
("setnz_subst", "setnzvc_subst", "setcc_subst"): New default_subst.
("*movsi_internal"): Rename from
"*movsi_internal".  Correct contents of, and rename attribute
"cc" to "cc".

Completion of, and first use of, the CRIS-specific parts of the
condition-code-setting framework, making use of the define_subst
machinery and the cmpelim optimization pass.  This round, just
moves in SImode.  Note the re-use of the cc0 era "cc" attribute
(tweaks needed).
---
 gcc/config/cris/cris.md | 61 +
 1 file changed, 56 insertions(+), 5 deletions(-)

diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index 362d63f6d..bee9e9735 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -117,10 +117,16 @@ (define_attr "slottable" "no,yes,has_slot,has_return_slot"
   (const_string "no"))
 
 ;; We also need attributes to sanely determine the condition code
-;; state.
-
+;; state.  This attribute isn't used as-is, just as a template,
+;; effectively a dummy except in a substitution setting CRIS_CC0_REGNUM
+;; to a specific value.
 (define_attr "cc" "none,clobber,normal" (const_string "normal"))
 
+;; The attribute "_enabled" is appended to "cc", forming "cc_enabled" to
+;; pick out certain alternatives when generating a useful
+;; condition-code-setting.  See the "enabled" attribute.
+(define_attr "cc_enabled" "none,clobber,normal" (const_string "normal"))
+
 ;; At the moment, this attribute is just used to help bb-reorder do its
 ;; work; the default 0 doesn't help it.  Many insns have other lengths,
 ;; though none are shorter.
@@ -147,7 +153,11 @@ (define_delay (eq_attr "slottable" "has_return_slot")
(not (match_test "dead_or_set_regno_p (insn, CRIS_SRP_REGNUM)")))
(nil) (nil)])
 
-(define_attr "enabled" "no,yes" (const_string "yes"))
+(define_attr "enabled" "no,yes"
+  (if_then_else
+   (eq_attr "cc_enabled" "normal")
+   (const_string "yes")
+   (const_string "no")))
 
 ;; Iterator definitions.
 
@@ -225,6 +235,44 @@ (define_code_attr xCC [(eq "CC") (ne "CC") (gtu "CC") (ltu 
"CC_NZVC")
   (geu "CC_NZVC") (leu "CC") (lt "CC") (ge "CC")
   (gt "CC_NZVC") (le "CC_NZVC")])
 
+;; Substitutions to describe condition-code settings.
+
+(define_subst_attr "setnz" "setnz_subst" "" "_setnz")
+(define_subst_attr "ccnz" "setnz_subst" "" "_enabled")
+
+(define_subst "setnz_subst"
+  [(set (match_operand 0)
+   (match_operand 1))
+   (clobber (reg:CC CRIS_CC0_REGNUM))]
+  "reload_completed"
+  [(set (reg:CC_NZ CRIS_CC0_REGNUM)
+   (compare:CC_NZ (match_dup 1) (const_int 0)))
+   (set (match_operand 0) (match_operand 1))])
+
+(define_subst_attr "setnzvc" "setnzvc_subst" "" "_setnzvc")
+(define_subst_attr "ccnzvc" "setnzvc_subst" "" "_enabled")
+
+(define_subst "setnzvc_subst"
+  [(set (match_operand 0)
+   (match_operand 1))
+   (clobber (reg:CC CRIS_CC0_REGNUM))]
+  "reload_completed"
+  [(set (reg:CC_NZVC CRIS_CC0_REGNUM)
+   (compare:CC_NZVC (match_dup 1) (const_int 0)))
+   (set (match_operand 0) (match_operand 1))])
+
+(define_subst_attr "setcc" "setcc_subst" "" "_setcc")
+(define_subst_attr "" "setcc_subst" "" "_enabled")
+
+(define_subst "setcc_subst"
+  [(set (match_operand 0)
+   (match_operand 1))
+   (clobber (reg:CC CRIS_CC0_REGNUM))]
+  "reload_completed"
+  [(set (reg:CC CRIS_CC0_REGNUM)
+   (compare:CC (match_dup 1) (const_int 0)))
+   (set (match_operand 0) (match_operand 1))])
+
 ;; Operand and operator predicates.
 
 (include "predicates.md")
@@ -495,7 +543,9 @@ (define_expand "movsi"
  }
 })
 
-(define_insn "*movsi_internal"
+;; We provide CC, CC_NZ and CC_NZVC variants, as moves clear V and C
+;; and the result is thus usable in a compare against 0.
+(define_insn "*movsi_internal"
   [(set
 (match_operand:SI 0 "nonimmediate_operand"
  "=r,r, r,Q>,r,Q>,g,r,r,g,rQ>,x,  m,x")
@@ -554,7 +604,8 @@ (define_insn "*movsi_internal"
 }
 }
   [(set_attr "slottable" "yes,yes,yes,yes,yes,yes,no,no,no,no,yes,yes,no,no")
-   (set_attr "cc" "*,*,*,*,*,*,*,*,*,*,none,none,none,none")])
+   (set_attr "cc"
+"*,*,none,none,*,none,none,*,*,none,none,none,none,none")])
 
 ;; FIXME: See movsi.
 
-- 
2.11.0

brgds, H-P

[cris-decc0 8/14] cris: Enable movhi and movqi to set condition codes. Anonymize.

[Hans-Peter Nilsson]

* config/cris/cris.md ("anz", "anzvc", "acc"): New define_subst_attrs.
("movhi"): Rename from
"movhi".  Rename "cc" attribute to "cc".
("movqi"): Similar from
"movqi".  Correct contents of, and rename "cc" attribute to
"cc".
("*b"): Rename from "b".
("*b"): Rename from "b".
("*b"): Rename from "*b".

Like with movsi_internal.  Looks like the "cc" attribute didn't
need tweaking for "movhi", but did for "movqi".  N.B.: disabled
alternatives make cause a later alternative to match.

Also, non-anonymous insns get declarations and gen_* functions.
We don't want that; even if it doesn't affect generated code
it's sloppy.  (This may or may not be preferable to the
name decorations obfuscating standard pattern names.)

Also anonymize left-over non-anonymous branches; they haven't
been needing names since the cbranch pattern was made the
generic method.
---
 gcc/config/cris/cris.md | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index bee9e9735..5f77bc9e0 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -239,6 +239,7 @@ (define_code_attr xCC [(eq "CC") (ne "CC") (gtu "CC") (ltu 
"CC_NZVC")
 
 (define_subst_attr "setnz" "setnz_subst" "" "_setnz")
 (define_subst_attr "ccnz" "setnz_subst" "" "_enabled")
+(define_subst_attr "anz" "setnz_subst" "" "*")
 
 (define_subst "setnz_subst"
   [(set (match_operand 0)
@@ -251,6 +252,7 @@ (define_subst "setnz_subst"
 
 (define_subst_attr "setnzvc" "setnzvc_subst" "" "_setnzvc")
 (define_subst_attr "ccnzvc" "setnzvc_subst" "" "_enabled")
+(define_subst_attr "anzvc" "setnzvc_subst" "" "*")
 
 (define_subst "setnzvc_subst"
   [(set (match_operand 0)
@@ -263,6 +265,7 @@ (define_subst "setnzvc_subst"
 
 (define_subst_attr "setcc" "setcc_subst" "" "_setcc")
 (define_subst_attr "" "setcc_subst" "" "_enabled")
+(define_subst_attr "acc" "setcc_subst" "" "*")
 
 (define_subst "setcc_subst"
   [(set (match_operand 0)
@@ -609,7 +612,7 @@ (define_insn "*movsi_internal"
 
 ;; FIXME: See movsi.
 
-(define_insn "movhi"
+(define_insn "movhi"
   [(set
 (match_operand:HI 0 "nonimmediate_operand" "=r,r, 
r,Q>,r,Q>,r,r,r,g,g,r,r,x")
 (match_operand:HI 1 "general_operand"  "r,Q>,M,M, I,r, 
L,O,n,M,r,g,x,r"))
@@ -649,7 +652,7 @@ (define_insn "movhi"
   }
 }
   [(set_attr "slottable" "yes,yes,yes,yes,yes,yes,no,yes,no,no,no,no,yes,yes")
-   (set_attr "cc" "*,*,none,none,*,none,*,clobber,*,none,none,*,none,none")])
+   (set_attr "cc" 
"*,*,none,none,*,none,*,clobber,*,none,none,*,none,none")])
 
 (define_insn "movstricthi"
   [(set
@@ -685,7 +688,7 @@ (define_expand "reload_out"
   ""
   "")
 
-(define_insn "movqi"
+(define_insn "movqi"
   [(set (match_operand:QI 0 "nonimmediate_operand" "=r,Q>,r, 
r,Q>,r,g,g,r,r,r,x")
(match_operand:QI 1 "general_operand"   "r,r, Q>,M,M, 
I,M,r,O,g,x,r"))
(clobber (reg:CC CRIS_CC0_REGNUM))]
@@ -704,7 +707,8 @@ (define_insn "movqi"
move %1,%0
move %1,%0"
   [(set_attr "slottable" "yes,yes,yes,yes,yes,yes,no,no,yes,no,yes,yes")
-   (set_attr "cc" "*,*,*,*,*,*,*,*,clobber,*,none,none")])
+   (set_attr "cc"
+"*,none,*,none,none,*,none,none,clobber,*,none,none")])
 
 (define_insn "movstrictqi"
   [(set (strict_low_part
@@ -2117,7 +2121,7 @@ (define_insn_and_split "*cbranch4_btstq"
 ;; e.g. m68k, so we have to check if overflow bit is set on all "signed"
 ;; conditions.
 
-(define_insn "b"
+(define_insn "*b"
   [(set (pc)
(if_then_else (zcond (reg:NZUSE CRIS_CC0_REGNUM)
 (const_int 0))
@@ -2127,7 +2131,7 @@ (define_insn "b"
   "b %l0%#"
   [(set_attr "slottable" "has_slot")])
 
-(define_insn "b"
+(define_insn "*b"
   [(set (pc)
(if_then_else (nzvccond (reg:NZVCUSE CRIS_CC0_REGNUM)
 (const_int 0))
@@ -2137,7 +2141,7 @@ (define_insn "b"
   "b %l0%#"
   [(set_attr "slottable" "has_slot")])
 
-(define_insn "b"
+(define_insn "*b"
   [(set (pc)
(if_then_else (rnzcond (reg:NZUSE CRIS_CC0_REGNUM)
 (const_int 0))
-- 
2.11.0

brgds, H-P

[cris-decc0 9/14] cris: Enable extend operations to SImode to set condition codes.

[Hans-Peter Nilsson]

* config/cris/cris.md
("extendsi2"):
Rename from "extendsi2".
("zero_extendsi2"):
Similar, from "zero_extendsi2".

Enable dropping of compares with zero of the result, through the
three CCmode substitutions and the cmpelim pass.
---
 gcc/config/cris/cris.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index 5f77bc9e0..2f3f328f5 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -856,7 +856,7 @@ (define_insn "extenddi2"
   ""
   "movs %1,%M0\;smi %H0\;neg.d %H0,%H0")
 
-(define_insn "extendsi2"
+(define_insn "extendsi2"
   [(set (match_operand:SI 0 "register_operand" "=r,r,r")
(sign_extend:SI (match_operand:BW 1 "general_operand" "r,Q>,g")))
(clobber (reg:CC CRIS_CC0_REGNUM))]
@@ -879,7 +879,7 @@ (define_insn "extendqihi2"
 ;; Zero-extend.  The DImode ones are synthesized by gcc, so we don't
 ;; specify them here.
 
-(define_insn "zero_extendsi2"
+(define_insn "zero_extendsi2"
   [(set (match_operand:SI 0 "register_operand" "=r,r,r")
(zero_extend:SI
 (match_operand:BW 1 "nonimmediate_operand" "r,Q>,m")))
-- 
2.11.0

brgds, H-P

[cris-decc0 10/14] cris: Enable additions and subtractions to set condition codes.

[Hans-Peter Nilsson]

* config/cris/cris.md ("*adddi3"): Rename from "*adddi3".
cris: Enable 32-bit addition to set condition codes.
("*subdi3"): Similarly from "*subdi3".
("*addsi3"): Similarly from "*addsi3".
("*subsi3"): Similarly from "*subsi3".
("*addhi3"): Similarly from "*addhi3" and decorate the
"cc" attribute to "cc".
("*addqi3"): Similarly from "*addqi3".
("*sub3"): Similarly from "*sub3".

Enabling dropping of compares with zero of the result, through
the non-VC-setting CCmode substitution.  Beware that the
substitutions for 8- and 16-bit patterns will in some cases be
size-neutral; e.g. replacing an "addq 1..63,$rN" + "test.w $rN"
or "subq 1..63,$rN" + "test.w $rN" with an "add.w -63..63,$rN".
---
 gcc/config/cris/cris.md | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index 2f3f328f5..8652f3586 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -913,7 +913,7 @@ (define_expand "adddi3"
   ""
   "")
 
-(define_insn "*adddi3"
+(define_insn "*adddi3"
   [(set (match_operand:DI 0 "register_operand" "=r,r,r,&r,&r")
(plus:DI (match_operand:DI 1 "register_operand" "%0,0,0,0,r")
 (match_operand:DI 2 "general_operand" "J,N,P,g,!To")))
@@ -936,7 +936,7 @@ (define_expand "add3"
   ""
   "")
 
-(define_insn "*addsi3"
+(define_insn "*addsi3"
   [(set (match_operand:SI 0 "register_operand"  "=r,r, r,r,r,r,r,  r")
(plus:SI
 (match_operand:SI 1 "register_operand" "%0,0, 0,0,0,0,r,  r")
@@ -989,7 +989,7 @@ (define_insn "*addsi3"
 }
  [(set_attr "slottable" "yes,yes,yes,yes,no,no,no,yes")])
 
-(define_insn "*addhi3"
+(define_insn "*addhi3"
   [(set (match_operand:HI 0 "register_operand" "=r,r, r,r,r,r")
(plus:HI (match_operand:HI 1 "register_operand" "%0,0, 0,0,0,r")
 (match_operand:HI 2 "general_operand"   "r,Q>,J,N,g,!To")))
@@ -1003,9 +1003,9 @@ (define_insn "*addhi3"
add.w %2,%0
add.w %2,%1,%0"
   [(set_attr "slottable" "yes,yes,yes,yes,no,no")
-   (set_attr "cc" "normal,normal,clobber,clobber,normal,normal")])
+   (set_attr "cc" "normal,normal,clobber,clobber,normal,normal")])
 
-(define_insn "*addqi3"
+(define_insn "*addqi3"
   [(set (match_operand:QI 0 "register_operand" "=r,r, r,r,r,r,r")
(plus:QI (match_operand:QI 1 "register_operand" "%0,0, 0,0,0,0,r")
 (match_operand:QI 2 "general_operand"   "r,Q>,J,N,O,g,!To")))
@@ -1020,7 +1020,7 @@ (define_insn "*addqi3"
add.b %2,%0
add.b %2,%1,%0"
   [(set_attr "slottable" "yes,yes,yes,yes,yes,no,no")
-   (set_attr "cc" "normal,normal,clobber,clobber,clobber,normal,normal")])
+   (set_attr "cc" 
"normal,normal,clobber,clobber,clobber,normal,normal")])
 
 ;; Subtract.
 ;;
@@ -1039,7 +1039,7 @@ (define_expand "subdi3"
   ""
   "")
 
-(define_insn "*subdi3"
+(define_insn "*subdi3"
   [(set (match_operand:DI 0 "register_operand" "=r,r,r,&r,&r")
(minus:DI (match_operand:DI 1 "register_operand" "0,0,0,0,r")
  (match_operand:DI 2 "general_operand" "J,N,P,g,!To")))
@@ -1062,7 +1062,7 @@ (define_expand "sub3"
   ""
   "")
 
-(define_insn "*subsi3"
+(define_insn "*subsi3"
   [(set (match_operand:SI 0 "register_operand" "=r,r, r,r,r,r,r,r")
(minus:SI
 (match_operand:SI 1 "register_operand" "0,0, 0,0,0,0,0,r")
@@ -1084,7 +1084,7 @@ (define_insn "*subsi3"
sub.d %2,%1,%0"
   [(set_attr "slottable" "yes,yes,yes,yes,no,no,no,no")])
 
-(define_insn "*sub3"
+(define_insn "*sub3"
   [(set (match_operand:BW 0 "register_operand" "=r,r, r,r,r,r")
(minus:BW (match_operand:BW 1 "register_operand" "0,0, 0,0,0,r")
  (match_operand:BW 2 "general_operand"  "r,Q>,J,N,g,!To")))
@@ -1098,7 +1098,7 @@ (define_insn "*sub3"
sub %2,%0
sub %2,%1,%0"
   [(set_attr "slottable" "yes,yes,yes,yes,no,no")
-   (set_attr "cc" "normal,normal,clobber,clobber,normal,normal")])
+   (set_attr "cc" "normal,normal,clobber,clobber,normal,normal")])
 
 ;; This is the special case when we use what corresponds to the
 ;; instruction above in "casesi".  Do *not* change it to use the generic
-- 
2.11.0

brgds, H-P

[cris-decc0 12/14] cris: Enable 32-bit shifts, clz, bswap, umin to set condition codes.

[Hans-Peter Nilsson]

* config/cris/cris.md
("si3"):
Rename from "si3".
("clzsi2"):
Rename from "clzsi2".
("bswapsi2"):
Rename from "bswapsi2".
("*uminsi3"): Rename from "*uminsi3".

Enables dropping of compares with zero of the result, through
any CCmode substitution.
---
 gcc/config/cris/cris.md | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index 6faef6cda..c085e2660 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -1758,7 +1758,7 @@ (define_insn "one_cmpl2"
 
 ;; Arithmetic/Logical shift right (and SI left).
 
-(define_insn "si3"
+(define_insn "si3"
   [(set (match_operand:SI 0 "register_operand" "=r")
(shift:SI (match_operand:SI 1 "register_operand" "0")
  (match_operand:SI 2 "nonmemory_operand" "Kcr")))
@@ -1918,7 +1918,7 @@ (define_expand "abs2"
   ""
   "operands[2] = gen_reg_rtx (SImode); operands[3] = gen_reg_rtx (SImode);")
 
-(define_insn "clzsi2"
+(define_insn "clzsi2"
   [(set (match_operand:SI 0 "register_operand" "=r")
(clz:SI (match_operand:SI 1 "register_operand" "r")))
(clobber (reg:CC CRIS_CC0_REGNUM))]
@@ -1926,7 +1926,7 @@ (define_insn "clzsi2"
   "lz %1,%0"
   [(set_attr "slottable" "yes")])
 
-(define_insn "bswapsi2"
+(define_insn "bswapsi2"
   [(set (match_operand:SI 0 "register_operand" "=r")
(bswap:SI (match_operand:SI 1 "register_operand" "0")))
(clobber (reg:CC CRIS_CC0_REGNUM))]
@@ -1979,7 +1979,7 @@ (define_expand "uminsi3"
   ""
   "")
 
-(define_insn "*uminsi3"
+(define_insn "*uminsi3"
   [(set (match_operand:SI 0 "register_operand"  "=r,r, r,r")
(umin:SI  (match_operand:SI 1 "register_operand" "%0,0, 0,r")
  (match_operand:SI 2 "general_operand"   "r,Q>,g,!To")))
-- 
2.11.0

brgds, H-P

[cris-decc0 11/14] cris: Enable general "and", "or", "xor", "not" to set condition codes.

[Hans-Peter Nilsson]

* config/cris/cris.md ("*expanded_andsi"):
Rename from "*expanded_andsi".
("*iorsi3"): Similar from "*iorsi3".
Decorate "cc" attribute to make "cc".
("*iorhi3"): Similar from "*iorhi3".
("*iorqi3"): Similar from "*iorqi3".
("*expanded_andhi"): Similar from
"*expanded_andhi".  Add quick cc-setting alternative for 0..31.
("*andqi3"): Similar from "*andqi3".
("xorsi3"): Rename
from "xorsi3".
("one_cmplsi2"): Rename
from "one_cmplsi2".

Enabling dropping of compares with zero of the result, through
any CCmode substitution.  Beware that this will cause
size-suboptimal operands to appear for e.g. 32-bit "and":
-65536, -256, 255, 65535; for 16-bit "and" -256, -31..-1, 255;
for 8-bit "and" -31..-1.  Fixed for 0..31 for 16- and 8-bit
sizes as it seemed worthwhile and used in libgcc.
---
 gcc/config/cris/cris.md | 51 +
 1 file changed, 30 insertions(+), 21 deletions(-)

diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index 8652f3586..6faef6cda 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -1419,7 +1419,7 @@ (define_insn "*andsi_clear"
 ;; pressure (worse code).  That will hopefully change with an
 ;; improved reload pass.
 
-(define_insn "*expanded_andsi"
+(define_insn "*expanded_andsi"
   [(set (match_operand:SI 0 "register_operand""=r,r,r, r,r")
(and:SI (match_operand:SI 1 "register_operand" "%0,0,0, 0,r")
(match_operand:SI 2 "general_operand"   "I,r,Q>,g,!To")))
@@ -1499,10 +1499,12 @@ (define_insn "*andhi_clear"
 
 ;; Catch-all andhi3 pattern.
 
-(define_insn "*expanded_andhi"
-  [(set (match_operand:HI 0 "register_operand""=r,r,r, r,r,r,r")
-   (and:HI (match_operand:HI 1 "register_operand" "%0,0,0, 0,0,0,r")
-   (match_operand:HI 2 "general_operand"   "I,r,Q>,L,O,g,!To")))
+(define_insn "*expanded_andhi"
+  [(set (match_operand:HI 0 "register_operand""=r,r, r,r, r,r,r,r")
+   (and:HI (match_operand:HI 1 "register_operand" "%0,0, 0,0, 0,0,0,r")
+   (match_operand:HI 2 "general_operand"   "I,Kc,r,Q>,L,O,g,!To")))
+   ;; The "Kc" alternative above, is there to match for cmpelim;
+   ;; it will be dominated by the "I" alternative at other times.
(clobber (reg:CC CRIS_CC0_REGNUM))]
 
 ;; Sidenote: the tightening from "general_operand" to
@@ -1513,14 +1515,16 @@ (define_insn "*expanded_andhi"
   ""
   "@
andq %2,%0
+   andq %2,%0
and.w %2,%0
and.w %2,%0
and.w %2,%0
anDq %b2,%0
and.w %2,%0
and.w %2,%1,%0"
-  [(set_attr "slottable" "yes,yes,yes,no,yes,no,no")
-   (set_attr "cc" "clobber,normal,normal,normal,clobber,normal,normal")])
+  [(set_attr "slottable" "yes,yes,yes,yes,no,yes,no,no")
+   (set_attr "cc"
+"clobber,normal,normal,normal,normal,clobber,normal,normal")])
 
 ;; A strict_low_part pattern.
 
@@ -1568,21 +1572,23 @@ (define_expand "andqi3"
   ""
   "")
 
-(define_insn "*andqi3"
-  [(set (match_operand:QI 0 "register_operand""=r,r,r, r,r,r")
-   (and:QI (match_operand:QI 1 "register_operand" "%0,0,0, 0,0,r")
-   (match_operand:QI 2 "general_operand"   "I,r,Q>,O,g,!To")))
+(define_insn "*andqi3"
+  [(set (match_operand:QI 0 "register_operand""=r,r, r,r, r,r,r")
+   (and:QI (match_operand:QI 1 "register_operand" "%0,0, 0,0, 0,0,r")
+   (match_operand:QI 2 "general_operand"   "I,Kc,r,Q>,O,g,!To")))
(clobber (reg:CC CRIS_CC0_REGNUM))]
   ""
   "@
andq %2,%0
+   andq %2,%0
and.b %2,%0
and.b %2,%0
andQ %b2,%0
and.b %2,%0
and.b %2,%1,%0"
-  [(set_attr "slottable" "yes,yes,yes,yes,no,no")
-   (set_attr "cc" "clobber,normal,normal,clobber,normal,normal")])
+  [(set_attr "slottable" "yes,yes,yes,yes,yes,no,no")
+   (set_attr "cc"
+"clobber,normal,normal,normal,clobber,normal,normal")])
 
 (define_insn "*andqi_lowpart"
   [(set (strict_low_part
@@ -1613,7 +1619,7 @@ (define_expand "ior3"
   ""
   "")
 
-(define_insn "*iorsi3"
+(define_insn "*iorsi3"
   [(set (match_operand:SI 0 "register_operand""=r,r,r, r,r,r")
(ior:SI (match_operand:SI 1 "register_operand" "%0,0,0, 0,0,r")
(match_operand:SI 2 "general_operand"  "I, r,Q>,n,g,!To")))
@@ -1627,9 +1633,10 @@ (define_insn "*iorsi3"
or.d %2,%0
or.d %2,%1,%0"
   [(set_attr "slottable" "yes,yes,yes,no,no,no")
-   (set_attr "cc" "normal,normal,normal,clobber,normal,normal")])
+   (set_attr "cc"
+"normal,normal,normal,clobber,normal,normal")])
 
-(define_insn "*iorhi3"
+(define_insn "*iorhi3"
   [(set (match_operand:HI 0 "register_operand""=r,r,r, r,r,r,r")
(ior:HI (match_operand:HI 1 "register_operand" "%0,0,0, 0,0,0,r")
(match_operand:HI 2 "general_operand"   "I,r,Q>,L,O,g,!To")))
@@ -1644,9 +1651,10 @@ (define_insn "*iorhi3"
or.w %2,%0
or.w %2,%1,%0"
   [(set_attr "slottable" "yes,yes,yes,no,yes,no,no")
-   (set_attr "cc" "clobber,normal,normal,normal,clobber,norma

[cris-decc0 13/14] cris: Enable single-bit btst/btstq to set condition codes.

[Hans-Peter Nilsson]

* config/cris/cris-modes.def (CC_ZnN): New CC_MODE.
* config/cris/cris.c (cris_rtx_costs): Handle pre-split bit-test
* config/cris/cris.md (ZnNNZSET, ZnNNZUSE): New mode_iterators.
(znnCC, rznnCC): New code_attrs.
("*btst"): Iterator over ZnNNZSET instead of NZVCSET.  Remove
obseolete comment.  Add belt-and-suspenders mode-test to condition.
Add fixme regarding remaining matched-but-not-generated case.
("*cbranch4_btstrq1_"): New insn_and_split.
("*cbranch4_btstqb0_"): Rename from
"*cbranch4_btstq".  Split to CC_NZ instead of CC.
("*b"): Iterate over ZnNNZUSE instead of NZUSE.
Handle output of CC_ZnNmode.
("*b_reversed"): Ditto.

Enables the use of btst / btstq for a single bit (at other bits
than 0, including as indicated by a variable) to set
condition-codes.  There's also a bug-fix for the bit-0-btstq
pattern; it shouldn't generate CCmode as only the Z flag is
valid, still using CC_NZmode is ok, as only equality-tests are
generated.  The cris_rtx_costs tweak is necessary or else
combine will consider the btst not preferable.  It reduces the
difference to cc0-costs beyond the threshold to the
transformation being seen as profitable, but there's still a
difference in values for the pre-split-time btst+branch as
opposed to the cc0 btst and branch, with both appearing to be
the cost of several insns (18 and 22).
---
 gcc/config/cris/cris-modes.def |  6 ++--
 gcc/config/cris/cris.c | 26 ++--
 gcc/config/cris/cris.md| 70 --
 3 files changed, 82 insertions(+), 20 deletions(-)

diff --git a/gcc/config/cris/cris-modes.def b/gcc/config/cris/cris-modes.def
index b0e426159..1aaf12a0f 100644
--- a/gcc/config/cris/cris-modes.def
+++ b/gcc/config/cris/cris-modes.def
@@ -28,8 +28,6 @@ along with GCC; see the file COPYING3.  If not see
(fpcraz).  The two subsets meaningful to gcc are all of N, Z, V, C
versus just N, Z; some CC-users care only about N and/or Z and some
that care about at least one of those flags together with V and/or C.
-   (FIXME: the result of testing a single bit using the btst instruction
-   should be described as a separate mode.)
 
The plain "CC_MODE (CC)" (which is always present in gcc), is used to
reflect the "unoptimized" state, where the CC-setter is a compare
@@ -52,3 +50,7 @@ CC_MODE (CC_NZ);
are set to usable values, fpcraz.  For a condition-code user: at least
one of V and C are used and possibly N and Z too.  */
 CC_MODE (CC_NZVC);
+
+/* The result of a btst / btstq instruction for extracting a single bit
+   goes negated into the N flag, or in olde cc0-parlance, CC_Z_IN_NOT_N.  */
+CC_MODE (CC_ZnN);
diff --git a/gcc/config/cris/cris.c b/gcc/config/cris/cris.c
index 04c80c314..d0807adc8 100644
--- a/gcc/config/cris/cris.c
+++ b/gcc/config/cris/cris.c
@@ -1772,8 +1772,30 @@ cris_rtx_costs (rtx x, machine_mode mode, int 
outer_code, int opno,
   return false;
 
 case ZERO_EXTRACT:
-  if (outer_code != COMPARE)
-return false;
+  /* Conditionals are split after reload, giving a different look.  */
+  if (reload_completed)
+   {
+ if (outer_code != COMPARE)
+   return false;
+   }
+  else
+   switch (outer_code)
+ {
+ case EQ:
+ case NE:
+ case LT:
+ case LTU:
+ case LE:
+ case LEU:
+ case GT:
+ case GTU:
+ case GE:
+ case GEU:
+   break;
+
+ default:
+   return false;
+ }
   /* fall through */
 
 case ZERO_EXTEND: case SIGN_EXTEND:
diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index c085e2660..1e895a375 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -197,6 +197,8 @@ (define_mode_iterator NZSET [CC_NZ])
 (define_mode_iterator NZUSE [CC CC_NZ CC_NZVC])
 (define_mode_iterator NZVCSET [CC CC_NZVC CC_NZ])
 (define_mode_iterator NZVCUSE [CC_NZVC])
+(define_mode_iterator ZnNNZSET [CC_ZnN CC_NZ])
+(define_mode_iterator ZnNNZUSE [CC CC_ZnN CC_NZ CC_NZVC])
 
 ;; All conditions.
 (define_code_iterator cond [eq ne gtu ltu geu leu gt le lt ge])
@@ -230,6 +232,12 @@ (define_code_attr oCC [(lt "mi") (ge "pl") (gtu "eq") (ltu 
"ne")])
 ;; Reverse of oCC.
 (define_code_attr roCC [(lt "pl") (ge "mi") (gtu "eq") (ltu "ne")])
 
+;; CC_Z_IN_NOT_N, a.k.a. CC_ZnNmode.
+(define_code_attr znnCC [(eq "pl") (ne "mi")])
+
+;;; ...and the reverse
+(define_code_attr rznnCC [(eq "mi") (ne "pl")])
+
 ;; Required unoptimized CCmode, different for nzcond and nzvccond.
 (define_code_attr xCC [(eq "CC") (ne "CC") (gtu "CC") (ltu "CC_NZVC")
   (geu "CC_NZVC") (leu "CC") (lt "CC") (ge "CC")
@@ -386,20 +394,20 @@ (define_insn "*cmp"
 ;; of zeros starting at bit 0).
 
 ;; SImode.  This mode is the only one needed, since gcc automatically
-;; extends subregs for lower-size modes.  FIXME: Add testcase.
+;; extends subregs for lower-size modes.
 (define_insn "*btst"
-  [(set (reg:NZVCSET CRIS_CC

[cris-decc0 14/14] cris: Enable "neg" to set condition codes.

[Hans-Peter Nilsson]

* config/cris/cris.c (cris_select_cc_mode): Return CC_NZmode for
NEG too.  Correct comment.
* config/cris/cris.md ("neg2"): Rename from
"neg2".

While gcc seems to prefer transforming tests on the result of
reversible operations, into tests on the original, it also can
work with the destination, if allocated to the same register as
it commonly-enough is.  The re-use is easily covered in a
test-case.  (N.B.: the value 0x8000 appears to be considered
invalid and unimportant.)  Spotted as a "microregression" in
libgcc when comparing to the cc0 version.
---
 gcc/config/cris/cris.c  | 8 
 gcc/config/cris/cris.md | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/config/cris/cris.c b/gcc/config/cris/cris.c
index d0807adc8..2bad9393c 100644
--- a/gcc/config/cris/cris.c
+++ b/gcc/config/cris/cris.c
@@ -1531,9 +1531,9 @@ cris_select_cc_mode (enum rtx_code op, rtx x, rtx y)
 return CCmode;
 
   /* If we have a comparison that doesn't have to look at V or C, check
- operand x; if it looks like a binary operator, return CC_NZmode,
- else CCmode, so we only use CC_NZmode for the cases where we don't
- actually have both V and C valid.  */
+ operand x; if it's a valid operator, return CC_NZmode, else CCmode,
+ so we only use CC_NZmode for the cases where we don't actually have
+ both V and C valid.  */
   if (op == EQ || op ==  NE || op ==  GTU || op ==  LEU
   || op ==  LT || op ==  GE)
 {
@@ -1542,7 +1542,7 @@ cris_select_cc_mode (enum rtx_code op, rtx x, rtx y)
 /* Mentioning the rtx_code here is required but not sufficient: the
insn also needs to be decorated with  (and the
anonymization prefix  for a named pattern).  */
-  return e == PLUS || e == MINUS || e == MULT || e == NOT
+  return e == PLUS || e == MINUS || e == MULT || e == NOT || e == NEG
? CC_NZmode : CCmode;
 }
 
diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md
index 1e895a375..081041fa2 100644
--- a/gcc/config/cris/cris.md
+++ b/gcc/config/cris/cris.md
@@ -1734,7 +1734,7 @@ (define_insn "*expanded_negsf2"
 ;; No "negdi2" although we could make one up that may be faster than
 ;; the one in libgcc.
 
-(define_insn "neg2"
+(define_insn "neg2"
   [(set (match_operand:BWD 0 "register_operand" "=r")
(neg:BWD (match_operand:BWD 1 "register_operand" "r")))
(clobber (reg:CC CRIS_CC0_REGNUM))]
-- 
2.11.0

brgds, H-P

Re: [PATCH] tree-optimization/93661 properly guard tree_to_poly_int64

[Hans-Peter Nilsson]

On Tue, 11 Feb 2020, Richard Biener wrote:
> Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.

> diff --git a/gcc/testsuite/gcc.dg/pr93661.c b/gcc/testsuite/gcc.dg/pr93661.c
> new file mode 100644
> index 000..e311ba545c4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr93661.c
> @@ -0,0 +1,9 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */

Missing int32plus qualifier considering the assumed-to-fit
constants?

> +
> +int f ()
> +{
> +  unsigned x = 0x;
> +  __builtin_memset (1+(char *) &x, 0, -1); /* { dg-warning "maximum object 
> size" } */
> +  return (x != 0xf000);

brgds, H-P
PS. no, doesn't fail for targets I care for, just random.