Re: PATCH: Add PROCESSOR_INTEL

[Uros Bizjak]

On Fri, Jan 10, 2014 at 11:29 PM, H.J. Lu  wrote:
> Hi,
>
> This patch adds PROCESSOR_INTEL, which is almost identical to
> PROCESSOR_SILVERMONT, except that __tune_slm__/__tune_silvermont__
> aren't defined for -mtune=intel.  OK for trunk?

No, we have said that -mtune=intel is used to tune for *current* intel
processor. It is not a target per itself. Currently, this "target"
points to PROCESSOR_SILVERMONT, and I see no problem if it also
defines relevant tune defines.

In future, this option will point to some other processor, so it will
switch tune defines as well.

Uros.

Re: [Ping]Two pending IVOPT patches

[Bin.Cheng]

On Sat, Jan 11, 2014 at 2:42 PM, Bin.Cheng  wrote:
> On Wed, Dec 11, 2013 at 4:18 AM, Jeff Law  wrote:
>> On 12/10/13 00:01, bin.cheng wrote:
>>>
>>> Emm, some kind of.  See the cost of iv candidate set consists of several
>>> parts, the representation cost in cost pair; the register pressure cost
>>> falls in dependence on invariant expressions, etc..  Here iv_ca_has_deps
>>> checks whether new cost pair depends on other invariant expression which
>>> is
>>> not involved before, if so, current algorithm considers the new cost pair
>>> has higher cost and just skips.  In fact, the new cost pair may give us
>>> lower overall cost even it introduces new dependence(similar to the case I
>>> gave).  That's why I used the overall cost comparison for good.
>>
>> OK.  Thanks for the explanation.
>>
>>
>>>
>>> Is this new version patch looks good to you? I will re-test if it's ok.
>>
>> It does.  Please do some final testing and it should be good to go.
> Hi Jeff, sorry for responding the message so late, I have being looked
> into something else.
> I retested the patch against the trunk, the patch boostrap and
> reg-test fine on x86 and x86_64, only causing new failure of one
> fortran case 'aliasing_dummy_4.f90' with below command and error
> message:
> $ x86_64-linux-gnu-gfortran -O2 ../aliasing_dummy_4.f90 -S -o
> aliasing_dummy_4.S -fdump-tree-all -fdump-tree-ivopts-details
> -fdump-rtl-all-slim -fno-inline
> ../aliasing_dummy_4.f90: in function ‘test_f90’:
> ../aliasing_dummy_4.f90:28:0: internal compiler error ：Segmentation fault
>  call test_sub(s(1, 1)%a(:, :), 1000)  ! Check "normal" references.
>  ^
> 0x87f14be crash_signal
> ../../gcc/gcc/toplev.c:337
> 0x8786c8b reg_used_between_p(rtx_def const*, rtx_def const*, rtx_def const*)
> ../../gcc/gcc/rtlanal.c:753
> 0x8efcb66 combine_reaching_defs
> ../../gcc/gcc/ree.c:733
> 0x8efd4f4 find_and_remove_re
> ../../gcc/gcc/ree.c:973
> 0x8efd798 rest_of_handle_ree
> ../../gcc/gcc/ree.c:1035
> 0x8efd810 execute
> ../../gcc/gcc/ree.c:1074
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
>
> I reduced the case and attached ivopt dumps with/without the patch.
> It seems the patch is doing right thing and choosing better
> candidates, most likely it reveals an existing bug.
> I am looking into this issue, in the meantime, I am wondering should I
> apply the patch and file a PR for it, or apply the patch after root
> causing it?
>
The issue happens for below dump before pass ree:
   82: NOTE_INSN_BASIC_BLOCK 4
   83: NOTE_INSN_DELETED
  259: dx:DI=bp:DI
   84: {dx:DI=dx:DI<<0x20;clobber flags:CC;}
   86: r9:DI=zero_extend(r12:SI)
   87: NOTE_INSN_DELETED
   88: {r9:DI=r9:DI|dx:DI;clobber flags:CC;}
  262: r12:DI=r9:DI
   89: NOTE_INSN_DELETED
   90: NOTE_INSN_DELETED
   93: NOTE_INSN_DELETED
   94: NOTE_INSN_DELETED
   ...
It calls reg_used_between_p (r9, insn_262, insn_86), only the problem
is def_insn (262) comes after cand_insn (86), the loop in
reg_used_between_p goes bad at the end of instruction list with
insn==NULL:

  for (insn = NEXT_INSN (from_insn); insn != to_insn; insn = NEXT_INSN (insn))
