Re: [PATCH fortran/diagnostics] Move gfc_error (buffered) to common diagnostics

[Tobias Burnus]

Manuel López-Ibáñez wrote:

OK, this is then the final patch. Bootstrapped and regression tested
on x86_64-linux-gnu.
OK to commit?


 void
 gfc_buffer_error (bool flag)
 {
   buffered_p = flag;
-  pp_warning_buffer.flush_p = !flag;
+  buffered_p = flag;
 }

Now there are two "buffered_p" …

Otherwise, it looks good to me. Thanks!

Tobias


gcc/ChangeLog:

2014-12-07  Manuel López-Ibáñez  

 PR fortran/44054
 * diagnostic.c (diagnostic_action_after_output): Make it extern.
 Take diagnostic_t argument instead of diagnostic_info.
 (diagnostic_report_diagnostic): Update call according to the above.
 (error_recursion): Likewise.
 * diagnostic.h (diagnostic_action_after_output): Declare.
 * pretty-print.c (pp_formatted_text_data): Delete.
 (pp_append_r): Call output_buffer_append_r.
 (pp_formatted_text): Call output_buffer_formatted_text.
 (pp_last_position_in_text): Call output_buffer_last_position_in_text.
 * pretty-print.h (output_buffer_formatted_text): New.
 (output_buffer_append_r): New.
 (output_buffer_last_position_in_text): New

gcc/testsuite/ChangeLog:

2014-12-07  Manuel López-Ibáñez  

 * gfortran.dg/do_iterator.f90: Remove bogus dg-warning.

gcc/fortran/ChangeLog:

2014-12-07  Manuel López-Ibáñez  

 PR fortran/44054
 * error.c (pp_error_buffer): New static variable.
 (gfc_output_buffer_empty_p): New.
 (gfc_error_init_1): Call gfc_buffer_error.
 (gfc_buffer_error): Do not use pp_warning_buffer.flush_p as the
 buffered_p flag.
 (gfc_clear_warning): Likewise.
 (gfc_warning_check): Call gfc_clear_warning. Only check the new
 pp_warning_buffer if the old warning_buffer was empty.
 (gfc_error_1): Renamed from gfc_error.
 (gfc_error): New.
 (gfc_clear_error): Clear also pp_error_buffer.
 (gfc_error_flag_test): Check also pp_error_buffer.
 (gfc_error_check): Likewise. Only check the new pp_error_buffer
 if the old error_buffer was empty.
 (gfc_move_output_buffer_from_to): New.
 (gfc_push_error): Use it here. Take also an output_buffer as argument.
 (gfc_pop_error): Likewise.
 (gfc_free_error): Likewise.
 (gfc_diagnostics_init): Init pp_error_buffer. Set
 flush_p to false for both pp_warning_buffer and pp_error_buffer.

 * Update gfc_push_error, gfc_pop_error and gfc_free_error calls
 according to the above changes.
 * Use gfc_error_1 for all gfc_error calls that use multiple
 locations.
 * Use %qs instead of '%s' for many gfc_error calls.

Re: [RFC] diagnostics.c: For terminals, restrict messages to terminal width?

[FX]

OK. But if we rename the function, why not simply terminal_width() ?

FX



> Le 6 déc. 2014 à 23:14, Tobias Burnus  a écrit :
> 
> This patch fixes a Fortran diagnostic "regression".
> 
> With the current common diagnostic, the width shown with caret diagnostic is 
> determined by:
> 
>case OPT_fmessage_length_:
>  pp_set_line_maximum_length (dc->printer, value);
>  diagnostic_set_caret_max_width (dc, value);
> 
> plus
> 
> diagnostic_set_caret_max_width (diagnostic_context *context, int value)
> {
>   /* One minus to account for the leading empty space.  */
>   value = value ? value - 1
> : (isatty (fileno (pp_buffer (context->printer)->stream))
>   ? getenv_columns () - 1: INT_MAX);
> 
>   if (value <= 0)
> value = INT_MAX;
> 
>   context->caret_max_width = value;
> }
> 
> where getenv_columns looks at the environment variable COLUMNS.
> 
> Note that -fmessage-length= applies to the error message (wraps) _and_ the 
> caret diagnostic (truncates) while the COLUMNS variable _only_ applies to the 
> caret diagnostic. (BTW: The documentation currently does not mention COLUMNS.)
> 
> On most terminals, which I tried, COLUMNS does not seem to be set. In 
> Fortran, error.c's get_terminal_width has a similar check, but additionally 
> it uses ioctl to determine the terminal width.
> 
> I think with caret diagnostics, it is useful not to exceed the terminal width 
> as having several "empty" lines before the "^" does not really improve the 
> readability. Thus, I would propose to additionally use ioctl. Which rises two 
> questions: (a) Should the COLUMNS environment variable or ioctl have a higher 
> priority? [Fortran ranks ioctl higher; in the patch, for backward 
> compatibilty, I rank COLUMNS higher.] (b) Should ioctl be always used or only 
> for Fortran?
> 
> Comments?
> 
> Tobias
> 

Re: [PATCH, i386] Fix PR64003

[Richard Sandiford]

Ilya Enkovich  writes:
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 88435d6..9019ed8 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -10958,6 +10958,24 @@
>  ;; Basic conditional jump instructions.
>  ;; We ignore the overflow flag for signed branch instructions.
>  
> +(define_insn "*jcc_1_bnd"
> +  [(set (pc)
> + (if_then_else (match_operator 1 "ix86_comparison_operator"
> +   [(reg FLAGS_REG) (const_int 0)])
> +   (label_ref (match_operand 0))
> +   (pc)))]
> +  "TARGET_MPX && ix86_bnd_prefixed_insn_p (insn)"
> +  "bnd %+j%C1\t%l0"
> +  [(set_attr "type" "ibr")
> +   (set_attr "modrm" "0")
> +   (set (attr "length")
> +(if_then_else (and (ge (minus (match_dup 0) (pc))
> +   (const_int -126))
> +   (lt (minus (match_dup 0) (pc))
> +   (const_int 128)))
> +  (const_int 3)
> +  (const_int 7)))])
> +

Sorry, looking at this again, shouldn't the offset be -125 rather
than -126?  The pc in:

   (ge (minus (match_dup 0) (pc))
   (const_int -126))

is the start of the instruction, so we need to add the length
of the jump itself to the real minimum range of -128.

Thanks,
Richard

Re: [PATCH AARCH64]load store pair optimization using sched_fusion pass.

[Andrew Pinski]

On Sat, Dec 6, 2014 at 6:35 PM, Andrew Pinski  wrote:
> On Sat, Dec 6, 2014 at 5:54 PM, Andrew Pinski  wrote:
>> On Fri, Dec 5, 2014 at 9:08 AM, Marcus Shawcroft
>>  wrote:
>>> On 18 November 2014 at 08:34, Bin Cheng  wrote:
>>>
 2014-11-18  Bin Cheng  

 * config/aarch64/aarch64.md (load_pair): Split to
 load_pairsi, load_pairdi, load_pairsf and load_pairdf.
 (load_pairsi, load_pairdi, load_pairsf, load_pairdf): Split
 from load_pair.  New alternative to support int/fp
 registers in fp/int mode patterns.
 (store_pair:): Split to store_pairsi, store_pairdi,
 store_pairsf and store_pairdi.
 (store_pairsi, store_pairdi, store_pairsf, store_pairdf): Split
 from store_pair.  New alternative to support int/fp
 registers in fp/int mode patterns.
 (*load_pair_extendsidi2_aarch64): New pattern.
 (*load_pair_zero_extendsidi2_aarch64): New pattern.
 (aarch64-ldpstp.md): Include.
 * config/aarch64/aarch64-ldpstp.md: New file.
 * config/aarch64/aarch64-protos.h (aarch64_gen_adjusted_ldpstp):
 New.
 (extract_base_offset_in_addr): New.
 (aarch64_operands_ok_for_ldpstp): New.
 (aarch64_operands_adjust_ok_for_ldpstp): New.
 * config/aarch64/aarch64.c (enum sched_fusion_type): New enum.
 (TARGET_SCHED_FUSION_PRIORITY): New hook.
 (fusion_load_store): New functon.
 (extract_base_offset_in_addr): New function.
 (aarch64_gen_adjusted_ldpstp): New function.
 (aarch64_sched_fusion_priority): New function.
 (aarch64_operands_ok_for_ldpstp): New function.
 (aarch64_operands_adjust_ok_for_ldpstp): New function.

 2014-11-18  Bin Cheng  

 * gcc.target/aarch64/ldp-stp-1.c: New test.
 * gcc.target/aarch64/ldp-stp-2.c: New test.
 * gcc.target/aarch64/ldp-stp-3.c: New test.
 * gcc.target/aarch64/ldp-stp-4.c: New test.
 * gcc.target/aarch64/ldp-stp-5.c: New test.
 * gcc.target/aarch64/lr_free_1.c: Disable scheduling fusion
 and peephole2 pass.
