[PATCH v2] xtensa: Optimize bitwise splicing operation

2023-01-07 Thread Takayuki 'January June' Suwa via Gcc-patches
This patch optimizes the operation of cutting and splicing two register
values at a specified bit position, in other words, combining (bitwise
ORing) bits 0 through (C-1) of the register with bits C through 31
of the other, where C is the specified immediate integer 17 through 31.

This typically applies to signed copy of floating point number and
__builtin_return_address() if the windowed register ABI, and saves one
instruction compared to four shifts and a bitwise OR by the default RTL
combination pass.

gcc/ChangeLog:

* config/xtensa/xtensa.md (*splice_bits):
New insn_and_split pattern.
---
 gcc/config/xtensa/xtensa.md | 47 +
 1 file changed, 47 insertions(+)

diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index 0a26d3dccf4..db1d68ee658 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -746,6 +746,53 @@
(set_attr "mode""SI")
(set_attr "length"  "3")])
 
+(define_insn_and_split "*splice_bits"
+  [(set (match_operand:SI 0 "register_operand" "=a")
+   (ior:SI (and:SI (match_operand:SI 1 "register_operand" "r")
+   (match_operand:SI 3 "const_int_operand" "i"))
+   (and:SI (match_operand:SI 2 "register_operand" "r")
+   (match_operand:SI 4 "const_int_operand" "i"]
+
+  "!optimize_debug && optimize
+   && INTVAL (operands[3]) + INTVAL (operands[4]) == -1
+   && (exact_log2 (INTVAL (operands[3]) + 1) > 16
+   || exact_log2 (INTVAL (operands[4]) + 1) > 16)"
+  "#"
+  "&& can_create_pseudo_p ()"
+  [(set (match_dup 5)
+   (ashift:SI (match_dup 1)
+  (match_dup 4)))
+   (set (match_dup 6)
+   (lshiftrt:SI (match_dup 2)
+(match_dup 3)))
+   (set (match_dup 0)
+   (ior:SI (lshiftrt:SI (match_dup 5)
+(match_dup 4))
+   (ashift:SI (match_dup 6)
+  (match_dup 3]
+{
+  int shift;
+  if (INTVAL (operands[3]) < 0)
+{
+  rtx x;
+  x = operands[1], operands[1] = operands[2], operands[2] = x;
+  x = operands[3], operands[3] = operands[4], operands[4] = x;
+}
+  shift = floor_log2 (INTVAL (operands[3]) + 1);
+  operands[3] = GEN_INT (shift);
+  operands[4] = GEN_INT (32 - shift);
+  operands[5] = gen_reg_rtx (SImode);
+  operands[6] = gen_reg_rtx (SImode);
+}
+  [(set_attr "type""arith")
+   (set_attr "mode""SI")
+   (set (attr "length")
+   (if_then_else (match_test "TARGET_DENSITY
+  && (INTVAL (operands[3]) == 0x7FFF
+  || INTVAL (operands[4]) == 0x7FFF)")
+ (const_int 11)
+ (const_int 12)))])
+
 
 ;; Zero-extend instructions.
 
-- 
2.30.2


Re: [PATCH] xtensa: Optimize bitwise splicing operation

2023-01-07 Thread Takayuki 'January June' Suwa via Gcc-patches
On 2023/01/08 6:53, Max Filippov wrote:
> On Fri, Jan 6, 2023 at 6:55 PM Takayuki 'January June' Suwa
>  wrote:
>>
>> This patch optimizes the operation of cutting and splicing two register
>> values at a specified bit position, in other words, combining (bitwise
>> ORing) bits 0 through (C-1) of the register with bits C through 31
>> of the other, where C is the specified immediate integer 1 through 31.
>>
>> This typically applies to signedness copy of floating point number or
>> __builtin_return_address() if the windowed register ABI, and saves one
>> instruction compared to four shifts and a bitwise OR by the RTL
>> generation pass.
> 
> While I indeed see this kind of change, e.g.:
> -   extui   a3, a3, 27, 5
> -   sllia2, a2, 5
> -   srlia2, a2, 5
> -   sllia3, a3, 27
> -   or  a2, a2, a3
> +   sllia2, a2, 5
> +   extui   a3, a3, 27, 5
> +   ssai5
> +   src a2, a3, a2
> 
> I also see the following:
> -   movi.n  a6, -4
> -   and a5, a5, a6
> -   extui   a3, a3, 0, 2
> -   or  a3, a3, a5
> +   srlia5, a5, 2
> +   sllia3, a3, 30
> +   ssai30
> +   src a3, a5, a3
> 
> i.e. after the split there's the same number of instructions,
> but the new sequence is one byte longer than the original one
> because of the movi.n.
> 
> Looking at a bunch of linux builds I observe a slight code size
> growth in call0 kernels and a slight code size reduction in
> windowed kernels.
> 
>> gcc/ChangeLog:
>>
>> * config/xtensa/xtensa.md (*splice_bits):
>> New insn_and_split pattern.
>> ---
>>  gcc/config/xtensa/xtensa.md | 47 +
>>  1 file changed, 47 insertions(+)
>>
>> diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
>> index 0a26d3dccf4..36ec1b1918e 100644
>> --- a/gcc/config/xtensa/xtensa.md
>> +++ b/gcc/config/xtensa/xtensa.md
>> @@ -746,6 +746,53 @@
>> (set_attr "mode""SI")
>> (set_attr "length"  "3")])
>>
>> +(define_insn_and_split "*splice_bits"
>> +  [(set (match_operand:SI 0 "register_operand" "=a")
>> +   (ior:SI (and:SI (match_operand:SI 1 "register_operand" "r")
>> +   (match_operand:SI 3 "const_int_operand" "i"))
>> +   (and:SI (match_operand:SI 2 "register_operand" "r")
>> +   (match_operand:SI 4 "const_int_operand" "i"]
>> +
>> +  "!optimize_debug && optimize
>> +   && INTVAL (operands[3]) + INTVAL (operands[4]) == -1
>> +   && (exact_log2 (INTVAL (operands[3]) + 1) > 0
>> +   || exact_log2 (INTVAL (operands[4]) + 1) > 0)"
>> +  "#"
>> +  "&& can_create_pseudo_p ()"
>> +  [(set (match_dup 5)
>> +   (ashift:SI (match_dup 1)
>> +  (match_dup 4)))
>> +   (set (match_dup 6)
>> +   (lshiftrt:SI (match_dup 2)
>> +(match_dup 3)))
>> +   (set (match_dup 0)
>> +   (ior:SI (lshiftrt:SI (match_dup 5)
>> +(match_dup 4))
>> +   (ashift:SI (match_dup 6)
>> +  (match_dup 3]
>> +{
>> +  int shift;
>> +  if (INTVAL (operands[3]) < 0)
>> +{
>> +  rtx x;
>> +  x = operands[1], operands[1] = operands[2], operands[2] = x;
>> +  x = operands[3], operands[3] = operands[4], operands[4] = x;
>> +}
>> +  shift = floor_log2 (INTVAL (operands[3]) + 1);
>> +  operands[3] = GEN_INT (shift);
>> +  operands[4] = GEN_INT (32 - shift);
>> +  operands[5] = gen_reg_rtx (SImode);
>> +  operands[6] = gen_reg_rtx (SImode);
>> +}
>> +  [(set_attr "type""arith")
>> +   (set_attr "mode""SI")
>> +   (set (attr "length")
>> +   (if_then_else (match_test "TARGET_DENSITY
>> +  && (INTVAL (operands[3]) == 0x7FFF
>> +  || INTVAL (operands[4]) == 
>> 0x7FFF)")
>> + (const_int 11)
>> + (const_int 12)))])
> 
> I wonder how the length could be 11 here? I always see 4 3-byte
> instructions generated by this pattern.
> 

Sorry, I should have carried out a systematic test beforehand:

#define TEST(c) \
  unsigned int test_ ## c (unsigned int a, unsigned int b) { \
return (a & (-1U >> c)) | (b & ~(-1U >> c)); \
  }
TEST(1)
TEST(2)
  ...
TEST(30)
TEST(31)

Without this patch, compiling the above if c is:

 a. between 1 and 15, slli (or add.n) + extui + slli + srli + or
 b. 16 then extui + slli + extui + or
 c. between 17 and 20, srli + slli + extui + or 
 d. between 21 and 31, movi(.n) + and + extui + or

Clearly, the patch should be restricted to apply only to case a.


Re: [PATCH] INSTALL: Default to --enable-cet=auto

2023-01-07 Thread Gerald Pfeifer
On Fri, 27 Nov 2020, H.J. Lu wrote:
> The new wording is
> 
> ---
> @code{--enable-cet=auto} is default.  CET is enabled on Linux/x86 if
> target binutils supports @code{Intel CET} instructions and disabled
> otherwise.  In this case, the target libraries are configured to get
> additional @option{-fcf-protection} option.
> ---
> 
> On Linux/x86, if binutils supports CET, target libraries will be compiled
> with -fcf-protection}.

I'm afraid this (the last sentence) is not really clear reading what is in 
install.texi.

Maybe instead of 

  "In this case, the target libraries are configured to get additional 
  @option{-fcf-protection} option."

something like

  "In the former case the target libraries are additionally configured 
  with @option{-fcf-protection}." ?

Gerald


Re: [PATCH] xtensa: Optimize bitwise splicing operation

2023-01-07 Thread Max Filippov via Gcc-patches
On Fri, Jan 6, 2023 at 6:55 PM Takayuki 'January June' Suwa
 wrote:
>
> This patch optimizes the operation of cutting and splicing two register
> values at a specified bit position, in other words, combining (bitwise
> ORing) bits 0 through (C-1) of the register with bits C through 31
> of the other, where C is the specified immediate integer 1 through 31.
>
> This typically applies to signedness copy of floating point number or
> __builtin_return_address() if the windowed register ABI, and saves one
> instruction compared to four shifts and a bitwise OR by the RTL
> generation pass.

While I indeed see this kind of change, e.g.:
-   extui   a3, a3, 27, 5
-   sllia2, a2, 5
-   srlia2, a2, 5
-   sllia3, a3, 27
-   or  a2, a2, a3
+   sllia2, a2, 5
+   extui   a3, a3, 27, 5
+   ssai5
+   src a2, a3, a2

I also see the following:
-   movi.n  a6, -4
-   and a5, a5, a6
-   extui   a3, a3, 0, 2
-   or  a3, a3, a5
+   srlia5, a5, 2
+   sllia3, a3, 30
+   ssai30
+   src a3, a5, a3

i.e. after the split there's the same number of instructions,
but the new sequence is one byte longer than the original one
because of the movi.n.

Looking at a bunch of linux builds I observe a slight code size
growth in call0 kernels and a slight code size reduction in
windowed kernels.

> gcc/ChangeLog:
>
> * config/xtensa/xtensa.md (*splice_bits):
> New insn_and_split pattern.
> ---
>  gcc/config/xtensa/xtensa.md | 47 +
>  1 file changed, 47 insertions(+)
>
> diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
> index 0a26d3dccf4..36ec1b1918e 100644
> --- a/gcc/config/xtensa/xtensa.md
> +++ b/gcc/config/xtensa/xtensa.md
> @@ -746,6 +746,53 @@
> (set_attr "mode""SI")
> (set_attr "length"  "3")])
>
> +(define_insn_and_split "*splice_bits"
> +  [(set (match_operand:SI 0 "register_operand" "=a")
> +   (ior:SI (and:SI (match_operand:SI 1 "register_operand" "r")
> +   (match_operand:SI 3 "const_int_operand" "i"))
> +   (and:SI (match_operand:SI 2 "register_operand" "r")
> +   (match_operand:SI 4 "const_int_operand" "i"]
> +
> +  "!optimize_debug && optimize
> +   && INTVAL (operands[3]) + INTVAL (operands[4]) == -1
> +   && (exact_log2 (INTVAL (operands[3]) + 1) > 0
> +   || exact_log2 (INTVAL (operands[4]) + 1) > 0)"
> +  "#"
> +  "&& can_create_pseudo_p ()"
> +  [(set (match_dup 5)
> +   (ashift:SI (match_dup 1)
> +  (match_dup 4)))
> +   (set (match_dup 6)
> +   (lshiftrt:SI (match_dup 2)
> +(match_dup 3)))
> +   (set (match_dup 0)
> +   (ior:SI (lshiftrt:SI (match_dup 5)
> +(match_dup 4))
> +   (ashift:SI (match_dup 6)
> +  (match_dup 3]
> +{
> +  int shift;
> +  if (INTVAL (operands[3]) < 0)
> +{
> +  rtx x;
> +  x = operands[1], operands[1] = operands[2], operands[2] = x;
> +  x = operands[3], operands[3] = operands[4], operands[4] = x;
> +}
> +  shift = floor_log2 (INTVAL (operands[3]) + 1);
> +  operands[3] = GEN_INT (shift);
> +  operands[4] = GEN_INT (32 - shift);
> +  operands[5] = gen_reg_rtx (SImode);
> +  operands[6] = gen_reg_rtx (SImode);
> +}
> +  [(set_attr "type""arith")
> +   (set_attr "mode""SI")
> +   (set (attr "length")
> +   (if_then_else (match_test "TARGET_DENSITY
> +  && (INTVAL (operands[3]) == 0x7FFF
> +  || INTVAL (operands[4]) == 
> 0x7FFF)")
> + (const_int 11)
> + (const_int 12)))])

I wonder how the length could be 11 here? I always see 4 3-byte
instructions generated by this pattern.

-- 
Thanks.
-- Max


Re: [PATCH v2] xtensa: Optimize stack frame adjustment more

2023-01-07 Thread Max Filippov via Gcc-patches
On Fri, Jan 6, 2023 at 6:55 PM Takayuki 'January June' Suwa
 wrote:
>
> This patch introduces a convenient helper function for integer immediate
> addition with scratch register as needed, that splits and emits either
> up to two ADDI/ADDMI machine instructions or an addition by register
> following an integer immediate load (which may later be transformed by
> constantsynth).
>
> By using the helper function, it makes stack frame adjustment logic
> simplified and instruction count less in some cases.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc
> (xtensa_split_imm_two_addends, xtensa_emit_add_imm):
> New helper functions.
> (xtensa_set_return_address, xtensa_output_mi_thunk):
> Change to use the helper function.
> (xtensa_emit_adjust_stack_ptr): Ditto.
> And also change to try reusing the content of scratch register
> A9 if the register is not modified in the function body.
> ---
>  gcc/config/xtensa/xtensa.cc | 151 +---
>  1 file changed, 106 insertions(+), 45 deletions(-)

Regtested for target=xtensa-linux-uclibc, no new regressions.
Committed to master.

-- 
Thanks.
-- Max


[PATCH] c++tools: Fix compilation of server.cc on hpux

2023-01-07 Thread John David Anglin
Tested on trunk and gcc-12 with hppa64-hp-hpux11.11.

Okay?

Dave
---

Fix compilation of server.cc on hpux.

Select and FD_ISSET are declared in sys/time.h on most versions
of hpux.  As a result, HAVE_PSELECT and HAVE_SELECT can be 0.

2023-01-07  John David Anglin  

c++tools/ChangeLog:

PR c++tools/107616
* server.cc (server): Don't call FD_ISSET when HAVE_PSELECT
and HAVE_SELECT are zero.

diff --git a/c++tools/server.cc b/c++tools/server.cc
index 00154a05925..693aec6820a 100644
--- a/c++tools/server.cc
+++ b/c++tools/server.cc
@@ -753,8 +753,10 @@ server (bool ipv6, int sock_fd, module_resolver *resolver)
  }
  }
 
+#if defined (HAVE_PSELECT) || defined (HAVE_SELECT)
  if (active < 0 && sock_fd >= 0 && FD_ISSET (sock_fd, ))
active = -1;
+#endif
}
 
  if (active >= 0)



signature.asc
Description: PGP signature


[committed] Fix compilation of gcc.dg/atomic/c11-atomic-exec-[45].c on hpux

2023-01-07 Thread John David Anglin
Tested on hppa64-hp-hpux11.11.  Committed to trunk.

Dave
---

Fix compilation of gcc.dg/atomic/c11-atomic-exec-[45].c on hpux.

_HPUX_SOURCE needs to be defined to provide various types needed
for pthreads.

2023-01-07  John David Anglin  

gcc/testsuite/ChangeLog:

* gcc.dg/atomic/c11-atomic-exec-4.c: Add "-D_HPUX_SOURCE" option
on *-*-hpux*.
* gcc.dg/atomic/c11-atomic-exec-5.c: Likewise.

diff --git a/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-4.c 
b/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-4.c
index 669e7c058c3..a7e158f14e8 100644
--- a/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-4.c
+++ b/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-4.c
@@ -4,6 +4,7 @@
 /* { dg-do run } */
 /* { dg-options "-std=c11 -pedantic-errors -pthread -U_POSIX_C_SOURCE 
-D_POSIX_C_SOURCE=200809L" } */
 /* { dg-additional-options "-D_XOPEN_SOURCE=600" { target *-*-solaris2* } } */
+/* { dg-additional-options "-D_HPUX_SOURCE" { target *-*-hpux* } } */
 /* { dg-require-effective-target pthread } */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c 
b/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c
index f8bfa63b4cc..299d6ab904b 100644
--- a/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c
+++ b/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c
@@ -7,6 +7,7 @@
 /* { dg-add-options ieee } */
 /* { dg-additional-options "-mfp-trap-mode=sui" { target alpha*-*-* } } */
 /* { dg-additional-options "-D_XOPEN_SOURCE=600" { target *-*-solaris2* } } */
+/* { dg-additional-options "-D_HPUX_SOURCE" { target *-*-hpux* } } */
 /* { dg-require-effective-target fenv_exceptions } */
 /* { dg-require-effective-target pthread } */
 /* { dg-timeout-factor 2 } */



signature.asc
Description: PGP signature


[PATCH, modula2] v2 PR-108182 gm2 driver mishandles target and multilib options

2023-01-07 Thread Gaius Mulley via Gcc-patches


Hi,

This is version 2 with the SKIPOPT applied to every option given to
save_switch.

ok for master?  Bootstrapped on x86_64 gnu/linux and darwin.

regards,
Gaius



PR-108182 gm2 driver mishandles target and multilib options

here are some patches which attempt to allow target specific include
paths and library paths in the gm2 driver.  I admit that the patch has
flaws in that it only processes options -f, -m in the lang_specific_driver.
[Called after driver::set_up_specs but before read_specs is called].

I suspect a better implementation might be to use a spec function
to fixup the paths.

gcc/ChangeLog:

* gcc.cc (save_switch): Remove static declaration.
(get_multilib_dir): New function.
(reset_mdswitches): New function.
* gcc/gcc.h (save_switch): Declare extern.
(get_multilib_dir): New extern.
(reset_mdswitches): New extern.

gcc/m2/ChangeLog:

* gm2spec.cc (lang_specific_driver): Detect -m and -f options and
call save_switch and SKIPOPT.  Assign multilib_dir with the result
of get_multilib_dir.  Call reset_mdswitches afterwards.

diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index d629ca5e424..362a6a96b63 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -3849,7 +3849,7 @@ alloc_switch (void)
 /* Save an option OPT with N_ARGS arguments in array ARGS, marking it
as validated if VALIDATED and KNOWN if it is an internal switch.  */

-static void
+void
 save_switch (const char *opt, size_t n_args, const char *const *args,
 bool validated, bool known)
 {
@@ -9559,6 +9559,24 @@ default_arg (const char *p, int len)
   return 0;
 }

+/* Return the value of multilib_dir.  */
+
+const char *
+get_multilib_dir (void)
+{
+  set_multilib_dir ();
+  return multilib_dir;
+}
+
+/* Reset the mdswitches array to empty.  */
+
+void
+reset_mdswitches (void)
+{
+  n_mdswitches = 0;
+  mdswitches = NULL;
+}
+
 /* Work out the subdirectory to use based on the options. The format of
multilib_select is a list of elements. Each element is a subdirectory
name followed by a list of options followed by a semicolon. The format
diff --git a/gcc/gcc.h b/gcc/gcc.h
index 19a61b373ee..03646ff2d87 100644
--- a/gcc/gcc.h
+++ b/gcc/gcc.h
@@ -73,6 +73,11 @@ struct spec_function
 extern int do_spec (const char *);
 extern void record_temp_file (const char *, int, int);
 extern void set_input (const char *);
+extern const char *get_multilib_dir (void);
+extern void reset_mdswitches (void);
+extern void save_switch (const char *opt, size_t n_args,
+const char *const *args,
+bool validated, bool known);

 /* Spec files linked with gcc.cc must provide definitions for these.  */

diff --git a/gcc/m2/gm2spec.cc b/gcc/m2/gm2spec.cc
index 583723da416..d813de4ab46 100644
--- a/gcc/m2/gm2spec.cc
+++ b/gcc/m2/gm2spec.cc
@@ -797,8 +797,20 @@ lang_specific_driver (struct cl_decoded_option 
**in_decoded_options,
  if ((decoded_options[i].orig_option_with_args_text != NULL)
  && (strncmp (decoded_options[i].orig_option_with_args_text,
   "-m", 2) == 0))
-   multilib_dir = xstrdup 
(decoded_options[i].orig_option_with_args_text
-   + 2);
+   {
+ save_switch (decoded_options[i].orig_option_with_args_text,
+  0, NULL, true, true);
+ args[i] |= SKIPOPT;
+   }
+ else if ((decoded_options[i].orig_option_with_args_text != NULL)
+  && (strncmp (decoded_options[i].orig_option_with_args_text,
+   "-f", 2) == 0))
+   {
+ save_switch (decoded_options[i].orig_option_with_args_text,
+  0, NULL, true, true);
+ args[i] |= SKIPOPT;
+   }
+ break;
}
 }
   if (language != NULL && (strcmp (language, "modula-2") != 0))
@@ -864,10 +876,13 @@ lang_specific_driver (struct cl_decoded_option 
**in_decoded_options,
   if ((! (seen_uselist || seen_gen_module_list)) && linking)
 append_option (OPT_fgen_module_list_, "-", 1);

+  multilib_dir = get_multilib_dir ();
+  reset_mdswitches ();
   if (allow_libraries)
 {
   /* If the libraries have not been specified by the user but the
-dialect has been specified then select the appropriate libraries.  */
+dialect has been specified then select the appropriate
+libraries.  */
   if (libraries == NULL)
{
  if (strcmp (dialect, "iso") == 0)


Re: [PATCH] modula-2, libm2min: Declare abort and exit as expected.

2023-01-07 Thread Gaius Mulley via Gcc-patches
Iain Sandoe  writes:

> Tested with a build on x86_64-darwin21, the build warnings are gone and
> the build completed as normal.
> OK for master?
> thanks
> Iain
>
> --- 8< ---
>
> The build is currently emitting a warning that abort() is declared differently
> from the built-in.  This updates the declaration to match expectations.
>
> Signed-off-by: Iain Sandoe 
>
> gcc/m2/ChangeLog:
>
>   * gm2-libs-min/libc.c (abort): Update declaration to match the
>   expected form, add no-return attribute.
>   (exit): Add no-return attribute.
> ---
>  gcc/m2/gm2-libs-min/libc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/m2/gm2-libs-min/libc.c b/gcc/m2/gm2-libs-min/libc.c
> index b39bfffb65c..8cddb5dd7b4 100644
> --- a/gcc/m2/gm2-libs-min/libc.c
> +++ b/gcc/m2/gm2-libs-min/libc.c
> @@ -24,10 +24,10 @@ a copy of the GCC Runtime Library Exception along with 
> this program;
>  see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
>  .  */
>  
> -void abort (int);
> -void exit (int);
> +extern void abort (void)  __attribute__ ((__noreturn__));
> +extern void exit (int) __attribute__ ((__noreturn__));
>  
> -void abort (int i)
> +void abort (void)
>  {
>while (1)
>  ;

yes LGTM, thanks!

regards,
Gaius


[patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)

2023-01-07 Thread Thomas Koenig via Gcc-patches

Hello world,

this patch fixes Fortran's handling of common subexpression elimination
across ieee_set_rouding_mode calls.  It does so using a rather big
hammer, by issuing a memory barrier to force reload from memory
(and thus a recomputation).

This is a rather big hammer, so if there are more elegant ways
to fix it, I am very much open to suggestions.

If PR 34678 is fixed, then this solution can also be applied here.

OK for trunk?  How do you feel about a backport?

Best regards

Thomas

Add memory barrier for calls to ieee_set_rounding_mode.

gcc/fortran/ChangeLog:

PR fortran/108329
* trans-expr.cc (trans_memory_barrier): New functions.
(gfc_conv_procedure_call): Insert memory barrier for
ieee_set_rounding_mode.

gcc/testsuite/ChangeLog:

PR fortran/108329
* gfortran.dg/rounding_4.f90: New test.diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 4f3ae82d39c..29be7804e11 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -5981,6 +5981,20 @@ post_call:
 gfc_add_block_to_block (>post, );
 }
 
+/* Helper function - generate a memory barrier.  */
+
+static tree
+trans_memory_barrier (void)
+{
+  tree tmp;
+
+  tmp = gfc_build_string_const (sizeof ("memory"), "memory");
+  tmp = build5_loc (input_location, ASM_EXPR, void_type_node,
+		gfc_build_string_const (1, ""), NULL_TREE, NULL_TREE,
+		tree_cons (NULL_TREE, tmp, NULL_TREE), NULL_TREE);
+  ASM_VOLATILE_P (tmp) = 1;
+  return tmp;
+}
 
 /* Generate code for a procedure call.  Note can return se->post != NULL.
If se->direct_byref is set then se->expr contains the return parameter.
@@ -7692,6 +7706,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
   else
 conv_base_obj_fcn_val (se, base_object, expr);
 
+  /* FIXME: Special handing of ieee_set_rounding_mode - we clobber
+ memory here to avoid common subexpression moving code past calls
+ to ieee_set_rounding_mode.  This should only be done for
+ floating point, but currently gcc offers no other possibility.
+ See PR 108329.  */
+
+  if (sym->from_intmod == INTMOD_IEEE_ARITHMETIC
+  && strcmp (sym->name, "ieee_set_rounding_mode") == 0)
+{
+  tree tmp = trans_memory_barrier ();
+  gfc_add_expr_to_block (, tmp);
+}
+
   /* If there are alternate return labels, function type should be
  integer.  Can't modify the type in place though, since it can be shared
  with other functions.  For dummy arguments, the typing is done to
diff --git a/gcc/testsuite/gfortran.dg/rounding_4.f90 b/gcc/testsuite/gfortran.dg/rounding_4.f90
new file mode 100644
index 000..e8799da67dc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/rounding_4.f90
@@ -0,0 +1,31 @@
+! { dg-do run }
+module y
+  implicit none
+  integer, parameter :: wp = selected_real_kind(15)
+contains
+  subroutine foo(a,b,c)
+use ieee_arithmetic
+real(kind=wp), dimension(4), intent(out) :: a
+real(kind=wp), intent(in) :: b, c
+type (ieee_round_type), dimension(4), parameter :: mode = &
+ [ieee_nearest, ieee_to_zero, ieee_up, ieee_down]
+call ieee_set_rounding_mode (mode(1))
+a(1) = b + c
+call ieee_set_rounding_mode (mode(2))
+a(2) = b + c
+call ieee_set_rounding_mode (mode(3))
+a(3) = b + c
+call ieee_set_rounding_mode (mode(4))
+a(4) = b + c
+  end subroutine foo
+end module y
+
+program main
+  use y
+  real(kind=wp), dimension(4) :: a
+  call foo(a,0.1_wp,0.2_wp)
+  if (a(1) <= a(2)) stop 1
+  if (a(3) <= a(4)) stop 2
+  if (a(1) /= a(3)) stop 3
+  if (a(2) /= a(4)) stop 4
+end program main


[PATCH] modula-2, libm2min: Declare abort and exit as expected.

2023-01-07 Thread Iain Sandoe via Gcc-patches
Tested with a build on x86_64-darwin21, the build warnings are gone and
the build completed as normal.
OK for master?
thanks
Iain

--- 8< ---

The build is currently emitting a warning that abort() is declared differently
from the built-in.  This updates the declaration to match expectations.

Signed-off-by: Iain Sandoe 

gcc/m2/ChangeLog:

* gm2-libs-min/libc.c (abort): Update declaration to match the
expected form, add no-return attribute.
(exit): Add no-return attribute.
---
 gcc/m2/gm2-libs-min/libc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/m2/gm2-libs-min/libc.c b/gcc/m2/gm2-libs-min/libc.c
index b39bfffb65c..8cddb5dd7b4 100644
--- a/gcc/m2/gm2-libs-min/libc.c
+++ b/gcc/m2/gm2-libs-min/libc.c
@@ -24,10 +24,10 @@ a copy of the GCC Runtime Library Exception along with this 
program;
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 .  */
 
-void abort (int);
-void exit (int);
+extern void abort (void)  __attribute__ ((__noreturn__));
+extern void exit (int) __attribute__ ((__noreturn__));
 
-void abort (int i)
+void abort (void)
 {
   while (1)
 ;
-- 
2.37.1 (Apple Git-137.1)



Java front-end and library patches v2

2023-01-07 Thread Max Downey Twiss via Gcc-patches
Disclaimer: this does not currently work.

The front-end and library compile successfully, but fail to link at
the very end.
This is due to a regression caused by
1dedc12d186a110854537e1279b4e6c29f2df35a, which I have been unable to solve.

Nevertheless, I am posting this patch series for two reasons.

Firstly, to get feedback and reviews on the 56 already existing
patches, even though most are just re-adding code or making idiomatic
changes, so that when the final issue is solved everything has already
been approved (hopefully) and the merge is good to go.

Secondly, to get assistance with the final issue, because it is simply
beyond me, and history has shown that asking for help via gcc-patches
will yield nothing.

You'll need libtool 2.4.7 and a bleeding-edge version of bdwgc to
build it, in case anyone planned to do some testing.

Answers to the questions asked on my last patch series leading email:

> Why is it now considered useful to add this front end back?

The way I see it, the Java front end was removed due to a lack of
maintenance and improvement. To put it simply, I am going to maintain
and improve it. That is the difference between now and then. There is
more nuance, but that is the gist of it.

> Which version is the basis of the one being added back...?

The exact same one that was removed from GCC, with the version taken
being the one right before it was removed.

> Would you propose to maintain the front end and libraries in future?

I have big plans for the library, and plan to maintain that long into
the future. In regards to the actual front-end code, I will do what I
can to make sure it remains at its previous level of function, but
that is about it. I dislike working with the front end code, so I will
fix it, but I will not make sweeping changes to it.

>  Would you re-open any bugs against the front end or libraries that were 
> closed...as a result of it being removed from the tree...?

Good point, I hadn't thought of that. It makes sense to re-open them,
as they are by definition valid again, although I may have difficulty
with the frontend ones, as that is not my strong suit.




Just a brief overview of my plans for the frontend and library-- When
GCJ was first introduced it was "the free Java implementation". It was
trying to offer a bytecode compiler, a machine code compiler and a
runtime library. Clearly, this was too much, as it borrowed another
bytecode compiler and runtime library, and even then the runtime
library fell into dissaray.

Now, we have many pieces of the puzzle. We have a bounty of free Java
bytecode compilers, and a free runtime library. The only thing missing
is a free machine code compiler, which GCJ was and is. I plan to
replace Classpath with the OpenJDK, and double down on the machine
code aspect of GCJ, dropping bytecode and interpreted support.


[PATCH] gcc: fix gcc --help -v opertion with linker flags and input files [PR108328]

2023-01-07 Thread Sagi Mor via Gcc-patches
PR gcc/108328

gcc/ChangeLog:

* gcc/gcc.cc: print help once and only once
---
 gcc/gcc.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index d629ca5e424..bd468a6a254 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -5414,9 +5414,9 @@ process_command (unsigned int decoded_options_count,
 }

   /* Ensure we only invoke each subprocess once.  */
-  if (n_infiles == 0
-  && (print_subprocess_help || print_help_list || print_version))
+  if (print_subprocess_help || print_help_list || print_version)
 {
+  n_infiles = 0;
   /* Create a dummy input file, so that we can pass
  the help option on to the various sub-processes.  */
   add_infile ("help-dummy", "c");
-- 
2.34.1


Re: [PATCH, modula2] PR-108182 gm2 driver mishandles target and multilib options

2023-01-07 Thread Iain Sandoe



> On 6 Jan 2023, at 21:42, Gaius Mulley via Gcc-patches 
>  wrote:
> 

> here are some patches which attempt to allow target specific include
> paths and library paths in the gm2 driver.  I admit that the patch has
> flaws in that it only processes options -f, -m in the lang_specific_driver.
> [Called after driver::set_up_specs but before read_specs is called].
> 
> I suspect a better implementation might include a language callback
> (lang_post_spec) which could fixup target related paths.
> 
> Nevertheless as a stage3 bugfix (workaround) they are presented below:
> 
> I wonder if they would be suitable for master?
> 
> Tested on Darwin (prior cleanup) and X86_64 Linux

retested this on Darwin, still fixes the issue.
Iain

> 
> regards,
> Gaius
> 
> - o< - o< - o< - o< - o< - o< - o< - o<
> diff --git a/gcc/gcc.cc b/gcc/gcc.cc
> index d629ca5e424..362a6a96b63 100644
> --- a/gcc/gcc.cc
> +++ b/gcc/gcc.cc
> @@ -3849,7 +3849,7 @@ alloc_switch (void)
> /* Save an option OPT with N_ARGS arguments in array ARGS, marking it
>as validated if VALIDATED and KNOWN if it is an internal switch.  */
> 
> -static void
> +void
> save_switch (const char *opt, size_t n_args, const char *const *args,
>bool validated, bool known)
> {
> @@ -9559,6 +9559,24 @@ default_arg (const char *p, int len)
>   return 0;
> }
> 
> +/* Return the value of multilib_dir.  */
> +
> +const char *
> +get_multilib_dir (void)
> +{
> +  set_multilib_dir ();
> +  return multilib_dir;
> +}
> +
> +/* Reset the mdswitches array to empty.  */
> +
> +void
> +reset_mdswitches (void)
> +{
> +  n_mdswitches = 0;
> +  mdswitches = NULL;
> +}
> +
> /* Work out the subdirectory to use based on the options. The format of
>multilib_select is a list of elements. Each element is a subdirectory
>name followed by a list of options followed by a semicolon. The format
> diff --git a/gcc/gcc.h b/gcc/gcc.h
> index 19a61b373ee..03646ff2d87 100644
> --- a/gcc/gcc.h
> +++ b/gcc/gcc.h
> @@ -73,6 +73,11 @@ struct spec_function
> extern int do_spec (const char *);
> extern void record_temp_file (const char *, int, int);
> extern void set_input (const char *);
> +extern const char *get_multilib_dir (void);
> +extern void reset_mdswitches (void);
> +extern void save_switch (const char *opt, size_t n_args,
> +  const char *const *args,
> +  bool validated, bool known);
> 
> /* Spec files linked with gcc.cc must provide definitions for these.  */
> 
> diff --git a/gcc/m2/gm2spec.cc b/gcc/m2/gm2spec.cc
> index 583723da416..dbfd1ca 100644
> --- a/gcc/m2/gm2spec.cc
> +++ b/gcc/m2/gm2spec.cc
> @@ -797,8 +797,14 @@ lang_specific_driver (struct cl_decoded_option 
> **in_decoded_options,
> if ((decoded_options[i].orig_option_with_args_text != NULL)
> && (strncmp (decoded_options[i].orig_option_with_args_text,
>  "-m", 2) == 0))
> - multilib_dir = xstrdup 
> (decoded_options[i].orig_option_with_args_text
> - + 2);
> + save_switch (decoded_options[i].orig_option_with_args_text,
> +  0, NULL, true, true);
> +   else if ((decoded_options[i].orig_option_with_args_text != NULL)
> +&& (strncmp (decoded_options[i].orig_option_with_args_text,
> + "-f", 2) == 0))
> +   save_switch (decoded_options[i].orig_option_with_args_text,
> +0, NULL, true, true);
> +   break;
>   }
> }
>   if (language != NULL && (strcmp (language, "modula-2") != 0))
> @@ -864,10 +870,13 @@ lang_specific_driver (struct cl_decoded_option 
> **in_decoded_options,
>   if ((! (seen_uselist || seen_gen_module_list)) && linking)
> append_option (OPT_fgen_module_list_, "-", 1);
> 
> +  multilib_dir = get_multilib_dir ();
> +  reset_mdswitches ();
>   if (allow_libraries)
> {
>   /* If the libraries have not been specified by the user but the
> -  dialect has been specified then select the appropriate libraries.  */
> +  dialect has been specified then select the appropriate
> +  libraries.  */
>   if (libraries == NULL)
>   {
> if (strcmp (dialect, "iso") == 0)
> 



[PATCH] modula-2, driver: Do not add extra '-L' options that shadow $libdir.

2023-01-07 Thread Iain Sandoe via Gcc-patches
tested on x86_64-linux-gnu, i686, powerpc, x86_64 darwin,
note that this patch does expose PR108261 (but that is a separate issue).
OK for trunk?
thanks
Iain

--- 8< ---

The driver is adding one '-L' option for each path to libm2xxx.a which is
shadowing $libpath where the shared libraries are installed.  This prevents
the shared libraries from being found (there are also convenience libs
in $libdir, so the additional -L options are not needed).

gcc/m2/ChangeLog:

* gm2spec.cc (add_default_combination): Do not add extra library
paths for the libm2xxx.a libraries.
---
 gcc/m2/gm2spec.cc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/m2/gm2spec.cc b/gcc/m2/gm2spec.cc
index dbfd1ca..f6d216269c1 100644
--- a/gcc/m2/gm2spec.cc
+++ b/gcc/m2/gm2spec.cc
@@ -289,7 +289,6 @@ add_default_combination (const char *libpath, const char 
*library)
 {
   if (library != NULL)
 {
-  append_option (OPT_L, build_archive_path (libpath, library), 1);
   append_option (OPT_l, safe_strdup (library), 1);
   return true;
 }
-- 
2.37.1 (Apple Git-137.1)