if (NONDEBUG_INSN_P (insn)
&& (reg_overlap_mentioned_p (reg, PATTERN (insn))
   || (CALL_P (insn) && find_reg_fusage (insn, USE, reg
  return 1;

What I don't understand is how the define instruction comes after the
use?  It doesn't make sense even for a loop.  Any words?

FYI, I attached the whole dump file before ree.

Thanks,
bin
-- 
Best Regards.


aliasing_dummy_4.f90.217r.split2
Description: Binary data

Re: [Ping]Two pending IVOPT patches

[Jakub Jelinek]

On Sat, Jan 11, 2014 at 05:02:26PM +0800, Bin.Cheng wrote:
> > I reduced the case and attached ivopt dumps with/without the patch.
> > It seems the patch is doing right thing and choosing better
> > candidates, most likely it reveals an existing bug.
> > I am looking into this issue, in the meantime, I am wondering should I
> > apply the patch and file a PR for it, or apply the patch after root
> > causing it?

Sounds like PR59743 which should be already fixed.

Jakub

Re: [Ping]Two pending IVOPT patches

[Bin.Cheng]

On Sat, Jan 11, 2014 at 5:07 PM, Jakub Jelinek  wrote:
> On Sat, Jan 11, 2014 at 05:02:26PM +0800, Bin.Cheng wrote:
>> > I reduced the case and attached ivopt dumps with/without the patch.
>> > It seems the patch is doing right thing and choosing better
>> > candidates, most likely it reveals an existing bug.
>> > I am looking into this issue, in the meantime, I am wondering should I
>> > apply the patch and file a PR for it, or apply the patch after root
>> > causing it?
>
> Sounds like PR59743 which should be already fixed.
Yes, it is.  I just did the test against trunk exactly before Jeff's fix.
Then I will apply the patch to trunk.

And an additional question: Are these uses before definition always
caused by uninitialized use in GCC?

Thanks,
bin

>
> Jakub



-- 
Best Regards.

Re: [Patch, Fortran, committed] PR 59612: iso_fortran_env segfaults with -fdump-fortran-original

[Mikael Morin]

Le 09/01/2014 14:33, Janus Weil a écrit :
> After noticing that the bug is actually a regression (see PR 57042):
> Ok to backport to 4.7 and 4.8?
> 
Sure!

Mikael

Re: [Patch, Fortran] PR 58026: Bad error recovery for allocatable component of undeclared type

[Mikael Morin]

Le 09/01/2014 16:30, Janus Weil a écrit :
> Hi all,
> 
> the attached patch started out as an ICE-on-invalid regression fix,
> but after the ICE had been fixed recently by other means, it was
> degraded to a mere error-recovery improvement. It removes some rather
> 'hackish' code that was added by Paul quite a long time ago.
> 
> Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk?
> 
Could you check whether it works with a regular error?
i.e. s/gfc_error_now/gfc_error/
If it doesn't, OK as is.

Thanks
Mikael

Re: [PATCH i386 10/8] [AVX512] Add missing AVX-512ER patterns, intrinsics, tests.

[Uros Bizjak]

On Fri, Jan 10, 2014 at 5:24 PM, Jakub Jelinek  wrote:
> On Fri, Jan 10, 2014 at 07:20:38PM +0300, Kirill Yukhin wrote:
>> @@ -28920,6 +28927,7 @@ static const struct builtin_description 
>> bdesc_special_args[] =
>>{ OPTION_MASK_ISA_AVX512F, CODE_FOR_avx512f_movntv16sf, 
>> "__builtin_ia32_movntps512", IX86_BUILTIN_MOVNTPS512, UNKNOWN, (int) 
>> VOID_FTYPE_PFLOAT_V16SF },
>>{ OPTION_MASK_ISA_AVX512F, CODE_FOR_avx512f_movntv8df, 
>> "__builtin_ia32_movntpd512", IX86_BUILTIN_MOVNTPD512, UNKNOWN, (int) 
>> VOID_FTYPE_PDOUBLE_V8DF },
>>{ OPTION_MASK_ISA_AVX512F, CODE_FOR_avx512f_movntv8di, 
>> "__builtin_ia32_movntdq512", IX86_BUILTIN_MOVNTDQ512, UNKNOWN, (int) 
>> VOID_FTYPE_PV8DI_V8DI },
>> +  { OPTION_MASK_ISA_AVX512F, CODE_FOR_avx512f_movntdqa, 
>> "__builtin_ia32_movntdqa512", IX86_BUILTIN_MOVNTDQA512, UNKNOWN, (int) 
>> V8DI_FTYPE_PV8DI },
>>{ OPTION_MASK_ISA_AVX512F, CODE_FOR_avx512f_storedquv16si_mask, 
>> "__builtin_ia32_storedqusi512_mask", IX86_BUILTIN_STOREDQUSI512, UNKNOWN, 
>> (int) VOID_FTYPE_PV16SI_V16SI_HI },
>>{ OPTION_MASK_ISA_AVX512F, CODE_FOR_avx512f_storedquv8di_mask, 
>> "__builtin_ia32_storedqudi512_mask", IX86_BUILTIN_STOREDQUDI512, UNKNOWN, 
>> (int) VOID_FTYPE_PV8DI_V8DI_QI },
>>{ OPTION_MASK_ISA_AVX512F, CODE_FOR_avx512f_storeupd512_mask, 
>> "__builtin_ia32_storeupd512_mask", IX86_BUILTIN_STOREUPD512, UNKNOWN, (int) 
>> VOID_FTYPE_PV8DF_V8DF_QI },
>
> This means you should ensure aligned_mem will be set for
> CODE_FOR_avx512f_movntdqa in ix86_expand_special_args_builtin.
>
> Leaving the rest of review to Uros/Richard.

The rest is OK.

Thanks,
Uros.

Re: [Patch, fortran] PR58007: unresolved fixup hell

[Mikael Morin]

Le 04/01/2014 16:35, Janus Weil a écrit :
> Hi Mikael,
> 
>> this patch fixes PR58007, where the compiler was not able to relate a
>> component pointer to any loaded derived type symbol.
>> The problem came from an optimization avoiding loading again a symbol
>> which had already been loaded, skipping by the way the association of
>> component pointers (if the symbol was a derived type) with the
>> corresponding module indexes.
>>
>> The attached patch fixes this by reading the derived type symbol dump's
>> component list and do the pointer<->integer association by hand.  Then
>> the regular on demand module loading code works properly and some code
>> in mio_component_ref that was forcing the module loading of the
>> containing derived type can be removed.
>> To associate the component pointers with the module integers, one has to
>> parse the symbol, or at least its components.  It is done by hand in
>> this patch and to reduce the maintainance burden (for possible future
>> evolutions of symbol dumping format/content) the component list is moved
>> at the beginning.  More exactly just after the symbol attributes,
>> because the check_for_ambiguous function relies on the symbol attributes
>> appearing first in a symbol.
>> This changes the module format, so MOD_VERSION is  bumped.
>>
>> Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
> 
> Basically your patch looks ok to me.
> 
> However, I don't quite see the necessity for changing the module
> format (apart from the fact that it makes your patch slightly
> simpler). Anyway, since the module format has been changed already in
> 4.9, I think it doesn't matter much if we do it once more, so okay
> with me.
Well, I'm afraid of a future evolution where we change the module
format, update mio_symbol, and forget to change read_module as well, so
that the code reads something thinking it is the component list, but it
has become something else.
It is possible as empty parentheses `()' are common in the module
format, and it matches an empty component list.  Moving the component
list earlier only makes it less likely.  Another possibility to prevent
this is adding a recognizable pattern like "@# component-list #@" or
something, but the price to pay is the same: changing the module format.

> 
> One question, though: I don't understand how  the problem is specific
> to OOP code (and why it did not come up before with F95-style code).
> Do you think it would be possible to find a non-OOP case where it
> fails? If not, could there be some problem in gfortran's OOP
> implementation which causes the failure?
> 
I attach here a non-OOP variant, as well as the script that generated
it.  You can see that i'm no good at writing shell scripts. ;-)
Anyway the principle is:  the bugs happens when the symbols are read in
one particular (failing) order, so this script adds useless variables to
the modules to saturate the pointer tree and trigger a tree rebalance,
until it fails.
For those who cannot afford updating their compilers, a variant of this
script might be used to have this bug _not_ happen on their codes.  This
is left as an exercise; not sure how difficult it is. ;-)

> 
>> I plan to submit a variant that doesn't change the module format for the
>> branches (doing more parsing by hand).
> 
> Isn't that what you posted in comment 12 of the PR?
> 
It is, yes.

> Which branches did you have in mind? The PR contains various test
> cases which fail on either 4.7 or 4.8 and sometimes both, so
> potentially both of them are affected by the bug, I guess?
> 
Oops, I thought it was a 4.7/4.8 regression.
Actually, the testcase provided here also fails with 4.8, so I was
actually right. :-)

Mikael

module matrix
  type :: sparse_matrix
integer :: max_degree
  end type
end module

module bsr
  use matrix
  type, extends(sparse_matrix) :: bsr_matrix
end type
  integer :: i1
  integer :: i2
  integer :: i3
contains
  function get_neighbors (A)
type(bsr_matrix), intent(in) :: A
integer :: get_neighbors(A%max_degree)
  end function
end module

program main
  use matrix
  use bsr
end


make_testcase.sh
Description: application/shellscript

Re: PR 59712 patch

[François Dumont]

On 01/09/2014 11:49 PM, Jonathan Wakely wrote:

On 9 January 2014 21:55, François Dumont wrote:

 All unordered_* tests run under Linux x86_64.

Please make sure you run the entire testsuite, not just the parts that
seem relevant.


Done and no failure, ok to commit ?

François

PING: PATCH: PR libitm/53113: Build fails in x86_avx.cc if AVX disabled by -mno-avx

[H.J. Lu]

On Wed, Dec 25, 2013 at 12:41 PM, H.J. Lu  wrote:
> Hi,
>
> In libitm, x86_sse.cc must be compiled with -msse and x86_avx.cc must
> be compiled with -mavx.  We need to make sure that -msse/-mavx is
> appended at the end of compiler options.  This patch appends -msse/-mavx
> to CXXFLAGS, instead of appending them to XCFLAGS.  Tested with
> CXXFLAGS="-g -O2 -mno-avx". OK for trunk and release branches?
>
> Thanks.
>
>
> H.J.
> ---
> diff --git a/libitm/ChangeLog b/libitm/ChangeLog
> index e6dc646..35c64ee 100644
> --- a/libitm/ChangeLog
> +++ b/libitm/ChangeLog
> @@ -1,3 +1,10 @@
> +2013-12-25  H.J. Lu  
> +
> +   PR libitm/53113
> +   * Makefile.am (x86_sse.lo): Append -msse to CXXFLAGS.
> +   (x86_avx.lo): Append -mavx to CXXFLAGS.
> +   * Makefile.in: Regenerate.
> +
>  2013-11-14  Ulrich Weigand  
>
> * config/powerpc/sjlj.S [__powerpc64__ && _CALL_ELF == 2]:
> diff --git a/libitm/Makefile.am b/libitm/Makefile.am
> index e754ccc..1dce82d 100644
> --- a/libitm/Makefile.am
> +++ b/libitm/Makefile.am
> @@ -67,10 +67,12 @@ libitm_la_SOURCES += hwcap.cc
>  endif
>  if ARCH_X86
>  libitm_la_SOURCES += x86_sse.cc x86_avx.cc
> -x86_sse.lo : XCFLAGS += -msse
> +# Make sure -msse is appended at the end.
> +x86_sse.lo : override CXXFLAGS += -msse
>  endif
>  if ARCH_X86_AVX
> -x86_avx.lo : XCFLAGS += -mavx
> +# Make sure -mavx is appended at the end.
> +x86_avx.lo : override CXXFLAGS += -mavx
>  endif
>
>  if ARCH_FUTEX
> diff --git a/libitm/Makefile.in b/libitm/Makefile.in
> index f44fd70..6c4d253 100644
> --- a/libitm/Makefile.in
> +++ b/libitm/Makefile.in
> @@ -1050,8 +1050,10 @@ vpath % $(strip $(search_path))
>  @LIBITM_BUILD_VERSIONED_SHLIB_SUN_TRUE@@LIBITM_BUILD_VERSIONED_SHLIB_TRUE@   
>`echo $(libitm_la_LIBADD) | \
>  @LIBITM_BUILD_VERSIONED_SHLIB_SUN_TRUE@@LIBITM_BUILD_VERSIONED_SHLIB_TRUE@   
>   sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \
>  @LIBITM_BUILD_VERSIONED_SHLIB_SUN_TRUE@@LIBITM_BUILD_VERSIONED_SHLIB_TRUE@   
>> $@ || (rm -f $@ ; exit 1)
> -@ARCH_X86_TRUE@x86_sse.lo : XCFLAGS += -msse
> -@ARCH_X86_AVX_TRUE@x86_avx.lo : XCFLAGS += -mavx
> +# Make sure -msse is appended at the end.
> +@ARCH_X86_TRUE@x86_sse.lo : override CXXFLAGS += -msse
> +# Make sure -mavx is appended at the end.
> +@ARCH_X86_AVX_TRUE@x86_avx.lo : override CXXFLAGS += -mavx
>
>  all-local: $(STAMP_GENINSRC)
>

Hi Richard, Torvald,

Can you take a look at this patch?

Thanks.

-- 
H.J.

[Patch, libgfortran] PR59700 and PR59764 Misleading/buggy runtime error message

[Jerry DeLisle]

The attached patch fixes both these bugs, combining Steve's patch and mine.
Recent fixes of memory leaks placed the free_line before the generation of the
error messages rather than after,  The item_count which identifies the read list
item involved with the error was getting cleared, resulting in a faulty error
message.  This is fixed by moving the free_line location to after the message
string is created (before issuing the error still).

The second issue is the variable item_count was being used for two separate
purposes and collided in the case of read_logical.  This was a known issue from
several years ago. Fixed by adjusting the dtp structure just a bit. I used a
spare bit for the expanded_read flag and then used the integer slot made
available for a new variable line_buffer_pos. The new variable name is an
accurate description of what it does, not confused with "item_count".

Regression tested on x86-64.

OK for trunk?  I will add the test case from PR59700 to the test suite.

Regards,

Jerry


2014-01-10  Jerry DeLisle  
Steven G. Kargl  

PR libfortran/59700
PR libfortran/59764
* io/io.h (struct st_parameter_dt): Assign expanded_read flag to
unused bit. Define new variable line_buffer_pos.
* io/list_read.c (free_saved, next_char, l_push_char,
read_logical, read_real): Replace use of item_count with
line_buffer_pos for line_buffer look ahead.
(read_logical, read_integer, parse_real, read_real, check_type):
Adjust location of free_line to after generating error messages
to retain the correct item count for the message.
Index: io.h
===
--- io.h	(revision 206351)
+++ io.h	(working copy)
@@ -430,7 +430,10 @@ typedef struct st_parameter_dt
 	  unsigned g0_no_blanks : 1;
 	  /* Used to signal use of free_format_data.  */
 	  unsigned format_not_saved : 1;
-	  /* 14 unused bits.  */
+	  /* A flag used to identify when a non-standard expanded namelist read
+	 has occurred.  */
+	  unsigned expanded_read : 1;
+	  /* 13 unused bits.  */
 
 	  /* Used for ungetc() style functionality. Possible values
 	 are an unsigned char, EOF, or EOF - 1 used to mark the
@@ -447,9 +450,8 @@ typedef struct st_parameter_dt
 	  char *line_buffer;
 	  struct format_data *fmt;
 	  namelist_info *ionml;
-	  /* A flag used to identify when a non-standard expanded namelist read
-	 has occurred.  */
-	  int expanded_read;
+	  /* Current position within the look-ahead line buffer.  */
+	  int line_buffer_pos;
 	  /* Storage area for values except for strings.  Must be
 	 large enough to hold a complex value (two reals) of the
 	 largest kind.  */
Index: list_read.c
===
--- list_read.c	(revision 206351)
+++ list_read.c	(working copy)
@@ -118,7 +118,7 @@ free_saved (st_parameter_dt *dtp)
 static void
 free_line (st_parameter_dt *dtp)
 {
-  dtp->u.p.item_count = 0;
+  dtp->u.p.line_buffer_pos = 0;
   dtp->u.p.line_buffer_enabled = 0;
 
   if (dtp->u.p.line_buffer == NULL)
@@ -150,15 +150,15 @@ next_char (st_parameter_dt *dtp)
 {
   dtp->u.p.at_eol = 0;
 
-  c = dtp->u.p.line_buffer[dtp->u.p.item_count];
-  if (c != '\0' && dtp->u.p.item_count < 64)
+  c = dtp->u.p.line_buffer[dtp->u.p.line_buffer_pos];
+  if (c != '\0' && dtp->u.p.line_buffer_pos < 64)
 	{
-	  dtp->u.p.line_buffer[dtp->u.p.item_count] = '\0';
-	  dtp->u.p.item_count++;
+	  dtp->u.p.line_buffer[dtp->u.p.line_buffer_pos] = '\0';
+	  dtp->u.p.line_buffer_pos++;
 	  goto done;
 	}
 
-  dtp->u.p.item_count = 0;
+  dtp->u.p.line_buffer_pos = 0;
   dtp->u.p.line_buffer_enabled = 0;
 }
 
@@ -639,7 +639,7 @@ l_push_char (st_parameter_dt *dtp, char c)
   if (dtp->u.p.line_buffer == NULL)
 dtp->u.p.line_buffer = xcalloc (SCRATCH_SIZE, 1);
 
-  dtp->u.p.line_buffer[dtp->u.p.item_count++] = c;
+  dtp->u.p.line_buffer[dtp->u.p.line_buffer_pos++] = c;
 }
 
 
@@ -749,7 +749,7 @@ read_logical (st_parameter_dt *dtp, int length)
 	{
 	  dtp->u.p.nml_read_error = 1;
 	  dtp->u.p.line_buffer_enabled = 1;
-	  dtp->u.p.item_count = 0;
+	  dtp->u.p.line_buffer_pos = 0;
 	  return;
 	}
   
@@ -757,14 +757,17 @@ read_logical (st_parameter_dt *dtp, int length)
 
  bad_logical:
 
-  free_line (dtp);
-
   if (nml_bad_return (dtp, c))
-return;
+{
+  free_line (dtp);
+  return;
+}
 
+
   free_saved (dtp);
   if (c == EOF)
 {
+  free_line (dtp);
   hit_eof (dtp);
   return;
 }
@@ -772,6 +775,7 @@ read_logical (st_parameter_dt *dtp, int length)
 eat_line (dtp);
   snprintf (message, MSGLEN, "Bad logical value while reading item %d",
 	  dtp->u.p.item_count);
+  free_line (dtp);
   generate_error (&dtp->common, LIBERROR_READ_VALUE, message);
   return;
 
@@ -912,9 +916,9 @@ read_integer (st_parameter_dt *dtp, int length)
   else if (c != '\n')
 eat_line (dtp);
 
- 

[PATCH, rs6000] Change rs6000 into SWITCHABLE_TARGET

[Peter Bergner]

After Jakub changed i?386/x86_64 to use SWITCHABLE_TARGET, he asked me to
look at changing rs6000 too.  Here's the rs6000 patch, which is basically
identical to the i386.[hc] change Jakub made.  This passed bootstrap and
regtesting on powerpc64-linux with no regressions.  Ok for mainline?

Peter


* config/rs6000/rs6000.h (SWITCHABLE_TARGET): Define.
* config/rs6000/rs6000.c: Include target-globals.h.
(rs6000_set_current_function): Instead of doing target_reinit
unconditionally, use save_target_globals_default_opts and
restore_target_globals.

Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h  (revision 206526)
+++ gcc/config/rs6000/rs6000.h  (working copy)
@@ -892,6 +892,9 @@ enum data_align { align_abi, align_opt,
&& (ALIGN) < 32)
\
|| (VECTOR_MODE_P ((MODE)) && (((int)(ALIGN)) < VECTOR_ALIGN (MODE

+/* For switching between functions with different target attributes.  */
+#define SWITCHABLE_TARGET 1
+
 
 /* Standard register usage.  */

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 206526)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -78,6 +78,7 @@
 #include "tree-vectorizer.h"
 #include "dumpfile.h"
 #include "cgraph.h"
+#include "target-globals.h"
 #if TARGET_XCOFF
 #include "xcoffout.h"  /* get declarations of xcoff_*_section_name */
 #endif
@@ -31199,16 +31200,25 @@ rs6000_set_current_function (tree fndecl
{
  cl_target_option_restore (&global_options,
TREE_TARGET_OPTION (new_tree));
- target_reinit ();
+ if (TREE_TARGET_GLOBALS (new_tree))
+   restore_target_globals (TREE_TARGET_GLOBALS (new_tree));
+ else
+   TREE_TARGET_GLOBALS (new_tree)
+ = save_target_globals_default_opts ();
}

   else if (old_tree)
{
- struct cl_target_option *def
-   = TREE_TARGET_OPTION (target_option_current_node);
-
- cl_target_option_restore (&global_options, def);
- target_reinit ();
+ new_tree = target_option_current_node;
+ cl_target_option_restore (&global_options,
+   TREE_TARGET_OPTION (new_tree));
+ if (TREE_TARGET_GLOBALS (new_tree))
+   restore_target_globals (TREE_TARGET_GLOBALS (new_tree));
+ else if (new_tree == target_option_default_node)
+   restore_target_globals (&default_target_globals);
+ else
+   TREE_TARGET_GLOBALS (new_tree)
+ = save_target_globals_default_opts ();
}
 }
 }

RE: [PATCH] Fix PR58115

[Peter Bergner]

On Thu, 2014-01-09 at 10:36 +0100, Bernd Edlinger wrote:
> On Thu, 9 Jan 2014 10:28:43, Jakub Jelinek wrote:
> > Yeah, if i386 is changed into SWITCHABLE_TARGET, then I'd strongly encourage
> > rs6000 and nios folks to follow the suit.
> 
> Ok for me. Hope they read this thread...

The rs600 patch was submitted here:

  http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00675.html

Peter

Re: [Patch, libgfortran] PR59700 and PR59764 Misleading/buggy runtime error message

[Jerry DeLisle]

My apologies please.  I forgot to mention Dominiq for his superb assistance with
this patch and testing. Many thanks!

On 01/11/2014 09:13 AM, Jerry DeLisle wrote:
> The attached patch fixes both these bugs, combining Steve's patch and mine.
> Recent fixes of memory leaks placed the free_line before the generation of the
> error messages rather than after,  The item_count which identifies the read 
> list
> item involved with the error was getting cleared, resulting in a faulty error
> message.  This is fixed by moving the free_line location to after the message
> string is created (before issuing the error still).
> 
> The second issue is the variable item_count was being used for two separate
> purposes and collided in the case of read_logical.  This was a known issue 
> from
> several years ago. Fixed by adjusting the dtp structure just a bit. I used a
> spare bit for the expanded_read flag and then used the integer slot made
> available for a new variable line_buffer_pos. The new variable name is an
> accurate description of what it does, not confused with "item_count".
> 
> Regression tested on x86-64.
> 
> OK for trunk?  I will add the test case from PR59700 to the test suite.
> 
> Regards,
> 
> Jerry
> 
> 
> 2014-01-10  Jerry DeLisle  
>   Steven G. Kargl  
> 
>   PR libfortran/59700
>   PR libfortran/59764
>   * io/io.h (struct st_parameter_dt): Assign expanded_read flag to
>   unused bit. Define new variable line_buffer_pos.
>   * io/list_read.c (free_saved, next_char, l_push_char,
>   read_logical, read_real): Replace use of item_count with
>   line_buffer_pos for line_buffer look ahead.
>   (read_logical, read_integer, parse_real, read_real, check_type):
>   Adjust location of free_line to after generating error messages
>   to retain the correct item count for the message.
> 

Re: [PATCH, rs6000] Change rs6000 into SWITCHABLE_TARGET

[David Edelsohn]

On Sat, Jan 11, 2014 at 12:16 PM, Peter Bergner  wrote:
> After Jakub changed i?386/x86_64 to use SWITCHABLE_TARGET, he asked me to
> look at changing rs6000 too.  Here's the rs6000 patch, which is basically
> identical to the i386.[hc] change Jakub made.  This passed bootstrap and
> regtesting on powerpc64-linux with no regressions.  Ok for mainline?
>
> Peter
>
>
> * config/rs6000/rs6000.h (SWITCHABLE_TARGET): Define.
> * config/rs6000/rs6000.c: Include target-globals.h.
> (rs6000_set_current_function): Instead of doing target_reinit
> unconditionally, use save_target_globals_default_opts and
> restore_target_globals.

No. Sorry, Peter, I wish that you had not done this because you
duplicated work that I already had done.

David

Re: [Patch, libgfortran] PR59700 and PR59764 Misleading/buggy runtime error message

[Steve Kargl]

On Sat, Jan 11, 2014 at 09:27:44AM -0800, Jerry DeLisle wrote:
> My apologies please.  I forgot to mention Dominiq for his
> superb assistance with this patch and testing. Many thanks!
> 

Add Dominiq to the ChangeLog entry.  I think the patch
is OK.

-- 
Steve

[PATCH, committed] rs6000 builtins for FPSCR

[David Edelsohn]

This patch adds builtins to load and store the PowerPC floating point
status and control register.

* config/rs6000/rs6000.c (rs6000_expand_mtfsf_builtin): New.
(rs6000_expand_builtin): Handle mffs and mtfsf.
(rs6000_init_builtins): Define mffs and mtfsf.
* config/rs6000/rs6000.md (UNSPECV_MFFS, UNSPECV_MTFSF): New constants.
(rs6000_mffs): New pattern.
(rs6000_mtfsf): New pattern.

Index: rs6000-builtin.def
===
--- rs6000-builtin.def  (revision 206552)
+++ rs6000-builtin.def  (working copy)
@@ -1752,6 +1752,14 @@
 BU_SPECIAL_X (RS6000_BUILTIN_MFTB, "__builtin_ppc_mftb",
  RS6000_BTM_ALWAYS, RS6000_BTC_MISC)

+BU_SPECIAL_X (RS6000_BUILTIN_MFFS, "__builtin_mffs",
+ RS6000_BTM_ALWAYS, RS6000_BTC_MISC)
+
+RS6000_BUILTIN_X (RS6000_BUILTIN_MTFSF, "__builtin_mtfsf",
+ RS6000_BTM_ALWAYS,
+ RS6000_BTC_MISC | RS6000_BTC_UNARY | RS6000_BTC_VOID,
+ CODE_FOR_rs6000_mtfsf)
+
 /* Darwin CfString builtin.  */
 BU_SPECIAL_X (RS6000_BUILTIN_CFSTRING, "__builtin_cfstring", RS6000_BTM_ALWAYS,
  RS6000_BTC_MISC)
Index: rs6000.c
===
--- rs6000.c(revision 206552)
+++ rs6000.c(working copy)
@@ -11469,6 +11470,48 @@


 static rtx
+rs6000_expand_mtfsf_builtin (enum insn_code icode, tree exp, rtx target)
+{
+  rtx pat;
+  tree arg0 = CALL_EXPR_ARG (exp, 0);
+  tree arg1 = CALL_EXPR_ARG (exp, 1);
+  rtx op0 = expand_normal (arg0);
+  rtx op1 = expand_normal (arg1);
+  enum machine_mode mode0 = insn_data[icode].operand[0].mode;
+  enum machine_mode mode1 = insn_data[icode].operand[1].mode;
+
+  if (icode == CODE_FOR_nothing)
+/* Builtin not supported on this processor.  */
+return 0;
+
+  /* If we got invalid arguments bail out before generating bad rtl.  */
+  if (arg0 == error_mark_node || arg1 == error_mark_node)
+return const0_rtx;
+
+  if (GET_CODE (op0) != CONST_INT
+  || INTVAL (op0) > 255
+  || INTVAL (op0) < 0)
+{
+  error ("argument 1 must be an 8-bit field value");
+  return const0_rtx;
+}
+
+  if (! (*insn_data[icode].operand[0].predicate) (op0, mode0))
+op0 = copy_to_mode_reg (mode0, op0);
+
+  if (! (*insn_data[icode].operand[1].predicate) (op1, mode1))
+op1 = copy_to_mode_reg (mode1, op1);
+
+  pat = GEN_FCN (icode) (op0, op1);
+  if (! pat)
+return const0_rtx;
+  emit_insn (pat);
+
+  return NULL_RTX;
+}
+
+
+static rtx
 rs6000_expand_unop_builtin (enum insn_code icode, tree exp, rtx target)
 {
   rtx pat;
@@ -13277,6 +13320,12 @@
: CODE_FOR_rs6000_mftb_si),
   target);

+case RS6000_BUILTIN_MFFS:
+  return rs6000_expand_zeroop_builtin (CODE_FOR_rs6000_mffs, target);
+
+case RS6000_BUILTIN_MTFSF:
+  return rs6000_expand_mtfsf_builtin (CODE_FOR_rs6000_mtfsf, exp, target);
+
 case ALTIVEC_BUILTIN_MASK_FOR_LOAD:
 case ALTIVEC_BUILTIN_MASK_FOR_STORE:
   {
@@ -13584,6 +13633,14 @@
  NULL_TREE);
   def_builtin ("__builtin_ppc_mftb", ftype, RS6000_BUILTIN_MFTB);

+  ftype = build_function_type_list (double_type_node, NULL_TREE);
+  def_builtin ("__builtin_mffs", ftype, RS6000_BUILTIN_MFFS);
+
+  ftype = build_function_type_list (void_type_node,
+   intSI_type_node, double_type_node,
+   NULL_TREE);
+  def_builtin ("__builtin_mtfsf", ftype, RS6000_BUILTIN_MTFSF);
+
 #if TARGET_XCOFF
   /* AIX libm provides clog as __clog.  */
   if ((tdecl = builtin_decl_explicit (BUILT_IN_CLOG)) != NULL_TREE)
Index: rs6000.md
===
--- rs6000.md   (revision 206552)
+++ rs6000.md   (working copy)
@@ -140,6 +140,8 @@
UNSPECV_ISYNC   ; isync instruction
UNSPECV_MFTB; move from time base
UNSPECV_NLGR; non-local goto receiver
+   UNSPECV_MFFS; Move from FPSCR
+   UNSPECV_MTFSF   ; Move to FPSCR Fields
   ])


@@ -15587,6 +15589,20 @@
 })