>>>
>>> Committed, thanks. /Marcus
>>
>>
>> This patch has a bug in it dealing with volatile mems.  It will do a
>> peephole of two volatile mems into a pair which is not correct as the
>> order in the architecture is not defined and might even swap the order
>> of the load/store incorrectly.
>> I noticed this when I was merging in my changes for an improved
>> peephone which already has a check for volatile.
>
> Something like:
> @@ -10555,6 +10863,10 @@ aarch64_operands_ok_for_ldpstp (rtx
> *operands, bool load,
>reg_2 = operands[3];
>  }
>
> +  /* The mems cannot be volatile.  */
> +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2))
> +return false;
> +
>/* Check if the addresses are in the form of [base+offset].  */
>extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
>if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
>
>
>  CUT 
> gcc.target/aarch64/rev16_1.c is the testcase where two volatile loads
> being merged into one load pair.


And this one:
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 40881e7..da36dc8 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -10974,6 +10974,10 @@ aarch64_operands_adjust_ok_for_ldpstp (rtx
*operands, bool load,
   if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode))
 return false;

+  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2)
+  || MEM_VOLATILE_P (mem_3) ||MEM_VOLATILE_P (mem_4))
+return false;
+
   /* Check if the addresses are in the form of [base+offset].  */
   extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
   if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
--- CUT ---
This one happens with c-c++-common/torture/complex-sign-add.c.
I will post a full patch tomorrow.

Thanks,
Andrew

>
> Thanks,
> Andrew
>
>>
>> Thanks,
>> Andrew Pinski

duplicated text in gcc.target/h8300

[Bernd Edlinger]

Hi Oleg,


your checking from 2013-06-15 duplicated contents of the following files:


./gcc.target/h8300/pragma-isr2.c
./gcc.target/h8300/pragma-isr.c
./gcc.target/h8300/h8300.exp


it is therefore unlikely that theses tests can work in the h8300 target.


svn log -r200117  

r200117 | olegendo | 2013-06-15 02:38:43 +0200 (Sa, 15. Jun 2013) | 23 Zeilen

    * gcc.target/h8300/h8300.exp: New.
    * gcc.dg/pragma-isr.c: Move to ...
    * gcc.target/sh/torture/pragma-isr.c: ... here ...
    * gcc.target/h8300/pragma-isr.c: ... and here.
    * gcc.dg/pragma-isr2.c: Move to ...
    * gcc.target/sh/torture/pragma-isr2.c: ... here ...
    * gcc.target/h8300/pragma-isr2.c: ... and here.
...


Bernd.
  

Re: duplicated text in gcc.target/h8300

[Oleg Endo]

Hi Bernd,

On Sun, 2014-12-07 at 15:17 +0100, Bernd Edlinger wrote:
> Hi Oleg,
> 
> 
> your checking from 2013-06-15 duplicated contents of the following files:
> 
> 
> ./gcc.target/h8300/pragma-isr2.c
> ./gcc.target/h8300/pragma-isr.c
> ./gcc.target/h8300/h8300.exp
> 
> 
> it is therefore unlikely that theses tests can work in the h8300 target.

Yes, totally.  Thanks for spotting this.  I've committed the attached
patch to trunk as r218465 and to 4.9 branch as r218466.

Cheers,
Oleg

gcc/testsuite/ChangeLog:
* gcc.target/h8300/h8300.exp: Fix duplicated text.
* gcc.target/h8300/pragma-isr.c: Likewise.
* gcc.target/h8300/pragma-isr2.c: Likewise.
Index: gcc/testsuite/gcc.target/h8300/pragma-isr.c
===
--- gcc/testsuite/gcc.target/h8300/pragma-isr.c	(revision 218464)
+++ gcc/testsuite/gcc.target/h8300/pragma-isr.c	(working copy)
@@ -18,23 +18,3 @@
 {
   foo ();
 }
-/* Check whether rte is generated for two ISRs.  */
-/* { dg-do compile { target h8300-*-* } }  */
-/* { dg-options "-O3" }  */
-/* { dg-final { scan-assembler-times "rte" 2} }  */
-
-extern void foo (void);
-
-#pragma interrupt
-void
-isr1 (void)
-{
-  foo ();
-}
-
-#pragma interrupt
-void
-isr2 (void)
-{
-  foo ();
-}
Index: gcc/testsuite/gcc.target/h8300/pragma-isr2.c
===
--- gcc/testsuite/gcc.target/h8300/pragma-isr2.c	(revision 218464)
+++ gcc/testsuite/gcc.target/h8300/pragma-isr2.c	(working copy)
@@ -19,24 +19,3 @@
 {
   return 0;
 }
-/* Check whether rte is generated only for an ISR.  */
-/* { dg-do compile { target h8300-*-* } }  */
-/* { dg-options "-O" }  */
-/* { dg-final { scan-assembler-times "rte" 1 } }  */
-
-#pragma interrupt
-void
-isr (void)
-{
-}
-
-void
-delay (int a)
-{
-}
-
-int
-main (void)
-{
-  return 0;
-}
Index: gcc/testsuite/gcc.target/h8300/h8300.exp
===
--- gcc/testsuite/gcc.target/h8300/h8300.exp	(revision 218464)
+++ gcc/testsuite/gcc.target/h8300/h8300.exp	(working copy)
@@ -39,44 +39,3 @@
 
 # All done.
 dg-finish
-# Copyright (C) 2013-2014 Free Software Foundation, Inc.
-
-# This program 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 of the License, or
-# (at your option) any later version.
-# 
-# This program 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
-# .
-
-# GCC testsuite that uses the `dg.exp' driver.
-
-# Exit immediately if this isn't a h8300 target.
-if ![istarget h8300*-*-*] then {
-  return
-}
-
-# Load support procs.
-load_lib gcc-dg.exp
-
-# If a testcase doesn't have special options, use these.
-global DEFAULT_CFLAGS
-if ![info exists DEFAULT_CFLAGS] then {
-set DEFAULT_CFLAGS " -ansi -pedantic-errors"
-}
-
-# Initialize `dg'.
-dg-init
-
-# Main loop.
-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\]]] \
-	"" $DEFAULT_CFLAGS
-
-# All done.
-dg-finish

[committed] Require c99_target for gcc.dg/ipa/ipa-icf-5.c and gcc.dg/ipa/ipa-icf-7.c

[John David Anglin]

The attached change fixes the fails of gcc.dg/ipa/ipa-icf-5.c and  
gcc.dg/ipa/ipa-icf-7.c

on hppa*-*-hpux*.  Committed to trunk.

Dave
--
John David Anglin   dave.ang...@bell.net


2014-12-07  John David Anglin  

PR testsuite/64038
* gcc.dg/ipa/ipa-icf-5.c: Require c99_runtime.  Add c99_runtime options.
* gcc.dg/ipa/ipa-icf-7.c: Likewise.

Index: gcc.dg/ipa/ipa-icf-5.c
===
--- gcc.dg/ipa/ipa-icf-5.c  (revision 218435)
+++ gcc.dg/ipa/ipa-icf-5.c  (working copy)
@@ -1,5 +1,6 @@
-/* { dg-do compile } */
+/* { dg-do compile { target c99_runtime } } */
 /* { dg-options "-O2 -fdump-ipa-icf"  } */
+/* { dg-add-options c99_runtime } */
 
 #include 
 
Index: gcc.dg/ipa/ipa-icf-7.c
===
--- gcc.dg/ipa/ipa-icf-7.c  (revision 218435)
+++ gcc.dg/ipa/ipa-icf-7.c  (working copy)
@@ -1,5 +1,6 @@
-/* { dg-do compile } */
+/* { dg-do compile { target c99_runtime } } */
 /* { dg-options "-O2 -fdump-ipa-icf"  } */
+/* { dg-add-options c99_runtime } */
 
 #include 
 

[PATCH] Fix failure of coarray tests on hpux

[John David Anglin]

The attached change fixes the fortran coarray tests on hpux.  On hpux,  
it is necessary

to link directly against libatomic.

Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.

Okay for trunk?

Dave
--
John David Anglin   dave.ang...@bell.net


2014-12-07  John David Anglin  

Pr testsuite/62250
* lib/gfortran.exp: Add libatomic library search path.
* gfortran.dg/coarray/caf.exp: Add -latomic to test options.
* gfortran.dg/coarray_lib_comm_1.f90: Likewise.

Index: lib/gfortran.exp
===
--- lib/gfortran.exp(revision 218435)
+++ lib/gfortran.exp(working copy)
@@ -102,6 +102,13 @@
   if [file exists "${gccpath}/libgfortran/libgforbegin.a"] {
   append flags "-L${gccpath}/libgfortran "
   }
