Re: [Patch, fortran] PR97612 [F08] Structure constructor of type with nested allocatable array components fails to compile

[Thomas Koenig via Gcc-patches]

Hi Paul,


Regtests on FC33/x86_64 - OK for master?


OK. Thanks for the patch!

Best regards

Thomas

Re: -mno-long-calls for expected regalloc in arm/fp16-aapcs-2.c test

[Richard Sandiford via Gcc-patches]

Alexandre Oliva  writes:
> The implicit -mlong-calls used in our arm-vxworks configurations
> changes the register allocation patterns in the arm/fp16-aapcs-2.c
> test: r3 ends up used in the long-call sequence, and we end up using
> ip as a temporary, which doesn't match the expected mov patterns.
>
> This patch adds an explicit -mno-long-calls for the generated code to
> match the expectation.
>
> Regstrapped on x86_64-linux-gnu, also tested on arm-vxworks7r2.
> Ok to install?

OK, thanks.

Richard

> for  gcc/testsuite/ChangeLog
>
>   * gcc.target/arm/fp16-aapcs-2.c: Use -mno-long-calls.
> ---
>  gcc/testsuite/gcc.target/arm/fp16-aapcs-2.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.target/arm/fp16-aapcs-2.c 
> b/gcc/testsuite/gcc.target/arm/fp16-aapcs-2.c
> index 51a76fc069353..c34387f57828d 100644
> --- a/gcc/testsuite/gcc.target/arm/fp16-aapcs-2.c
> +++ b/gcc/testsuite/gcc.target/arm/fp16-aapcs-2.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile }  */
>  /* { dg-require-effective-target arm_fp16_ok } */
> -/* { dg-options "-mfloat-abi=softfp -O2" }  */
> +/* { dg-options "-mfloat-abi=softfp -O2 -mno-long-calls" }  */
>  /* { dg-add-options arm_fp16_ieee } */
>  /* { dg-skip-if "incompatible float-abi" { arm*-*-* } { "-mfloat-abi=hard" } 
> } */

Re: -mno-long-calls for arm/headmerge tests

[Richard Sandiford via Gcc-patches]

Alexandre Oliva  writes:
> The headmerge tests pass a constant to conditional calls, so that the
> same constant is always passed to a function, though it's a different
> function depending on which path is taken.
>
> The test checks that the constant appears only once in the assembly
> output, as a means to verify that the insns setting up the argument
> are unified: they appear as separate insns up to jump2, where
> crossjump identifies a common prefix to all conditional paths and
> unifies them.
>
> Alas, with -mlong-calls, that we enable in our arm-vxworks
> configurations, the argument register is loaded after loading the
> callee address into another register.  Since each path calls a
> different function, there's no common initial code sequence for
> crossjump to unify, and the argument register set up remains separate,
> so the test fails.
>
> Though it would surely be desirable for the compiler to perform the
> unification of the argument register setting up, this patch merely
> avoids the effects of -mlong-calls, with an explicit -mno-long-calls.
>
> Regstrapped on x86_64-linux-gnu, also tested on arm-vxworks7r2.
> Ok to install?

OK, thanks.

Richard

> for  gcc/testsuite/ChangeLog
>
>   * gcc.target/arm/headmerge-1.c: Add -mno-long-calls.
>   * gcc.target/arm/headmerge-2.c: Likewise.
> ---
>  gcc/testsuite/gcc.target/arm/headmerge-1.c |2 +-
>  gcc/testsuite/gcc.target/arm/headmerge-2.c |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/arm/headmerge-1.c 
> b/gcc/testsuite/gcc.target/arm/headmerge-1.c
> index 218c6a21ebd27..319ccd254626d 100644
> --- a/gcc/testsuite/gcc.target/arm/headmerge-1.c
> +++ b/gcc/testsuite/gcc.target/arm/headmerge-1.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile }  */
> -/* { dg-options "-O2" }  */
> +/* { dg-options "-O2 -mno-long-calls" }  */
>  /* { dg-final { scan-assembler-times "#120" 1 } } */
>  
>  extern void foo1 (int);
> diff --git a/gcc/testsuite/gcc.target/arm/headmerge-2.c 
> b/gcc/testsuite/gcc.target/arm/headmerge-2.c
> index 17d8e9365c52e..a015eb0f56905 100644
> --- a/gcc/testsuite/gcc.target/arm/headmerge-2.c
> +++ b/gcc/testsuite/gcc.target/arm/headmerge-2.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile }  */
> -/* { dg-options "-O2" }  */
> +/* { dg-options "-O2 -mno-long-calls" }  */
>  /* { dg-final { scan-assembler-times "120\n" 1 } } */
>  
>  extern void foo1 (int);