+(define_insn "rs6000_mffs"
+  [(set (match_operand:DF 0 "gpc_reg_operand" "=d")
+(unspec_volatile:DF [(const_int 0)] UNSPECV_MFFS))]
+  "TARGET_HARD_FLOAT && TARGET_FPRS"
+  "mffs %0")
+
+(define_insn "rs6000_mtfsf"
+  [(unspec_volatile [(match_operand:SI 0 "const_int_operand" "i")
+ (match_operand:DF 1 "gpc_reg_operand" "d")]
+UNSPECV_MTFSF)]
+  "TARGET_HARD_FLOAT && TARGET_FPRS"
+  "mtfsf %0,%1")
+
+

 ;; Power8 fusion support for fusing an addis instruction with a D-form load of
 ;; a GPR.  The addis instruction must be adjacent to the load, and use the same
 ;; register that is being loaded.  The fused ops must be physically adjacent.

Re: [patch] make the libstdc++ pretty printers compatible with both Python 2 and Python3

[Jonathan Wakely]

On 31 October 2013 16:46, Tom Tromey  wrote:
>> "Matthias" == Matthias Klose  writes:
>
> Matthias> Starting with gdb 7.6, gdb can be linked with both Python 2.x
> Matthias> and Python 3.x.  Therefore the pretty printers should be
> Matthias> compatible with both Python versions.
>
> Thanks for doing this.
>
> Matthias> -n = self.rbiter.next()
> Matthias> +n = next(self.rbiter)
>
> Matthias> -def next(self):
> Matthias> -item = self.rbiter.next()
> Matthias> +def __next__(self):
> Matthias> +item = next(self.rbiter)
>
> Matthias> +return zip (counter, data)
>
> I don't think these two hunks will work on Python 2.x.
> But, I also don't think they are really needed, as I think it's just
> fine to call the 'next' method on the iterator objects.
>
> Matthias> +
> Matthias>  def display_hint (self):
> Matthias>  return 'map'
>
> Spurious whitespace change?
>
> You didn't say how you tested this.  Did you run the libstdc++
> pretty-printer tests?