+  if [file exists "${gccpath}/libatomic/.libs/libatomic.${shlib_ext}"] {
+ append flags "-L${gccpath}/libatomic/.libs "
+ append ld_library_path ":${gccpath}/libatomic/.libs"
+  }
+  if [file exists "${gccpath}/libatomic/libatomic.a"] {
+  append flags "-L${gccpath}/libatomic "
+  }
   if [file exists "${gccpath}/libquadmath/.libs/libquadmath.a"] {
   # Some targets use libquadmath.a%s in their specs, so they need a -B 
option
   # for uninstalled testing.
Index: gfortran.dg/coarray/caf.exp
===
--- gfortran.dg/coarray/caf.exp (revision 218435)
+++ gfortran.dg/coarray/caf.exp (working copy)
@@ -65,13 +65,13 @@
 
 foreach flags $option_list {
verbose "Testing $nshort (single), $flags" 1
-   dg-test $test "-fcoarray=single $flags" "" 
+   dg-test $test "-fcoarray=single $flags -latomic" "" 
cleanup-modules ""
 }
 
 foreach flags $option_list {
verbose "Testing $nshort (libcaf_single), $flags" 1
-   dg-test $test "-fcoarray=lib $flags -lcaf_single" ""
+   dg-test $test "-fcoarray=lib $flags -lcaf_single -latomic" ""
cleanup-modules ""
 }
 }
Index: gfortran.dg/coarray_lib_comm_1.f90
===
--- gfortran.dg/coarray_lib_comm_1.f90  (revision 218435)
+++ gfortran.dg/coarray_lib_comm_1.f90  (working copy)
@@ -1,5 +1,5 @@
 ! { dg-do run }
-! { dg-options "-fdump-tree-original -fcoarray=lib -lcaf_single" }
+! { dg-options "-fdump-tree-original -fcoarray=lib -lcaf_single -latomic" }
 !
 ! Some dependency-analysis check for coarray communication
 !

Re: [PATCH] Fix failure of coarray tests on hpux

[Tobias Burnus]

John David Anglin wrote:
The attached change fixes the fortran coarray tests on hpux.  On hpux, 
it is necessary to link directly against libatomic.


Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Okay for trunk?


From the Fortran side, it looks okay.

Tobias

[PATCH] Correctly handle stack arguments of sibling calls in DSE pass

[John David Anglin]

On 1-Dec-14, at 11:57 AM, Jeff Law wrote:

Prior to reload (ie, in DSE1) there's a bit of magic in that we do  
not set frame_read on call insns.  That may in fact be wrong and  
possibly the source of the problem.


/* This field is only used for the processing of const functions.
These functions cannot read memory, but they can read the stack
because that is where they may get their parms.  We need to be
this conservative because, like the store motion pass, we don't
consider CALL_INSN_FUNCTION_USAGE when processing call insns.
Moreover, we need to distinguish two cases:
1. Before reload (register elimination), the stores related to
   outgoing arguments are stack pointer based and thus deemed
   of non-constant base in this pass.  This requires special
   handling but also means that the frame pointer based stores
   need not be killed upon encountering a const function call.
2. After reload, the stores related to outgoing arguments can be
   either stack pointer or hard frame pointer based.  This means
   that we have no other choice than also killing all the frame
   pointer based stores upon encountering a const function call.
This field is set after reload for const function calls.  Having
this set is less severe than a wild read, it just means that all
the frame related stores are killed rather than all the stores.   
*/

 bool frame_read;


As a test, what happens if we change:


 /* See the head comment of the frame_read field.  */
 if (reload_completed)
   insn_info->frame_read = true;

To do unconditionally set frame_read?  Or if we don't want to get  
that drastic,


if (reload_completed || SIBLING_CALL_P (insn))
 insn_info->frame_read = true;



The attached patch uses your suggestion above.  It also doesn't kill  
stack based stores

before reload when we have a sibling call.

Sibling calls use the incoming argument pointer to store arguments for  
the sibcall.  Typically,
the argument pointer and the frame pointer are related, but not on  
hppa64 where sibcalls are

disabled.  So, I have to wonder if the first approach wasn't better.

The change updates the comment for the frame_read field to mention  
sibling calls and

adds a testcase.

Tested on hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11.11, hppa64-hp- 
hpux11.11

with no observed regressions.

Bootstrap tested on on i686-unknown-linux-gnu.

Okay?

Dave
--
John David Anglin   dave.ang...@bell.net


2014-12-07  John David Anglin  

PR target/55023
* dse.c (frame_read): Update comment.
(scan_insn): Set insn_info->frame_read to true for sibling calls.
Don't remove stack pointer based stores for sibling calls before
reload.

Index: gcc/dse.c
===
--- gcc/dse.c   (revision 218467)
+++ gcc/dse.c   (working copy)
@@ -363,7 +363,8 @@
  consider CALL_INSN_FUNCTION_USAGE when processing call insns.
  Moreover, we need to distinguish two cases:
  1. Before reload (register elimination), the stores related to
-   outgoing arguments are stack pointer based and thus deemed
+   outgoing arguments are stack pointer based, except for sibling
+   calls which use incoming arguments, and thus they are deemed
of non-constant base in this pass.  This requires special
handling but also means that the frame pointer based stores
need not be killed upon encountering a const function call.
@@ -2516,7 +2517,7 @@
 const_call ? "const" : "memset", INSN_UID (insn));
 
  /* See the head comment of the frame_read field.  */
- if (reload_completed)
+ if (reload_completed || SIBLING_CALL_P (insn))
insn_info->frame_read = true;
 
  /* Loop over the active stores and remove those which are
@@ -2525,8 +2526,11 @@
{
  bool remove_store = false;
 
- /* The stack pointer based stores are always killed.  */
- if (i_ptr->stack_pointer_based)
+ /* The stack pointer based stores are always killed for
+non sibling calls.  Before reload, the arguments of a
+sibling call are frame pointer based.  */
+ if (i_ptr->stack_pointer_based
+ && (reload_completed || !SIBLING_CALL_P (insn)))
remove_store = true;
 
  /* If the frame is read, the frame related stores are killed.  */