Re: -mno-long-calls for arm/no_unique_address tests

[Richard Sandiford via Gcc-patches]

Alexandre Oliva  writes:
> The implicit -mlong-calls from our vxworks configurations makes the
> tail-call instructions differ from those expected by the
> no_unique_address tests in gcc.target/arm.
>
> This patch adds -mno-long-calls to the compilation commands, so that
> we generate the expected sequences.
>
> Regstrapped on x86_64-linux-gnu, also tested on arm-vxworks7r2.
> Ok to install?

OK, thanks.  The dg-bogus parts shouldn't of course depend on -mlong-calls,
but they shouldn't depend on -O or -foptimize-sibling-calls either.
It seems unlikely that there is any hidden interaction between
-mlong-calls and no_unique_address, and if we find one later, we can
always add tests for it then.

Richard

> for  gcc/testsuite/ChangeLog
>
>   * gcc.target/arm/no_unique_address_1.C: Add -mno-long-calls.
>   * gcc.target/arm/no_unique_address_2.C: Likewise.
> ---
>  gcc/testsuite/g++.target/arm/no_unique_address_1.C |2 +-
>  gcc/testsuite/g++.target/arm/no_unique_address_2.C |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/g++.target/arm/no_unique_address_1.C 
> b/gcc/testsuite/g++.target/arm/no_unique_address_1.C
> index 038aa00a499e9..40fc68b374521 100644
> --- a/gcc/testsuite/g++.target/arm/no_unique_address_1.C
> +++ b/gcc/testsuite/g++.target/arm/no_unique_address_1.C
> @@ -1,5 +1,5 @@
>  /* { dg-require-effective-target arm_arch_v8a_hard_ok } */
> -/* { dg-options "-std=c++11 -O -foptimize-sibling-calls" } */
> +/* { dg-options "-std=c++11 -O -foptimize-sibling-calls -mno-long-calls" } */
>  /* { dg-add-options arm_arch_v8a_hard } */
>  /* { dg-final { check-function-bodies "**" "" "" } } */
>  
> diff --git a/gcc/testsuite/g++.target/arm/no_unique_address_2.C 
> b/gcc/testsuite/g++.target/arm/no_unique_address_2.C
> index 8be5de2539a38..b66b4d004965b 100644
> --- a/gcc/testsuite/g++.target/arm/no_unique_address_2.C
> +++ b/gcc/testsuite/g++.target/arm/no_unique_address_2.C
> @@ -1,5 +1,5 @@
>  /* { dg-require-effective-target arm_arch_v8a_hard_ok } */
> -/* { dg-options "-std=c++17 -O -foptimize-sibling-calls" } */
> +/* { dg-options "-std=c++17 -O -foptimize-sibling-calls -mno-long-calls" } */
>  /* { dg-add-options arm_arch_v8a_hard } */
>  /* { dg-final { check-function-bodies "**" "" "" } } */

Re: -mno-long-calls for mve_libcall tests

[Richard Sandiford via Gcc-patches]

Alexandre Oliva  writes:
> The implicit -mlong-calls used in our vxworks configurations changes
> the call sequences from those expected in the mve_libcall testcases.
>
> This patch brings the test output in line with the expectations, with
> an explicit -mno-long-calls.
>
> Regstrapped on x86_64-linux-gnu, also tested on arm-vxworks7r2.
> Ok to install?

OK, thanks.

Richard

> for  gcc/testsuite/ChangeLog
>
>   * gcc.target/arm/mve/intrinsics/mve_libcall1.c: Pass an
>   explicit -mno-long-calls.
>   * gcc.target/arm/mve/intrinsics/mve_libcall2.c: Likewise.
> ---
>  .../gcc.target/arm/mve/intrinsics/mve_libcall1.c   |2 +-
>  .../gcc.target/arm/mve/intrinsics/mve_libcall2.c   |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c 
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c
> index 4fd422c6afe6a..222007f7ee21d 100644
> --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c
> +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c
> @@ -1,6 +1,6 @@
>  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
>  /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
> {""} } */
> -/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard 
> -mthumb -mfpu=auto --save-temps" } */
> +/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard 
> -mthumb -mfpu=auto -mno-long-calls --save-temps" } */
>  
>  float
>  foo (float a, float b, float c)
> diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall2.c 
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall2.c
> index 3fd1329d384a9..42047a33fdfaa 100644
> --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall2.c
> +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall2.c
> @@ -1,6 +1,6 @@
>  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
>  /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
> {""} } */
> -/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard 
> -mthumb -mfpu=auto --save-temps" } */
> +/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard 
> -mthumb -mfpu=auto -mno-long-calls --save-temps" } */
>  
>  double
>  foo (double a, double b, double c)