Matthias, did this patch get forgotten about?

I'd like to see it go in, if Tom's concerns can be addressed.

Re: [Patch, Fortran, committed] PR 59612: iso_fortran_env segfaults with -fdump-fortran-original

[Janus Weil]

2014/1/11 Mikael Morin :
> Le 09/01/2014 14:33, Janus Weil a écrit :
>> After noticing that the bug is actually a regression (see PR 57042):
>> Ok to backport to 4.7 and 4.8?
>>
> Sure!

Thanks. Committed to 4.8 as r206556. Will do 4.7 soon.

Cheers,
Janus

Re: [Patch, fortran] PR58007: unresolved fixup hell

[Janus Weil]

Hi,

>>> this patch fixes PR58007, where the compiler was not able to relate a
>>> component pointer to any loaded derived type symbol.
>>> The problem came from an optimization avoiding loading again a symbol
>>> which had already been loaded, skipping by the way the association of
>>> component pointers (if the symbol was a derived type) with the
>>> corresponding module indexes.
>>>
>>> The attached patch fixes this by reading the derived type symbol dump's
>>> component list and do the pointer<->integer association by hand.  Then
>>> the regular on demand module loading code works properly and some code
>>> in mio_component_ref that was forcing the module loading of the
>>> containing derived type can be removed.
>>> To associate the component pointers with the module integers, one has to
>>> parse the symbol, or at least its components.  It is done by hand in
>>> this patch and to reduce the maintainance burden (for possible future
>>> evolutions of symbol dumping format/content) the component list is moved
>>> at the beginning.  More exactly just after the symbol attributes,
>>> because the check_for_ambiguous function relies on the symbol attributes
>>> appearing first in a symbol.
>>> This changes the module format, so MOD_VERSION is  bumped.
>>>
>>> Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
>>
>> Basically your patch looks ok to me.
>>
>> However, I don't quite see the necessity for changing the module
>> format (apart from the fact that it makes your patch slightly
>> simpler). Anyway, since the module format has been changed already in
>> 4.9, I think it doesn't matter much if we do it once more, so okay
>> with me.
> Well, I'm afraid of a future evolution where we change the module
> format, update mio_symbol, and forget to change read_module as well, so
> that the code reads something thinking it is the component list, but it
> has become something else.
> It is possible as empty parentheses `()' are common in the module
> format, and it matches an empty component list.  Moving the component
> list earlier only makes it less likely.  Another possibility to prevent
> this is adding a recognizable pattern like "@# component-list #@" or
> something, but the price to pay is the same: changing the module format.
>
>> One question, though: I don't understand how  the problem is specific
>> to OOP code (and why it did not come up before with F95-style code).
>> Do you think it would be possible to find a non-OOP case where it
>> fails? If not, could there be some problem in gfortran's OOP
>> implementation which causes the failure?
>>
> I attach here a non-OOP variant, as well as the script that generated
> it.  You can see that i'm no good at writing shell scripts. ;-)
> Anyway the principle is:  the bugs happens when the symbols are read in
> one particular (failing) order, so this script adds useless variables to
> the modules to saturate the pointer tree and trigger a tree rebalance,
> until it fails.

Good, thanks for checking. As written before, the patch is ok for
trunk from my side.


>> Which branches did you have in mind? The PR contains various test
>> cases which fail on either 4.7 or 4.8 and sometimes both, so
>> potentially both of them are affected by the bug, I guess?
>>
> Oops, I thought it was a 4.7/4.8 regression.
> Actually, the testcase provided here also fails with 4.8, so I was
> actually right. :-)

In fact your test case fails with all versions I tried (4.4, 4.6, 4.7,
4.8 and trunk). So, is it a regression at all?

Cheers,
Janus

[AARCH64][PATCH] PR59695

[Kugan]

Hi,

aarch64_build_constant incorrectly truncates the immediate when
constants are generated with MOVN. This causes coinor-osi tests to fail
(tracked also in https://bugs.launchpad.net/gcc-linaro/+bug/1263576)

Attached patch fixes this. Also attaching a reduced testcase that
reproduces this. Tested on aarch64-none-linux-gnu with no new
regressions. Is this OK for trunk?

Thanks,
Kugan

gcc/
+2013-10-15  Matthew Gretton-Dann  
+   Kugan Vivekanandarajah  
+
+   PR target/59588
+   * config/aarch64/aarch64.c (aarch64_build_constant): Fix incorrect
+   truncation.
+


gcc/testsuite/
+2014-01-11  Matthew Gretton-Dann  
+   Kugan Vivekanandarajah  
+
+   PR target/59695
+   * g++.dg/pr59695.C: New file.
+
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 3d32ea5..854666f 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -2486,7 +2486,7 @@ aarch64_build_constant (int regnum, HOST_WIDE_INT val)
   if (ncount < zcount)
{
  emit_move_insn (gen_rtx_REG (Pmode, regnum),
- GEN_INT ((~val) & 0x));
+ GEN_INT (~((~val) & 0x)));
  tval = 0x;
}
   else
diff --git a/gcc/testsuite/g++.dg/pr59695.C b/gcc/testsuite/g++.dg/pr59695.C
index e69de29..0da06cb 100644
--- a/gcc/testsuite/g++.dg/pr59695.C
+++ b/gcc/testsuite/g++.dg/pr59695.C
@@ -0,0 +1,125 @@
+
+/* PR target/53055 */
+/* { dg-do run { target aarch64*-*-* } } */
+/* { dg-options "-O0" } */
+
+#define  DEFINE_VIRTUALS_FNS(i)virtual void  xxx##i () {} \
+  virtual void  foo1_##i (){}\
+  virtual void  foo2_##i (){}\
+  virtual void  foo3_##i (){}\
+  virtual void  foo4_##i (){}\
+  virtual void  foo5_##i (){}\
+  virtual void  foo6_##i (){}\
+  virtual void  foo7_##i (){}\
+  virtual void  foo8_##i (){}\
+  virtual void  foo9_##i (){}\
+  virtual void  foo10_##i ()   {}\
+  virtual void  foo11_##i ()   {}\
+  virtual void  foo12_##i ()   {}\
+  virtual void  foo13_##i ()   {}\
+  virtual void  foo14_##i ()   {}\
+  virtual void  foo15_##i ()   {}\
+  virtual void  foo16_##i ()   {}\
+  virtual void  foo17_##i ()   {}\
+  virtual void  foo18_##i ()   {}\
+  virtual void  foo19_##i ()   {}\
+  virtual void  foo20_##i ()   {}\
+  virtual void  foo21_##i ()   {}\
+  virtual void  foo22_##i ()   {}\
+
+class base_class_2
+{
+
+public:
+  /* Define lots of virtual functions */
+  DEFINE_VIRTUALS_FNS (1)
+  DEFINE_VIRTUALS_FNS (2)
+  DEFINE_VIRTUALS_FNS (3)
+  DEFINE_VIRTUALS_FNS (4)
+  DEFINE_VIRTUALS_FNS (5)
+  DEFINE_VIRTUALS_FNS (6)
+  DEFINE_VIRTUALS_FNS (7)
+  DEFINE_VIRTUALS_FNS (8)
+  DEFINE_VIRTUALS_FNS (9)
+  DEFINE_VIRTUALS_FNS (10)
+  DEFINE_VIRTUALS_FNS (11)
+  DEFINE_VIRTUALS_FNS (12)
+  DEFINE_VIRTUALS_FNS (13)
+  DEFINE_VIRTUALS_FNS (14)
+  DEFINE_VIRTUALS_FNS (15)
+  DEFINE_VIRTUALS_FNS (16)
+  DEFINE_VIRTUALS_FNS (17)
+  DEFINE_VIRTUALS_FNS (18)
+  DEFINE_VIRTUALS_FNS (19)
+  DEFINE_VIRTUALS_FNS (20)
+
+  base_class_2();
+  virtual ~base_class_2 ();
+};
+
+base_class_2::base_class_2()
+{
+}
+
+base_class_2::~base_class_2 ()
+{
+}
+
+class base_class_1
+{
+public:
+  virtual ~base_class_1();
+  base_class_1();
+};
+
+base_class_1::base_class_1()
+{
+}
+
+base_class_1::~base_class_1()
+{
+}
+
+class base_Impl_class :
+  virtual public base_class_2, public base_class_1
+{
+public:
+  base_Impl_class ();
+  virtual ~base_Impl_class ();
+};
+
+base_Impl_class::base_Impl_class ()
+{
+}
+
+base_Impl_class::~base_Impl_class ()
+{
+}
+
+
+class test_cls : public base_Impl_class
+{
+public:
+  test_cls();
+  virtual ~test_cls();
+};
+
+test_cls::test_cls()
+{
+}
+
+test_cls::~test_cls()
+{
+}
+
+int main()
+{
+  test_cls *test = new test_cls;
+  base_class_2 *p1 = test;
+
+  /* PR 53055  destructor thunk offsets are not setup
+   correctly resulting in crash.  */
+  delete p1;
+  return 0;
+}
+