--- /dev/null   2014-11-28 19:44:51.44000 -0500
+++ gcc/testsuite/gcc.dg/pr55023.c  2014-12-04 19:49:45.887701600 -0500
@@ -0,0 +1,33 @@
+/* PR rtl-optimization/55023 */
+/* { dg-do run } */
+/* { dg-options "-O2 -fno-inline" } */
+
+extern void abort (void);
+typedef long long int64_t;
+
+struct foo {
+int x;
+int y;
+};
+
+int64_t foo(int64_t a, int64_t b, int64_t c)
+{
+return a + b + c;
+}
+
+int64_t bar(int64_t a, struct foo bq, struct foo cq

Re: [patch, ARM] Add support for crtfastmath.o

[Sandra Loosemore]

On 11/08/2014 08:57 AM, Sandra Loosemore wrote:


2014-11-08  Sandra Loosemore  
 Chris Jones  
 Joshua Conner  

 gcc/
 * config/arm/unknown-elf.h (STARTFILE_SPEC): Add conditional
 linking of crtfastmath.o.
 * config/arm/linux-eabi.h (STARTFILE_SPEC): Likewise.

 libgcc/
 * config.host (arm*-*-linux*): Add support for crtfastmath.o.
 (arm*-*-uclinux*): Likewise.
 (arm*-*-eabi* | arm*-*-rtems*): Likewise.
 * config/arm/crtfastmath.c: New file.


Ping?

https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00711.html

-Sandra

Re: [testsuite] Fix multiple definitions of _init

[Oleg Endo]

On Tue, 2014-12-02 at 10:23 -0800, Mike Stump wrote:
> No.  It is reasonable for the test suite to fail when the
> implementation of gcc is wrong (unclean) or newlib startup code is
> wrong (unclean).  Since that is what happened, the fix is to fix the
> cleanliness problem.
> 
> I’ve read through the thread…  I think the sh newlib port has a trivial
> bug and should be fixed.  Either, add an underscore or remove one, just
> like _all_ the other ports.  There is no complexity here, just a typo
> (or someone copied the wrong port).
> 
> When newlib/libc/sys/sh/crt0.S is fixed, and libgcc/config/sh/crt1.S is
> fixed, then these test cases will pass.
> 
> USER_LABEL_PREFIX  is not the issue.  Let me quote from the code:
> 
> .long   _atexit .long   _init
> 
> This is wrong.
> 
> Also, _fini needs to be fixed as well.  It is unfortunate that the fix
> involves two packages, but, such is life.

On Tue, 2014-12-02 at 21:55 +, Joseph Myers wrote:
> See e.g. config/arm/lib1funcs.S:
> 
> #define SYM(x) CONCAT1 (__USER_LABEL_PREFIX__, x)
> 
> (and the associated macro definition of CONCAT1 that uses, etc.).  If
> you have .S sources that may be used on targets both with and without
> a prefix, you should do something similar.  (The ELF gABI says
> "External C symbols have the same names in C and object files' symbol
> tables.", so ELF targets using leading underscores on C symbol names
> are going against the gABI.)

Thanks for the comments.  I've tried the attached patch on my newlib
config and it seems to fix the problem.  Newlib doesn't seem to be in
need for patching for non-SH64/SH5 in this case.

Kaz, could you please check if the patch doesn't break anything on
sh4-linux?  If so, I'd like to commit this to trunk.

I'm a bit puzzled though.  In libgcc/arm/crti.S there are also _init and
_fini function names.  It seems that an arm-eabi configuration doesn't
add the _ prefix.  But if it did, that'd be the same problem as on SH I
guess?

I still think there should be a configure option to control/override the
target defined default value of USER_LABEL_PREFIX.  But that's another
story.

Cheers,
Oleg

Index: libgcc/config/sh/crti.S
===
--- libgcc/config/sh/crti.S	(revision 218464)
+++ libgcc/config/sh/crti.S	(working copy)
@@ -22,6 +22,7 @@
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 .  */
 
+#include "crt.h"
 
 /* The code in sections .init and .fini is supposed to be a single
regular function.  The function in .init is called directly from
@@ -44,8 +45,8 @@
 #else
 	.p2align 1
 #endif
-	.global	 _init
-_init:
+	.global	 GLOBAL(_init)
+GLOBAL(_init):
 #if __SHMEDIA__
 	addi	r15, -16, r15
 	st.q	r15, 8, r14
@@ -89,8 +90,8 @@
 #else
 	.p2align 1
 #endif
-	.global  _fini
-_fini:	
+	.global  GLOBAL(_fini)
+GLOBAL(_fini):	
 #if __SHMEDIA__
 	addi	r15, -16, r15
 	st.q	r15, 8, r14
Index: libgcc/config/sh/crt1.S
===
--- libgcc/config/sh/crt1.S	(revision 218464)
+++ libgcc/config/sh/crt1.S	(working copy)
@@ -22,6 +22,7 @@
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 .  */
 
+#include "crt.h"
 
 #ifdef MMU_SUPPORT
 	/* Section used for exception/timer interrupt stack area */
@@ -420,7 +421,7 @@
 #endif /* MMU_SUPPORT */
 
 	pt/l	.Lzero_bss_loop, tr0
-	pt/l	_init, tr5
+	pt/l	GLOBAL(_init), tr5
 	pt/l	___setup_argv_and_call_main, tr6
 	pt/l	_exit, tr7
 
@@ -452,7 +453,7 @@
 
 	! arrange for exit to call fini
 	pt/l	_atexit, tr1
-	LOAD_ADDR (_fini, r2)
+	LOAD_ADDR (GLOBAL(_fini), r2)
 	blink	tr1, r18
 
 	! call init
@@ -850,9 +851,9 @@
 atexit_k:
 	.long	_atexit
 init_k:
-	.long	_init
+	.long	GLOBAL(_init)
 fini_k:
-	.long	_fini
+	.long	GLOBAL(_fini)
 #ifdef VBR_SETUP
 old_vbr_k:
 	.long	old_vbr
@@ -1116,9 +1117,7 @@
 #if defined(__SH_FPU_ANY__)
 	.balign 4
 pervading_precision_k:
-#define CONCAT1(A,B) A##B
-#define CONCAT(A,B) CONCAT1(A,B)
-	.long CONCAT(__USER_LABEL_PREFIX__,__fpscr_values)+4
+	.long GLOBAL(__fpscr_values)+4
 #endif
 #else
 	mov.l 2f, r0 ! Load the old vbr setting (if any).
Index: libgcc/config/sh/crt.h
===
--- libgcc/config/sh/crt.h	(revision 0)
+++ libgcc/config/sh/crt.h	(revision 0)
@@ -0,0 +1,29 @@
+/* Copyright (C) 2014 Free Software Foundation, Inc.
+
+This file 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.
+
+This file 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.
+
+Under Section 7 of GPL version 3, you are granted additional
+per

[SH][committed] Fix extendqihi2 expander on SH64

[Oleg Endo]

Hi,

This fixes an SH64 problem which was introduced in r185534 and went
unnoticed until recently.  There, the extendqihi2 insn was converted to
an expander and the TARGET_SH1 condition was wrongly omitted.  Tested
with 'make all-gcc' on sh-elf and sh64-elf.  Committed on trunk as
r218469, on 4.9 as r218470 and on 4.8 as r218471.

Cheers,
Oleg

gcc/ChangeLog:
PR target/50751
* config/sh/sh.md (extendqihi2): Allow only for TARGET_SH1.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 218464)
+++ gcc/config/sh/sh.md	(working copy)
@@ -6364,10 +6364,9 @@
 })
 
 (define_expand "extendqihi2"
-  [(set (match_operand:HI 0 "arith_reg_dest" "")
-	(sign_extend:HI (match_operand:QI 1 "arith_reg_operand" "")))]
-  ""
-  "")
+  [(set (match_operand:HI 0 "arith_reg_dest")
+	(sign_extend:HI (match_operand:QI 1 "arith_reg_operand")))]
+  "TARGET_SH1")
 
 (define_insn "*extendqihi2_compact_reg"
   [(set (match_operand:HI 0 "arith_reg_dest" "=r")

[SH][committed] PR 53513 - Fix test case failure

[Oleg Endo]

Hi,

After the changes regarding the FPSCR handling, some SH test cases
started to fail.  This fixes one of them.  Tested with
make -k check-gcc RUNTESTFLAGS="sh.exp --target_board=sh-sim\{-m4/-ml}"
to verify that the test case passes again.  Committed as r218472.

Cheers,
Oleg

gcc/testsuite/ChangeLog
PR target/53513
* gcc.target/sh/pr54602-4.c: Fix matching of rte-nop sequence.
Index: gcc/testsuite/gcc.target/sh/pr54602-4.c
===
--- gcc/testsuite/gcc.target/sh/pr54602-4.c	(revision 218468)
+++ gcc/testsuite/gcc.target/sh/pr54602-4.c	(working copy)
@@ -4,7 +4,7 @@
 /* { dg-do compile }  */
 /* { dg-options "-O1" } */
 /* { dg-skip-if "" { "sh*-*-*" } { "*" } { "-m3*" "-m4*" } }  */
-/* { dg-final { scan-assembler-not "nop" } } */
+/* { dg-final { scan-assembler-not "rte\n\tnop" } } */
 
 int test00 (int a, int b);
 

Re: [PATCH 6/n] OpenMP 4.0 offloading infrastructure: option handling

[Ilya Verbin]

Hi,

On 28 Nov 09:36, Richard Biener wrote:
> On Fri, 28 Nov 2014, Ilya Verbin wrote:
> > I found a bug here, have_{lto,offload} must be set if at least one file 
> > contains
> > lto/offload sections, but currently they are overwritten by the last file.
> > Fix is bootstrapped and regtested on x86_64-linux.  OK for trunk?
> Ok.

Unfortunately, this fix was not general enough.
There might be cases when mixed object files get into lto-wrapper, ie some of
them contain only LTO sections, some contain only offload sections, and some
contain both.  But when lto-wrapper will pass all these files to recompilation,
the compiler might crash (it depends on the order of input files), since in
read_cgraph_and_symbols it expects that *all* input files contain IR section of
given type.
This patch splits input objects from argv into lto_argv and offload_argv, so
that all files in arrays contain corresponding IR.
Similarly, in lto-plugin, it was bad idea to add objects, which contain offload
IR without LTO, to claimed_files, since this may corrupt a resolution file.

Tested on various combinations of files with/without -flto and with/without
offload, using trunk ld and gold, also tested on ld without plugin support.
Bootstrap and make check passed on x86_64-linux and i686-linux.  Ok for trunk?

But I am unable to run lto-bootstrap on trunk, it says:
/x/build-x86_64-linux/./prev-gcc/gcc-ar -B/x/build-x86_64-linux/./prev-gcc/ cru 
libdecnumber.a decNumber.o decContext.o decimal32.o decimal64.o decimal128.o 
bid2dpd_dpd2bid.o host-ieee32.o host-ieee64.o host-ieee128.o
/usr/bin/ar terminated with signal 11 [Segmentation fault], core dumped
make[4]: *** [libdecnumber.a] Error 1


gcc/
* lto-wrapper.c (compile_offload_image): Start processing in_argv
from 0 instead of 1.
(run_gcc): Put offload objects into offload_argv, put LTO objects and
possible preceding arguments into lto_argv.
Pass offload_argv to compile_images_for_offload_targets instead of argv.
Use lto_argv for LTO recompilation instead of argv.
lto-plugin/
* lto-plugin.c (offload_files, num_offload_files): New static variables.
(free_1): Use arguments instead of global variables.
(free_2): Free offload_files.
(all_symbols_read_handler): Add names from offload_files to lto-wrapper
arguments.
(claim_file_handler): Do not add file to claimed_files if it contains
offload sections without LTO sections.  Add it to offload_files instead.


diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index 0f69457..f75c0dc 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -669,7 +669,7 @@ compile_offload_image (const char *target, const char 
*compiler_path,
   obstack_ptr_grow (&argv_obstack, filename);
 
   /* Append names of input object files.  */
-  for (unsigned i = 1; i < in_argc; i++)
+  for (unsigned i = 0; i < in_argc; i++)
obstack_ptr_grow (&argv_obstack, in_argv[i]);
 
   /* Append options from offload_lto sections.  */
@@ -883,6 +883,8 @@ run_gcc (unsigned argc, char *argv[])
   int new_head_argc;
   bool have_lto = false;
   bool have_offload = false;
+  unsigned lto_argc = 0, offload_argc = 0;
+  char **lto_argv, **offload_argv;
 
   /* Get the driver and options.  */
   collect_gcc = getenv ("COLLECT_GCC");
@@ -896,6 +898,11 @@ run_gcc (unsigned argc, char *argv[])
&decoded_options,
&decoded_options_count);
 
+  /* Allocate arrays for input object files with LTO or offload IL,
+ and for possible preceding arguments.  */
+  lto_argv = XNEWVEC (char *, argc);
+  offload_argv = XNEWVEC (char *, argc);
+
   /* Look at saved options in the IL files.  */
   for (i = 1; i < argc; ++i)
 {
@@ -918,17 +925,27 @@ run_gcc (unsigned argc, char *argv[])
}
   fd = open (argv[i], O_RDONLY);
   if (fd == -1)
-   continue;
+   {
+ lto_argv[lto_argc++] = argv[i];
+ continue;
+   }
+
+  if (find_and_merge_options (fd, file_offset, LTO_SECTION_NAME_PREFIX,
+ &fdecoded_options, &fdecoded_options_count,
+ collect_gcc))
+   {
+ have_lto = true;
+ lto_argv[lto_argc++] = argv[i];
+   }
+
+  if (find_and_merge_options (fd, file_offset, OFFLOAD_SECTION_NAME_PREFIX,
+ &offload_fdecoded_options,
+ &offload_fdecoded_options_count, collect_gcc))
+   {
+ have_offload = true;
+ offload_argv[offload_argc++] = argv[i];
+   }
 
-  have_lto
-   |= find_and_merge_options (fd, file_offset, LTO_SECTION_NAME_PREFIX,
-  &fdecoded_options, &fdecoded_options_count,
-  collect_gcc);
-  have_offload
-   |= find_and_merge_options (fd, file_offset, OFFLOAD_SECTION_NAME_PREFIX,
- 

Re: [PATCH AARCH64]load store pair optimization using sched_fusion pass.

[Bin.Cheng]

On Sun, Dec 7, 2014 at 6:24 PM, Andrew Pinski  wrote:
> On Sat, Dec 6, 2014 at 6:35 PM, Andrew Pinski  wrote:
>> On Sat, Dec 6, 2014 at 5:54 PM, Andrew Pinski  wrote:
>>> On Fri, Dec 5, 2014 at 9:08 AM, Marcus Shawcroft
>>>  wrote:
 On 18 November 2014 at 08:34, Bin Cheng  wrote:

> 2014-11-18  Bin Cheng  
>
> * config/aarch64/aarch64.md (load_pair): Split to
> load_pairsi, load_pairdi, load_pairsf and load_pairdf.
> (load_pairsi, load_pairdi, load_pairsf, load_pairdf): Split
> from load_pair.  New alternative to support int/fp
> registers in fp/int mode patterns.
> (store_pair:): Split to store_pairsi, store_pairdi,
> store_pairsf and store_pairdi.
> (store_pairsi, store_pairdi, store_pairsf, store_pairdf): Split
> from store_pair.  New alternative to support int/fp
> registers in fp/int mode patterns.
> (*load_pair_extendsidi2_aarch64): New pattern.
> (*load_pair_zero_extendsidi2_aarch64): New pattern.
> (aarch64-ldpstp.md): Include.
> * config/aarch64/aarch64-ldpstp.md: New file.
> * config/aarch64/aarch64-protos.h (aarch64_gen_adjusted_ldpstp):
> New.
> (extract_base_offset_in_addr): New.
> (aarch64_operands_ok_for_ldpstp): New.
> (aarch64_operands_adjust_ok_for_ldpstp): New.
> * config/aarch64/aarch64.c (enum sched_fusion_type): New enum.
> (TARGET_SCHED_FUSION_PRIORITY): New hook.
> (fusion_load_store): New functon.
> (extract_base_offset_in_addr): New function.
> (aarch64_gen_adjusted_ldpstp): New function.
> (aarch64_sched_fusion_priority): New function.
> (aarch64_operands_ok_for_ldpstp): New function.
> (aarch64_operands_adjust_ok_for_ldpstp): New function.
>
> 2014-11-18  Bin Cheng  
>
> * gcc.target/aarch64/ldp-stp-1.c: New test.
> * gcc.target/aarch64/ldp-stp-2.c: New test.
> * gcc.target/aarch64/ldp-stp-3.c: New test.
> * gcc.target/aarch64/ldp-stp-4.c: New test.
> * gcc.target/aarch64/ldp-stp-5.c: New test.
> * gcc.target/aarch64/lr_free_1.c: Disable scheduling fusion
> and peephole2 pass.

 Committed, thanks. /Marcus
>>>
>>>
>>> This patch has a bug in it dealing with volatile mems.  It will do a
>>> peephole of two volatile mems into a pair which is not correct as the
>>> order in the architecture is not defined and might even swap the order
>>> of the load/store incorrectly.
>>> I noticed this when I was merging in my changes for an improved
>>> peephone which already has a check for volatile.
>>
>> Something like:
>> @@ -10555,6 +10863,10 @@ aarch64_operands_ok_for_ldpstp (rtx
>> *operands, bool load,
>>reg_2 = operands[3];
>>  }
>>
>> +  /* The mems cannot be volatile.  */
>> +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2))
>> +return false;
>> +
>>/* Check if the addresses are in the form of [base+offset].  */
>>extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
>>if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
>>
>>
>>  CUT 
>> gcc.target/aarch64/rev16_1.c is the testcase where two volatile loads
>> being merged into one load pair.
>
>
> And this one:
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 40881e7..da36dc8 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -10974,6 +10974,10 @@ aarch64_operands_adjust_ok_for_ldpstp (rtx
> *operands, bool load,
>if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode))
>  return false;
>
> +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2)
> +  || MEM_VOLATILE_P (mem_3) ||MEM_VOLATILE_P (mem_4))
> +return false;
> +
>/* Check if the addresses are in the form of [base+offset].  */
>extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
>if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
> --- CUT ---
> This one happens with c-c++-common/torture/complex-sign-add.c.
> I will post a full patch tomorrow.
>
> Thanks,
> Andrew
>
>>
>> Thanks,
>> Andrew
>>
>>>
>>> Thanks,
>>> Andrew Pinski
Hi Andrew,
Thanks for reporting this.  When I facing this volatile problem, I
thought it was fine as long as the memory access wasn't removed
accidentally.  Could you please explain more why the order of volatile
also matters?  Is it related to some barriers between the two
accesses?  If that's the case, does it imply that dependence created
by GCC isn't correct?  I am still not sure why the case passed in my
regression test, or how I missed it.