Re: Add missing vxworks filters to lib/target-supports.exp functions

[Richard Sandiford via Gcc-patches]

Alexandre Oliva  writes:
> Explicitly disable some vxworks-missing features in the testsuite, that
> the current feature tests detect as present.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
>
>
> from Olivier Hainque 
> for  gcc/testsuite/ChangeLog
>
>   * lib/target-supports.exp (check_weak_available,
>   check_fork_available, check_effective_target_lto,
>   check_effective_target_mempcpy): Add vxworks filters.

This comes under Olivier's maintainership, but LGTM.

Richard

> ---
>  gcc/testsuite/lib/target-supports.exp |   21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 11343d0192fcb..6b1d13b105da7 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -326,6 +326,12 @@ proc check_weak_available { } {
>   return 0
>  }
>  
> +# VxWorks hardly supports it (vx7 RTPs only)
> +
> +if { [istarget *-*-vxworks*] } {
> + return 0
> +}
> +
>  # ELF and ECOFF support it. a.out does with gas/gld but may also with
>  # other linkers, so we should try it
>  
> @@ -2606,6 +2612,11 @@ proc check_function_available { function } {
>  # Returns true iff "fork" is available on the target system.
>  
>  proc check_fork_available {} {
> +if { [istarget *-*-vxworks*] } {
> + # VxWorks doesn't have fork but our way to test can't
> + # tell as we're doing partial links for kernel modules.
> + return 0
> + }
>  return [check_function_available "fork"]
>  }
>  
> @@ -9295,6 +9306,11 @@ proc check_effective_target_gld { } {
>  # (LTO) support.
>  
>  proc check_effective_target_lto { } {
> +if { [istarget *-*-vxworks*] } {
> + # No LTO on VxWorks, with kernel modules
> + # built with partial links
> + return 0
> +}
>  if { [istarget nvptx-*-*]
>|| [istarget amdgcn-*-*] } {
>   return 0;
> @@ -9514,6 +9530,11 @@ proc check_effective_target_run_expensive_tests { } {
>  # Returns 1 if "mempcpy" is available on the target system.
>  
>  proc check_effective_target_mempcpy {} {
> +if { [istarget *-*-vxworks*] } {
> + # VxWorks doesn't have mempcpy but our way to test fails
> + # to detect as we're doing partial links for kernel modules.
> + return 0
> + }
>  return [check_function_available "mempcpy"]
>  }

[committed 1/6] arc: Don't use predicated vadd2 instructions in mov patterns.

[Claudiu Zissulescu via Gcc-patches]

Update movdi, movdf and mov vectors not to use predicated vadd2
instructions. vadd2 is used as a "fast" move in these patterns. This
fixes a number of failures in dejagnu.

gcc/
2020-12-29  Claudiu Zissulescu  

* config/arc/arc.md (movdi_insn): Update pattern, no predicated
vadd2 usage.
(movdf_insn): Likewise.
* config/arc/simdext.md (movVEC_insn): Likewise.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.md | 6 +++---
 gcc/config/arc/simdext.md | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index ae08146bcaf..75c32f6d3e9 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -1341,7 +1341,7 @@ (define_insn_and_split "*movdi_insn"
 if (TARGET_PLUS_QMACW
&& even_register_operand (operands[0], DImode)
&& even_register_operand (operands[1], DImode))
-  return \"vadd2\\t%0,%1,0\";
+  return \"vadd2%?\\t%0,%1,0\";
 return \"#\";
 
 case 2:
@@ -1421,7 +1421,7 @@ (define_insn_and_split "*movdf_insn"
 if (TARGET_PLUS_QMACW
&& even_register_operand (operands[0], DFmode)
&& even_register_operand (operands[1], DFmode))
-  return \"vadd2\\t%0,%1,0\";
+  return \"vadd2%?\\t%0,%1,0\";
 return \"#\";
 
 case 4:
@@ -1450,7 +1450,7 @@ (define_insn_and_split "*movdf_insn"
DONE;
   }
   [(set_attr "type" "move,move,move,move,load,store")
-   (set_attr "predicable" "no,no,yes,yes,no,no")
+   (set_attr "predicable" "no,no,no,yes,no,no")
;; ??? The ld/st values could be 16 if it's [reg,bignum].
(set_attr "length" "4,16,8,16,16,16")])
 
diff --git a/gcc/config/arc/simdext.md b/gcc/config/arc/simdext.md
index d2fc309ea87..58651b5fcac 100644
--- a/gcc/config/arc/simdext.md
+++ b/gcc/config/arc/simdext.md
@@ -1413,7 +1413,7 @@ (define_insn_and_split "*mov_insn"
if (TARGET_PLUS_QMACW
&& even_register_operand (operands[0], mode)
   && even_register_operand (operands[1], mode))
- return \"vadd2\\t%0,%1,0\";
+ return \"vadd2%?\\t%0,%1,0\";
return \"#\";
 
  case 2:
@@ -1434,7 +1434,7 @@ (define_insn_and_split "*mov_insn"
DONE;
   }
   [(set_attr "type" "move,multi,load,store")
-   (set_attr "predicable" "yes,no,no,no")
+   (set_attr "predicable" "no,no,no,no")
(set_attr "iscompact"  "false,false,false,false")
])
 
-- 
2.26.2

[committed 2/6] arc: Fix cached to uncached moves.

[Claudiu Zissulescu via Gcc-patches]

We need an temporary register when moving data from a cached memory to
an uncached memory. Fix this issue and add a test for it.

gcc/
2020-12-29  Claudiu Zissulescu  

* config/arc/arc.c (prepare_move_operands): Use a temporary
registers when we have cached mem-to-uncached mem moves.

gcc/testsuite/
2020-12-29  Claudiu Zissulescu  
Vladimir Isaev 

* cc.target/arc/uncached-9.c: New test.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.c  | 12 +--
 gcc/testsuite/gcc.target/arc/uncached-9.c | 39 +++
 2 files changed, 49 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arc/uncached-9.c

diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 6a9e1fbf824..d0a52ee8b8d 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -9234,13 +9234,21 @@ prepare_move_operands (rtx *operands, machine_mode mode)
}
   if (arc_is_uncached_mem_p (operands[1]))
{
+ rtx tmp = operands[0];
+
  if (MEM_P (operands[0]))
-   operands[0] = force_reg (mode, operands[0]);
+   tmp = gen_reg_rtx (mode);
+
  emit_insn (gen_rtx_SET
-(operands[0],
+(tmp,
  gen_rtx_UNSPEC_VOLATILE
  (mode, gen_rtvec (1, operands[1]),
   VUNSPEC_ARC_LDDI)));
+ if (MEM_P (operands[0]))
+   {
+ operands[1] = tmp;
+ return false;
+   }
  return true;
}
 }
diff --git a/gcc/testsuite/gcc.target/arc/uncached-9.c 
b/gcc/testsuite/gcc.target/arc/uncached-9.c
new file mode 100644
index 000..4caba293bc5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arc/uncached-9.c
@@ -0,0 +1,39 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+#include 
+
+struct uncached_st
+{
+  int value;
+} __attribute__((uncached));
+
+struct cached_st
+{
+  int value;
+};
+
+struct uncached_st g_uncached_st =
+  {
+.value = 17
+  };
+
+struct cached_st g_cached_st =
+  {
+.value = 4
+  };
+
+void __attribute__((noinline)) test_struct_copy (void)
+{
+  g_cached_st.value = g_uncached_st.value;
+}
+
+int main (void)
+{
+  test_struct_copy();
+
+  if (g_cached_st.value != g_uncached_st.value)
+abort ();
+
+  return 0;
+}
-- 
2.26.2

[committed 3/6] arc: Update test pattern.

[Claudiu Zissulescu via Gcc-patches]

gcc/testsuite
2020-12-29  Claudiu Zissulescu  

* gcc.target/arc/loop-3.c: Update test pattern.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/testsuite/gcc.target/arc/loop-3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/arc/loop-3.c 
b/gcc/testsuite/gcc.target/arc/loop-3.c
index bf7aec94842..7f55e2f43fa 100644
--- a/gcc/testsuite/gcc.target/arc/loop-3.c
+++ b/gcc/testsuite/gcc.target/arc/loop-3.c
@@ -23,5 +23,5 @@ void fn1(void)
   }
 }
 
-/* { dg-final { scan-assembler "bne_s @.L2" } } */
+/* { dg-final { scan-assembler "bne.*@.L2" } } */
 /* { dg-final { scan-assembler-not "add.eq" } } */
-- 
2.26.2

[committed 4/6] arc: Make use reg_renumber safe.

[Claudiu Zissulescu via Gcc-patches]

The REGNO_OK_FOR_BASE_P is using reg_renumber array. However, it is
not always defined. Use it only when it is defined.

gcc/
2020-12-29  Claudiu Zissulescu  

* config/arc/arc.h (REGNO_OK_FOR_BASE_P): Check if defined
reg_renumber.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index fd6e21adfaa..c3886330f1b 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -588,7 +588,7 @@ extern enum reg_class arc_regno_reg_class[];
|| ((REGNO) == ARG_POINTER_REGNUM)  \
|| ((REGNO) == FRAME_POINTER_REGNUM)
\
|| ((REGNO) == PCL_REG) \
-   || ((unsigned) reg_renumber[REGNO] < 29)\
+   || (reg_renumber && ((unsigned) reg_renumber[REGNO] < 29))  \
|| ((unsigned) (REGNO) == (unsigned) arc_tp_regno)  \
|| (fixed_regs[REGNO] == 0 && IN_RANGE (REGNO, 32, 59)) \
|| (fixed_regs[REGNO] == 0 && (REGNO) == R30_REG))
-- 
2.26.2

[committed 5/6] arc: flip if-condition predicates in secondary reload hook

[Claudiu Zissulescu via Gcc-patches]

The ARC code contains code which should only work with the old reload
pass. Such code is found in arc_secondary_reload hook, however it was
not properly quarded. Reverse the if-condition predicate such that
req_equiv_mem is called when lra is not in progress.

gcc/
2020-12-29  Claudiu Zissulescu  

* config/arc/arc.c (arc_secondary_reload): Flip if-condition
predicates.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index d0a52ee8b8d..fb672c75ff4 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -901,7 +901,7 @@ arc_secondary_reload (bool in_p,
 
  /* It is a pseudo that ends in a stack location.  This
 procedure only works with the old reload step.  */
- if (reg_equiv_mem (REGNO (x)) && !lra_in_progress)
+ if (!lra_in_progress && reg_equiv_mem (REGNO (x)))
{
  /* Get the equivalent address and check the range of the
 offset.  */
-- 
2.26.2

[committed 6/6] arc: generate mac(u) insn instead of macd(u) when destination is accl

[Claudiu Zissulescu via Gcc-patches]

Generate MAC(U) instruction instead of MACD(U) when the destination
register is already choosen as ACCL register.

gcc/
2020-12-29  Claudiu Zissulescu  

* config/arc/arc.md (maddsidi4_split): Skip macd gen, use mac insn
instead.
(macd): Update register letters.
(umaddsidi4_split): Skip macdu gen, use macu insn instead.
(macdu): Update register letters.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.md | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index 75c32f6d3e9..b616c7fb82c 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -6176,12 +6176,14 @@ (define_insn_and_split "maddsidi4_split"
   "{
rtx acc_reg = gen_rtx_REG (DImode, ACC_REG_FIRST);
emit_move_insn (acc_reg, operands[3]);
-   if (TARGET_PLUS_MACD && even_register_operand (operands[0], DImode))
- emit_insn (gen_macd (operands[0], operands[1], operands[2]));
+   if (TARGET_PLUS_MACD && even_register_operand (operands[0], DImode)
+   && REGNO (operands[0]) != ACCL_REGNO)
+  emit_insn (gen_macd (operands[0], operands[1], operands[2]));
else
  {
   emit_insn (gen_mac (operands[1], operands[2]));
-  emit_move_insn (operands[0], acc_reg);
+  if (REGNO (operands[0]) != ACCL_REGNO)
+emit_move_insn (operands[0], acc_reg);
  }
DONE;
}"
@@ -6192,8 +6194,8 @@ (define_insn "macd"
   [(set (match_operand:DI 0 "even_register_operand"   "=Rcr,r,r")
(plus:DI
 (mult:DI
- (sign_extend:DI (match_operand:SI 1 "register_operand" "%0,c,c"))
- (sign_extend:DI (match_operand:SI 2 "extend_operand" " c,cI,Cal")))
+ (sign_extend:DI (match_operand:SI 1 "register_operand" "%0,r,r"))
+ (sign_extend:DI (match_operand:SI 2 "extend_operand""r,rI,Cal")))
 (reg:DI ARCV2_ACC)))
(set (reg:DI ARCV2_ACC)
(plus:DI
@@ -6276,12 +6278,14 @@ (define_insn_and_split "umaddsidi4_split"
   "{
rtx acc_reg = gen_rtx_REG (DImode, ACC_REG_FIRST);
emit_move_insn (acc_reg, operands[3]);
-   if (TARGET_PLUS_MACD && even_register_operand (operands[0], DImode))
- emit_insn (gen_macdu (operands[0], operands[1], operands[2]));
+   if (TARGET_PLUS_MACD && even_register_operand (operands[0], DImode)
+   && REGNO (operands[0]) != ACCL_REGNO)
+  emit_insn (gen_macdu (operands[0], operands[1], operands[2]));
else
  {
   emit_insn (gen_macu (operands[1], operands[2]));
-  emit_move_insn (operands[0], acc_reg);
+  if (REGNO (operands[0]) != ACCL_REGNO)
+emit_move_insn (operands[0], acc_reg);
  }
DONE;
}"
@@ -6292,8 +6296,8 @@ (define_insn "macdu"
   [(set (match_operand:DI 0 "even_register_operand"   "=Rcr,r,r")
(plus:DI
 (mult:DI
- (zero_extend:DI (match_operand:SI 1 "register_operand" "%0,c,c"))
- (zero_extend:DI (match_operand:SI 2 "extend_operand" " c,cI,i")))
+ (zero_extend:DI (match_operand:SI 1 "register_operand" "%0,r,r"))
+ (zero_extend:DI (match_operand:SI 2 "extend_operand""r,rI,i")))
 (reg:DI ARCV2_ACC)))
(set (reg:DI ARCV2_ACC)
(plus:DI
-- 
2.26.2

Re: [Patch, fortran] PR93833 - [8/9/10 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

[Paul Richard Thomas via Gcc-patches]

Hi Thomas,

Thanks for taking a look at the patch. Applied to master as
r11-6364-gfeae0af82753e06fbff6103da5fbb3b28e1ddbd7 .

The branches will follow in a week or so.

Regards

Paul


On Mon, 28 Dec 2020 at 17:10, Thomas Koenig  wrote:

> Hi Paul,
>
> >>
> > Retested on FC33/x86_64 - OK for master, then 9&10 branches in a few
> weeks?
>
> OK.
>
> Thanks a lot for the patch!
>
> Best regards
>
> Thomas
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: [Patch, fortran] PR97612 [F08] Structure constructor of type with nested allocatable array components fails to compile

[Paul Richard Thomas via Gcc-patches]

Hi Thomas,

Thanks - applied to master in
r11-6365-geeb145317b42d5203056851435457d9189a7303d .

I wonder if this one deserves backporting?

Cheers

Paul




On Tue, 29 Dec 2020 at 09:06, Thomas Koenig  wrote:

>
> Hi Paul,
>
> > Regtests on FC33/x86_64 - OK for master?
>
> OK. Thanks for the patch!
>
> Best regards
>
> Thomas
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: Add conditional include of vxWorks.h for kernel mode

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:14 PM, Alexandre Oliva  wrote:
> 
> In kernel mode, an application must include vxWorks.h before any other
> system header, this patch adds exactly that to the test that were
> failing due to a missing declaration that was found in vxWorks.h.

I'm inclined to rather have a -include vxWorks.h method where you figure out 
when this should be done and add it to the command line flags as necessary, 
that, or have the gcc includes mechanism automatically include the file itself 
when those conditions are present.  Although, yet more possibilities exist, 
like knowing what from that file is necessary, and builtinizing that content so 
that the tests pass anyway.

Thoughts?

Re: Fix VxWorks xfail filters on pthread-init-?.c

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:34 PM, Alexandre Oliva  wrote:
> Match xfail on kernel instead of rtp mode.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Longer term, would be nice to fix includes the relevant file to have the 
relevant definition.

Re: gcc.dg/intmax_t-1.c compiles without error on VxWorks 7 SR06x0

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:36 PM, Alexandre Oliva  wrote:
> 
> This test currently fails on VxWorks 7 SR06x0 targets when in kernel
> mode, because it expects a discrepancy between built-in and system
> intmax_t for all VxWorks targets when in kernel mode.  Fortunately,
> this has now been fixed when targetting VxWorks 7 SR06x0, so this
> commit adjusts the "dg-error" condition to exclude newer versions of
> VxWorks 7.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

fix includes or making the builtin agree with the system is a nicer longer term 
solution.

Re: Add conditions on VxWorks versions for gcc.dg/vxworks/initpri?.c

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:37 PM, Alexandre Oliva  wrote:
> 
> Adjust vxworks initpri expectations, given that vxworks7 has switched
> to .init_array.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

I suppose I should say that if the port maintainers want to chime in and 
recommend a different solution or have different idea on how to do things, I'd 
encourage them to chime in.  I'm kicking in only because no one else has yet, 
and thats roughly what I do.

Re: skip testsuite/g++.dg/other/anon5.C on vxworks_kernel targets

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:40 PM, Alexandre Oliva  wrote:
> 
> The vxworks kernel-mode linking is partial linking, so it cannot
> detect missing symbols.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: Undefine ERROR in g++.dg/tree-ssa/copyprop.C

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:41 PM, Alexandre Oliva  wrote:
> 
> VxWorks headers define ERROR as a macro, which conflicts with the use
> in the test.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: Remove VxWorks-specific test directives in g++.dg/warn/miss-format-1.C

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:42 PM, Alexandre Oliva  wrote:
> 
> These are no longer applicable.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: Skip testsuite/g++.old-deja/g++.pt/const2.C on vxworks_kernel

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:43 PM, Alexandre Oliva  wrote:
> 
> Linking in vxworks kernel-mode is partial linking, so missing symbols
> are not detected.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Generally nicer to bunch all like ones ("partial link" for example) together.

Re: Fix testsuite/g++.dg/cpp1y/constexpr-66093.C execution failure...

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:44 PM, Alexandre Oliva  wrote:
> 
> The constexpr iteration dereferenced an array element past the end of
> the array.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

How about:

  a[i-1] = i;

instead?  This I think better matches the comment in the code, and preserves 
the expected output as well.

If you like that and that works, Ok for that version.

> from Jerome Lambourg 
> for  gcc/testsuite/ChangeLog
> 
>* g++.dg/cpp1y/constexpr-66093.C: Fix bounds issue.
> ---
> gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C 
> b/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> index ad3169210d29a..3d742cfebd83d 100644
> --- a/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> @@ -19,7 +19,7 @@ private:
> 
> constexpr A f() {
> A a{};
> -for (int i = 1; i <= n; i++) {
> +for (int i = 0; i < n; i++) {
> a[i] = i;
> }
> return a;

Re: Fix testsuite/g++.dg/opt/20050511-1.C compilation error on VxWorks 7

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:44 PM, Alexandre Oliva  wrote:
> 
> In VxWorks 7, UINT32 is defined in both modes, kernel and rtp.  Adjust
> the work around accordingly.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: Fix testsuite/g++.old-deja/g++.mike/p658.C build failure on VxWorks RTP

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:45 PM, Alexandre Oliva  wrote:
> 
> The conflicting definition of OK is present in VxWorks RTP headers too.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Ok to stylize all the #undef in the same way.  This is one happens to use a 
slightly different stye then the others as I recall.

Re: compile gcc.target/arm/{pr78255-2.c, memset-inline-2.c} with -mno-long-calls

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:56 PM, Alexandre Oliva  wrote:
> 
> This change adds -mno-long-calls to the list of compiler options
> to make sure we generate short call code, allowing the assembly
> matching to pass.
> 
> This is added unconditionally to the dg-options (as opposed to using
> dg-additional-options) because this test is already specific to ARM
> targets, and -mno-long-calls is available on all ARM targets.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: g++.dg/tls/pr79288.C: Skip on vxworks_kernel (TLS model not supported)

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:57 PM, Alexandre Oliva  wrote:
> 
> The only TLS model supported in VxWorks kernel mode is local-exec.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: fix testsuite/g++.dg/init/new26.C for C++-14 and later

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:40 PM, Alexandre Oliva  wrote:
> 
> This test fails during the execution on VxWorks 7 when using
> C++-14 and C++-17.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: disable some aapcs/vfp*.c test if not arm_fp16_alternative_ok

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:47 PM, Alexandre Oliva  wrote:
> 
> The tests use -mfp16-format=alternative, and so should not be run
> if that option isn't supported.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: [committed] doc: Remove HSAIL from Language Standards

[Martin Jambor]

Hi Gerald,

On Mon, Dec 28 2020, Gerald Pfeifer wrote:
> Pushed.  
>
> There's quite a number of further references in gcc/doc; is anyone
> planning on continuing the deprecation and removing the actual bits?
>
> Gerald
>
>
> commit 7e999bd84f47205dc44b0f2dc90b53b3c888ca48
> Author: Gerald Pfeifer 
> Date:   Mon Dec 28 21:41:55 2020 +0100
>
> doc: Remove HSAIL from Language Standards
> 
> Support for HSAIL has been deprecated with GCC 10 and their web server
> has been down for weeks.
> 
> gcc/
> 2020-12-28  Gerald Pfeifer  
> 
> * doc/standards.texi (HSAIL): Remove section.
>

The HSAIL/BRIG consuming front-end has not been removed, as opposed to
the HSAIL/BRIG emitting back-end which was, and is still part of the
compiler, so this should not have been applied, I'm afraid.

Given the state of HSAIL, the front-end is probably not very useful
either and so we may remove it in near term too, but it seems to still
mostly work and causes no trouble, so at least for now it stayed.

Can you please revert this?

Thanks,

Martin


> diff --git a/gcc/doc/standards.texi b/gcc/doc/standards.texi
> index fc5016028dd..974f9b7e46d 100644
> --- a/gcc/doc/standards.texi
> +++ b/gcc/doc/standards.texi
> @@ -312,14 +312,6 @@ available online, see 
> @uref{http://gcc.gnu.org/readings.html}
>  As of the GCC 4.7.1 release, GCC supports the Go 1 language standard,
>  described at @uref{https://golang.org/doc/go1}.
>  
> -@section HSA Intermediate Language (HSAIL)
> -
> -GCC can compile the binary representation (BRIG) of the HSAIL text format as
> -described in HSA Programmer's Reference Manual version 1.0.1. This
> -capability is typically utilized to implement the HSA runtime API's HSAIL 
> -finalization extension for a gcc supported processor. HSA standards are
> -freely available at @uref{http://www.hsafoundation.com/standards/}.
> -
>  @section D language
>  
>  GCC supports the D 2.0 programming language.  The D language itself is

Re: [committed] doc: Remove HSAIL from Language Standards

[Gerald Pfeifer]

On Tue, 29 Dec 2020, Martin Jambor wrote:
>> commit 7e999bd84f47205dc44b0f2dc90b53b3c888ca48
>> Author: Gerald Pfeifer 
>> Date:   Mon Dec 28 21:41:55 2020 +0100
>>
>> doc: Remove HSAIL from Language Standards
>> 
>> Support for HSAIL has been deprecated with GCC 10 and their web server
>> has been down for weeks.

Please note the above.

> The HSAIL/BRIG consuming front-end has not been removed, as opposed to
> the HSAIL/BRIG emitting back-end which was, and is still part of the
> compiler, so this should not have been applied, I'm afraid.

This section in the documentation is about language standards and
reference to those standards.  hsafoundation.com literally has been
dead for a while, and there is not (evident) other location where
the standard appears vailable.

Also, wasn't the latest version 1.0.3 whereas our doc snippet still
referred to 1.0.1.

> Given the state of HSAIL, the front-end is probably not very useful
> either and so we may remove it in near term too, but it seems to still
> mostly work and causes no trouble, so at least for now it stayed.
> 
> Can you please revert this?

A simple revert does not appear appropriate, but if you have a strong
preference and see a benefit for our users, we surely can put something 
back in again.  

In that case, should the version updated to 1.0.3?  Apart from that 
and the defunct web site, what are other changes compared to the status 
pre commit 7e999bd84f47205dc44b0f2dc90b53b3c888ca48 ?

Can you propose some text / changes taking into account the deprecation
and related developments?  Can be rough, and I'll take care of the patch.

Gerald

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Jeff Law via Gcc-patches]

On 12/23/20 9:01 AM, abebeos wrote:
>
>
> On Sun, 13 Dec 2020 at 20:14, abebeos  +abeb...@gmail.com >
> wrote:
>
>
>
> On Fri, 11 Dec 2020 at 20:32, Jeff Law  > wrote:
>
>
>
> On 12/9/20 6:12 AM, abebeos via Gcc-patches wrote:
> > Essence:
> >
> > I need a confirmation that the testsuite setup as presented in:
> >
> > https://github.com/abebeos/avr-gnu
> 
> >
> > works fine.
> >
> > The problem with the avr target is that the testsuite cannot
> be run easily,
> > mainly because of the need for a special simulated-target
> setup, which does
> > not work for avr as documented. This led developers to a
> dead-end with
> > their non-cc0-avr-backends (the non-cc0 backend is needed
> thus avr is not
> > dropped from gcc11).
> >
> > I integrated a toolchain/testsetup to be able to run the gcc
> testsuite
> > against a simulated avr target.
> >
> > I then used this toolchain to test 2 different existent
> > non-cc0-avr-backends (from pipcet and saaadhu, both github).
> >
> > The result is that saaadhu's backend seems to be working
> 100%. It has
> > identical testsuite results with the existing (but
> deprecated) cc0-backend,
> > which means that it can be used "as-is" for inclusion in gcc11.
> >
> > Please note that I did this work in context of a bounty @
> bountysouce, more
> > information within the issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
> 
> I haven't looked at the github repo.  But I do have a couple
> comments here.
>
> First, the author of the changes (pipcet and saaadhu) need to have
> copyright assignments on file with the FSF.  Otherwise we can
> not use
> their work at all.
>
> Second, the work needs to be submitted for inclusion.  I don't
> recall
> seeing an official submission from either of them to gcc-patches.
>
> I'm definitely curious about the testing setup and whether or
> not it can
> be replicated into our Jenkins setup.  
>
>
> Where can I find this Jenkins setup?
>
>
> To close this: assuming " into our Jenkins setup" is some redhat
> internal jenkins setup.
No, it's public.

http://gcc.gnu.org/jenkins

jeff