Any way, volatile cases should be handled conservatively here.  Thanks again.

Thanks,
bin

Re: [PATCH AARCH64]load store pair optimization using sched_fusion pass.

[Andrew Pinski]

On Sun, Dec 7, 2014 at 5:47 PM, Bin.Cheng  wrote:
> On Sun, Dec 7, 2014 at 6:24 PM, Andrew Pinski  wrote:
>> On Sat, Dec 6, 2014 at 6:35 PM, Andrew Pinski  wrote:
>>> On Sat, Dec 6, 2014 at 5:54 PM, Andrew Pinski  wrote:
 On Fri, Dec 5, 2014 at 9:08 AM, Marcus Shawcroft
  wrote:
> On 18 November 2014 at 08:34, Bin Cheng  wrote:
>
>> 2014-11-18  Bin Cheng  
>>
>> * config/aarch64/aarch64.md (load_pair): Split to
>> load_pairsi, load_pairdi, load_pairsf and load_pairdf.
>> (load_pairsi, load_pairdi, load_pairsf, load_pairdf): Split
>> from load_pair.  New alternative to support int/fp
>> registers in fp/int mode patterns.
>> (store_pair:): Split to store_pairsi, store_pairdi,
>> store_pairsf and store_pairdi.
>> (store_pairsi, store_pairdi, store_pairsf, store_pairdf): Split
>> from store_pair.  New alternative to support int/fp
>> registers in fp/int mode patterns.
>> (*load_pair_extendsidi2_aarch64): New pattern.
>> (*load_pair_zero_extendsidi2_aarch64): New pattern.
>> (aarch64-ldpstp.md): Include.
>> * config/aarch64/aarch64-ldpstp.md: New file.
>> * config/aarch64/aarch64-protos.h (aarch64_gen_adjusted_ldpstp):
>> New.
>> (extract_base_offset_in_addr): New.
>> (aarch64_operands_ok_for_ldpstp): New.
>> (aarch64_operands_adjust_ok_for_ldpstp): New.
>> * config/aarch64/aarch64.c (enum sched_fusion_type): New enum.
>> (TARGET_SCHED_FUSION_PRIORITY): New hook.
>> (fusion_load_store): New functon.
>> (extract_base_offset_in_addr): New function.
>> (aarch64_gen_adjusted_ldpstp): New function.
>> (aarch64_sched_fusion_priority): New function.
>> (aarch64_operands_ok_for_ldpstp): New function.
>> (aarch64_operands_adjust_ok_for_ldpstp): New function.
>>
>> 2014-11-18  Bin Cheng  
>>
>> * gcc.target/aarch64/ldp-stp-1.c: New test.
>> * gcc.target/aarch64/ldp-stp-2.c: New test.
>> * gcc.target/aarch64/ldp-stp-3.c: New test.
>> * gcc.target/aarch64/ldp-stp-4.c: New test.
>> * gcc.target/aarch64/ldp-stp-5.c: New test.
>> * gcc.target/aarch64/lr_free_1.c: Disable scheduling fusion
>> and peephole2 pass.
>
> Committed, thanks. /Marcus


 This patch has a bug in it dealing with volatile mems.  It will do a
 peephole of two volatile mems into a pair which is not correct as the
 order in the architecture is not defined and might even swap the order
 of the load/store incorrectly.
 I noticed this when I was merging in my changes for an improved
 peephone which already has a check for volatile.
>>>
>>> Something like:
>>> @@ -10555,6 +10863,10 @@ aarch64_operands_ok_for_ldpstp (rtx
>>> *operands, bool load,
>>>reg_2 = operands[3];
>>>  }
>>>
>>> +  /* The mems cannot be volatile.  */
>>> +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2))
>>> +return false;
>>> +
>>>/* Check if the addresses are in the form of [base+offset].  */
>>>extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
>>>if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
>>>
>>>
>>>  CUT 
>>> gcc.target/aarch64/rev16_1.c is the testcase where two volatile loads
>>> being merged into one load pair.
>>
>>
>> And this one:
>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> index 40881e7..da36dc8 100644
>> --- a/gcc/config/aarch64/aarch64.c
>> +++ b/gcc/config/aarch64/aarch64.c
>> @@ -10974,6 +10974,10 @@ aarch64_operands_adjust_ok_for_ldpstp (rtx
>> *operands, bool load,
>>if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode))
>>  return false;
>>
>> +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2)
>> +  || MEM_VOLATILE_P (mem_3) ||MEM_VOLATILE_P (mem_4))
>> +return false;
>> +
>>/* Check if the addresses are in the form of [base+offset].  */
>>extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
>>if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
>> --- CUT ---
>> This one happens with c-c++-common/torture/complex-sign-add.c.
>> I will post a full patch tomorrow.
>>
>> Thanks,
>> Andrew
>>
>>>
>>> Thanks,
>>> Andrew
>>>

 Thanks,
 Andrew Pinski
> Hi Andrew,
> Thanks for reporting this.  When I facing this volatile problem, I
> thought it was fine as long as the memory access wasn't removed
> accidentally.  Could you please explain more why the order of volatile
> also matters?

Because volatile access between sequence points cannot be reordered.
See https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html .
Mainly:
" The minimum requirement is that at a sequence point all previous
accesses to volatile objects have stabilized and no subsequent
accesses have occurred. Thus an im

Re: [PATCH AARCH64]load store pair optimization using sched_fusion pass.

[Bin.Cheng]

On Mon, Dec 8, 2014 at 11:16 AM, Andrew Pinski  wrote:
> On Sun, Dec 7, 2014 at 5:47 PM, Bin.Cheng  wrote:
>> On Sun, Dec 7, 2014 at 6:24 PM, Andrew Pinski  wrote:
>>> On Sat, Dec 6, 2014 at 6:35 PM, Andrew Pinski  wrote:
 On Sat, Dec 6, 2014 at 5:54 PM, Andrew Pinski  wrote:
> On Fri, Dec 5, 2014 at 9:08 AM, Marcus Shawcroft
>  wrote:
>> On 18 November 2014 at 08:34, Bin Cheng  wrote:
>>
>>> 2014-11-18  Bin Cheng  
>>>
>>> * config/aarch64/aarch64.md (load_pair): Split to
>>> load_pairsi, load_pairdi, load_pairsf and load_pairdf.
>>> (load_pairsi, load_pairdi, load_pairsf, load_pairdf): Split
>>> from load_pair.  New alternative to support int/fp
>>> registers in fp/int mode patterns.
>>> (store_pair:): Split to store_pairsi, store_pairdi,
>>> store_pairsf and store_pairdi.
>>> (store_pairsi, store_pairdi, store_pairsf, store_pairdf): Split
>>> from store_pair.  New alternative to support int/fp
>>> registers in fp/int mode patterns.
>>> (*load_pair_extendsidi2_aarch64): New pattern.
>>> (*load_pair_zero_extendsidi2_aarch64): New pattern.
>>> (aarch64-ldpstp.md): Include.
>>> * config/aarch64/aarch64-ldpstp.md: New file.
>>> * config/aarch64/aarch64-protos.h (aarch64_gen_adjusted_ldpstp):
>>> New.
>>> (extract_base_offset_in_addr): New.
>>> (aarch64_operands_ok_for_ldpstp): New.
>>> (aarch64_operands_adjust_ok_for_ldpstp): New.
>>> * config/aarch64/aarch64.c (enum sched_fusion_type): New enum.
>>> (TARGET_SCHED_FUSION_PRIORITY): New hook.
>>> (fusion_load_store): New functon.
>>> (extract_base_offset_in_addr): New function.
>>> (aarch64_gen_adjusted_ldpstp): New function.
>>> (aarch64_sched_fusion_priority): New function.
>>> (aarch64_operands_ok_for_ldpstp): New function.
>>> (aarch64_operands_adjust_ok_for_ldpstp): New function.
>>>
>>> 2014-11-18  Bin Cheng  
>>>
>>> * gcc.target/aarch64/ldp-stp-1.c: New test.
>>> * gcc.target/aarch64/ldp-stp-2.c: New test.
>>> * gcc.target/aarch64/ldp-stp-3.c: New test.
>>> * gcc.target/aarch64/ldp-stp-4.c: New test.
>>> * gcc.target/aarch64/ldp-stp-5.c: New test.
>>> * gcc.target/aarch64/lr_free_1.c: Disable scheduling fusion
>>> and peephole2 pass.
>>
>> Committed, thanks. /Marcus
>
>
> This patch has a bug in it dealing with volatile mems.  It will do a
> peephole of two volatile mems into a pair which is not correct as the
> order in the architecture is not defined and might even swap the order
> of the load/store incorrectly.
> I noticed this when I was merging in my changes for an improved
> peephone which already has a check for volatile.

 Something like:
 @@ -10555,6 +10863,10 @@ aarch64_operands_ok_for_ldpstp (rtx
 *operands, bool load,
reg_2 = operands[3];
  }

 +  /* The mems cannot be volatile.  */
 +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2))
 +return false;
 +
/* Check if the addresses are in the form of [base+offset].  */
extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
if (base_1 == NULL_RTX || offset_1 == NULL_RTX)


  CUT 
 gcc.target/aarch64/rev16_1.c is the testcase where two volatile loads
 being merged into one load pair.
>>>
>>>
>>> And this one:
>>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>>> index 40881e7..da36dc8 100644
>>> --- a/gcc/config/aarch64/aarch64.c
>>> +++ b/gcc/config/aarch64/aarch64.c
>>> @@ -10974,6 +10974,10 @@ aarch64_operands_adjust_ok_for_ldpstp (rtx
>>> *operands, bool load,
>>>if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode))
>>>  return false;
>>>
>>> +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2)
>>> +  || MEM_VOLATILE_P (mem_3) ||MEM_VOLATILE_P (mem_4))
>>> +return false;
>>> +
>>>/* Check if the addresses are in the form of [base+offset].  */
>>>extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
>>>if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
>>> --- CUT ---
>>> This one happens with c-c++-common/torture/complex-sign-add.c.
>>> I will post a full patch tomorrow.
>>>
>>> Thanks,
>>> Andrew
>>>

 Thanks,
 Andrew

>
> Thanks,
> Andrew Pinski
>> Hi Andrew,
>> Thanks for reporting this.  When I facing this volatile problem, I
>> thought it was fine as long as the memory access wasn't removed
>> accidentally.  Could you please explain more why the order of volatile
>> also matters?
>
> Because volatile access between sequence points cannot be reordered.
> See https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html

Re: [PATCH AARCH64]load store pair optimization using sched_fusion pass.

[Bin.Cheng]

On Mon, Dec 8, 2014 at 11:26 AM, Bin.Cheng  wrote:
> On Mon, Dec 8, 2014 at 11:16 AM, Andrew Pinski  wrote:
>> On Sun, Dec 7, 2014 at 5:47 PM, Bin.Cheng  wrote:
>>> On Sun, Dec 7, 2014 at 6:24 PM, Andrew Pinski  wrote:
 On Sat, Dec 6, 2014 at 6:35 PM, Andrew Pinski  wrote:
> On Sat, Dec 6, 2014 at 5:54 PM, Andrew Pinski  wrote:
>> On Fri, Dec 5, 2014 at 9:08 AM, Marcus Shawcroft
>>  wrote:
>>> On 18 November 2014 at 08:34, Bin Cheng  wrote:
>>>
 2014-11-18  Bin Cheng  

 * config/aarch64/aarch64.md (load_pair): Split to
 load_pairsi, load_pairdi, load_pairsf and load_pairdf.
 (load_pairsi, load_pairdi, load_pairsf, load_pairdf): Split
 from load_pair.  New alternative to support int/fp
 registers in fp/int mode patterns.
 (store_pair:): Split to store_pairsi, store_pairdi,
 store_pairsf and store_pairdi.
 (store_pairsi, store_pairdi, store_pairsf, store_pairdf): Split
 from store_pair.  New alternative to support int/fp
 registers in fp/int mode patterns.
 (*load_pair_extendsidi2_aarch64): New pattern.
 (*load_pair_zero_extendsidi2_aarch64): New pattern.
 (aarch64-ldpstp.md): Include.
 * config/aarch64/aarch64-ldpstp.md: New file.
 * config/aarch64/aarch64-protos.h 
 (aarch64_gen_adjusted_ldpstp):
 New.
 (extract_base_offset_in_addr): New.
 (aarch64_operands_ok_for_ldpstp): New.
 (aarch64_operands_adjust_ok_for_ldpstp): New.
 * config/aarch64/aarch64.c (enum sched_fusion_type): New enum.
 (TARGET_SCHED_FUSION_PRIORITY): New hook.
 (fusion_load_store): New functon.
 (extract_base_offset_in_addr): New function.
 (aarch64_gen_adjusted_ldpstp): New function.
 (aarch64_sched_fusion_priority): New function.
 (aarch64_operands_ok_for_ldpstp): New function.
 (aarch64_operands_adjust_ok_for_ldpstp): New function.

 2014-11-18  Bin Cheng  

 * gcc.target/aarch64/ldp-stp-1.c: New test.
 * gcc.target/aarch64/ldp-stp-2.c: New test.
 * gcc.target/aarch64/ldp-stp-3.c: New test.
 * gcc.target/aarch64/ldp-stp-4.c: New test.
 * gcc.target/aarch64/ldp-stp-5.c: New test.
 * gcc.target/aarch64/lr_free_1.c: Disable scheduling fusion
 and peephole2 pass.
>>>
>>> Committed, thanks. /Marcus
>>
>>
>> This patch has a bug in it dealing with volatile mems.  It will do a
>> peephole of two volatile mems into a pair which is not correct as the
>> order in the architecture is not defined and might even swap the order
>> of the load/store incorrectly.
>> I noticed this when I was merging in my changes for an improved
>> peephone which already has a check for volatile.
>
> Something like:
> @@ -10555,6 +10863,10 @@ aarch64_operands_ok_for_ldpstp (rtx
> *operands, bool load,
>reg_2 = operands[3];
>  }
>
> +  /* The mems cannot be volatile.  */
> +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2))
> +return false;
> +
>/* Check if the addresses are in the form of [base+offset].  */
>extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
>if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
>
>
>  CUT 
> gcc.target/aarch64/rev16_1.c is the testcase where two volatile loads
> being merged into one load pair.


 And this one:
 diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
 index 40881e7..da36dc8 100644
 --- a/gcc/config/aarch64/aarch64.c
 +++ b/gcc/config/aarch64/aarch64.c
 @@ -10974,6 +10974,10 @@ aarch64_operands_adjust_ok_for_ldpstp (rtx
 *operands, bool load,
if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode))
  return false;

 +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2)
 +  || MEM_VOLATILE_P (mem_3) ||MEM_VOLATILE_P (mem_4))
 +return false;
 +
/* Check if the addresses are in the form of [base+offset].  */
extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
 --- CUT ---
 This one happens with c-c++-common/torture/complex-sign-add.c.
 I will post a full patch tomorrow.

 Thanks,
 Andrew

>
> Thanks,
> Andrew
>
>>
>> Thanks,
>> Andrew Pinski
>>> Hi Andrew,
>>> Thanks for reporting this.  When I facing this volatile problem, I
>>> thought it was fine as long as the memory access wasn't removed
>>> accidentally.  Could you please explain 

Re: [PATCH AARCH64]load store pair optimization using sched_fusion pass.

[Andrew Pinski]

On Sun, Dec 7, 2014 at 7:35 PM, Bin.Cheng  wrote:
> On Mon, Dec 8, 2014 at 11:26 AM, Bin.Cheng  wrote:
>> On Mon, Dec 8, 2014 at 11:16 AM, Andrew Pinski  wrote:
>>> On Sun, Dec 7, 2014 at 5:47 PM, Bin.Cheng  wrote:
 On Sun, Dec 7, 2014 at 6:24 PM, Andrew Pinski  wrote:
> On Sat, Dec 6, 2014 at 6:35 PM, Andrew Pinski  wrote:
>> On Sat, Dec 6, 2014 at 5:54 PM, Andrew Pinski  wrote:
>>> On Fri, Dec 5, 2014 at 9:08 AM, Marcus Shawcroft
>>>  wrote:
 On 18 November 2014 at 08:34, Bin Cheng  wrote:

> 2014-11-18  Bin Cheng  
>
> * config/aarch64/aarch64.md (load_pair): Split to
> load_pairsi, load_pairdi, load_pairsf and load_pairdf.
> (load_pairsi, load_pairdi, load_pairsf, load_pairdf): Split
> from load_pair.  New alternative to support int/fp
> registers in fp/int mode patterns.
> (store_pair:): Split to store_pairsi, store_pairdi,
> store_pairsf and store_pairdi.
> (store_pairsi, store_pairdi, store_pairsf, store_pairdf): 
> Split
> from store_pair.  New alternative to support int/fp
> registers in fp/int mode patterns.
> (*load_pair_extendsidi2_aarch64): New pattern.
> (*load_pair_zero_extendsidi2_aarch64): New pattern.
> (aarch64-ldpstp.md): Include.
> * config/aarch64/aarch64-ldpstp.md: New file.
> * config/aarch64/aarch64-protos.h 
> (aarch64_gen_adjusted_ldpstp):
> New.
> (extract_base_offset_in_addr): New.
> (aarch64_operands_ok_for_ldpstp): New.
> (aarch64_operands_adjust_ok_for_ldpstp): New.
> * config/aarch64/aarch64.c (enum sched_fusion_type): New enum.
> (TARGET_SCHED_FUSION_PRIORITY): New hook.
> (fusion_load_store): New functon.
> (extract_base_offset_in_addr): New function.
> (aarch64_gen_adjusted_ldpstp): New function.
> (aarch64_sched_fusion_priority): New function.
> (aarch64_operands_ok_for_ldpstp): New function.
> (aarch64_operands_adjust_ok_for_ldpstp): New function.
>
> 2014-11-18  Bin Cheng  
>
> * gcc.target/aarch64/ldp-stp-1.c: New test.
> * gcc.target/aarch64/ldp-stp-2.c: New test.
> * gcc.target/aarch64/ldp-stp-3.c: New test.
> * gcc.target/aarch64/ldp-stp-4.c: New test.
> * gcc.target/aarch64/ldp-stp-5.c: New test.
> * gcc.target/aarch64/lr_free_1.c: Disable scheduling fusion
> and peephole2 pass.

 Committed, thanks. /Marcus
>>>
>>>
>>> This patch has a bug in it dealing with volatile mems.  It will do a
>>> peephole of two volatile mems into a pair which is not correct as the
>>> order in the architecture is not defined and might even swap the order
>>> of the load/store incorrectly.
>>> I noticed this when I was merging in my changes for an improved
>>> peephone which already has a check for volatile.
>>
>> Something like:
>> @@ -10555,6 +10863,10 @@ aarch64_operands_ok_for_ldpstp (rtx
>> *operands, bool load,
>>reg_2 = operands[3];
>>  }
>>
>> +  /* The mems cannot be volatile.  */
>> +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2))
>> +return false;
>> +
>>/* Check if the addresses are in the form of [base+offset].  */
>>extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
>>if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
>>
>>
>>  CUT 
>> gcc.target/aarch64/rev16_1.c is the testcase where two volatile loads
>> being merged into one load pair.
>
>
> And this one:
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 40881e7..da36dc8 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -10974,6 +10974,10 @@ aarch64_operands_adjust_ok_for_ldpstp (rtx
> *operands, bool load,
>if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode))
>  return false;
>
> +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2)
> +  || MEM_VOLATILE_P (mem_3) ||MEM_VOLATILE_P (mem_4))
> +return false;
> +
>/* Check if the addresses are in the form of [base+offset].  */
>extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
>if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
> --- CUT ---
> This one happens with c-c++-common/torture/complex-sign-add.c.
> I will post a full patch tomorrow.
>
> Thanks,
> Andrew
>
>>
>> Thanks,
>> Andrew
>>
>>>
>>> Thanks,
>>> Andrew Pinski
 Hi Andrew,
 Tha

Re: [PATCH AARCH64]load store pair optimization using sched_fusion pass.

[Bin.Cheng]

On Mon, Dec 8, 2014 at 11:38 AM, Andrew Pinski  wrote:
> On Sun, Dec 7, 2014 at 7:35 PM, Bin.Cheng  wrote:
>> On Mon, Dec 8, 2014 at 11:26 AM, Bin.Cheng  wrote:
>>> On Mon, Dec 8, 2014 at 11:16 AM, Andrew Pinski  wrote:
 On Sun, Dec 7, 2014 at 5:47 PM, Bin.Cheng  wrote:
> On Sun, Dec 7, 2014 at 6:24 PM, Andrew Pinski  wrote:
>> On Sat, Dec 6, 2014 at 6:35 PM, Andrew Pinski  wrote:
>>> On Sat, Dec 6, 2014 at 5:54 PM, Andrew Pinski  wrote:
 On Fri, Dec 5, 2014 at 9:08 AM, Marcus Shawcroft
  wrote:
> On 18 November 2014 at 08:34, Bin Cheng  wrote:
>
>> 2014-11-18  Bin Cheng  
>>
>> * config/aarch64/aarch64.md (load_pair): Split to
>> load_pairsi, load_pairdi, load_pairsf and load_pairdf.
>> (load_pairsi, load_pairdi, load_pairsf, load_pairdf): Split
>> from load_pair.  New alternative to support int/fp
>> registers in fp/int mode patterns.
>> (store_pair:): Split to store_pairsi, store_pairdi,
>> store_pairsf and store_pairdi.
>> (store_pairsi, store_pairdi, store_pairsf, store_pairdf): 
>> Split
>> from store_pair.  New alternative to support int/fp
>> registers in fp/int mode patterns.
>> (*load_pair_extendsidi2_aarch64): New pattern.
>> (*load_pair_zero_extendsidi2_aarch64): New pattern.
>> (aarch64-ldpstp.md): Include.
>> * config/aarch64/aarch64-ldpstp.md: New file.
>> * config/aarch64/aarch64-protos.h 
>> (aarch64_gen_adjusted_ldpstp):
>> New.
>> (extract_base_offset_in_addr): New.
>> (aarch64_operands_ok_for_ldpstp): New.
>> (aarch64_operands_adjust_ok_for_ldpstp): New.
>> * config/aarch64/aarch64.c (enum sched_fusion_type): New 
>> enum.
>> (TARGET_SCHED_FUSION_PRIORITY): New hook.
>> (fusion_load_store): New functon.
>> (extract_base_offset_in_addr): New function.
>> (aarch64_gen_adjusted_ldpstp): New function.
>> (aarch64_sched_fusion_priority): New function.
>> (aarch64_operands_ok_for_ldpstp): New function.
>> (aarch64_operands_adjust_ok_for_ldpstp): New function.
>>
>> 2014-11-18  Bin Cheng  
>>
>> * gcc.target/aarch64/ldp-stp-1.c: New test.
>> * gcc.target/aarch64/ldp-stp-2.c: New test.
>> * gcc.target/aarch64/ldp-stp-3.c: New test.
>> * gcc.target/aarch64/ldp-stp-4.c: New test.
>> * gcc.target/aarch64/ldp-stp-5.c: New test.
>> * gcc.target/aarch64/lr_free_1.c: Disable scheduling fusion
>> and peephole2 pass.
>
> Committed, thanks. /Marcus


 This patch has a bug in it dealing with volatile mems.  It will do a
 peephole of two volatile mems into a pair which is not correct as the
 order in the architecture is not defined and might even swap the order
 of the load/store incorrectly.
 I noticed this when I was merging in my changes for an improved
 peephone which already has a check for volatile.
>>>
>>> Something like:
>>> @@ -10555,6 +10863,10 @@ aarch64_operands_ok_for_ldpstp (rtx
>>> *operands, bool load,
>>>reg_2 = operands[3];
>>>  }
>>>
>>> +  /* The mems cannot be volatile.  */
>>> +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2))
>>> +return false;
>>> +
>>>/* Check if the addresses are in the form of [base+offset].  */
>>>extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
>>>if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
>>>
>>>
>>>  CUT 
>>> gcc.target/aarch64/rev16_1.c is the testcase where two volatile loads
>>> being merged into one load pair.
>>
>>
>> And this one:
>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> index 40881e7..da36dc8 100644
>> --- a/gcc/config/aarch64/aarch64.c
>> +++ b/gcc/config/aarch64/aarch64.c
>> @@ -10974,6 +10974,10 @@ aarch64_operands_adjust_ok_for_ldpstp (rtx
>> *operands, bool load,
>>if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode))
>>  return false;
>>
>> +  if (MEM_VOLATILE_P (mem_1) || MEM_VOLATILE_P (mem_2)
>> +  || MEM_VOLATILE_P (mem_3) ||MEM_VOLATILE_P (mem_4))
>> +return false;
>> +
>>/* Check if the addresses are in the form of [base+offset].  */
>>extract_base_offset_in_addr (mem_1, &base_1, &offset_1);
>>if (base_1 == NULL_RTX || offset_1 == NULL_RTX)
>> --- CUT ---
>> This one happens with c-c++-common/torture/complex-sign-add.c.
>> I will post a fu

Re: [PATCH v4] gcc/c-family/c-cppbuiltin.c: Let buffer enough to print host wide integer value

[Chen Gang]

On 11/27/14 07:41, Chen Gang wrote:
> OK, I shall send related test case within two weeks (2014-12-10).
> 
> Joseph Myers  wrote:
> 
> On Thu, 27 Nov 2014, Chen Gang wrote:
> 
>> The original length 18 is not enough for HOST_WIDE_INT printing, need
>> use 20 instead of.
>>
>> Also need additional bytes for printing related prefix and suffix, and
>> give a related check.
>>
>> It passes testsuite under fedora 20 x86_64-unknown-linux-gnu.
>>
>> 2014-11-27  Chen Gang 
>>
>> * c-family/c-cppbuiltin.c (builtin_define_with_int_value): Let
>> buffer enough to print host wide integer value.
> 
> OK.  Properly implementing the (-9223372036854775807LL-1) and similar 
> cases (when the value is the least int, long or long long on the target) 
> can be a followup fix.
> 

Sorry, after check all related callers, at present, it can not cause
real world issue:

 - builtin_define_with_int_value() is static function which is only used
   within 'c-cppbuiltin.c'.

 - except builtin_define_type_sizeof(), all callers wants to use 'int'
   for 'value', and in fact, builtin_define_type_sizeof() uses a small
   integer too (although it use HOST_WIDE_INT).

 - for 'flag_abi_version' (can be customized by '-fabi-version=??'):

   '99' will over flow 16-bit 'int', but will cast to HOST_WIDE_INT
   automatically, which will not cause real issue.

   '1000 + flag_abi_version' may over flow 32-bit 'int', but still will
   cast to HOST_WIDE_INT automatically, which will not cause real issue.

So for me, at present, current patch is not a current bug fix patch, but
I guess, it is still useful in the future (the related code really need
be improved).


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [testsuite] Fix multiple definitions of _init

[Kaz Kojima]

Oleg Endo  wrote:
> Kaz, could you please check if the patch doesn't break anything on
> sh4-linux?  If so, I'd like to commit this to trunk.

Build and test ok on sh4-unknown-linux-gnu.

Regards,
kaz