Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs

[Maxim Kuvyrkov]

On Jan 29, 2015, at 10:36 AM, Alexandre Oliva  wrote:

> On Jan 19, 2015, Maxim Kuvyrkov  wrote:
> 
>> Presence or absence of DEBUG_INSNs in the ready list can change the
>> comparison order, and cause slightly different instruction schedules.
> 
>> The solution that I propose (and that the patch implements) is to sort
>> DEBUG_INSNs separately from normal insns.  If DEBUG_INSNs are present
>> in the ready_list, sort the DEBUG_INSNs only among themselves, while
>> preserving order of the normal insns.  Once there are no DEBUG_INSNs
>> in the ready list, sort using the rank_for_schedule heuristic, just as
>> when we would when compiling without debug info.
> 
> I like that.  Thanks!
> 
> I wonder if it having a separate ready list for debug insns would make
> things simpler.  In general, you shouldn't have to sort debug insns at
> all, since they're not supposed to be reordered in the first place,

The debug insns are not really sorted, it just happens that qsort is the 
easiest tool to separate debug insns from normal ones.  The rank function for 
debug insns keeps them in original order.

> but
> keeping them separate would presumably avoid differences in sorting of
> the non-debug ready list.

This would have been my preference too, /if/ we didn't already have handling of 
ready lists which can have debug insns and normal insns.  With our current 
infrastructure for handling of debug insns in scheduler all done and working, 
the above approach is the least intrusive one, which is what I want to get the 
patch approved for stage 4.

> 
> This is not so different from what you do, though; it just requires
> different bookkeeping.

Thanks, Alexandre!

--
Maxim Kuvyrkov
www.linaro.org

Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs

[Alexandre Oliva]

On Jan 19, 2015, Maxim Kuvyrkov  wrote:

> Presence or absence of DEBUG_INSNs in the ready list can change the
> comparison order, and cause slightly different instruction schedules.

> The solution that I propose (and that the patch implements) is to sort
> DEBUG_INSNs separately from normal insns.  If DEBUG_INSNs are present
> in the ready_list, sort the DEBUG_INSNs only among themselves, while
> preserving order of the normal insns.  Once there are no DEBUG_INSNs
> in the ready list, sort using the rank_for_schedule heuristic, just as
> when we would when compiling without debug info.

I like that.  Thanks!

I wonder if it having a separate ready list for debug insns would make
things simpler.  In general, you shouldn't have to sort debug insns at
all, since they're not supposed to be reordered in the first place, but
keeping them separate would presumably avoid differences in sorting of
the non-debug ready list.

This is not so different from what you do, though; it just requires
different bookkeeping.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [libobjc] Fix failures on AIX (PR libobjc/63765)

[Alexandre Oliva]

On Jan 28, 2015, Mike Stump  wrote:

> On Jan 28, 2015, at 2:27 AM, Rainer Orth  
> wrote:
>> There are two ways to fix this:
>> 
>> * Remove the definition of _XOPEN_SOURCE completely.  This is slightly
>> more risky, but more future-proof since defining features test macros
>> has been an endless source of trouble in the past.

> I think I prefer this one...

> But, as I say that, I read:

>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4372

> and there is no hint what host caused him to put the change in, in the
> first place.  :-( Alexandre, do you recall what host needed the
> _XOPEN_SOURCE in libobjc for pthread_mutexattr_settype?

The 2005 timeframe suggests it was probably GNU/Linux, and some digging
in glibc indicates this flag affected nptl's pthread.h's declarations of
various such functions back then.  This changed back in 2010, with glibc
commit d3c7e68655, in response to newer standards, so I guess this
confirms the suggestion from the timeframe.  Of course, this being a
standard-compliance issue, other targets were likely affected as well,
since it looks like there was a standards change, and removing the flag
might cause regressions in old systems that remain stuck to the old
standards.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

ICF versus inlining

[Jan Hubicka]

Hi,
the PR is about function not being inlined because it is called via a wrapper
introduced by ICF merging code. cgraph_node::create_wrapper set
call_stmt_cannot_inline_p that I suggested to Martin to try to figure out how
much of merging is undone by inliner.  It was not meant to get into mainline.

Because the wrappers may end up at performance critical places, I also added
profile mainteinance - otherwise all BBs will get count of 0 and after
inlining we end up with lousy code with -fprofile-use.

To get sane inlining we probably want to make inliner to realize that call
cost in thunk is minimal.  I will look into that incrementally.

Bootstrapped/regtested x86_64-linux, will commit shortly.

PR ipa/64801
* gcc.dg/tree-ssa/pr64801.c: New testcase.
* cgraphunit.c (init_lowered_empty_function): Add CoUNT parameter;
make sane BB profile.
(cgraph_node::expand_thunk): Make sane BB profile.
(cgraph_node::create_wrapper): Do not set call_stmt_cannot_inline_p.
* cgraph.h (init_lowered_empty_function): Update prototype.
* config/i386/i386.c (make_resolver_func): Update call.
* predict.c (gate): Disable branch prediction pass if
profile is already there.

Index: testsuite/gcc.dg/tree-ssa/pr64801.c
===
--- testsuite/gcc.dg/tree-ssa/pr64801.c (revision 0)
+++ testsuite/gcc.dg/tree-ssa/pr64801.c (revision 0)
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+int a;
+int
+elantech_detect (void)
+{
+  return -38;
+}
+inline int
+fsp_detect (void)
+{
+  return -38;
+}
+void
+psmouse_extensions (void)
+{
+  int (*b)() = fsp_detect;
+  a = b ();
+}
+/* { dg-final { scan-tree-dump-not "fsp_detect"} } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: cgraphunit.c
===
--- cgraphunit.c(revision 220229)
+++ cgraphunit.c(working copy)
@@ -1325,9 +1325,10 @@ mark_functions_to_output (void)
return basic block in the function body.  */
 
 basic_block
-init_lowered_empty_function (tree decl, bool in_ssa)
+init_lowered_empty_function (tree decl, bool in_ssa, gcov_type count)
 {
   basic_block bb;
+  edge e;
 
   current_function_decl = decl;
   allocate_struct_function (decl, false);
@@ -1353,9 +1354,19 @@ init_lowered_empty_function (tree decl,
   loops_for_fn (cfun)->state |= LOOPS_MAY_HAVE_MULTIPLE_LATCHES;
 
   /* Create BB for body of the function and connect it properly.  */
+  ENTRY_BLOCK_PTR_FOR_FN (cfun)->count = count;
+  ENTRY_BLOCK_PTR_FOR_FN (cfun)->frequency = REG_BR_PROB_BASE;
+  EXIT_BLOCK_PTR_FOR_FN (cfun)->count = count;
+  EXIT_BLOCK_PTR_FOR_FN (cfun)->frequency = REG_BR_PROB_BASE;
   bb = create_basic_block (NULL, (void *) 0, ENTRY_BLOCK_PTR_FOR_FN (cfun));
-  make_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun), bb, EDGE_FALLTHRU);
-  make_edge (bb, EXIT_BLOCK_PTR_FOR_FN (cfun), 0);
+  bb->count = count;
+  bb->frequency = BB_FREQ_MAX;
+  e = make_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun), bb, EDGE_FALLTHRU);
+  e->count = count;
+  e->probability = REG_BR_PROB_BASE;
+  e = make_edge (bb, EXIT_BLOCK_PTR_FOR_FN (cfun), 0);
+  e->count = count;
+  e->probability = REG_BR_PROB_BASE;
   add_bb_to_loop (bb, ENTRY_BLOCK_PTR_FOR_FN (cfun)->loop_father);
 
   return bb;
@@ -1578,7 +1589,8 @@ cgraph_node::expand_thunk (bool output_a
   else
resdecl = DECL_RESULT (thunk_fndecl);
 
-  bb = then_bb = else_bb = return_bb = init_lowered_empty_function 
(thunk_fndecl, true);
+  bb = then_bb = else_bb = return_bb
+   = init_lowered_empty_function (thunk_fndecl, true, count);
 
   bsi = gsi_start_bb (bb);
 
@@ -1654,13 +1666,20 @@ cgraph_node::expand_thunk (bool output_a
  if (TREE_CODE (TREE_TYPE (restmp)) == POINTER_TYPE)
{
  gimple stmt;
+ edge e;
  /* If the return type is a pointer, we need to
 protect against NULL.  We know there will be an
 adjustment, because that's why we're emitting a
 thunk.  */
  then_bb = create_basic_block (NULL, (void *) 0, bb);
+ then_bb->count = count - count / 16;
+ then_bb->frequency = BB_FREQ_MAX - BB_FREQ_MAX / 16;
  return_bb = create_basic_block (NULL, (void *) 0, then_bb);
+ return_bb->count = count;
+ return_bb->frequency = BB_FREQ_MAX;
  else_bb = create_basic_block (NULL, (void *) 0, else_bb);
+ then_bb->count = count / 16;
+ then_bb->frequency = BB_FREQ_MAX / 16;
  add_bb_to_loop (then_bb, bb->loop_father);
  add_bb_to_loop (return_bb, bb->loop_father);
  add_bb_to_loop (else_bb, bb->loop_father);
@@ -1670,11 +1689,21 @@ cgraph_node::expand_thunk (bool output_a
   

Re: [PATCH] PR64635 - load libgomp-plugin-host_nonshm shared library with correct suffix

[Thomas Schwinge]

Hi!

First, thanks for improving portability of the libgomp plugin interface!


On Wed, 28 Jan 2015 16:43:19 -0500, Jack Howarth  
wrote:
> There is one other issue that I have been
> pondering about filing a PR. In fink and MacPorts, FSF gcc is built
> and packaged using either...
> 
> --prefix=/sw/lib/gcc5.0
> 
> or
> 
> --libdir=/opt/local/lib/gcc5
> 
> such that the libraries for each gcc release are buried. While this
> doesn't present an issue in running the libgomp test suite when
> -DACC_DEVICE_TYPE_host_nonshm=1 is used

(Note that the host_nonshm device type/plugin is probably not something
end users would really use -- other than for debugging if no more
suitable offloading device is available -- but the problem of course is a
general one.)

> end-users will have to
> explicitly set DYLD_LIBRARY_PATH to contain /sw/lib/gcc5.0/lib or
> /opt/local/lib/gcc5 for such executables to find the
> libgomp-plugin-host_nonshm shared library.
>  I realize this is a corner case, but shouldn't libgomp/target.c
> contain a hard-coded path from the build for the location of the
> installed gcc libraries and make an initial attempt to open it from
> that location before attempting a second time without an explicit
> path? Any thoughts?

This has been discussed before in

and the messages before that one.  A GCC installation tree has to be
relocatable, so in my understanding it is not appropriate to hard-code
absolute (build-time) paths.  My idea was that a system's dynamic linker
already has to locate the libgomp shared object (on a GNU/Linux system
through LD_LIBRARY_PATH, or -Wl,-rpath,[...], for example), and via the
same lookup mechanism the libgomp plugins should be found.  Does that
scheme not generally work?  That'd be a pity indeed...  :-/


Grüße,
 Thomas


pgpvDo36_jNAl.pgp
Description: PGP signature

Re: Fix tls model dumping

[Alan Modra]

On Thu, Jan 29, 2015 at 06:07:16AM +0100, Jan Hubicka wrote:
> > On Wed, Jan 28, 2015 at 08:56:22PM +0100, Jan Hubicka wrote:
> > > -const char * const tls_model_names[]={"none", "tls-emulated", "tls-real",
> > > -   "tls-global-dynamic", "tls-local-dynamic",
> > > -   "tls-initial-exec", "tls-local-exec"};
> > > +const char * const tls_model_names[]={"none", "emulated",
> > > +   "global-dynamic", "local-dynamic",
> > > +   "initial-exec", "local-exec"};
> >
> > I just made the same mistake in a binutils commit message.  The proper
> > term is general-dynamic, not global-dynamic.  See Drepper's TLS paper,
> > section 4.  http://www.akkadia.org/drepper/tls.pdf
>
> Hmm, this seems to disagree with our attribute:
> @item -ftls-model=@var{model}
> @opindex ftls-model
> Alter the thread-local storage model to be used (@pxref{Thread-Local}).
> The @var{model} argument should be one of @code{global-dynamic},
> @code{local-dynamic}, @code{initial-exec} or @code{local-exec}.

Huh, it must have been Drepper that made the mistake.  :-)

--
Alan Modra
Australia Development Lab, IBM

Fix flag_fp_contract_mode with LTO

[Jan Hubicka]

Hi,
Igor found an performance regression related to my patch enabling option
streaming. It turns out that with LTO we disable FMA instruction generation
because fp_contract_mode is not streamed and set to 0.
This is because patch https://gcc.gnu.org/ml/gcc-patches/2010-11/msg01827.html
that makes fp_contract_mode special hanled by the generator but i fialed to
copy this to option streaming.
The support for general enums was added later and there is no longer reason
to special case this.

Bootstrapped/regtested x86_64-linux, comitted.

* optc-save-gen.awk: flag_fp_contract_mode is no longer speical.
* opth-gen.awk: Likewise.
* common.opt: Mark flag_fp_contract_mode as Optimization.
Index: optc-save-gen.awk
===
--- optc-save-gen.awk   (revision 220228)
+++ optc-save-gen.awk   (working copy)
@@ -87,7 +87,7 @@ print "{";
 n_opt_char = 3;
 n_opt_short = 0;
 n_opt_int = 0;
-n_opt_enum = 1;
+n_opt_enum = 0;
 n_opt_other = 0;
 var_opt_char[0] = "optimize";
 var_opt_char[1] = "optimize_size";
@@ -95,7 +95,6 @@ var_opt_char[2] = "optimize_debug";
 var_opt_range["optimize"] = "0, 255";
 var_opt_range["optimize_size"] = "0, 1";
 var_opt_range["optimize_debug"] = "0, 1";
-var_opt_enum[0] = "flag_fp_contract_mode";
 
 # Sort by size to mimic how the structure is laid out to be friendlier to the
 # cache.
Index: opth-gen.awk
===
--- opth-gen.awk(revision 220228)
+++ opth-gen.awk(working copy)
@@ -135,12 +135,11 @@ print "{";
 n_opt_char = 3;
 n_opt_short = 0;
 n_opt_int = 0;
-n_opt_enum = 1;
+n_opt_enum = 0;
 n_opt_other = 0;
 var_opt_char[0] = "unsigned char x_optimize";
 var_opt_char[1] = "unsigned char x_optimize_size";
 var_opt_char[2] = "unsigned char x_optimize_debug";
-var_opt_enum[0] = "enum fp_contract_mode x_flag_fp_contract_mode";
 
 for (i = 0; i < n_opts; i++) {
if (flag_set_p("Optimization", flags[i])) {
Index: common.opt
===
--- common.opt  (revision 220228)
+++ common.opt  (working copy)
@@ -1248,7 +1248,7 @@ Common Report Var(flag_forward_propagate
 Perform a forward propagation pass on RTL
 
 ffp-contract=
-Common Joined RejectNegative Enum(fp_contract_mode) Var(flag_fp_contract_mode) 
Init(FP_CONTRACT_FAST)
+Common Joined RejectNegative Enum(fp_contract_mode) Var(flag_fp_contract_mode) 
Init(FP_CONTRACT_FAST) Optimization
 -ffp-contract=[off|on|fast] Perform floating-point expression contraction.
 
 Enum

Re: Fix tls model dumping

[Jan Hubicka]

> On Wed, Jan 28, 2015 at 08:56:22PM +0100, Jan Hubicka wrote:
> > -const char * const tls_model_names[]={"none", "tls-emulated", "tls-real",
> > - "tls-global-dynamic", "tls-local-dynamic",
> > - "tls-initial-exec", "tls-local-exec"};
> > +const char * const tls_model_names[]={"none", "emulated",
> > + "global-dynamic", "local-dynamic",
> > + "initial-exec", "local-exec"};
> 
> I just made the same mistake in a binutils commit message.  The proper
> term is general-dynamic, not global-dynamic.  See Drepper's TLS paper,
> section 4.  http://www.akkadia.org/drepper/tls.pdf

Hmm, this seems to disagree with our attribute:
@item -ftls-model=@var{model}   
@opindex ftls-model 
Alter the thread-local storage model to be used (@pxref{Thread-Local}). 
The @var{model} argument should be one of @code{global-dynamic},
@code{local-dynamic}, @code{initial-exec} or @code{local-exec}. 
Note that the choice is subject to optimization: the compiler may use   
a more efficient model for symbols not visible outside of the translation   
unit, or if @option{-fpic} is not given on the command line.

The default without @option{-fpic} is @code{initial-exec}; with 
@option{-fpic} the default is @code{global-dynamic}.

If it is indeed a mistake, I guess we can just support both names.

Honza

RE: [Patch][wwwdocs]Deprecate the ARM TPCS related options in gcc 5.0

[Terry Guo]

> -Original Message-
> From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
> Sent: Thursday, January 29, 2015 2:53 AM
> To: Terry Guo
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw; Ramana Radhakrishnan
> Subject: RE: [Patch][wwwdocs]Deprecate the ARM TPCS related options in
> gcc 5.0
> 
> On Wednesday 2015-01-28 09:57, Terry Guo wrote:
> > Thanks Gerald. Patch is updated. Is this one OK?
> 
> This good to me.  (Perhaps say "which were only applicable", since there
are
> gone now?)
> 
> Gerald

Thanks Gerald. Patch is committed.  Because the options are not removed from
GCC right now, I am not using "which were". We give a warning first and then
remove the gcc code later, user can have chances to update their existing
projects.

BR,
Terry 

Re: Fix tls model dumping

[Alan Modra]

On Wed, Jan 28, 2015 at 08:56:22PM +0100, Jan Hubicka wrote:
> -const char * const tls_model_names[]={"none", "tls-emulated", "tls-real",
> -   "tls-global-dynamic", "tls-local-dynamic",
> -   "tls-initial-exec", "tls-local-exec"};
> +const char * const tls_model_names[]={"none", "emulated",
> +   "global-dynamic", "local-dynamic",
> +   "initial-exec", "local-exec"};

I just made the same mistake in a binutils commit message.  The proper
term is general-dynamic, not global-dynamic.  See Drepper's TLS paper,
section 4.  http://www.akkadia.org/drepper/tls.pdf

-- 
Alan Modra
Australia Development Lab, IBM

RE: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

[Hale Wang]

Hi Segher,

I have updated the patch as you suggested. Both the patch and the changelog
are attached.

By the way, the test case provided by Tim Pambor in PR46164 was a different
bug with PR46164. So I resubmitted the bug in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64818.
And this patch is just used to fix this bug. Is it OK for you?

Thanks,
Hale

gcc/ChangeLog:
2015-01-27  Segher Boessenkool  
Hale Wang  

PR rtl-optimization/64818
* combine.c (can_combine_p): Don't combine the insn if
the dest of insn is a user specified register.

gcc/testsuit/ChangeLog:
2015-01-27  Segher Boessenkool  
Hale Wang  

PR rtl-optimization/64818
* gcc.target/arm/pr64818.c: New test.


diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..6901ac2 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1904,6 +1904,12 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn
*pred ATTRIBUTE_UNUSED,
   set = expand_field_assignment (set);
   src = SET_SRC (set), dest = SET_DEST (set);
 
+  /* Don't combine if dest contains a user specified register, because the
+ user specified register (same with dest) in i3 would be replaced by
the
+ src of insn which might be different with the user's expectation.  */
+  if (REG_P (dest) && REG_USERVAR_P (dest) && HARD_REGISTER_P (dest))
+return 0;
+
   /* Don't eliminate a store in the stack pointer.  */
   if (dest == stack_pointer_rtx
   /* Don't combine with an insn that sets a register to itself if it
has
diff --git a/gcc/testsuite/gcc.target/arm/pr64818.c
b/gcc/testsuite/gcc.target/arm/pr64818.c
new file mode 100644
index 000..bddd846
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr64818.c
@@ -0,0 +1,30 @@
+/* { dg-do compile } */
+/* { dg-options "-O1" } */
+
+char temp[16];
+extern int foo1 (void);
+
+void foo (void)
+{
+  int i;
+  int len;
+
+  while (1)
+  {
+len = foo1 ();
+register int a asm ("r0") = 5;
+register char *b asm ("r1") = temp;
+register int c asm ("r2") = len;
+asm volatile ("mov %[r0], %[r0]\n  mov %[r1], %[r1]\n  mov %[r2],
%[r2]\n"
+  : "+m"(*b)
+  : [r0]"r"(a), [r1]"r"(b), [r2]"r"(c));
+
+for (i = 0; i < len; i++)
+{
+  if (temp[i] == 10)
+  return;
+}
+  }
+}
+
+/* { dg-final { scan-assembler "\[\\t \]+mov\ r1,\ r1" } } */


> > On Tue, Jan 27, 2015 at 11:49:55AM +0800, Hale Wang wrote:
> >
> > Hi Hale,
> > > You are correct. Just "-O1" reproduces this problem.
> > > However it's a combine bug which is related to the combing user
> > > specified register into inline-asm.
> >
> > Yes, it is.  But the registers the testcase uses exist on any ARM
> > version
> there
> > is as far as I know, so not specifying specific model and ABI should
> > give
> wider
> > test coverage (if anyone actually builds and/or tests more than the
> default,
> > of course :-) )
> >
> > > > Could you try this patch please?
> > >
> > > Your patch rejected the combine 98+43, that's correct.
> >
> > Excellent, thanks for testing.
> >
> > > However, Jakub
> > > pointed out that preventing that to be combined would be a serious
> > > regression on code quality.
> >
> > I know; I needed to think of some good way to detect register
> > variables
> (they
> > aren't marked specially in RTL).  I think I found one, for combine
> > that
> is; if we
> > need to detect it in other passes too, we probably need to put another
> flag
> > on it, or something.
> >
> > > Andrew Pinski suggested: can_combine_p would reject combing into an
> > > inline-asm to prevent this issue. And I have updated the patch. What
> > > do you think about this change?
> >
> > That will regress combining anything else into an asm.  It will
> > disallow combining asms _at all_, if we really wanted that we should
> > simply not
> build
> > LOG_LINKS for them.  But it hurts optimisation (for simple "r"
> > constraints
> it is
> > not a real problem, RA should take care of it, but for anything else
> > it
> is).
> >
> > Updated patch below.  A user variable that is also a hard register can
> only
> > happen in a few cases: 1) a register variable, the case we are after;
> > 2)
> an
> > argument for the current function that was propagated into a user
> > variable (something combine should not do at all, it hinders good
> > register
> allocation,
> > but it does anyway on most targets).
> >
> > Do you want to take this or shall I?  This is not a regression, so it
> probably
> > should wait for stage1 :-(
> >
> 
> Your solution is very good. I will test this patch locally and send out
the result
> ASAP.
> Thanks,
> 
> Hale
> 
> >
> > Segher
> >

pr64818-combine-user-specified-register.changelog
Description: Binary data


pr64818-combine-user-specified-register.patch-2
Description: Binary data

Re: [wwwdocs] Mention ipa-ICF and auto-FDO

[Gerald Pfeifer]

On Monday 2015-01-26 07:10, Jan Hubicka wrote:
> Index: changes.html
> ===
> + An Identical Code Folding (ICF) pass (controled via

controlled

> +  this pass unifies about 29000 functions that is 10% overall.

"functions, that is"  (adding a comma)
 or
"functions, or 10% overall"


This is fine with these two changes.  Thank you.

Gerald

Re: [google/gcc-4_9] Add -ftwo-level-line-tables and -gline-tables-only options

[Dehao Chen]

On Wed, Jan 28, 2015 at 4:34 PM, Cary Coutant  wrote:
>>> > Not quite clear why we need block_table. This table is not gonna be
>>> > emitted. And we can easily get subprog_entry through block->block_num
>>>
>>> When final_scan_insn() calls dwarf2out_begin_block(), all it passes is
>>> a block number. I don't know a way to get from block number to the
>>> block, so I traverse all the blocks of a function when
>>> dwarf2out_begin_function() is called, and build this table. Now in
>>> dwarf2out_source_line, I can look at the current block number and tell
>>> what the inline call stack is.
>>
>> Is it correct that block_num has 1-1 mapping with block_table. And
>> block_table has 1-1 mapping with logical_table?
>
> The first part, yes -- there's one entry in block_table for each
> block_num in the function tree. But two or more blocks may map to a
> single logical, and some blocks may not correspond to a logical at all
> -- if dwarf2out_source_line() is never called for a block, I'll never
> create a logical for it.

I don't understand why multiple blocks may map to a single
logical_entry. Can you give an example?

Thanks,
Dehao

>
> -cary

Re: [google/gcc-4_9] Add -ftwo-level-line-tables and -gline-tables-only options

[Cary Coutant]

>> > Not quite clear why we need block_table. This table is not gonna be
>> > emitted. And we can easily get subprog_entry through block->block_num
>>
>> When final_scan_insn() calls dwarf2out_begin_block(), all it passes is
>> a block number. I don't know a way to get from block number to the
>> block, so I traverse all the blocks of a function when
>> dwarf2out_begin_function() is called, and build this table. Now in
>> dwarf2out_source_line, I can look at the current block number and tell
>> what the inline call stack is.
>
> Is it correct that block_num has 1-1 mapping with block_table. And
> block_table has 1-1 mapping with logical_table?

The first part, yes -- there's one entry in block_table for each
block_num in the function tree. But two or more blocks may map to a
single logical, and some blocks may not correspond to a logical at all
-- if dwarf2out_source_line() is never called for a block, I'll never
create a logical for it.

-cary

Re: [google/gcc-4_9] Add -ftwo-level-line-tables and -gline-tables-only options

[Dehao Chen]

On Wed, Jan 28, 2015 at 3:04 PM, Cary Coutant  wrote:
>
> >> +static subprog_entry *
> >> +add_subprog_entry (tree decl, bool is_inlined)
> >> +{
> >> +  subprog_entry **slot;
> >> +  subprog_entry *entry;
> >> +
> >> +  slot = subprog_table->find_slot_with_hash (decl, DECL_UID (decl), 
> >> INSERT);
> >> +  if (*slot == HTAB_EMPTY_ENTRY)
> >> +{
> >> +  entry = XCNEW (struct subprog_entry);
> >> +  entry->decl = decl;
> >> +  entry->is_inlined = is_inlined;
> >> +  entry->subprog_num = 0;
> >> +  *slot = entry;
> >> +}
> >> +  else if (is_inlined)
> >
> > When will the logic go into else branch?
>
> When we already have an entry for the given subprogram (e.g., the same
> subroutine gets inlined in multiple places).
>
>
> >> +/* For two-level line tables, a map from block number to an
> >> +   inlined call chain.  */
> >> +
> >> +struct block_entry
> >> +{
> >> +  unsigned int block_num;
> >> +  struct subprog_entry *subprog;
> >> +  struct block_entry *caller;
> >> +  location_t caller_loc;
> >> +};
> >> +
> >> +struct block_hasher : typed_free_remove 
> >> +{
> >> +  typedef block_entry value_type;
> >> +  typedef unsigned int compare_type;
> >> +  static hashval_t hash (const value_type *);
> >> +  static bool equal (const value_type *, const compare_type *);
> >> +};
> >> +
> >> +inline hashval_t
> >> +block_hasher::hash (const value_type *p)
> >> +{
> >> +  return (hashval_t) p->block_num;
> >> +}
> >> +
> >> +inline bool
> >> +block_hasher::equal (const value_type *p1, const compare_type *p2)
> >> +{
> >> +  return p1->block_num == *p2;
> >> +}
> >> +
> >> +static hash_table *block_table;
> >
> > Not quite clear why we need block_table. This table is not gonna be
> > emitted. And we can easily get subprog_entry through block->block_num
>
> When final_scan_insn() calls dwarf2out_begin_block(), all it passes is
> a block number. I don't know a way to get from block number to the
> block, so I traverse all the blocks of a function when
> dwarf2out_begin_function() is called, and build this table. Now in
> dwarf2out_source_line, I can look at the current block number and tell
> what the inline call stack is.

Is it correct that block_num has 1-1 mapping with block_table. And
block_table has 1-1 mapping with logical_table?

Dehao
>
>
> >> +#ifdef DEBUG_TWO_LEVEL
> >> +  static unsigned int level = 0;
> >> +#endif
> >> +
> >> +  if (block == NULL)
> >> +return;
> >> +
> >> +#ifdef DEBUG_TWO_LEVEL
> >
> > Shall this be controlled by dump options with TDF_DETAILS dump_flag?
>
> I don't see the need -- I'll rip this out before submitting for trunk.
> I'd have ripped it out already, but thought it might be useful for a
> little while longer.
>
>
> >> +  block_num = BLOCK_NUMBER (block);
> >> +  slot = block_table->find_slot_with_hash (&block_num, (hashval_t) 
> >> block_num, INSERT);
> >> +  if (*slot != HTAB_EMPTY_ENTRY)
> >
> > Instead of return, can you assert that the data stored in *slot is
> > consistent with the new data? Or should *slot never be
> > HTAB_EMPTY_ENTRY?
>
> It should probably be consistent, but I wasn't absolutely sure, and I
> didn't want to have the compiler crash when either version of the data
> is probably good enough. It might not be empty, because I might have
> already added the block number to the table in the loop over the
> parent node's BLOCK_FRAGMENT_CHAIN. (I may not need to have that loop
> at all, if it's always the case that the blocks in
> BLOCK_FRAGMENT_CHAIN are also contained in the subtree under
> BLOCK_SUBBLOCKS. I'm being conservative here.)
>
> -cary

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[H.J. Lu]

On Wed, Jan 28, 2015 at 11:37 AM, H.J. Lu  wrote:
> On Wed, Jan 28, 2015 at 11:19 AM, Richard Biener
>  wrote:
>> On January 28, 2015 7:12:43 PM CET, "H.J. Lu"  wrote:
>>>Hi,
>>>
>>>This patch makes claim_file_handler to call release_input_file after it
>>>finishes processing input file.  OK for trunk?
>>
>> OK.  How did you test this?
>
> I did normal bootstrap and "make check" on Linux/x86-64.
> I also run ld.bfd and ld.gold by hand to verify that release_input_file
> is called.
>

This is needed for LTO build.  ar/nm/ranlib don't provide
release_input_file.  I checked it in as an obvious fix.

-- 
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 220212)
+++ ChangeLog (working copy)
@@ -1,5 +1,10 @@
 2015-01-28  H.J. Lu  

+ * lto-plugin.c (claim_file_handler): Call release_input_file only
+ if it is not NULL.
+
+2015-01-28  H.J. Lu  
+
  PR lto/64837
  * lto-plugin.c (release_input_file): New.
  (claim_file_handler): Call release_input_file.
Index: lto-plugin.c
===
--- lto-plugin.c (revision 220212)
+++ lto-plugin.c (working copy)
@@ -1007,7 +1007,8 @@ claim_file_handler (const struct ld_plug
   if (obj.objfile)
 simple_object_release_read (obj.objfile);

-  release_input_file (file);
+  if (release_input_file)
+release_input_file (file);

   return LDPS_OK;
 }

Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.

[Doug Gilmore]

On 01/18/2015 05:19 AM, Jonathan Wakely wrote:
> On 17/01/15 19:51 -0700, Sandra Loosemore wrote:
>> On 01/17/2015 03:58 PM, Jonathan Wakely wrote:
>>>
>>> My fault, this additional chunk is needed alongside the patch I sent
>>> earlier:
>>>
>>> --- a/libstdc++-v3/include/bits/atomic_futex.h
>>> +++ b/libstdc++-v3/include/bits/atomic_futex.h
>>> @@ -35,7 +35,7 @@
>>> #include 
>>> #include 
>>> #include 
>>> -#if !defined(_GLIBCXX_HAVE_LINUX_FUTEX)
>>> +#if ! (defined(_GLIBCXX_HAVE_LINUX_FUTEX) && ATOMIC_INT_LOCK_FREE > 1)
>>> #include 
>>> #include 
>>> #endif
>>>
>>> What I sent earlier causes your target to use std::mutex and
>>> std::condition_variable, but without the bit above the headers aren't
>>> included.
>>
>> Still no joy:
>> /scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/futex.cc:45:3:
>>  error: '__atomic_futex_unsigned_base' has not been declared
>>   __atomic_futex_unsigned_base::_M_futex_wait_until(unsigned *__addr,
>>   ^
>> /scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/futex.cc:88:3:
>>  error: '__atomic_futex_unsigned_base' has not been declared
>>   __atomic_futex_unsigned_base::_M_futex_notify_all(unsigned* __addr)
>>   ^
> 
> futex.cc needs the same change ...
I am still noticing a problem building a native X86_64 ToT compiler on
Ubuntu 12.04.5 LTS.

Attached is a patch where the CPP guards in atomic_futex.h are
reflected in futex.cc, which fixes my build problem.

OK to commit?

Thanks,

Doug

>From 1debe13da342ac30d905e12a9ca243e30cb61870 Mon Sep 17 00:00:00 2001
From: Doug Gilmore 
Date: Wed, 28 Jan 2015 14:29:14 -0800
Subject: [PATCH] CPP guards in futex.cc should match guards in futex.ii.

---
 libstdc++-v3/src/c++11/futex.cc |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++11/futex.cc b/libstdc++-v3/src/c++11/futex.cc
index 1336779..5087483 100644
--- a/libstdc++-v3/src/c++11/futex.cc
+++ b/libstdc++-v3/src/c++11/futex.cc
@@ -23,6 +23,7 @@
 // .
 
 #include 
+#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
 #if defined(_GLIBCXX_HAVE_LINUX_FUTEX) && ATOMIC_INT_LOCK_FREE > 1
 #include 
 #include 
@@ -93,4 +94,5 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
 }
-#endif
+#endif // _GLIBCXX_HAVE_LINUX_FUTEX && ATOMIC_INT_LOCK_FREE > 1
+#endif // _GLIBCXX_HAS_GTHREADS && _GLIBCXX_USE_C99_STDINT_TR1
-- 
1.7.9.5

Re: [google/gcc-4_9] Add -ftwo-level-line-tables and -gline-tables-only options

[Cary Coutant]

>> +static subprog_entry *
>> +add_subprog_entry (tree decl, bool is_inlined)
>> +{
>> +  subprog_entry **slot;
>> +  subprog_entry *entry;
>> +
>> +  slot = subprog_table->find_slot_with_hash (decl, DECL_UID (decl), INSERT);
>> +  if (*slot == HTAB_EMPTY_ENTRY)
>> +{
>> +  entry = XCNEW (struct subprog_entry);
>> +  entry->decl = decl;
>> +  entry->is_inlined = is_inlined;
>> +  entry->subprog_num = 0;
>> +  *slot = entry;
>> +}
>> +  else if (is_inlined)
>
> When will the logic go into else branch?

When we already have an entry for the given subprogram (e.g., the same
subroutine gets inlined in multiple places).


>> +/* For two-level line tables, a map from block number to an
>> +   inlined call chain.  */
>> +
>> +struct block_entry
>> +{
>> +  unsigned int block_num;
>> +  struct subprog_entry *subprog;
>> +  struct block_entry *caller;
>> +  location_t caller_loc;
>> +};
>> +
>> +struct block_hasher : typed_free_remove 
>> +{
>> +  typedef block_entry value_type;
>> +  typedef unsigned int compare_type;
>> +  static hashval_t hash (const value_type *);
>> +  static bool equal (const value_type *, const compare_type *);
>> +};
>> +
>> +inline hashval_t
>> +block_hasher::hash (const value_type *p)
>> +{
>> +  return (hashval_t) p->block_num;
>> +}
>> +
>> +inline bool
>> +block_hasher::equal (const value_type *p1, const compare_type *p2)
>> +{
>> +  return p1->block_num == *p2;
>> +}
>> +
>> +static hash_table *block_table;
>
> Not quite clear why we need block_table. This table is not gonna be
> emitted. And we can easily get subprog_entry through block->block_num

When final_scan_insn() calls dwarf2out_begin_block(), all it passes is
a block number. I don't know a way to get from block number to the
block, so I traverse all the blocks of a function when
dwarf2out_begin_function() is called, and build this table. Now in
dwarf2out_source_line, I can look at the current block number and tell
what the inline call stack is.


>> +#ifdef DEBUG_TWO_LEVEL
>> +  static unsigned int level = 0;
>> +#endif
>> +
>> +  if (block == NULL)
>> +return;
>> +
>> +#ifdef DEBUG_TWO_LEVEL
>
> Shall this be controlled by dump options with TDF_DETAILS dump_flag?

I don't see the need -- I'll rip this out before submitting for trunk.
I'd have ripped it out already, but thought it might be useful for a
little while longer.


>> +  block_num = BLOCK_NUMBER (block);
>> +  slot = block_table->find_slot_with_hash (&block_num, (hashval_t) 
>> block_num, INSERT);
>> +  if (*slot != HTAB_EMPTY_ENTRY)
>
> Instead of return, can you assert that the data stored in *slot is
> consistent with the new data? Or should *slot never be
> HTAB_EMPTY_ENTRY?

It should probably be consistent, but I wasn't absolutely sure, and I
didn't want to have the compiler crash when either version of the data
is probably good enough. It might not be empty, because I might have
already added the block number to the table in the loop over the
parent node's BLOCK_FRAGMENT_CHAIN. (I may not need to have that loop
at all, if it's always the case that the blocks in
BLOCK_FRAGMENT_CHAIN are also contained in the subtree under
BLOCK_SUBBLOCKS. I'm being conservative here.)

-cary

Re: [Ping] Port of VTV for Cygwin and MinGW

[Caroline Tice]

Since all the pieces of this patch have been approved, I will commit
it later today (since Patrick does not have commit privileges).


-- Caroline Tice
cmt...@google.com



On Wed, Jan 28, 2015 at 3:31 AM, Patrick Wollgast
 wrote:
> Ping.
>
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01270.html
>
> On 15.01.2015 22:50, Patrick Wollgast wrote:
>> On 15.01.2015 17:01, Ian Lance Taylor wrote:
>>> On Wed, Jan 14, 2015 at 11:54 PM, Patrick Wollgast
>>>  wrote:
 Is there something I'm still supposed to do, since I don't have write
 access and this was the last part missing an "OK"?
>>>
>>> Somebody with write access will need to commit the patch for you.  You
>>> should send a new clean patch including all the changes, along with
>>> updated ChangeLog entries.
>>>
>>> Ian
>>>
>>
>> For the clean patch I co'ed the latest version of the trunk again and
>> applied my patch. It applies correctly, except for two changes:
>>
>> patching file libgcc/Makefile.in
>> Hunk #1 succeeded at 995 with fuzz 2 (offset 9 lines).
>> Hunk #2 succeeded at 1020 (offset 17 lines).
>>
>>> # This is a version of crtbegin for -static links.
>>> crtbeginT$(objext): $(srcdir)/crtstuff.c
>>>  $(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $< -DCRT_BEGIN
>>> -DCRTSTUFFT_O
>>> endif
>>>
>>> ifeq ($(enable_vtable_verify),yes)
>>> # These are used in vtable verification; see comments in source files
>>> for
>>> # more details.
>>
>> I had to move the endif down, since something was added before
>> "ifeq ($(enable_vtable_verify),yes)" inside the if.
>>
>>> # This is a version of crtbegin for -static links.
>>> crtbeginT$(objext): $(srcdir)/crtstuff.c
>>>  $(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $< -DCRT_BEGIN
>>> -DCRTSTUFFT_O
>>>
>>> # crtoffloadbegin and crtoffloadend contain symbols, that mark the
>>> begin and
>>> # the end of tables with addresses, required for offloading.
>>> crtoffloadbegin$(objext): $(srcdir)/offloadstuff.c
>>>  $(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $< -DCRT_BEGIN
>>>
>>> crtoffloadend$(objext): $(srcdir)/offloadstuff.c
>>>  $(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $< -DCRT_END
>>> endif
>>>
>>> ifeq ($(enable_vtable_verify),yes)
>>> # These are used in vtable verification; see comments in source files
>>> for
>>> # more details.
>>
>>
>> patching file libgcc/config.host
>> Hunk #1 succeeded at 621 (offset 6 lines).
>> Hunk #2 succeeded at 640 (offset 6 lines).
>> Hunk #3 succeeded at 660 (offset 6 lines).
>> Hunk #4 succeeded at 1198 with fuzz 2 (offset 495 lines).
>>
>>>  tmake_file="${tmake_file} ${tmake_eh_file} ${tmake_dlldir_file}
>> i386/t-slibgcc-cygming i386/t-mingw32 t-dfprules i386/t-crtfm i386/t-chkstk"
>>>  extra_parts="$extra_parts crtfastmath.o"
>>
>> The last two lines were changed to the following two lines.
>>
>>>  tmake_file="${tmake_file} ${tmake_eh_file} ${tmake_dlldir_file}
>> i386/t-slibgcc-cygming i386/t-cygming i386/t-mingw32 t-dfprules
>> i386/t-crtfm i386/t-chkstk"
>>>  extra_parts="$extra_parts crtbegin.o crtend.o crtfastmath.o"
>>
>> And therefore Hunk #4, which follows these lines, wasn't applied correctly.
>>
>> These two parts were corrected in vtv_cygmin_clean.patch. For
>> convenience I also added vtv_cygmin_unclean.patch, which is the patch
>> from my last mail.
>>
>> Regards,
>> Patrick
>>

Re: [PATCH] libiberty/argv.c: Use freeargv() instead of free() to avoid memory leak.

[Chen Gang S]

On 1/28/15 20:02, Andrew Burgess wrote:
> * Chen Gang S  [2015-01-28 19:34:38 +0800]:
> 
>>  libiberty/argv.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libiberty/argv.c b/libiberty/argv.c
>> index f2727e8..9fdd55b 100644
>> --- a/libiberty/argv.c
>> +++ b/libiberty/argv.c
>> @@ -454,7 +454,7 @@ expandargv (int *argcp, char ***argvp)
>>/* Free up memory allocated to process the response file.  We do
>>   not use freeargv because the individual options in FILE_ARGV
>>   are now in the main ARGV.  */
>> -  free (file_argv);
>> +  freeargv (file_argv);
> 
> I'm not commenting on the correctness of the patch, however, you will
> need to update the comment just above this change.
> 
> Personally, I'd also hope that the commit message explains why the
> comment is no longer correct, rather than just stating that the change
> has been made.
> 

Oh, sorry! After read the comments carefully, for me, it doesn't need
additional explanation. Sorry for my carelessness, also excuse me for my
poor English.

Thanks.
-- 
Chen Gang

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

Re: [testsuite] Run guality tests on Solaris

[Rainer Orth]

Jakub Jelinek  writes:

> On Wed, Jan 28, 2015 at 01:42:47PM -0700, Jeff Law wrote:
>> >2015-01-28  Rainer Orth  
>> >
>> >gcc/testsuite:
>> >* gcc.dg/guality/guality.h (main): Add argv[0] to
>> >guality_gdb_command.
>> OK.
>> 
>> As for what to do with guality, I haven't a clue.  They're dependent on the
>> debugger version and perhaps other stuff that I don't recall.
>> 
>> Perhaps skip them if we find gdb and determine it is "too old"?
>
> We already do that.  I bet the Solaris case is more about the lack
> of support to find an executable from its pid (/proc//exe
> in Linux).
> Guess one can easily try it, run
> gdb
> (without arguments, or those -nx -nw that guality uses) and type
> attach 19355 # pick pid of some process you can debug
> in Linux gdb will find the binary etc.

That issue is easily solved by passing the executable name to gdb; this
is guaranteed to work everywhere.  On Solaris (at least from Solaris 10
onwards, haven't checked earlier version), gdb could use
/proc//path/a.out to get at the executable, but that won't help for
released versions of gdb (and eventually other platforms which provide
no such facility).

But this issue is minor and easily avoided.  The major problem is that
on both Solaris and Linux, many of the guality tests FAIL (or XPASS,
equally adding noise to mail-reports.log) even with a current version of
gdb (7.8 in my case):


Linux/x86_64Solaris 11/x86  Solaris 11/SPARC
(Fedora 20)

gcc.dg/guality:

# of expected passes649065005489
# of unexpected failures191 171 802
# of unexpected successes   61  66  73
# of expected failures  35  30  23
# of unsupported tests  257 267 383

g++.dg/guality:

# of expected passes128 128 118
# of unexpected failures6   10  10
# of unsupported tests  34  30  40

It also seems (haven't checked yet in detail) that the results also
depend on whether they are created as part of a regular make check at
the toplevel, compared to runtest --tool  guality.exp.

Judging from posted testresults, I'm no the only one seeing this, and
the guality tests have way more FAILs than all other tests combined:
with those amounts of noise, it's almost impossile to see other errors,
and nobody seems to work on fixing those.

Thus my suggestion not run them by default until someone steps forward
to take care of all those issues.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH, CHKP] Fix PR middle-end/64805

[Jeff Law]

On 01/27/15 05:48, Ilya Enkovich wrote:

Hi,

Some time ago removal of not instrumented version of funtion with 
'always_inline' was delayed to enable their inlining.  With this change we may 
have situations when we inline into a not instrumented version of a function 
which also has an instrumented version (happens when both of them have 
'always_inline').  It causes ICE in cgraph_node verifier because we clear all 
references before inlining and verifier expects IPA_REF_CHKP reference for all 
functions having instrumented version.  This patch fixes it by rebuilding 
IPA_REF_CHKP reference.

Bootstrapped and tested on x86_64-unknown-linux-gnu.  OK for trunk?

Thanks,
Ilya
--
2015-01-27  Ilya Enkovich  

PR middle-end/64805
* ipa-inline.c (early_inliner): Rebuild IPA_REF_CHKP reference
to avoid error in cgraph node verification.

2015-01-27  Ilya Enkovich  

PR middle-end/64805
* gcc.target/i386/pr64805.c: New.

OK.
jeff

Re: [PATCH 3/3] Fix dbr_schedule for -freorder-blocks-and-partition

[Jeff Law]

On 01/26/15 16:52, Kaz Kojima wrote:

This patch is to fix 2 issues found in dbr_schedule when trying to
fix PR target/64761.  The first is relax_delay_slots removes
the jump insn in the insns like below:

(jump_insn/j 74 58 59 (set (pc) (label_ref:SI 29)) ...)
(barrier 59 74 105)
(note 105 59 29 NOTE_INSN_SWITCH_TEXT_SECTIONS)
(code_label 29 105 30 31 "" [5 uses])
(insn 31 30 32 (set (reg ...

i.e. relax_delay_slot tries to delete the jump insn pointing to
the next active insn of that jump insn as a trivial jump even when
there is a NOTE_INSN_SWITCH_TEXT_SECTIONS note between that jump
and its next active insn.
The second issue is that relax_delay_slots does a variant of
follow jump optimization without checking targetm.can_follow_jump.

--
PR target/64761
* reorg.c (switch_text_sections_between_p): New function.
(relax_delay_slots): Call it when testing if the jump insn
is removable.  Use targetm.can_follow_jump when testing if
the conditional branch can follow an unconditional jump.
OK.  I'm a bit surprised we're still finding this kind of stuff 10 years 
after NOTE_INSN_SWITCH_TEXT_SECTIONS went in.  Sigh.


Jeff

Re: [PATCH] PR jit/64780: configure: --enable-host-shared and the jit

[Jeff Law]

On 01/27/15 10:17, David Malcolm wrote:

Currently the jit requires you to specify --enable-host-shared, or the
build eventually fails with  linker errors (this is something of a FAQ
for people trying out the jit).

We seem to have two choices here:

(A) default to --enable-host-shared when jit is an enabled language
(B) have the toplevel configure reject jit as language if
 --enable-host-shared is not supplied.

FWIW apparently Darwin defaults to position-independent code, so it's not
explicitly needed there.

I think (B) is the better option for us, since there is a performance
cost: there are people who perform benchmarking of GCC (and publish
their results on prominent websites).  If they turn on the jit and use
the same configuration to do their benchmarking of the rest of GCC,
they'll see GCC 5 be apparently slower than earlier releases.  This
is sufficiently subtle that I don't think it's reasonable to simply
document it and expect 3rd-party reviewers to see such a note in the
documentation before benchmarking.

The attached patch implements (B), with a note in the error message
recommending that people configure and build GCC twice to avoid the
performance hit, so that it can be self-documenting.

Tested by hand with various combinations of values for
--enable-host-shared and --enable-languages.

OK for stage 4?

PR jit/64780
* configure.ac: Require the user to explicitly specify
--enable-host-shared if the jit is enabled.
* configure: Regenerate.

OK.
jeff

Re: [PATCH] Fix libjava version number under cygwin

[Jeff Law]

On 01/28/15 04:51, Bernd Edlinger wrote:

Hi,


after the recent version bump of the libjava libraries, java under cygwin is 
broken.

The reason is that libgcc/config/i386/cygming-crtbegin.c needs to know the exact
version number to load the symbol _Jv_RegisterClasses from cyggcj-16.dll.

This patch fixes the cyggcj-xx.dll version numbers for cygwin and mingw32 again.

Boot-strapped with java under x86_64-pc-cygwin.
OK for trunk?

OK.
jeff

Re: [PATCH] libiberty/argv.c: Use freeargv() instead of free() to avoid memory leak.

[Chen Gang S]

On 1/28/15 20:02, Andrew Burgess wrote:
> * Chen Gang S  [2015-01-28 19:34:38 +0800]:
> 
>>  libiberty/argv.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libiberty/argv.c b/libiberty/argv.c
>> index f2727e8..9fdd55b 100644
>> --- a/libiberty/argv.c
>> +++ b/libiberty/argv.c
>> @@ -454,7 +454,7 @@ expandargv (int *argcp, char ***argvp)
>>/* Free up memory allocated to process the response file.  We do
>>   not use freeargv because the individual options in FILE_ARGV
>>   are now in the main ARGV.  */
>> -  free (file_argv);
>> +  freeargv (file_argv);
> 
> I'm not commenting on the correctness of the patch, however, you will
> need to update the comment just above this change.
> 
> Personally, I'd also hope that the commit message explains why the
> comment is no longer correct, rather than just stating that the change
> has been made.
> 

Oh, really. Excuse me, originally I did not notice about it. I shall
send patch v2 for it (just like what DJ Delorie said in another reply).


Thanks.
-- 
Chen Gang

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

Re: [PATCH] PR64635 - load libgomp-plugin-host_nonshm shared library with correct suffix

[Jack Howarth]

Mike,
  Thanks for the commit. There is one other issue that I have been
pondering about filing a PR. In fink and MacPorts, FSF gcc is built
and packaged using either...

--prefix=/sw/lib/gcc5.0

or

--libdir=/opt/local/lib/gcc5

such that the libraries for each gcc release are buried. While this
doesn't present an issue in running the libgomp test suite when
-DACC_DEVICE_TYPE_host_nonshm=1 is used, end-users will have to
explicitly set DYLD_LIBRARY_PATH to contain /sw/lib/gcc5.0/lib or
/opt/local/lib/gcc5 for such executables to find the
libgomp-plugin-host_nonshm shared library.
 I realize this is a corner case, but shouldn't libgomp/target.c
contain a hard-coded path from the build for the location of the
installed gcc libraries and make an initial attempt to open it from
that location before attempting a second time without an explicit
path? Any thoughts?
  Jack

On Wed, Jan 28, 2015 at 4:22 PM, Mike Stump  wrote:
> On Jan 28, 2015, at 1:03 PM, Jakub Jelinek  wrote:
>> Please add
>>   PR libgomp/64635
>> to the ChangeLog entry.
>> Ok with that change.
>
> Committed revision 220218.

Re: [google/gcc-4_9] Add -ftwo-level-line-tables and -gline-tables-only options

[Dehao Chen]

On Sun, Jan 25, 2015 at 6:06 PM, Cary Coutant  wrote:
> Add -ftwo-level-line-tables and -gline-tables-only options.
>
> With -ftwo-level-line-tables, GCC will generate two-level line tables,
> which adds inline call information to the line tables, obviating the
> need to keep bulky debug info around for the purposes of generating
> stack traces.
>
> The -gline-tables-only option suppresses all other debug info except
> the single DW_AT_compilation_unit DIE that points to the line table
> for that compilation unit, and any .debug_ranges entries needed for
> that DIE.
>
> Two-level line tables are being proposed for the DWARF version 6
> standard, and are described here:
>
>   http://dwarfstd.org/ShowIssue.php?issue=140906.1
>
>   http://wiki.dwarfstd.org/index.php?title=TwoLevelLineTables
>
> In order to generate two-level line tables, GCC requires support
> from the assembler, in the form of new .subprog and .lloc pseudo-ops.
>
> This patch is for the google/gcc-4_9 branch. I plan to propose it
> for trunk after we gain more experience with it.
>
> -cary
>
>
> 2015-01-23  Cary Coutant  
>
> gcc/
> * common.opt (-ftwo-level-line-tables): New option.
> (-gline-tables-only): New option.
> * dwarf2out.c (struct dw_line_info_table_struct): Add subprog_num
> and context fields.
> (dwarf2out_abstract_function): Check for line tables only.
> (dwarf2out_decl): Likewise.
> (block_stack): New variable.
> (dwarf2out_begin_block): For two-level line tables, keep a stack of
> current blocks.
> (dwarf2out_end_block): Likewise.
> (dwarf2out_var_location): Check for line tables only.
> (new_line_info_table): Initialize subprog_num and context fields.
> (struct subprog_entry): New type.
> (struct subprog_hasher): New type.
> (subprog_hasher::hash): New function.
> (subprog_hasher::equal): New function.
> (subprog_table): New variable.
> (last_subprog_num): New variable.
> (add_subprog_entry): New function.
> (struct block_entry): New type.
> (struct block_hasher): New type.
> (block_hasher::hash): New function.
> (block_hasher::equal): New function.
> (block_table): New variable.
> (struct logical_entry): New type.
> (struct logical_hasher): New type.
> (logical_hasher::hash): New function.
> (logical_hasher::equal): New function.
> (logical_table): New variable.
> (last_logical_num): New variable.
> (scan_blocks_for_inlined_calls): New function.
> (dwarf2out_begin_function): For two-level line tables, build map
> of blocks to inlined call stacks.
> (out_subprog_directive): New function.
> (out_logical_entry): New function.
> (dwarf2out_source_line): Add support for two-level line tables.
> (dwarf2out_init): Create subprog_table, block_table, and 
> logical_table.
> (dwarf2out_finish): When -gline-tables-only is set, always output
> the compilation_unit DIE; don't output aranges table.
> * final.c (final_start_function): Move call to number blocks...
> (rest_of_handle_final): ... to here.
> * opts.c (common_handle_option): Add -gline-tables-only.
> (set_debug_level): Clear debug_line_tables_only flag.
>
>
> Index: common.opt
> ===
> --- common.opt  (revision 220070)
> +++ common.opt  (working copy)
> @@ -1213,6 +1213,10 @@ fdwarf2-cfi-asm
>  Common Report Var(flag_dwarf2_cfi_asm) Init(HAVE_GAS_CFI_DIRECTIVE)
>  Enable CFI tables via GAS assembler directives.
>
> +ftwo-level-line-tables
> +Common Report Var(flag_two_level_line_tables) Init(0)
> +Use two-level line tables in DWARF (experimental).
> +
>  fripa
>  Common Report Var(flag_dyn_ipa)
>  Perform Dynamic Inter-Procedural Analysis.
> @@ -2657,6 +2661,10 @@ ggdb
>  Common JoinedOrMissing
>  Generate debug information in default extended format
>
> +gline-tables-only
> +Common RejectNegative Var(debug_line_tables_only) Init(0)
> +Generate DWARF line number tables and no other debug sections
> +
>  gno-pubnames
>  Common Negative(gpubnames) Var(debug_generate_pub_sections, 0) Init(-1)
>  Don't generate DWARF pubnames and pubtypes sections.
> Index: dwarf2out.c
> ===
> --- dwarf2out.c (revision 220070)
> +++ dwarf2out.c (working copy)
> @@ -2552,6 +2552,8 @@ typedef struct GTY(()) dw_line_info_tabl
>unsigned int line_num;
>unsigned int column_num;
>int discrim_num;
> +  unsigned int subprog_num;
> +  unsigned int context;
>bool is_stmt;
>bool in_use;
>
> @@ -1,6 +17779,9 @@ dwarf2out_abstract_function (tree decl)
>int old_call_site_count, old_tail_call_site_count;
>struct call_arg_loc_node *old_call_arg_locations;
>
> +  if (debug_line_tables_only)
> +return;
> +
>/* Mak

Re: [PATCH] PR64635 - load libgomp-plugin-host_nonshm shared library with correct suffix

[Mike Stump]

On Jan 28, 2015, at 1:03 PM, Jakub Jelinek  wrote:
> Please add
>   PR libgomp/64635
> to the ChangeLog entry.
> Ok with that change.

Committed revision 220218.

Re: [testsuite] Run guality tests on Solaris

[Rainer Orth]

Jakub Jelinek  writes:

> On Wed, Jan 28, 2015 at 10:10:18PM +0100, Rainer Orth wrote:
>> passing argv[0] seems the easiest course of action.  As I said,
>> gfortran.dg/guality/guality.exp already does it, and there were no
>> issues even on Solaris.
>
> gfortran.dg/guality/guality.exp doesn't do that.
> The thing is, there are 2 kinds of guality tests, the C/C++ ones using
> guality.h, and then ones using gcc-gdb-test.exp, where the spawning of
> gdb is done in tcl.
> Those share just directories, nothing else, and gfortran.dg/guality
> for obvious reasons doesn't contain any such tests.

You're right, of course: I looked at lib/gcc-gdb-test.exp (gdb-test),
where gdb is called with the executable name, but there's no attach to
an already running process involved, so it cannot be done any other way.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[SH][committed] Fix PR 64659

[Oleg Endo]

Hi,

Attached patch allows the atomic ops on SH to utilize some of the
immediate value insns, which can save an insn and reg sometimes.  The
actual changes are in the predicates, constraints and some adjustments
to some of the asm snippets.  While at it, I've changed uses of
register_operand into arith_reg_dest and arith_reg_operand respectively.

Committed as r220217.  Tested with
make -k check-gcc RUNTESTFLAGS="sh.exp=pr64659* --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2e/-ml,-m2e/-mb,-m3/-ml,-m3/-mb,-m3e/-ml,-m3e/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
to verify that the insns actually work.  Will observe daily sh4-linux
test results for fallouts.

Cheers,
Oleg

gcc/ChangeLog:
PR target/64659
* config/sh/predicates.md (atomic_arith_operand,
atomic_logical_operand): Remove.
* config/sh/sync.md (fetchop_predicate, fetchop_constraint): Remove.
(atomic_arith_operand_0): New predicate.
(atomic_compare_and_swap): Use arith_reg_dest for output values.
Use atomic_arith_operand_0 for input values.
(atomic_compare_and_swapsi_hard, atomic_compare_and_swap_hard,
atomic_compare_and_swap_soft_gusa,
atomic_compare_and_swap_soft_tcb,
atomic_compare_and_swap_soft_imask): Use arith_reg_dest and
arith_reg_operand instead of register_operand.
(atomic_exchange): Use arith_reg_dest for output value.  Use
atomic_arith_operand_0 for newval input.
(atomic_exchangesi_hard, atomic_exchange_hard,
atomic_exchange_soft_gusa, atomic_exchange_soft_tcb,
atomic_exchange_soft_imask): Use arith_reg_dest and
arith_reg_operand instead of register_operand.
(atomic_arith_operand_1, atomic_logical_operand_1): New predicates.
fetchop_predicate_1, fetchop_constraint_1_llcs,
fetchop_constraint_1_gusa, fetchop_constraint_1_tcb,
fetchop_constraint_1_imask): New code iterator attributes.
(atomic_fetch_): Use arith_reg_dest instead of
register_operand.  Use fetchop_predicate_1.
(atomic_fetch_si_hard,
atomic_fetch__hard): Use arith_reg_dest instead of
register_operand.  Use fetchop_predicate_1, fetchop_constraint_1_llcs.
(atomic_fetch__soft_gusa): Use arith_reg_dest
and arith_reg_operand instead of register_operand.  Use
fetchop_predicate_1, fetchop_constraint_1_gusa.
(atomic_fetch__soft_tcb): Use arith_reg_dest
and arith_reg_operand instead of register_operand.  Use
fetchop_predicate_1, fetchop_constraint_1_tcb.  Adjust asm sequence
to allow R0 usage.
(atomic_fetch__soft_imask): Use arith_reg_dest
and arith_reg_operand instead of register_operand.  Use
fetchop_predicate_1, fetchop_constraint_1_imask.  Adjust asm sequence
to allow R0 usage.
(atomic_fetch_nand): Use arith_reg_dest instead of
register_operand.  Use atomic_logical_operand_1.
(atomic_fetch_nandsi_hard, atomic_fetch_nand_hard,
atomic_fetch_nand_soft_gusa): Use arith_reg_dest and
arith_reg_operand instead of register_operand.
(atomic_fetch_nand_soft_tcb, atomic_fetch_nand_soft_imask):
Use arith_reg_dest and arith_reg_operand instead of register_operand.
Use logical_operand and rK08.  Adjust asm sequence to allow R0 usage.
(atomic__fetch): Use arith_reg_dest instead of
register_operand.  Use fetchop_predicate_1.
(atomic__fetchsi_hard,
atomic__fetch_hard): Use arith_reg_dest and
arith_reg_operand instead of register_operand.  Use fetchop_predicate_1,
fetchop_constraint_1_llcs.
(atomic__fetch_soft_gusa): Use arith_reg_dest and
arith_reg_operand instead of register_operand.  Use fetchop_predicate_1,
fetchop_constraint_1_gusa.
(atomic__fetch_soft_tcb): Use arith_reg_dest and
arith_reg_operand instead of register_operand.  Use fetchop_predicate_1,
fetchop_constraint_1_tcb.  Adjust asm sequence to allow R0 usage.
(atomic__fetch_soft_imask): Use arith_reg_dest and
arith_reg_operand instead of register_operand.  Use fetchop_predicate_1,
fetchop_constraint_1_imask.  Adjust asm sequence to allow R0 usage.
(atomic_nand_fetch): Use arith_reg_dest instead of
register_operand.  Use atomic_logical_operand_1.
(atomic_nand_fetchsi_hard, atomic_nand_fetch_hard,
atomic_nand_fetch_soft_gusa): Use arith_reg_dest and
arith_reg_operand instead of register_operand.
(atomic_nand_fetch_soft_tcb): Use arith_reg_dest and
arith_reg_operand instead of register_operand.  Use logical_operand
and K08.  Adjust asm sequence to allow R0 usage.
(atomic_nand_fetch_soft_imask): Use arith_reg_dest and
arith_reg_operand instead of register_operand.  Use logical_operand
and K08.

gcc/testsuite/ChangeLog:
PR target/64659
* gcc.target/sh/sh.exp
 

Re: [PATCH] libiberty/argv.c: Use freeargv() instead of free() to avoid memory leak.

[DJ Delorie]

>  memcpy (*argvp + i, file_argv, file_argc * sizeof (char *));

This code copies all the pointers in file_argv[] into argv[], so if
you freeargv them via file_argv, argv[] will point to free'd memory.
Hence the comment:

>   /* Free up memory allocated to process the response file.  We do
>not use freeargv because the individual options in FILE_ARGV
>are now in the main ARGV.  */

Re: [testsuite] Run guality tests on Solaris

[Jakub Jelinek]

On Wed, Jan 28, 2015 at 10:10:18PM +0100, Rainer Orth wrote:
> passing argv[0] seems the easiest course of action.  As I said,
> gfortran.dg/guality/guality.exp already does it, and there were no
> issues even on Solaris.

gfortran.dg/guality/guality.exp doesn't do that.
The thing is, there are 2 kinds of guality tests, the C/C++ ones using
guality.h, and then ones using gcc-gdb-test.exp, where the spawning of
gdb is done in tcl.
Those share just directories, nothing else, and gfortran.dg/guality
for obvious reasons doesn't contain any such tests.

Jakub

Re: [PATCH] Fix libbacktrace and libiberty tests fail on sanitized GCC due to wrong link options.

[DJ Delorie]

> Does the patch look sane?

I don't think anything in the toplevel configury looks "sane" any
more, but I think this patch is OK.

Re: [testsuite] Run guality tests on Solaris

[Rainer Orth]

Mike Stump  writes:

> On Jan 28, 2015, at 4:58 AM, Rainer Orth  
> wrote:
>> 
>> Thoughts?
>
> So the timeout for slow things can be increased:
>
> # More time is needed 
>   
> set_board_info gcc,timeout 800
> set_board_info gdb,timeout 60
>
> from the frv-sim.exp file.  And:
>
> # Increase the timeout
>   
> set timeout 60
>
> from a few others.  And:
>
> set_board_info testcase_timeout 30
>
> from usparc-cygmon.exp.  I’d like to think one or more of those would cure 
> the timeout problem.  You can put the timeout in a site.exp file or a 
> $HOME/.dejgnurc file for dejagnu and try it out, something like:
>
> case "$target_triplet" in {
> { “sparc-*-*" } {
> set_board_info gdb,timeout 60
> }
> }
>
> if you want to try site.exp.  The timeouts should be buried somewhere inside 
> gcc or dejagnu for non-site specific timeouts however.

I know: I've been using something like this for a long time while still
testing gcc on a 250 MHz MIPS R10k running (crawling, actually ;-)
IRIX.  But that's not the point here: without passing the exec name to
gdb, the check_guality test hangs forever, however large one might make
the dejagnu timeout.

> For individual test cases that are pigs that you catch, dg-timeout-factor can 
> be used to slide it up.  On a good host, every test should take 10 seconds or 
> less.  If they take more, I would bump the timeout to be 30x the time it 
> takes on a good host.  This gives us headroom for shared machines, slower 
> machines and all sorts of variations.  The slowest of the targets (m68k 
> testing), aren’t expected to be able to be covered by this slop, they would 
> need to use a more formal mechanism to say they are extra slow.

I'll have to look into this some more when I'll be forced to to more
Solaris/SPARC testing on slow UltraSPARC-T2 systems: there are a couple
of tests that regularly run into the dejagnu timeout, some already
reported, others not yet.

> Upping the timeout of course won’t cure an infinite loop due to gdb bugs.

Indeed.

> One thing that I wonder about is how much swap space one has and if the test 
> suite firing up too many gdb tasks too fast and simply running it out of 
> memory or causing thrashing due to testtcase size.  If you wanted to explore 
> this, look for check_gcc_parallelize=1 in the Makefile, and see if 
> trimming it down helps.  If so, then Jakub might be able to help trim the 
> guilty tests down so they don’t so thrash as much.

I don't think this is an issue: one I'd fixed guality.h to pass argv[0]
to gdb, all guality tests completed just fine, even on my slowest SPARC
machine.

>>> Ok for mainline?
>
> Ok to me, but, if the gdb/guality folks have better comments, I’d defer to 
> them.

Indeed: this part of the question is more about the general quality and
future of the guality tests.  They have been Alexandre's baby mostly,
and he's been largely absent from GCC development lately.

> The command line issue sounds like a gdb bug.  I’d report it and tag in a PR 
> number into the comment where we create the command line.

Depends: one some platforms, it might be possible to determine the exec
name by OS-dependent means (be it /proc, getexecname, or whatever), but
I bet there are targets supported by gdb that have no such facility, and
for their sake (and currently available versions of gdb), just always
passing argv[0] seems the easiest course of action.  As I said,
gfortran.dg/guality/guality.exp already does it, and there were no
issues even on Solaris.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[Patch, fortran] PR 64757 - [5 Regression] ICE in fold_convert_loc, at fold-const.c:2353

[Paul Richard Thomas]

Dear All,

This regression was caused by the patch for PR60357. The fix is
straightforward. Please note however, that I have not checked for
other fallout yet - I have merely addressed the reported failure. I
will check around the reported testcase tomorrow night.

Dominique, thanks for the rapid feedback.

class_to_type_4.f90 is reserved for the patch for PR63205.

Bootstrapped and regtested on x86_64/FC21 - OK for trunk?

Michael, many thanks for a prompt report. Please come back to us with
any more bugs that you find!

Cheers

Paul

2015-01-28  Paul Thomas  

PR fortran/640757
* trans-expr.c
(alloc_scalar_allocatable_for_subcomponent_assignment): If comp
is a class component, get the data pointer.
(gfc_trans_subcomponent_assign): If a class component with a
derived type expression get the data pointer for the assignment
and set the vptr.

2015-01-28  Paul Thomas  

PR fortran/640757
* gfortran.dg/class_to_type_5.f90: New test
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 220083)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -6335,6 +6335,7 @@
  gfc_symbol *sym)
 {
   tree tmp;
+  tree ptr;
   tree size;
   tree size_in_bytes;
   tree lhs_cl_size = NULL_TREE;
@@ -6400,8 +6401,12 @@
   tmp = build_call_expr_loc (input_location,
 builtin_decl_explicit (BUILT_IN_MALLOC),
 1, size_in_bytes);
-  tmp = fold_convert (TREE_TYPE (comp), tmp);
-  gfc_add_modify (block, comp, tmp);
+  if (GFC_CLASS_TYPE_P (TREE_TYPE (comp)))
+   ptr = gfc_class_data_get (comp);
+  else
+   ptr = comp;
+  tmp = fold_convert (TREE_TYPE (ptr), tmp);
+  gfc_add_modify (block, ptr, tmp);
 }

   if (cm->ts.type == BT_CHARACTER && cm->ts.deferred)
@@ -6504,7 +6509,21 @@
   if (expr->symtree && expr->symtree->n.sym->attr.proc_pointer
  && expr->symtree->n.sym->attr.dummy)
se.expr = build_fold_indirect_ref_loc (input_location, se.expr);
-  tmp = build_fold_indirect_ref_loc (input_location, dest);
+
+  if (GFC_CLASS_TYPE_P (TREE_TYPE (dest)) && expr->ts.type == BT_DERIVED)
+   {
+ tree vtab;
+ tmp = gfc_class_data_get (dest);
+ tmp = build_fold_indirect_ref_loc (input_location, tmp);
+ vtab = gfc_get_symbol_decl (gfc_find_vtab (&expr->ts));
+ vtab = gfc_build_addr_expr (NULL_TREE, vtab);
+ gfc_add_modify (&block, gfc_class_vptr_get (dest),
+fold_convert (TREE_TYPE (gfc_class_vptr_get (dest)), vtab));
+   }
+  else
+   tmp = build_fold_indirect_ref_loc (input_location, dest);
+
+
   /* For deferred strings insert a memcpy.  */
   if (cm->ts.type == BT_CHARACTER && cm->ts.deferred)
{
Index: gcc/testsuite/gfortran.dg/class_to_type_5.f03
===
--- gcc/testsuite/gfortran.dg/class_to_type_5.f03   (revision 0)
+++ gcc/testsuite/gfortran.dg/class_to_type_5.f03   (working copy)
@@ -0,0 +1,30 @@
+! { dg-do run }
+!
+! Test the fix for PR64757.
+!
+! Contributed by Michael Lee Rilee  
+!
+  type :: Test
+integer :: i
+  end type
+
+  type :: TestReference
+ class(Test), allocatable :: test
+  end type
+
+  type(TestReference) :: testList
+  type(test) :: x
+
+  testList = TestReference(Test(99))  ! ICE in fold_convert_loc was here
+
+  x = testList%test
+
+  select type (y => testList%test)! Check vptr set
+type is (Test)
+  if (x%i .ne. y%i) call abort
+class default
+  call abort
+  end select
+end
+
+

Re: [PATCH] PR64635 - load libgomp-plugin-host_nonshm shared library with correct suffix

[Mike Stump]

On Jan 28, 2015, at 12:52 PM, Jack Howarth  wrote:
>   The attached patch solves PR64635 for those targets which produce a
> libgomp-plugin-host_nonshm shared library with a suffix other than
> ".so.1”.

Nice...

Re: [PATCH] PR64635 - load libgomp-plugin-host_nonshm shared library with correct suffix

[Jakub Jelinek]

On Wed, Jan 28, 2015 at 03:52:25PM -0500, Jack Howarth wrote:
>The attached patch solves PR64635 for those targets which produce a
> libgomp-plugin-host_nonshm shared library with a suffix other than
> ".so.1". A set of target specific plugin-suffix.h headers are
> installed in libgomp/config/aix, libgomp/config/darwin and
> libgomp/config/hpux as well as a generic plugin-suffix.h in
> libgomp/config/posix. For aix, darwin and hpux, configure.tgt is
> modified to add the new config directory to the config_path search
> path for those targets. Finally the new plugin-suffix.h is included in
> target.c and its target-specific SONAME_SUFFIX macro is used to set
> the plugin's suffix. Bootstrap and libgomp regression tested on
> x86_64-apple-darwin14.
>   Okay for gcc truink?

Please add
PR libgomp/64635
to the ChangeLog entry.
Ok with that change.

Jakub

[PATCH] PR64635 - load libgomp-plugin-host_nonshm shared library with correct suffix

[Jack Howarth]

   The attached patch solves PR64635 for those targets which produce a
libgomp-plugin-host_nonshm shared library with a suffix other than
".so.1". A set of target specific plugin-suffix.h headers are
installed in libgomp/config/aix, libgomp/config/darwin and
libgomp/config/hpux as well as a generic plugin-suffix.h in
libgomp/config/posix. For aix, darwin and hpux, configure.tgt is
modified to add the new config directory to the config_path search
path for those targets. Finally the new plugin-suffix.h is included in
target.c and its target-specific SONAME_SUFFIX macro is used to set
the plugin's suffix. Bootstrap and libgomp regression tested on
x86_64-apple-darwin14.
  Okay for gcc truink?
   Jack


PR64635.patch
Description: Binary data

Re: [testsuite] Run guality tests on Solaris

[Jakub Jelinek]

On Wed, Jan 28, 2015 at 01:42:47PM -0700, Jeff Law wrote:
> >2015-01-28  Rainer Orth  
> >
> > gcc/testsuite:
> > * gcc.dg/guality/guality.h (main): Add argv[0] to
> > guality_gdb_command.
> OK.
> 
> As for what to do with guality, I haven't a clue.  They're dependent on the
> debugger version and perhaps other stuff that I don't recall.
> 
> Perhaps skip them if we find gdb and determine it is "too old"?

We already do that.  I bet the Solaris case is more about the lack
of support to find an executable from its pid (/proc//exe
in Linux).
Guess one can easily try it, run
gdb
(without arguments, or those -nx -nw that guality uses) and type
attach 19355 # pick pid of some process you can debug
in Linux gdb will find the binary etc.

Jakub

Re: [testsuite] Run guality tests on Solaris

[Jeff Law]

On 01/28/15 05:58, Rainer Orth wrote:

Since the testsuite parallelism has been massively increased some time
ago, I'm seing lots of timeouts on slower SPARC hardware (1.2 Ghz
UltraSPARC-T2).  Closer investigation revealed that this happens on
Solaris everywhere, though not so badly that the testsuite 300 second
timeout hits.  The check_guality test in gcc.dg/guality and
g++.dg/guality times out every time.

It turns out that while the gfortran.dg/guality test do run, the gcc.dg
and g++.dg ones don't.  Running check_guality under truss shows that gdb
complains

No symbol table is loaded.  Use the "file" command.

and loops from there, unlike gfortran.dg where the command name is
passed to gdb.  No idea why this doesn't happen on Linux, but the
problem is easily cured by adding the command name (which is the actual
executable gdb tries to attach to) to the gdb command line.

This makes the guality tests run sucessfully on Solaris, even on the
slow T2 box.

However, the guality tests show dozens or even hundreds of FAILs and/or
XPASSes, adding insane amounts of noise to the testsuite results, which
nobody seems to be looking into.  So I wonder what the best course of
action is here: one might consider running them only when a
GCC_TEST_RUN_GUALITY environment variable is set, but skip them by
default until someone acutally interested in improving results here
shows up.

Thoughts?

Anyway, here's the patch I've used.

Ok for mainline?

Rainer


2015-01-28  Rainer Orth  

gcc/testsuite:
* gcc.dg/guality/guality.h (main): Add argv[0] to
guality_gdb_command.

OK.

As for what to do with guality, I haven't a clue.  They're dependent on 
the debugger version and perhaps other stuff that I don't recall.


Perhaps skip them if we find gdb and determine it is "too old"?

jeff

Re: [RFC PATCH] Avoid most of the BUILT_IN_*_CHKP enum values

[Jeff Law]

On 01/28/15 12:24, Richard Biener wrote:

It should be the STABS and/or affected target maintainers job to get

this fixed

for them.


Richard,

Even if the STABS continuations are fixed, it requires fixing it in
previous releases of GCC, deploying the solution and achieving
adoption.  The current problem prevents linking of stage 1 cc1,
cc1plus, etc.


I am aware of this.  But if GCC 5 were fixed stabs-wise then stage1 could be 
built with XLC or earlier GCC with -g0, no?

But if there's a problem, then you don't have debug symbols.

We've been through this before.  Really the way forward is to cut down 
the size of those enums.


Jeff

Re: Relat TLS model merging in lto-symtab

[Jakub Jelinek]

On Wed, Jan 28, 2015 at 08:59:07PM +0100, Jan Hubicka wrote:
> --- lto-symtab.c  (revision 220212)
> +++ lto-symtab.c  (working copy)
> @@ -158,11 +158,44 @@ lto_varpool_replace_node (varpool_node *
>  
>if (vnode->tls_model != prevailing_node->tls_model)
>  {
> -  error_at (DECL_SOURCE_LOCATION (vnode->decl),
> - "%qD is defined as %s", vnode->decl, tls_model_names 
> [vnode->tls_model]);
> -  inform (DECL_SOURCE_LOCATION (prevailing_node->decl),
> -   "previously defined here as %s",
> -   tls_model_names [prevailing_node->tls_model]);
> +  bool error = false;
> +
> +  /* Non-TLS and TLS never mix together.  Also emulated model is not
> +  compatible with anything else.  */
> +  if (prevailing_node->tls_model == TLS_MODEL_NONE
> +   || prevailing_node->tls_model == TLS_MODEL_EMULATED
> +   || vnode->tls_model == TLS_MODEL_NONE
> +   || vnode->tls_model == TLS_MODEL_EMULATED)
> + error = true;
> +  /* Linked is silently supporting transitions

Linker instead of Linked.

> +  GD -> IE, GD -> LE, LD -> LE, IE -> LE, LD -> IE.

Looking at linker, there is actually no LD -> IE transition, so
linker if there were LD and IE accesses to the same TLS var and no
LE accesses, then the linker would probably keep LD and IE accesses
untouched.  That said, this is before the RTL is generated, and IE is
cheaper, so I think it is fine to also transform LD -> IE in the compiler.

I think you could do similarly a GD -> LD transition, if anything is
accessed using LD model, then by definition it has to be defined in the
current shared library (or executable), not using a definition from
somewhere else, and if something else accesses it globally, it is fine to
access it locally too.  Just make it clear what transitions are done
by the linker and what you do on top of that.
Though, once you add the LD -> IE and GD -> LD transitions the linker
doesn't do, you can just do
prevailing_node->tls_model = MAX (prevailing_node->tls_model, vnode->tls_model);
after checking the NONE/EMULATED cases.

> +  Do the same transitions and error out on others.  */
> +  else if ((prevailing_node->tls_model == TLS_MODEL_REAL

I'd use TLS_MODEL_GLOBAL_DYNAMIC instead of TLS_MODEL_REAL, it is the
same value, but the former makes it more obvious and will better match
the comment.

> + || prevailing_node->tls_model == TLS_MODEL_LOCAL_DYNAMIC)
> +&& (vnode->tls_model == TLS_MODEL_INITIAL_EXEC
> +|| vnode->tls_model == TLS_MODEL_LOCAL_EXEC))
> + prevailing_node->tls_model = vnode->tls_model;
> +  else if ((vnode->tls_model == TLS_MODEL_REAL
> + || vnode->tls_model == TLS_MODEL_LOCAL_DYNAMIC)
> +&& (prevailing_node->tls_model == TLS_MODEL_INITIAL_EXEC
> +|| prevailing_node->tls_model == TLS_MODEL_LOCAL_EXEC))
> + ;
> +  else if (prevailing_node->tls_model == TLS_MODEL_INITIAL_EXEC
> +&& vnode->tls_model == TLS_MODEL_LOCAL_EXEC)
> + prevailing_node->tls_model = vnode->tls_model;
> +  else if (vnode->tls_model == TLS_MODEL_INITIAL_EXEC
> +&& prevailing_node->tls_model == TLS_MODEL_LOCAL_EXEC)
> + ;
> +  else
> + error = true;
> +  if (error)
> + {
> +   error_at (DECL_SOURCE_LOCATION (vnode->decl),
> + "%qD is defined with tls model %s", vnode->decl, 
> tls_model_names [vnode->tls_model]);
> +   inform (DECL_SOURCE_LOCATION (prevailing_node->decl),
> +   "previously defined here as %s",
> +   tls_model_names [prevailing_node->tls_model]);
> + }
>  }
>/* Finally remove the replaced node.  */
>vnode->remove ();

Jakub

Re: [RFC PATCH] Avoid most of the BUILT_IN_*_CHKP enum values

[Jeff Law]

On 01/28/15 12:57, Jakub Jelinek wrote:

On Wed, Jan 28, 2015 at 12:51:24PM -0700, Jeff Law wrote:

On 01/28/15 12:24, Richard Biener wrote:

It should be the STABS and/or affected target maintainers job to get

this fixed

for them.


Richard,

Even if the STABS continuations are fixed, it requires fixing it in
previous releases of GCC, deploying the solution and achieving
adoption.  The current problem prevents linking of stage 1 cc1,
cc1plus, etc.


I am aware of this.  But if GCC 5 were fixed stabs-wise then stage1 could be 
built with XLC or earlier GCC with -g0, no?

But if there's a problem, then you don't have debug symbols.

We've been through this before.  Really the way forward is to cut down the
size of those enums.


I'd say cut down the size of those enums and really fix the stabs issue, so
that we don't run into it again next release with another enum or large
struct etc. or users don't run into it elsewhere.
64K for textual representation of the enumerators and their values is a
severe limitation.
Agreed.  David is already working on the stabs side of this which is 
really more a question of how do we interface with the AIX tools 
continuation support.


Jeff

[PATCH] Fix x86 #pragma GCC target and target attribute handling (PR target/61925)

[Jakub Jelinek]

Hi!

This patch rewrites the target pragma and target attribute handling in the
i386 backend, so that outside of functions global_options and target globals
reflect the currently active #pragma GCC target (if none active, obviously
the default options) and inside of functions (in between set_cfun to that
function and set_cfun to another function or NULL) the target state of the
function.

Without this patch, that state often was wherever last set_cfun left it
(consider e.g. function with target attribute inside of #pragma GCC target
region), and furthermore #pragma GCC target without any function definition
before #pragma GCC pop_options confused it altogether, plus there has been
confusion between when should be the default options active and when should
be the currently active #pragma GCC target activated.

The last hunk in i386.c also attempts to save some compile time cycles, I
think it is pointless to add currently active #pragma GCC target as
attributes to all the target builtins that are activated in the call,
we certainly don't do that e.g. for target attribute.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2015-01-28  Jakub Jelinek  

PR target/61925
* config/i386/i386.c (ix86_reset_to_default_globals): Removed.
(ix86_reset_previous_fndecl): Restore it here, unconditionally.
(ix86_set_current_function): Rewritten.
(ix86_add_new_builtins): Temporarily clear current_target_pragma
when creating builtin fndecls.

* gcc.target/i386/pr61925-1.c: New test.
* gcc.target/i386/pr61925-2.c: New test.
* gcc.target/i386/pr61925-3.c: New test.

--- gcc/config/i386/i386.c.jj   2015-01-26 22:27:20.0 +0100
+++ gcc/config/i386/i386.c  2015-01-28 14:41:03.008727087 +0100
@@ -5076,35 +5076,20 @@ ix86_can_inline_p (tree caller, tree cal
 /* Remember the last target of ix86_set_current_function.  */
 static GTY(()) tree ix86_previous_fndecl;
 
-/* Set target globals to default.  */
+/* Set targets globals to the default (or current #pragma GCC target
+   if active).  Invalidate ix86_previous_fndecl cache.  */
 
-static void
-ix86_reset_to_default_globals (void)
-{
-  tree old_tree = (ix86_previous_fndecl
-  ? DECL_FUNCTION_SPECIFIC_TARGET (ix86_previous_fndecl)
-  : NULL_TREE);
-
-  if (old_tree)
-{
-  tree 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 ();
-}
-}
-
-/* Invalidate ix86_previous_fndecl cache.  */
 void
 ix86_reset_previous_fndecl (void)
 {
-  ix86_reset_to_default_globals ();
+  tree 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 ();
   ix86_previous_fndecl = NULL_TREE;
 }
 
@@ -5117,34 +5102,39 @@ ix86_set_current_function (tree fndecl)
   /* Only change the context if the function changes.  This hook is called
  several times in the course of compiling a function, and we don't want to
  slow things down too much or call target_reinit when it isn't safe.  */
-  if (fndecl && fndecl != ix86_previous_fndecl)
-{
-  tree old_tree = (ix86_previous_fndecl
-  ? DECL_FUNCTION_SPECIFIC_TARGET (ix86_previous_fndecl)
-  : NULL_TREE);
+  if (fndecl == ix86_previous_fndecl)
+return;
 
-  tree new_tree = (fndecl
-  ? DECL_FUNCTION_SPECIFIC_TARGET (fndecl)
-  : NULL_TREE);
+  tree old_tree;
+  if (ix86_previous_fndecl == NULL_TREE)
+old_tree = target_option_current_node;
+  else if (DECL_FUNCTION_SPECIFIC_TARGET (ix86_previous_fndecl))
+old_tree = DECL_FUNCTION_SPECIFIC_TARGET (ix86_previous_fndecl);
+  else
+old_tree = target_option_default_node;
 
-  if (old_tree == new_tree)
-   ;
+  if (fndecl == NULL_TREE)
+{
+  if (old_tree != target_option_current_node)
+   ix86_reset_previous_fndecl ();
+  return;
+}
 
-  else if (new_tree && new_tree != target_option_default_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
-   TREE_TARGET_GLOB

Re: [PATCH] Fix dwarf2out wide-int issues (PR other/63504)

[Jason Merrill]

OK.

Jason

Relat TLS model merging in lto-symtab

[Jan Hubicka]

Hi,
newer Firefox trees fails to build because jsmalloc contain variable that is
declared as tls-initial-exec in one unit but used as tls-global-dynamic
in others.

As discussed with Jakub on IRC, the linker supports some model transitions,
so we should do the same in symtab.c too.

Bootstrapped/regtested x86_64-linux, tested on firefox, comitted.

Honza

* lto-symtab.c (lto_varpool_replace_node): Merge TLS models.
Index: lto-symtab.c
===
--- lto-symtab.c(revision 220212)
+++ lto-symtab.c(working copy)
@@ -158,11 +158,44 @@ lto_varpool_replace_node (varpool_node *
 
   if (vnode->tls_model != prevailing_node->tls_model)
 {
-  error_at (DECL_SOURCE_LOCATION (vnode->decl),
-   "%qD is defined as %s", vnode->decl, tls_model_names 
[vnode->tls_model]);
-  inform (DECL_SOURCE_LOCATION (prevailing_node->decl),
- "previously defined here as %s",
- tls_model_names [prevailing_node->tls_model]);
+  bool error = false;
+
+  /* Non-TLS and TLS never mix together.  Also emulated model is not
+compatible with anything else.  */
+  if (prevailing_node->tls_model == TLS_MODEL_NONE
+ || prevailing_node->tls_model == TLS_MODEL_EMULATED
+ || vnode->tls_model == TLS_MODEL_NONE
+ || vnode->tls_model == TLS_MODEL_EMULATED)
+   error = true;
+  /* Linked is silently supporting transitions
+GD -> IE, GD -> LE, LD -> LE, IE -> LE, LD -> IE.
+Do the same transitions and error out on others.  */
+  else if ((prevailing_node->tls_model == TLS_MODEL_REAL
+   || prevailing_node->tls_model == TLS_MODEL_LOCAL_DYNAMIC)
+  && (vnode->tls_model == TLS_MODEL_INITIAL_EXEC
+  || vnode->tls_model == TLS_MODEL_LOCAL_EXEC))
+   prevailing_node->tls_model = vnode->tls_model;
+  else if ((vnode->tls_model == TLS_MODEL_REAL
+   || vnode->tls_model == TLS_MODEL_LOCAL_DYNAMIC)
+  && (prevailing_node->tls_model == TLS_MODEL_INITIAL_EXEC
+  || prevailing_node->tls_model == TLS_MODEL_LOCAL_EXEC))
+   ;
+  else if (prevailing_node->tls_model == TLS_MODEL_INITIAL_EXEC
+  && vnode->tls_model == TLS_MODEL_LOCAL_EXEC)
+   prevailing_node->tls_model = vnode->tls_model;
+  else if (vnode->tls_model == TLS_MODEL_INITIAL_EXEC
+  && prevailing_node->tls_model == TLS_MODEL_LOCAL_EXEC)
+   ;
+  else
+   error = true;
+  if (error)
+   {
+ error_at (DECL_SOURCE_LOCATION (vnode->decl),
+   "%qD is defined with tls model %s", vnode->decl, 
tls_model_names [vnode->tls_model]);
+ inform (DECL_SOURCE_LOCATION (prevailing_node->decl),
+ "previously defined here as %s",
+ tls_model_names [prevailing_node->tls_model]);
+   }
 }
   /* Finally remove the replaced node.  */
   vnode->remove ();

Re: [RFC PATCH] Avoid most of the BUILT_IN_*_CHKP enum values

[Jakub Jelinek]

On Wed, Jan 28, 2015 at 12:51:24PM -0700, Jeff Law wrote:
> On 01/28/15 12:24, Richard Biener wrote:
> >>>It should be the STABS and/or affected target maintainers job to get
> >>this fixed
> >>>for them.
> >>
> >>Richard,
> >>
> >>Even if the STABS continuations are fixed, it requires fixing it in
> >>previous releases of GCC, deploying the solution and achieving
> >>adoption.  The current problem prevents linking of stage 1 cc1,
> >>cc1plus, etc.
> >
> >I am aware of this.  But if GCC 5 were fixed stabs-wise then stage1 could be 
> >built with XLC or earlier GCC with -g0, no?
> But if there's a problem, then you don't have debug symbols.
> 
> We've been through this before.  Really the way forward is to cut down the
> size of those enums.

I'd say cut down the size of those enums and really fix the stabs issue, so
that we don't run into it again next release with another enum or large
struct etc. or users don't run into it elsewhere.
64K for textual representation of the enumerators and their values is a
severe limitation.

Jakub

Fix tls model dumping

[Jan Hubicka]

Hi,
this patch fixes dumping of tls models. tls-real is not really a model,
just equivalent of tls-global-dynamic.

Comitted as obvious.

Honza

Index: ChangeLog
===
--- ChangeLog   (revision 220212)
+++ ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+2015-01-28  Jan Hubicka  
+
+   * varpool.c (tls_model_names): Fix names.
+   (varpool_node::dump): Dump tls- prefix for tls models.
+
 2015-01-28  Thomas Schwinge  
Bernd Schmidt  
Nathan Sidwell  
Index: varpool.c
===
--- varpool.c   (revision 220212)
+++ varpool.c   (working copy)
@@ -58,9 +58,9 @@ along with GCC; see the file COPYING3.
 #include "context.h"
 #include "omp-low.h"
 
-const char * const tls_model_names[]={"none", "tls-emulated", "tls-real",
- "tls-global-dynamic", "tls-local-dynamic",
- "tls-initial-exec", "tls-local-exec"};
+const char * const tls_model_names[]={"none", "emulated",
+ "global-dynamic", "local-dynamic",
+ "initial-exec", "local-exec"};
 
 /* List of hooks triggered on varpool_node events.  */
 struct varpool_node_hook_list {
@@ -251,7 +251,7 @@ varpool_node::dump (FILE *f)
   if (writeonly)
 fprintf (f, " write-only");
   if (tls_model)
-fprintf (f, " %s", tls_model_names [tls_model]);
+fprintf (f, " tls-%s", tls_model_names [tls_model]);
   fprintf (f, "\n");
 }
 

[PATCH] Fix dwarf2out wide-int issues (PR other/63504)

[Jakub Jelinek]

Hi!

Despite the cleared_ part, the
attr.dw_attr_val.v.val_wide = ggc_cleared_alloc ();
*attr.dw_attr_val.v.val_wide = w;
etc. sequences put in there uninitialized bits (array elements beyond
get_len (), and perhaps structure padding), as it constructs a temporary
and then assigns it to *val_wide.  For comparisons we already use
operator== on the wide_ints, so we are fine, but for hashing we were hashing
everything, which was diagnosed by valgrind.

Fixed by only checksumming get_full_len hwis from get_val () returned array.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2015-01-28  Jakub Jelinek  

PR other/63504
* dwarf2out.c (add_AT_wide, mem_loc_descriptor, loc_descriptor):
Use ggc_alloc instead of ggc_cleared_alloc.
(attr_checksum, attr_checksum_ordered, hash_loc_operands): Checksum
only get_full_len HOST_WIDE_INTs from get_val () array rather than
all bits in *val_wide.

--- gcc/dwarf2out.c.jj  2015-01-28 09:34:55.500615372 +0100
+++ gcc/dwarf2out.c 2015-01-28 16:46:17.174789598 +0100
@@ -3886,7 +3886,7 @@ add_AT_wide (dw_die_ref die, enum dwarf_
 
   attr.dw_attr = attr_kind;
   attr.dw_attr_val.val_class = dw_val_class_wide_int;
-  attr.dw_attr_val.v.val_wide = ggc_cleared_alloc ();
+  attr.dw_attr_val.v.val_wide = ggc_alloc ();
   *attr.dw_attr_val.v.val_wide = w;
   add_dwarf_attr (die, &attr);
 }
@@ -5726,7 +5726,9 @@ attr_checksum (dw_attr_ref at, struct md
   CHECKSUM (at->dw_attr_val.v.val_double);
   break;
 case dw_val_class_wide_int:
-  CHECKSUM (*at->dw_attr_val.v.val_wide);
+  CHECKSUM_BLOCK (at->dw_attr_val.v.val_wide->get_val (),
+ get_full_len (*at->dw_attr_val.v.val_wide)
+ * HOST_BITS_PER_WIDE_INT / HOST_BITS_PER_CHAR);
   break;
 case dw_val_class_vec:
   CHECKSUM_BLOCK (at->dw_attr_val.v.val_vec.array,
@@ -6009,8 +6011,11 @@ attr_checksum_ordered (enum dwarf_tag ta
 
 case dw_val_class_wide_int:
   CHECKSUM_ULEB128 (DW_FORM_block);
-  CHECKSUM_ULEB128 (sizeof (*at->dw_attr_val.v.val_wide));
-  CHECKSUM (*at->dw_attr_val.v.val_wide);
+  CHECKSUM_ULEB128 (get_full_len (*at->dw_attr_val.v.val_wide)
+   * HOST_BITS_PER_WIDE_INT / BITS_PER_UNIT);
+  CHECKSUM_BLOCK (at->dw_attr_val.v.val_wide->get_val (),
+ get_full_len (*at->dw_attr_val.v.val_wide)
+ * HOST_BITS_PER_WIDE_INT / HOST_BITS_PER_CHAR);
   break;
 
 case dw_val_class_vec:
@@ -13160,7 +13165,7 @@ mem_loc_descriptor (rtx rtl, machine_mod
  mem_loc_result->dw_loc_oprnd1.v.val_die_ref.external = 0;
  mem_loc_result->dw_loc_oprnd2.val_class
= dw_val_class_wide_int;
- mem_loc_result->dw_loc_oprnd2.v.val_wide = 
ggc_cleared_alloc ();
+ mem_loc_result->dw_loc_oprnd2.v.val_wide = ggc_alloc ();
  *mem_loc_result->dw_loc_oprnd2.v.val_wide = std::make_pair (rtl, 
mode);
}
   break;
@@ -13663,7 +13668,7 @@ loc_descriptor (rtx rtl, machine_mode mo
  loc_result = new_loc_descr (DW_OP_implicit_value,
  GET_MODE_SIZE (mode), 0);
  loc_result->dw_loc_oprnd2.val_class = dw_val_class_wide_int;
- loc_result->dw_loc_oprnd2.v.val_wide = ggc_cleared_alloc ();
+ loc_result->dw_loc_oprnd2.v.val_wide = ggc_alloc ();
  *loc_result->dw_loc_oprnd2.v.val_wide = std::make_pair (rtl, mode);
}
   break;
@@ -24022,7 +24027,9 @@ hash_loc_operands (dw_loc_descr_ref loc,
  hstate.add_object (val2->v.val_double.high);
  break;
case dw_val_class_wide_int:
- hstate.add_object (*val2->v.val_wide);
+ hstate.add (val2->v.val_wide->get_val (),
+ get_full_len (*val2->v.val_wide)
+ * HOST_BITS_PER_WIDE_INT / HOST_BITS_PER_CHAR);
  break;
case dw_val_class_addr: 
  inchash::add_rtx (val2->v.val_addr, hstate);
@@ -24113,7 +24120,9 @@ hash_loc_operands (dw_loc_descr_ref loc,
hstate.add_object (val2->v.val_double.high);
break;
  case dw_val_class_wide_int:
-   hstate.add_object (*val2->v.val_wide);
+   hstate.add (val2->v.val_wide->get_val (),
+   get_full_len (*val2->v.val_wide)
+   * HOST_BITS_PER_WIDE_INT / HOST_BITS_PER_CHAR);
break;
  default:
gcc_unreachable ();

Jakub

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[H.J. Lu]

On Wed, Jan 28, 2015 at 11:44 AM, Cary Coutant  wrote:
This patch makes claim_file_handler to call release_input_file after it
finishes processing input file.  OK for trunk?
>>>
>>> OK.  How did you test this?
>>
>> I did normal bootstrap and "make check" on Linux/x86-64.
>> I also run ld.bfd and ld.gold by hand to verify that release_input_file
>> is called.
>
> But release_input_file is only supposed to be used after calling
> get_input_file from the all_symbols_read handler. It's not needed in
> the claim_file handler. If gold isn't freeing the file descriptor
> properly in that case, it's a bug entirely within gold (I think). I'm
> looking at it.

release_input_file should be allowed in the claim_file handler
since GCC plugin doesn't use get_input_file at all.


-- 
H.J.

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[Cary Coutant]

>>>This patch makes claim_file_handler to call release_input_file after it
>>>finishes processing input file.  OK for trunk?
>>
>> OK.  How did you test this?
>
> I did normal bootstrap and "make check" on Linux/x86-64.
> I also run ld.bfd and ld.gold by hand to verify that release_input_file
> is called.

But release_input_file is only supposed to be used after calling
get_input_file from the all_symbols_read handler. It's not needed in
the claim_file handler. If gold isn't freeing the file descriptor
properly in that case, it's a bug entirely within gold (I think). I'm
looking at it.

-cary

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[H.J. Lu]

On Wed, Jan 28, 2015 at 11:19 AM, Richard Biener
 wrote:
> On January 28, 2015 7:12:43 PM CET, "H.J. Lu"  wrote:
>>Hi,
>>
>>This patch makes claim_file_handler to call release_input_file after it
>>finishes processing input file.  OK for trunk?
>
> OK.  How did you test this?

I did normal bootstrap and "make check" on Linux/x86-64.
I also run ld.bfd and ld.gold by hand to verify that release_input_file
is called.

H.J.
> Thanks,
> Richard.
>
>
>>Thanks.
>>
>>
>>H.J.
>>---
>>diff --git a/lto-plugin/ChangeLog b/lto-plugin/ChangeLog
>>index e8ec05b..c0eae24 100644
>>--- a/lto-plugin/ChangeLog
>>+++ b/lto-plugin/ChangeLog
>>@@ -1,3 +1,10 @@
>>+2015-01-28  H.J. Lu  
>>+
>>+  PR lto/64837
>>+  * lto-plugin.c (release_input_file): New.
>>+  (claim_file_handler): Call release_input_file.
>>+  (onload): Set release_input_file.
>>+
>> 2014-12-09  Ilya Verbin  
>>
>>   * lto-plugin.c (offload_files, num_offload_files): New static
>>variables.
>>diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto-plugin.c
>>index 8d957402..8e0a657 100644
>>--- a/lto-plugin/lto-plugin.c
>>+++ b/lto-plugin/lto-plugin.c
>>@@ -145,6 +145,7 @@ static ld_plugin_register_all_symbols_read
>>register_all_symbols_read;
>> static ld_plugin_get_symbols get_symbols, get_symbols_v2;
>> static ld_plugin_register_cleanup register_cleanup;
>> static ld_plugin_add_input_file add_input_file;
>>+static ld_plugin_release_input_file release_input_file;
>> static ld_plugin_add_input_library add_input_library;
>> static ld_plugin_message message;
>> static ld_plugin_add_symbols add_symbols;
>>@@ -1006,6 +1007,8 @@ claim_file_handler (const struct
>>ld_plugin_input_file *file, int *claimed)
>>   if (obj.objfile)
>> simple_object_release_read (obj.objfile);
>>
>>+  release_input_file (file);
>>+
>>   return LDPS_OK;
>> }
>>
>>@@ -1091,6 +1094,9 @@ onload (struct ld_plugin_tv *tv)
>>   case LDPT_ADD_INPUT_FILE:
>> add_input_file = p->tv_u.tv_add_input_file;
>> break;
>>+  case LDPT_RELEASE_INPUT_FILE:
>>+release_input_file = p->tv_u.tv_release_input_file;
>>+break;
>>   case LDPT_ADD_INPUT_LIBRARY:
>> add_input_library = p->tv_u.tv_add_input_library;
>> break;
>
>

Re: [fixincludes] Fix signbit on Solaris

[Bruce Korb]

On 01/28/15 10:15, Bruce Korb wrote:

On 01/28/15 10:13, Bruce Korb wrote:

Hi Rainer,

Sorry for the long delay.  Anyway:

On 01/28/15 06:12, Rainer Orth wrote:

* In test_text, I had to backslash-escape the trailing \, otherwise they
   were eaten up.  Whether or not I do this makes no difference for the
   generated fixincl.x, but only with the escaping does make check pass.


Right.  It likely gets massaged by a shell script somewhere.


Line 88 of check.tpl:


Oh, line 59 too:
  59 cat >> [=(. sfile)=] <<_HACK_EOF_
  60
  61
  62 #if defined( [=(. HACK)=]_CHECK_[=(for-index)=] )
  63 [=test_text=]
  64 #endif  /* [=(. HACK)=]_CHECK_[=(for-index)=] */
  65 _HACK_EOF_


I kicked off a test.  It is not as simple as quoting the sentinel.
I'll dig into it when I can.


features.h /u/gnu/proj/gcc-svn-bld/fixincludes/tests/base/features.h differ: 
char 318, line 13
*** features.h  Wed Jan 28 11:26:38 2015
--- /u/gnu/proj/gcc-svn-bld/fixincludes/tests/base/features.h   Sat Dec  6 
06:10:29 2014
***
*** 10,17 


  #if defined( GLIBC_C99_INLINE_1_CHECK )
! #if __GNUC_PREREQ (2, 7) && defined __OPTIMIZE__ \
! && !defined __OPTIMIZE_SIZE__ && !defined __NO_INLINE__ && (defined 
__extern_inline || defined __GNUC_GNU_INLINE__)
  # define __USE_EXTERN_INLINES 1
  #endif
  #endif  /* GLIBC_C99_INLINE_1_CHECK */
--- 10,16 


  #if defined( GLIBC_C99_INLINE_1_CHECK )
! #if __GNUC_PREREQ (2, 7) && defined __OPTIMIZE__ && !defined __OPTIMIZE_SIZE__ 
&& !defined __NO_INLINE__
  # define __USE_EXTERN_INLINES 1
  #endif
  #endif  /* GLIBC_C99_INLINE_1_CHECK */


This should be fixed by changing the "base" version.

Re: [RFC PATCH] Avoid most of the BUILT_IN_*_CHKP enum values

[Richard Biener]

On January 28, 2015 4:23:05 PM CET, David Edelsohn  wrote:
>On Wed, Jan 28, 2015 at 6:45 AM, Richard Biener
> wrote:
>> On Wed, Jan 28, 2015 at 12:24 PM, Jakub Jelinek 
>wrote:
>>> On Wed, Jan 28, 2015 at 12:15:40PM +0100, Richard Biener wrote:
 > Note, patch successfully bootstrapped/regtested on x86_64-linux
>and
 > i686-linux, and David said that on AIX it passed stage1 cc1
>linking.
 >
 > Ok for trunk?

 Is the stabs issue meanwhile fixed at least on trunk?
>>>
>>> AFAIK no.  The generic stabs code has support for either infinite
>length
>>> records, or records split using continuations (targets can choose
>which
>>> character is continuation character).  But AIX doesn't support
>infinite
>>> length records and for some reason doesn't support continuations
>either.
>>>
>>> IMHO it should just enable support for continuations, even if there
>was a
>>> reason not to enable them 15 years ago on AIX, I bet the debuggers
>changed a
>>> little bit even on that platform during that time.
>>>
>>> The other option is to add generic support for just throwing stabs
>records
>>> on the floor if they are too large and target doesn't want to
>support
>>> continuations (would be for AIX only), but in that case the target
>at least
>>> would need to hint what means too large.
>>
>> Yes, dropping them on the floor would be the solution.  Not sure what
>STABS
>> defines as maximum record length on AIX.
>>
>> It should be the STABS and/or affected target maintainers job to get
>this fixed
>> for them.
>
>Richard,
>
>Even if the STABS continuations are fixed, it requires fixing it in
>previous releases of GCC, deploying the solution and achieving
>adoption.  The current problem prevents linking of stage 1 cc1,
>cc1plus, etc.

I am aware of this.  But if GCC 5 were fixed stabs-wise then stage1 could be 
built with XLC or earlier GCC with -g0, no?

>I am working through the STABS continuation issues on AIX, but it does
>not solve the problem of the GCC 5 release functioning on AIX.

Well, the earlier we fix it the better.

Richard.

>Thanks, David

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[Richard Biener]

On January 28, 2015 7:12:43 PM CET, "H.J. Lu"  wrote:
>Hi,
>
>This patch makes claim_file_handler to call release_input_file after it
>finishes processing input file.  OK for trunk?

OK.  How did you test this?

Thanks,
Richard.


>Thanks.
>
>
>H.J.
>---
>diff --git a/lto-plugin/ChangeLog b/lto-plugin/ChangeLog
>index e8ec05b..c0eae24 100644
>--- a/lto-plugin/ChangeLog
>+++ b/lto-plugin/ChangeLog
>@@ -1,3 +1,10 @@
>+2015-01-28  H.J. Lu  
>+
>+  PR lto/64837
>+  * lto-plugin.c (release_input_file): New.
>+  (claim_file_handler): Call release_input_file.
>+  (onload): Set release_input_file.
>+
> 2014-12-09  Ilya Verbin  
> 
>   * lto-plugin.c (offload_files, num_offload_files): New static
>variables.
>diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto-plugin.c
>index 8d957402..8e0a657 100644
>--- a/lto-plugin/lto-plugin.c
>+++ b/lto-plugin/lto-plugin.c
>@@ -145,6 +145,7 @@ static ld_plugin_register_all_symbols_read
>register_all_symbols_read;
> static ld_plugin_get_symbols get_symbols, get_symbols_v2;
> static ld_plugin_register_cleanup register_cleanup;
> static ld_plugin_add_input_file add_input_file;
>+static ld_plugin_release_input_file release_input_file;
> static ld_plugin_add_input_library add_input_library;
> static ld_plugin_message message;
> static ld_plugin_add_symbols add_symbols;
>@@ -1006,6 +1007,8 @@ claim_file_handler (const struct
>ld_plugin_input_file *file, int *claimed)
>   if (obj.objfile)
> simple_object_release_read (obj.objfile);
> 
>+  release_input_file (file);
>+
>   return LDPS_OK;
> }
> 
>@@ -1091,6 +1094,9 @@ onload (struct ld_plugin_tv *tv)
>   case LDPT_ADD_INPUT_FILE:
> add_input_file = p->tv_u.tv_add_input_file;
> break;
>+  case LDPT_RELEASE_INPUT_FILE:
>+release_input_file = p->tv_u.tv_release_input_file;
>+break;
>   case LDPT_ADD_INPUT_LIBRARY:
> add_input_library = p->tv_u.tv_add_input_library;
> break;

RE: [Patch][wwwdocs]Deprecate the ARM TPCS related options in gcc 5.0

[Gerald Pfeifer]

On Wednesday 2015-01-28 09:57, Terry Guo wrote:
> Thanks Gerald. Patch is updated. Is this one OK?

This good to me.  (Perhaps say "which were only applicable", since
there are gone now?)

Gerald

Re: [PATCH][AArch64] Testcase fix for __ATOMIC_CONSUME

[Mike Stump]

On Jan 28, 2015, at 9:51 AM, Marcus Shawcroft  
wrote:
> Going forward we can [ … ] xfail the test case pending a proper solution to
> 59448 ?

> Mike do you prefer one of the other two approaches ?

I’d xfail the test case and mark with the fix consume PR.  If we don’t have an 
unambiguous, fix consume PR, I’d file that.  It should be listed as failing on 
aarch, and the fix for that PR should then make the aarch test case pass.  This 
way no one can run off with the PR and do anything else with it.

Re: [debug-early] C++ clones and limbo DIEs

[Jason Merrill]

On 01/28/2015 01:29 PM, Aldy Hernandez wrote:

+  /* It is rather unfortunate that Cilk creates trees this late
+ (during gimplification).  However, until this gets fixed,
+ specially handle emitting DWARF for this new function and
+ immediately clean up the limbo_die_list where the new function's
+ DIE will inevitably end up.  */


Why does it go on limbo_die_list at all?


I noticed dwarf2out's gen_member_die() disallows generation of clones earlier, 
by design:

 /* Don't include clones in the member list.  */
 if (DECL_ABSTRACT_ORIGIN (member))
   continue;

I played around trying to disable this "feature", but my approach ran into 
various walls, and I decided instead to attack it from the front-end side. The attached 
patch generates early DIEs for the C++ clones in the C++ parser. I'd be (un)happy to 
revisit the dwarf2out approach if it's deemed more appropriate.


I'd still like to understand why disabling this doesn't work; I don't 
like the special handling of clones in the front end.


Jason

Re: [debug-early] C++ clones and limbo DIEs

[Aldy Hernandez]

On 01/16/2015 02:55 AM, Richard Biener wrote:

On Fri, Jan 16, 2015 at 4:11 AM, Jason Merrill  wrote:

On 01/15/2015 09:58 PM, Aldy Hernandez wrote:



I hoped we wouldn't need the limbo list at all ... that is, parent DIEs
are always present when we create children.  I think that should
work in principle if the frontends would create DIEs while parsing.


By the way, don't think I ignored this suggestion.  I played around with 
this approach for the C++ front-end, and gave up after having to keep 
track of a few too many things to get the parenthood right.  It's 
totally doable; it was just easier to flush out the limbo DIE list as 
with my current patch.  Ok, call me lazy :).



Note that dwarf2out forces parent DIE creation in some cases
but not in some others - it would be interesting to sort out which
parent DIEs it thinks it cannot create when we create the DIE
for a sibling.  Maybe it's just poor ordering of early_global_decl
calls?


In my current patch, I added an ICE to make sure we're not creating 
limbo destined DIEs past early dwarf dumping.  The only exception to 
this (temporarily) is that the ltrans stage is adding things late, but 
that's only because we're not streaming dwarf as the ultimate plan is. 
I've documented all this.


Aldy

Re: [libobjc] Fix failures on AIX (PR libobjc/63765)

[Mike Stump]

On Jan 28, 2015, at 2:27 AM, Rainer Orth  wrote:
> There are two ways to fix this:
> 
> * Remove the definition of _XOPEN_SOURCE completely.  This is slightly
>  more risky, but more future-proof since defining features test macros
>  has been an endless source of trouble in the past.

I think I prefer this one...

But, as I say that, I read:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4372

and there is no hint what host caused him to put the change in, in the first 
place.  :-(  Alexandre, do you recall what host needed the _XOPEN_SOURCE in 
libobjc for pthread_mutexattr_settype?

Anyway, going forward, I would say that any target that needs a specific value 
should just put in the #ifdef arch #define XPOPEN val #end, if they need it.

Re: [debug-early] C++ clones and limbo DIEs

[Aldy Hernandez]

And now with the actual patch ;-).
* c-family/cilk.c (create_cilk_wrapper_body): Emit debug
information for wrappers.
* cp/decl2.c (emit_debug_for_namespace): Add FIXME note for
templates.
* cp/optimize.c (maybe_clone_body): Emit early debug for clones.
* dbxout.c (dbx_debug_hooks): Add early_finish field.
* sdbout.c (sdb_debug_hooks): Same.
* vmsdbgout.c (vmsdbg_debug_hooks): Same.
* debug.h (gcc_debug_hooks): Same.
* dwarf2out.c (dwarf2_debug_hooks): Same.
(new_die): Inhibit limbo dies unless generating early dwarf.
(gen_subprogram_die): Do not create a new DIE if we have an
old DIE and it has DW_AT_abstract_origin set.
(lookup_filename): Return NULL when no file name.
(optimize_location_lists): Abstract flushing of limbo list to...
(dwarf2out_early_finish): ...here. New function.
(dwarf2out_abstract_function): Do not set DECL_ABSTRACT_P
recursively if DECL_ABSTRACT_P of parent is set.
* toplev.c (toplev::main): Add temporary debugging aid.
* tree.c (free_lang_data): Call debug_hooks->early_finish.

diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c
index 82dd2cb..c9a4a4b 100644
--- a/gcc/c-family/cilk.c
+++ b/gcc/c-family/cilk.c
@@ -48,6 +48,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cgraph.h"
 #include "diagnostic.h"
 #include "cilk.h"
+#include "debug.h"
 
 enum add_variable_type {
 /* Reference to previously-defined variable.  */
@@ -573,6 +574,14 @@ create_cilk_wrapper_body (tree stmt, struct wrapper_data 
*wd)
 
   pop_cfun_to (outer);
 
+  /* It is rather unfortunate that Cilk creates trees this late
+ (during gimplification).  However, until this gets fixed,
+ specially handle emitting DWARF for this new function and
+ immediately clean up the limbo_die_list where the new function's
+ DIE will inevitably end up.  */
+  debug_hooks->early_global_decl (fndecl);
+  debug_hooks->early_finish ();
+
   /* Recognize the new function.  */
   call_graph_add_fn (fndecl);
   return fndecl;
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 691688b..70abc99 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -4346,6 +4346,9 @@ emit_debug_for_namespace (tree name_space, void* data 
ATTRIBUTE_UNUSED)
 
   check_global_declarations (vec, len);
 
+  /* FIXME: What does this do for templates?  I think we don't want to
+ send a template off to early_global_decl, but rather walk through
+ its specializations and emit them.  */
   for (tree t = level->names; t; t = TREE_CHAIN(t))
 debug_hooks->early_global_decl (t);
 
diff --git a/gcc/cp/optimize.c b/gcc/cp/optimize.c
index 62e32d2..ab3e93e 100644
--- a/gcc/cp/optimize.c
+++ b/gcc/cp/optimize.c
@@ -539,6 +539,10 @@ maybe_clone_body (tree fn)
   /* Start processing the function.  */
   start_preparsed_function (clone, NULL_TREE, SF_PRE_PARSED);
 
+  /* Generate early dwarf for the clone now that we have a body
+for it.  */
+  debug_hooks->early_global_decl (clone);
+
   /* Tell cgraph if both ctors or both dtors are known to have
 the same body.  */
   if (can_alias
diff --git a/gcc/dbxout.c b/gcc/dbxout.c
index 430a2eb..202ef8a 100644
--- a/gcc/dbxout.c
+++ b/gcc/dbxout.c
@@ -359,6 +359,7 @@ const struct gcc_debug_hooks dbx_debug_hooks =
   dbxout_init,
   dbxout_finish,
   debug_nothing_void,
+  debug_nothing_void,
   debug_nothing_int_charstar,
   debug_nothing_int_charstar,
   dbxout_start_source_file,
@@ -400,6 +401,7 @@ const struct gcc_debug_hooks xcoff_debug_hooks =
   dbxout_init,
   dbxout_finish,
   debug_nothing_void,
+  debug_nothing_void,
   debug_nothing_int_charstar,
   debug_nothing_int_charstar,
   dbxout_start_source_file,
diff --git a/gcc/debug.c b/gcc/debug.c
index 449d3a1..d0e00c0 100644
--- a/gcc/debug.c
+++ b/gcc/debug.c
@@ -27,6 +27,7 @@ const struct gcc_debug_hooks do_nothing_debug_hooks =
 {
   debug_nothing_charstar,
   debug_nothing_charstar,
+  debug_nothing_void,  /* early_finish */
   debug_nothing_void,
   debug_nothing_int_charstar,
   debug_nothing_int_charstar,
diff --git a/gcc/debug.h b/gcc/debug.h
index f9485bc..a8d3f23 100644
--- a/gcc/debug.h
+++ b/gcc/debug.h
@@ -30,6 +30,9 @@ struct gcc_debug_hooks
   /* Output debug symbols.  */
   void (* finish) (const char *main_filename);
 
+  /* Run cleanups necessary after early debug generation.  */
+  void (* early_finish) (void);
+
   /* Called from cgraph_optimize before starting to assemble
  functions/variables/toplevel asms.  */
   void (* assembly_start) (void);
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index e3ccda2..bf9268a 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -106,6 +106,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-dfa.h"
 #include "gdb/gdb-index.h"
 #include "rtl-iter.h"
+#include "print-tree.h"
 
 static void dwarf2out_source_line (unsigned int, con

Re: [debug-early] C++ clones and limbo DIEs

[Aldy Hernandez]

On 01/27/2015 12:51 PM, Jason Merrill wrote:

On 01/23/2015 01:45 PM, Aldy Hernandez wrote:

It would expect [the flush] to be before free_lang_data and LTO
streaming.


The reason this wouldn't make a difference is because, as it stands,
dwarf for the clones are not generated until final.c:

   if (!DECL_IGNORED_P (current_function_decl))
 debug_hooks->function_decl (current_function_decl);

which happens after free_lang_data.


I agree that the current code doesn't have this effect, but we're
talking about changing things, right? :)


Oh, my bad.  I completely misread your original comment.  Yes, yes... we 
can move the flushing of the limbo list to free_lang_data.  See attached 
patch.





Unfortunately, this sets DECL_ABSTRACT_P for the "static_p" above, and
refuses to unset it after the call to dwarf2out_decl.


Well, that sounds like a bug.  Why isn't it being unset?  Is it because
DECL_ABSTRACT_P was already set for the function, so we don't call
set_decl_abstract_flags (decl, 0)?  Perhaps a solution to that would be
to avoid calling set_decl_abstract_flags (decl, 1) if the function is
already marked as abstract.  Or to teach set_decl_abstract_flags not to
mess with static local variables.


Its' being unset because DECL_ABSTRACT_P was already set.  I propose we 
avoid calling set_decl_abstract_flags() for this scenario, as you 
suggest, and if this causes any problems, look into your second approach.


The attached patch gets rid of our limbo dependency past LTO streaming 
by flushing it out early, and adding some sanity checks throughout.


Cilk required some special handholding.  It seems to be the only culprit 
of late FUNCTION_DECL creation.


Now that we call dwarf2out_decl() for clones early on, I had to adjust 
gen_subprogram_die() to make sure we're not duplicating work and 
creating a new DIE if we already have on with DW_AT_abstract_origin.


I also kept lookup_filename() uses from ICEing now that we hit this code 
path.  It shouldn't affect other code paths (since it was ICEing before 
;-)).


With the attached patch we take care of C++ clones early, and get rid of 
our dependence on the limbo DIE list into LTO land.  No guality regressions.


Are we all in agreement with this approach?

Thanks for everyone's help BTW.
Aldy

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

On 01/28/2015 10:10 AM, Dominique d'Humières wrote:
>> I can't think of any reason they shouldn't work.  Were they not running 
>> before,
>> or did something else change?
> 
> AFAIU the commit, the tests were not run on x86_64-*-*, so the tests and the 
> corresponding failures are new.

Well, the commit fixed the fact that they weren't running on x86_64 for the
-m32 multilib.  If you had built a i686-darwin before the commit, the tests
should have already been running (and, presumably, failing).

> If you think the failures are a bug, I’ll open a PR for them.

I do think the failures are a bug.  If Darwin wasn't supposed to support these
abis, they ought to have failed test compilation, not test execution.


r~

Re: [fixincludes] Fix signbit on Solaris

[Bruce Korb]

On 01/28/15 10:13, Bruce Korb wrote:

Hi Rainer,

Sorry for the long delay.  Anyway:

On 01/28/15 06:12, Rainer Orth wrote:

* In test_text, I had to backslash-escape the trailing \, otherwise they
   were eaten up.  Whether or not I do this makes no difference for the
   generated fixincl.x, but only with the escaping does make check pass.


Right.  It likely gets massaged by a shell script somewhere.


Line 88 of check.tpl:


Oh, line 59 too:
 59 cat >> [=(. sfile)=] <<_HACK_EOF_
 60
 61
 62 #if defined( [=(. HACK)=]_CHECK_[=(for-index)=] )
 63 [=test_text=]
 64 #endif  /* [=(. HACK)=]_CHECK_[=(for-index)=] */
 65 _HACK_EOF_

Re: [fixincludes] Fix signbit on Solaris

[Bruce Korb]

Hi Rainer,

Sorry for the long delay.  Anyway:

On 01/28/15 06:12, Rainer Orth wrote:

* In test_text, I had to backslash-escape the trailing \, otherwise they
   were eaten up.  Whether or not I do this makes no difference for the
   generated fixincl.x, but only with the escaping does make check pass.


Right.  It likely gets massaged by a shell script somewhere.


Line 88 of check.tpl:

 88 cat >> [= (raw-shell-str (if (exist? "files") (get "files[0]") 
"testing.h"))
 89  =] <<_HACK_EOF_
 90
 91
 92 #if defined( [=(. HACK)=]_CHECK )
 93 [=test_text=]
 94 #endif  /* [=(. HACK)=]_CHECK */
 95 _HACK_EOF_

By quoting the "_HACK_EOF_" delimiter on line 89, the shell will not
try to process the "test_text".


This is certainly something that needs to be decided: if we go this
route, we should bump the autogen version requirement in install.texi
(to whatever is necessary to support the TAB\ magic).


I think Debian stable has moved up to 5.18.2, if I am remembering
correctly.  It's a year old (last fall).  I think that is old enough to
have been spread around by now.


It's your call ultimately.


OK, let's bump the defined requirement to something (almost) in this decade,
even if (for the moment) we don't use the TAB\ magic:

rel5.9.8/16-May-2009

PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[H.J. Lu]

Hi,

This patch makes claim_file_handler to call release_input_file after it
finishes processing input file.  OK for trunk?

Thanks.


H.J.
---
diff --git a/lto-plugin/ChangeLog b/lto-plugin/ChangeLog
index e8ec05b..c0eae24 100644
--- a/lto-plugin/ChangeLog
+++ b/lto-plugin/ChangeLog
@@ -1,3 +1,10 @@
+2015-01-28  H.J. Lu  
+
+   PR lto/64837
+   * lto-plugin.c (release_input_file): New.
+   (claim_file_handler): Call release_input_file.
+   (onload): Set release_input_file.
+
 2014-12-09  Ilya Verbin  
 
* lto-plugin.c (offload_files, num_offload_files): New static variables.
diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto-plugin.c
index 8d957402..8e0a657 100644
--- a/lto-plugin/lto-plugin.c
+++ b/lto-plugin/lto-plugin.c
@@ -145,6 +145,7 @@ static ld_plugin_register_all_symbols_read 
register_all_symbols_read;
 static ld_plugin_get_symbols get_symbols, get_symbols_v2;
 static ld_plugin_register_cleanup register_cleanup;
 static ld_plugin_add_input_file add_input_file;
+static ld_plugin_release_input_file release_input_file;
 static ld_plugin_add_input_library add_input_library;
 static ld_plugin_message message;
 static ld_plugin_add_symbols add_symbols;
@@ -1006,6 +1007,8 @@ claim_file_handler (const struct ld_plugin_input_file 
*file, int *claimed)
   if (obj.objfile)
 simple_object_release_read (obj.objfile);
 
+  release_input_file (file);
+
   return LDPS_OK;
 }
 
@@ -1091,6 +1094,9 @@ onload (struct ld_plugin_tv *tv)
case LDPT_ADD_INPUT_FILE:
  add_input_file = p->tv_u.tv_add_input_file;
  break;
+   case LDPT_RELEASE_INPUT_FILE:
+ release_input_file = p->tv_u.tv_release_input_file;
+ break;
case LDPT_ADD_INPUT_LIBRARY:
  add_input_library = p->tv_u.tv_add_input_library;
  break;

Re: [COMMITTED] Merge libffi with upstream

[Dominique d'Humières]

> Le 28 janv. 2015 à 19:03, Richard Henderson  a écrit :
> 
> On 01/28/2015 06:28 AM, Dominique Dhumieres wrote:
>>> This patch worked for me.  Ok for mainline now? (r220158)
>> 
>> This causes 340 new tests on darwin with -m32, 255 of them failing when 
>> executes,
>> see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03197.html.
>> 
>> Are the tests with '-DABI_NUM=*' supposed to work on darwin?
> 
> I can't think of any reason they shouldn't work.  Were they not running 
> before,
> or did something else change?

AFAIU the commit, the tests were not run on x86_64-*-*, so the tests and the 
corresponding failures are new.

If you think the failures are a bug, I’ll open a PR for them.

Dominique

> r~

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

On 01/28/2015 06:28 AM, Dominique Dhumieres wrote:
>> This patch worked for me.  Ok for mainline now? (r220158)
> 
> This causes 340 new tests on darwin with -m32, 255 of them failing when 
> executes,
> see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03197.html.
> 
> Are the tests with '-DABI_NUM=*' supposed to work on darwin?

I can't think of any reason they shouldn't work.  Were they not running before,
or did something else change?


r~

Re: [PATCH][AArch64] Testcase fix for __ATOMIC_CONSUME

[James Greenhalgh]

On Wed, Jan 28, 2015 at 05:51:27PM +, Marcus Shawcroft wrote:
> On 28 January 2015 at 17:41, Mike Stump  wrote:
> > On Jan 27, 2015, at 8:24 AM, Alex Velenko  wrote:
> >> This patch fixes aarch64/atomic-op-consume.c test to expect safe "LDAXR"
> >> instruction to be generated when __ATOMIC_CONSUME semantics is requested.
> >
> > Did you see:
> >
> >   /* Workaround for Bugzilla 59448. GCC doesn't track consume properly, so
> >  be conservative and promote consume to acquire.  */
> >   if (val == MEMMODEL_CONSUME)
> > val = MEMMODEL_ACQUIRE;
> >
> > in builtins.c?  Feels like if gcc isn’t going to support it for you, then 
> > testing for it would be, hard?
> 
> The original test was written pre 59448 and expects GCC to implement
> consume behaviour.  The workaround for 59448 changes GCC behaviour but
> did not update this test case.  Going forward we can either remove the
> test case completely, xfail the test case pending a proper solution to
> 59448 ? or change the test case to expect the current intended
> behaviour of gcc.  This patch implements that latter, which seems
> reasonable to me. Mike do you prefer one of the other two approaches ?

I'll vote for keeping the test case, please. It still fulfills a useful
purpose.

GCC must now promote __ATOMIC_CONSUME to __ATOMIC_ACQUIRE, and the test
case now reflects that - expecting the LDAXR instruction (load acquire
exclusive) over the more relaxed LDXR (load exclusive) that we emitted
prior to PR59448.

If we lose that promotion, or if we start emitting different instructions
for __ATOMIC_ACQUIRE, we have a regression, and this test should spot
that. I also wouldn't want to see the test XFAIL; we know what the correct
expected behaviour is and should update the test to reflect that - as in
Alex' patch.

Thanks,
James

Re: [PATCH][RFA][PR target/15184] Partial fix for direct byte access on x86

[Mike Stump]

On Jan 27, 2015, at 10:08 PM, Jeff Law  wrote:
> We're still going to need the changes to the heuristic to enable 4 insn 
> combinations

Yeah, I’ve love for a masters student to come up with a sane way to do 16 or 
less and enhance gcc to do that.  Things like, oh, this pattern is a dead end 
here, so, no point in trying any combinations with it, or, oh, look, a set or 
extend, these are really popular in the patterns in this port and I can see 100 
ways these can form a basis for combination.

As I recall llvm doesn’t limit itself to 3.

Re: nvptx offloading patches [4/n]

[Ilya Verbin]

On 28 Jan 18:05, Thomas Schwinge wrote:
> +  fprintf (out, "#define PTX_ID 1\n");
> +  fprintf (out, "static __attribute__((constructor)) void init (void)\n{\n");
> +  fprintf (out, "  GOMP_offload_register (__OPENMP_TARGET__, PTX_ID,\n");

The file include/gomp-constants.h already contains:
#define GOMP_DEVICE_NVIDIA_PTX  5

I guess it would be better to include gomp-constants.h into mkoffload and to use
this define.

  -- Ilya

Re: [PATCH][AArch64] Testcase fix for __ATOMIC_CONSUME

[Marcus Shawcroft]

On 28 January 2015 at 17:41, Mike Stump  wrote:
> On Jan 27, 2015, at 8:24 AM, Alex Velenko  wrote:
>> This patch fixes aarch64/atomic-op-consume.c test to expect safe "LDAXR"
>> instruction to be generated when __ATOMIC_CONSUME semantics is requested.
>
> Did you see:
>
>   /* Workaround for Bugzilla 59448. GCC doesn't track consume properly, so
>  be conservative and promote consume to acquire.  */
>   if (val == MEMMODEL_CONSUME)
> val = MEMMODEL_ACQUIRE;
>
> in builtins.c?  Feels like if gcc isn’t going to support it for you, then 
> testing for it would be, hard?

The original test was written pre 59448 and expects GCC to implement
consume behaviour.  The workaround for 59448 changes GCC behaviour but
did not update this test case.  Going forward we can either remove the
test case completely, xfail the test case pending a proper solution to
59448 ? or change the test case to expect the current intended
behaviour of gcc.  This patch implements that latter, which seems
reasonable to me. Mike do you prefer one of the other two approaches ?

Cheers
/Marcus

Re: [PATCH][AArch64] Testcase fix for __ATOMIC_CONSUME

[Mike Stump]

On Jan 27, 2015, at 8:24 AM, Alex Velenko  wrote:
> This patch fixes aarch64/atomic-op-consume.c test to expect safe "LDAXR"
> instruction to be generated when __ATOMIC_CONSUME semantics is requested.

Did you see:

  /* Workaround for Bugzilla 59448. GCC doesn't track consume properly, so  

 be conservative and promote consume to acquire.  */
  if (val == MEMMODEL_CONSUME)
val = MEMMODEL_ACQUIRE;

in builtins.c?  Feels like if gcc isn’t going to support it for you, then 
testing for it would be, hard?

Re: [testsuite] Run guality tests on Solaris

[Mike Stump]

On Jan 28, 2015, at 4:58 AM, Rainer Orth  wrote:
> 
> Thoughts?

So the timeout for slow things can be increased:

# More time is needed   

set_board_info gcc,timeout 800
set_board_info gdb,timeout 60

from the frv-sim.exp file.  And:

# Increase the timeout  

set timeout 60

from a few others.  And:

set_board_info testcase_timeout 30

from usparc-cygmon.exp.  I’d like to think one or more of those would cure the 
timeout problem.  You can put the timeout in a site.exp file or a 
$HOME/.dejgnurc file for dejagnu and try it out, something like:

case "$target_triplet" in {
{ “sparc-*-*" } {
set_board_info gdb,timeout 60
}
}

if you want to try site.exp.  The timeouts should be buried somewhere inside 
gcc or dejagnu for non-site specific timeouts however.

For individual test cases that are pigs that you catch, dg-timeout-factor can 
be used to slide it up.  On a good host, every test should take 10 seconds or 
less.  If they take more, I would bump the timeout to be 30x the time it takes 
on a good host.  This gives us headroom for shared machines, slower machines 
and all sorts of variations.  The slowest of the targets (m68k testing), aren’t 
expected to be able to be covered by this slop, they would need to use a more 
formal mechanism to say they are extra slow.

Upping the timeout of course won’t cure an infinite loop due to gdb bugs.

One thing that I wonder about is how much swap space one has and if the test 
suite firing up too many gdb tasks too fast and simply running it out of memory 
or causing thrashing due to testtcase size.  If you wanted to explore this, 
look for check_gcc_parallelize=1 in the Makefile, and see if trimming it 
down helps.  If so, then Jakub might be able to help trim the guilty tests down 
so they don’t so thrash as much.

> Ok for mainline?

Ok to me, but, if the gdb/guality folks have better comments, I’d defer to them.

The command line issue sounds like a gdb bug.  I’d report it and tag in a PR 
number into the comment where we create the command line.

Re: [PATCH PR64809]

[Jakub Jelinek]

On Wed, Jan 28, 2015 at 09:23:55AM -0800, H.J. Lu wrote:
> On Tue, Jan 27, 2015 at 6:52 AM, Yuri Rumyantsev  wrote:
> > Hi All,
> >
> > Here is a simple patch that cures ICE - skip debug gimples.
> > Test is also included.
> >
> > Bootstrap and regression testing did not show any new failures.
> >
> > Is it OK for trunk?
> >
> > ChangeLog:
> >
> > 2015-01-27  Yuri Rumyantsev  
> >
> > PR tree-optimization/64809
> > * cfgexpand.c (reorder_operands): Skip debug gimples.
> >
> > gcc/testsuite/ChangeLog
> >
> > * gcc.dg/pr64809.c: New test.
> 
> I got
> 
> FAIL: gcc.dg/pr64809.c (test for excess errors)
> 
> on x86.

The test IMHO shouldn't have been added, as it couldn't be properly
reduced.

Jakub

Re: [PATCH PR64809]

[H.J. Lu]

On Tue, Jan 27, 2015 at 6:52 AM, Yuri Rumyantsev  wrote:
> Hi All,
>
> Here is a simple patch that cures ICE - skip debug gimples.
> Test is also included.
>
> Bootstrap and regression testing did not show any new failures.
>
> Is it OK for trunk?
>
> ChangeLog:
>
> 2015-01-27  Yuri Rumyantsev  
>
> PR tree-optimization/64809
> * cfgexpand.c (reorder_operands): Skip debug gimples.
>
> gcc/testsuite/ChangeLog
>
> * gcc.dg/pr64809.c: New test.

I got

FAIL: gcc.dg/pr64809.c (test for excess errors)

on x86.

-- 
H.J.

Re: nvptx offloading patches [4/n]

[Thomas Schwinge]

Hi!

On Sat, 1 Nov 2014 13:11:29 +0100, Bernd Schmidt  
wrote:
> I'm sending this for reference more than anything else - this is the 
> patch that adds the target support for offloading to the nvptx port. It 
> depends on the other offloading patches Ilya is currently submitting.

Committed to trunk in r220209:

commit 9c08fbb35aa95420268c2762151f22a6a9b90e85
Author: tschwinge 
Date:   Wed Jan 28 17:03:44 2015 +

nvptx mkoffload.

gcc/
* config/nvptx/mkoffload.c: New file.
* config/nvptx/t-nvptx: Add build rules for it.
* config.gcc  [$enable_as_accelerator = yes]
(extra_programs): Add mkoffload.
* config/nvptx/nvptx.c (nvptx_record_offload_symbol): New
function.
(TARGET_RECORD_OFFLOAD_SYMBOL): Define macro to use it.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@220209 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog|  12 +
 gcc/config.gcc   |   5 +-
 gcc/config/nvptx/mkoffload.c | 907 +++
 gcc/config/nvptx/nvptx.c |  13 +
 gcc/config/nvptx/t-nvptx |   9 +-
 5 files changed, 944 insertions(+), 2 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 6968b82..6b957bf 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,15 @@
+2015-01-28  Thomas Schwinge  
+   Bernd Schmidt  
+   Nathan Sidwell  
+
+   * config/nvptx/mkoffload.c: New file.
+   * config/nvptx/t-nvptx: Add build rules for it.
+   * config.gcc  [$enable_as_accelerator = yes]
+   (extra_programs): Add mkoffload.
+   * config/nvptx/nvptx.c (nvptx_record_offload_symbol): New
+   function.
+   (TARGET_RECORD_OFFLOAD_SYMBOL): Define macro to use it.
+
 2015-01-28  Yuri Rumyantsev  
 
PR middle-end/64809
diff --git gcc/config.gcc gcc/config.gcc
index bf67beb..abd915e 100644
--- gcc/config.gcc
+++ gcc/config.gcc
@@ -2233,7 +2233,10 @@ nios2-*-*)
 nvptx-*)
tm_file="${tm_file} newlib-stdint.h"
tmake_file="nvptx/t-nvptx"
-   tm_file="${tm_file} nvptx/offload.h"
+   if test x$enable_as_accelerator = xyes; then
+   extra_programs="${extra_programs} mkoffload\$(exeext)"
+   tm_file="${tm_file} nvptx/offload.h"
+   fi
;;
 pdp11-*-*)
tm_file="${tm_file} newlib-stdint.h"
diff --git gcc/config/nvptx/mkoffload.c gcc/config/nvptx/mkoffload.c
new file mode 100644
index 000..9138bdd
--- /dev/null
+++ gcc/config/nvptx/mkoffload.c
@@ -0,0 +1,907 @@
+/* Offload image generation tool for PTX.
+
+   Copyright (C) 2014-2015 Free Software Foundation, Inc.
+
+   Contributed by Nathan Sidwell  and
+   Bernd Schmidt .
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+/* Munges PTX assembly into a C source file defining the PTX code as a
+   string.
+
+   This is not a complete assembler.  We presume the source is well
+   formed from the compiler and can die horribly if it is not.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "intl.h"
+#include 
+#include "obstack.h"
+#include "diagnostic-core.h"
+#include "collect-utils.h"
+
+const char tool_name[] = "nvptx mkoffload";
+
+#define COMMENT_PREFIX "#"
+
+typedef enum Kind
+{
+  /* 0-ff used for single char tokens */
+  K_symbol = 0x100, /* a symbol */
+  K_label,  /* a label defn (i.e. symbol:) */
+  K_ident,  /* other ident */
+  K_dotted, /* dotted identifier */
+  K_number,
+  K_string,
+  K_comment
+} Kind;
+
+typedef struct Token
+{
+  unsigned short kind : 12;
+  unsigned short space : 1; /* preceded by space */
+  unsigned short end : 1;   /* succeeded by end of line */
+  /* Length of token */
+  unsigned short len;
+
+  /* Token itself */
+  char const *ptr;
+} Token;
+
+/* statement info */
+typedef enum Vis
+{
+  V_dot = 0,  /* random pseudo */
+  V_var = 1,  /* var decl/defn */
+  V_func = 2, /* func decl/defn */
+  V_insn = 3, /* random insn */
+  V_label = 4, /* label defn */
+  V_comment = 5,
+  V_pred = 6,  /* predicate */
+  V_mask = 0x7,
+  V_global = 0x08, /* globalize */
+  V_weak = 0x10,   /* weakly globalize */
+  V_no_eol = 0x20, /* no end of line */
+  V_prefix_comment = 0x40 /* prefixed comment */
+} Vis;
+
+typedef struct Stmt
+{
+  struct Stmt *next;
+  Token *tokens;
+  unsigned char vis;
+  unsigned len : 12;
+  unsigned sym : 12;
+} Stmt;
+
+struct 

Re: [PATCH][RFC][OpenMP] Forbid target* pragmas in target regions

[Ilya Verbin]

Hi Jakub!

We have 3 pending patches with warnings/errors about omp pragmas:

1. https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00617.html
2. https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00621.html
3. This one.

What should we do with them?

[ ] Rebase and continue pinging.
[ ] Postpone until Stage 1.
[ ] Completely remove.


On 12 Jan 00:22, Ilya Verbin wrote:
> Currently if a target* pragma appears within a target region, GCC successfully
> compiles such code (with a warning).  But the binary fails at run-time, since 
> it
> tries to call GOMP_target* functions on target.
> 
> The spec says: "If a target, target update, or target data construct appears
> within a target region then the behavior is unspecified."
> 
> I see 2 options to make the behavior more user-friendly:
> 1. To return an error at compile-time.
> 2. To check at run-time in libgomp whether GOMP_target* is called on target, 
> and
> perform target-fallback if so.
> 
> If we will select option #1, the patch is ready.

  -- Ilya

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

[Ilya Verbin]

On 28 Jan 17:15, Jakub Jelinek wrote:
> On Wed, Jan 28, 2015 at 07:02:59PM +0300, Ilya Verbin wrote:
> > +   = XNEWVEC (char, len + sizeof ("-B" "../" DEFAULT_TARGET_MACHINE
> > +  "/libgomp/"));
> > +  sprintf (optional_target_path2, "-B%s/../../../" 
> > DEFAULT_TARGET_MACHINE
> > + "/libgomp/", current_path);
> 
> This will surely overflow the buffer, won't it?  There is space just for
> "../" but you put there "/../../../".
> 
> I'd strongly prefer if you rewrote all these XNEWVEC or XRESIZEVEC etc.
> + sprintf cases into concat, like
>   optional_target_path2 = concat ("-B", current_path,
> "/../../../" DEFAULT_TARGET_MACHINE
> "/libgomp/", NULL);
> and similar.  That way you avoid all such bugs.

The variable 'len' contains sizeof ("/../../").
I agree that this code looks ugly :)  I'll rewrite it using concat.

  -- Ilya

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

[Jakub Jelinek]

On Wed, Jan 28, 2015 at 07:02:59PM +0300, Ilya Verbin wrote:
> + = XNEWVEC (char, len + sizeof ("-B" "../" DEFAULT_TARGET_MACHINE
> +"/libgomp/"));
> +  sprintf (optional_target_path2, "-B%s/../../../" DEFAULT_TARGET_MACHINE
> +   "/libgomp/", current_path);

This will surely overflow the buffer, won't it?  There is space just for
"../" but you put there "/../../../".

I'd strongly prefer if you rewrote all these XNEWVEC or XRESIZEVEC etc.
+ sprintf cases into concat, like
  optional_target_path2 = concat ("-B", current_path,
  "/../../../" DEFAULT_TARGET_MACHINE
  "/libgomp/", NULL);
and similar.  That way you avoid all such bugs.

Jakub

PING: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option

[H.J. Lu]

PING.

On Tue, Jan 13, 2015 at 3:25 PM, H.J. Lu  wrote:
> On Tue, Jan 13, 2015 at 5:03 AM, H.J. Lu  wrote:
>> On Mon, Jan 12, 2015 at 11:50:41PM +, Joseph Myers wrote:
>>> On Mon, 12 Jan 2015, H.J. Lu wrote:
>>>
>>> > +if test x$enable_default_pie = xyes; then
>>> > +  AC_MSG_CHECKING(if $target supports default PIE)
>>> > +  enable_default_pie=no
>>> > +  case $target in
>>> > +i?86*-*-linux* | x86_64*-*-linux*)
>>> > +  saved_LDFLAGS="$LDFLAGS"
>>> > +  saved_CFLAGS="$CFLAGS"
>>> > +  CFLAGS="$CFLAGS -fPIE"
>>> > +  LDFLAGS="$LDFLAGS -fPIE -pie"
>>> > +  AC_TRY_LINK(,,[enable_default_pie=yes],)
>>> > +  LDFLAGS="$saved_LDFLAGS"
>>> > +  CFLAGS="$saved_CFLAGS"
>>> > +  ;;
>>> > +*)
>>> > +  ;;
>>> > +esac
>>>
>>> There should not be any such hardcoding of targets here without concrete
>>> evidence that the targets for which this sets enable_default_pie=no really
>>> cannot support PIE.  In particular, there is no reason at all for this to
>>> be architecture-specific; all GNU/Linux architectures should support PIE.
>>>
>>> I believe AC_TRY_LINK here will test for the host, whereas what you want
>>> to know is what's supported for the target (but it's not possible to run
>>> link tests for the target at this point; the compiler for the target
>>> hasn't even been built).
>>>
>>> So: just presume that if the user passes --enable-default-pie then they
>>> know what they are doing, and don't try to override their choice.
>>>
>>> > diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
>>> > index c9e3bf1..89fc305 100644
>>> > --- a/gcc/doc/install.texi
>>> > +++ b/gcc/doc/install.texi
>>> > @@ -1583,6 +1583,10 @@ not be built.
>>> >  Specify that the run-time libraries for stack smashing protection
>>> >  should not be built.
>>> >
>>> > +@item --enable-default-pie
>>> > +Turn on @option{-fPIE} and @option{-pie} by default if supported.
>>> > +Currently supported targets are i?86-*-linux* and x86-64-*-linux*.
>>>
>>> The "if supported" and target list can then be removed here.
>>>
>>
>> Here is the updated patch.  To support --enable-default-pie, each target
>> must update STARTFILE_SPEC to support PIE_SPEC and NO_PIE_SPEC.  I can
>> provide STARTFILE_SPEC patch if needed.
>>
>> Thanks.
>>
>>
>> H.J.
>> ---
>> gcc/
>>
>> 2015-01-12  Magnus Granberg  
>> H.J. Lu  
>>
>> * Makefile.in (COMPILER): Add @NO_PIE_CFLAGS@.
>> (LINKER): Add @NO_PIE_FLAG@.
>> (libgcc.mvars): Set NO_PIE_CFLAGS to -fno-PIE for
>> --enable-default-pie.
>> * common.opt (fPIE): Initialize to -1.
>> (fpie): Likewise.
>> (static): Add "RejectNegative Negative(shared)".
>> (no-pie): New option.
>> (pie): Replace "Negative(shared)" with "Negative(no-pie)".
>> * configure.ac: Add --enable-default-pie.
>> (NO_PIE_CFLAGS): New.  Check if -fno-PIE works.  AC_SUBST.
>> (NO_PIE_FLAG): New.  Check if -no-pie works.  AC_SUBST.
>> * defaults.h (DEFAULT_FLAG_PIE): New.  Default PIE to -fPIE.
>> * gcc.c (NO_PIE_SPEC): New.
>> (PIE_SPEC): Likewise.
>> (LD_PIE_SPEC): Likewise.
>> (LINK_PIE_SPEC): Handle -no-pie.  Use PIE_SPEC and LD_PIE_SPEC.
>> * opts.c (DEFAULT_FLAG_PIE): New.  Set to 0 if ENABLE_DEFAULT_PIE
>> is undefined.
>> (finish_options): Update opts->x_flag_pie if it is -1.
>> * config/gnu-user.h (FVTABLE_VERIFY_SPEC): New.
>> (GNU_USER_TARGET_STARTFILE_SPEC): Use FVTABLE_VERIFY_SPEC.  Use
>> NO_PIE_SPEC and NO_PIE_SPEC if ENABLE_DEFAULT_PIE is defined.
>> (GNU_USER_TARGET_STARTFILE_SPEC): Use FVTABLE_VERIFY_SPEC.
>> * doc/install.texi: Document --enable-default-pie.
>> * doc/invoke.texi: Document -no-pie.
>> * config.in: Regenerated.
>> * configure: Likewise.
>>
>> gcc/ada/
>>
>> 2015-01-12  H.J. Lu  
>>
>> * gcc-interface/Makefile.in (TOOLS_LIBS): Add @NO_PIE_FLAG@.
>>
>> libgcc/
>>
>> 2015-01-12  H.J. Lu  
>>
>> * Makefile.in (CRTSTUFF_CFLAGS): Add $(NO_PIE_CFLAGS).
>>
>
> This is the updated patch.  I fixed the -r regression.   LTO tests
> pass now.
>
> --
> H.J.



-- 
H.J.

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

[Ilya Verbin]

On 15 Jan 19:58, Jakub Jelinek wrote:
> On Thu, Jan 15, 2015 at 09:55:40PM +0300, Ilya Verbin wrote:
> > This patch enables 'make check-target-libgomp' with noninstalled offloading
> > compilers.  It creates gcc/accel// directory in the build tree of 
> > the
> > offloading compiler, this allows lto-wrapper to find corresponding 
> > mkoffload in
> > case if there is more than one offloading compiler.  Is this approach ok?
> > I don't like changes in config.gcc and t-intelmic, probably there is a 
> > better
> > way to create a link?
> 
> Let's wait until Thomas hopefully checks in the OpenACC merge in order not
> to make him work even harder.
> I'll look at your patch afterwards.

I've rebased this patch.


diff --git a/gcc/config.gcc b/gcc/config.gcc
index bf67beb..c56c055 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4371,7 +4371,7 @@ fi
 case ${target} in
 i[34567]86-*-* | x86_64-*-*)
if test x$enable_as_accelerator = xyes; then
-   extra_programs="mkoffload\$(exeext)"
+   extra_programs="mkoffload\$(exeext) 
accel/${target_noncanonical}/mkoffload$(exeext)"
fi
;;
 esac
diff --git a/gcc/config/i386/intelmic-mkoffload.c 
b/gcc/config/i386/intelmic-mkoffload.c
index 5d9ed33..73ca9ce 100644
--- a/gcc/config/i386/intelmic-mkoffload.c
+++ b/gcc/config/i386/intelmic-mkoffload.c
@@ -45,6 +45,13 @@ const char *temp_files[MAX_NUM_TEMPS];
 /* Shows if we should compile binaries for i386 instead of x86-64.  */
 bool target_ilp32 = false;
 
+/* Optional prefixes for the target compiler, which are required when target
+   compiler is not installed.  */
+char *optional_target_path1 = NULL;
+char *optional_target_path2 = NULL;
+char *optional_target_lib_path = NULL;
+
+
 /* Delete tempfiles and exit function.  */
 void
 tool_cleanup (bool from_signal ATTRIBUTE_UNUSED)
@@ -151,14 +158,18 @@ access_check (const char *name, int mode)
   return access (name, mode);
 }
 
-/* Find target compiler using a path from COLLECT_GCC or COMPILER_PATH.  */
+/* Find target compiler using a path from COLLECT_GCC, COMPILER_PATH, or a path
+   relative to ARGV0.  */
 static char *
-find_target_compiler (const char *name)
+find_target_compiler (const char *argv0)
 {
   bool found = false;
   char **paths = NULL;
   unsigned n_paths, i;
+  const char *current_path;
   const char *collect_path = dirname (ASTRDUP (getenv ("COLLECT_GCC")));
+  const char *name
+= DEFAULT_REAL_TARGET_MACHINE "-accel-" DEFAULT_TARGET_MACHINE "-gcc";
   size_t len = strlen (collect_path) + 1 + strlen (name) + 1;
   char *target_compiler = XNEWVEC (char, len);
   sprintf (target_compiler, "%s/%s", collect_path, name);
@@ -177,13 +188,38 @@ find_target_compiler (const char *name)
   if (access_check (target_compiler, X_OK) == 0)
{
  found = true;
- break;
+ goto out;
}
 }
 
+  /* If installed compiler wasn't found, try to find a non-installed compiler,
+ using a path relative to mkoffload.  */
+  current_path = dirname (ASTRDUP (argv0));
+  len = strlen (current_path) + sizeof ("/../../") - 1;
+  target_compiler = XRESIZEVEC (char, target_compiler, len + sizeof ("xgcc"));
+  sprintf (target_compiler, "%s/../../xgcc", current_path);
+  if (access_check (target_compiler, X_OK) == 0)
+{
+  optional_target_path1 = XNEWVEC (char, len + sizeof ("-B"));
+  sprintf (optional_target_path1, "-B%s/../../", current_path);
+  optional_target_path2
+   = XNEWVEC (char, len + sizeof ("-B" "../" DEFAULT_TARGET_MACHINE
+  "/libgomp/"));
+  sprintf (optional_target_path2, "-B%s/../../../" DEFAULT_TARGET_MACHINE
+ "/libgomp/", current_path);
+  optional_target_lib_path
+   = XNEWVEC (char, len + sizeof ("-L" "../" DEFAULT_TARGET_MACHINE
+  "/libgomp/.libs/"));
+  sprintf (optional_target_lib_path, "-L%s/../../../" 
DEFAULT_TARGET_MACHINE
+"/libgomp/.libs/", current_path);
+  found = true;
+}
+
 out:
   free_array_of_ptrs ((void **) paths, n_paths);
-  return found ? target_compiler : NULL;
+  if (!found)
+fatal_error ("offload compiler %s not found", name);
+  return target_compiler;
 }
 
 static void
@@ -193,6 +229,14 @@ compile_for_target (struct obstack *argv_obstack)
 obstack_ptr_grow (argv_obstack, "-m32");
   else
 obstack_ptr_grow (argv_obstack, "-m64");
+
+  if (optional_target_path1)
+obstack_ptr_grow (argv_obstack, optional_target_path1);
+  if (optional_target_path2)
+obstack_ptr_grow (argv_obstack, optional_target_path2);
+  if (optional_target_lib_path)
+obstack_ptr_grow (argv_obstack, optional_target_lib_path);
+
   obstack_ptr_grow (argv_obstack, NULL);
   char **argv = XOBFINISH (argv_obstack, char **);
 
@@ -492,11 +536,7 @@ main (int argc, char **argv)
   if (!host_compiler)
 fatal_error ("COLLECT_GCC must be set");
 
-  const char *target

Re: [PATCH, i386] Never fix register for PIC when pseudo PIC reg is used

[Uros Bizjak]

Hello!

> Currently ix86_conditional_register_usage code may mark EBX as a fixed 
> register if it is called
> when pic_offset_table_rtx is NULL even if we are going to use pseudo PIC 
> register.  It already
> caused some problem in combination with another issue (PR jit/64722).  This 
> patch will probably
> help to avoid problems in the future.
>
> BTW if we don't want to support possibility to switch to the fixed PIC 
> register in i386 target then
> this code may be removed at all.

No, we don't want to switch to fixed PIC register. cpuid asm in
cpuid.h and cmpxchg8b pattern will break. Please do not bring back the
dead and remove this code.

Uros.

Re: [RFC PATCH] Avoid most of the BUILT_IN_*_CHKP enum values

[David Edelsohn]

On Wed, Jan 28, 2015 at 6:45 AM, Richard Biener
 wrote:
> On Wed, Jan 28, 2015 at 12:24 PM, Jakub Jelinek  wrote:
>> On Wed, Jan 28, 2015 at 12:15:40PM +0100, Richard Biener wrote:
>>> > Note, patch successfully bootstrapped/regtested on x86_64-linux and
>>> > i686-linux, and David said that on AIX it passed stage1 cc1 linking.
>>> >
>>> > Ok for trunk?
>>>
>>> Is the stabs issue meanwhile fixed at least on trunk?
>>
>> AFAIK no.  The generic stabs code has support for either infinite length
>> records, or records split using continuations (targets can choose which
>> character is continuation character).  But AIX doesn't support infinite
>> length records and for some reason doesn't support continuations either.
>>
>> IMHO it should just enable support for continuations, even if there was a
>> reason not to enable them 15 years ago on AIX, I bet the debuggers changed a
>> little bit even on that platform during that time.
>>
>> The other option is to add generic support for just throwing stabs records
>> on the floor if they are too large and target doesn't want to support
>> continuations (would be for AIX only), but in that case the target at least
>> would need to hint what means too large.
>
> Yes, dropping them on the floor would be the solution.  Not sure what STABS
> defines as maximum record length on AIX.
>
> It should be the STABS and/or affected target maintainers job to get this 
> fixed
> for them.

Richard,

Even if the STABS continuations are fixed, it requires fixing it in
previous releases of GCC, deploying the solution and achieving
adoption.  The current problem prevents linking of stage 1 cc1,
cc1plus, etc.

I am working through the STABS continuation issues on AIX, but it does
not solve the problem of the GCC 5 release functioning on AIX.

Thanks, David

Re: [PATCH][AArch32] Testcase fix for __ATOMIC_CONSUME

[Alex Velenko]

On 27/01/15 16:13, Ramana Radhakrishnan wrote:

On Tue, Jan 27, 2015 at 4:06 PM, Alex Velenko  wrote:


Hi,

This patch fixes arm/atomic-op-consume.c test to expect safe "LDAEX"
instruction to be generated when __ATOMIC_CONSUME semantics is requested.

This patch was tested by running the modified test on arm-none-eabi and
arm-none-linux-gnueabi compilers.

Is this patch ok?


Ok. Please remember James's comments in the future about cover notes.



Commited.

Alex


Ramana



Alex

2015-01-27  Alex Velenko  

gcc/testsuite/

   * gcc.target/arm/atomic-op-consume.c (scan-assember-times): Adjust
   scan-assembler-times pattern.

diff --git a/gcc/testsuite/gcc.target/arm/atomic-op-consume.c 
b/gcc/testsuite/gcc.target/arm/atomic-op-consume.c
index 0354717..cc6c028 100644
--- a/gcc/testsuite/gcc.target/arm/atomic-op-consume.c
+++ b/gcc/testsuite/gcc.target/arm/atomic-op-consume.c
@@ -5,6 +5,9 @@

  #include "../aarch64/atomic-op-consume.x"

-/* { dg-final { scan-assembler-times "ldrex\tr\[0-9\]+, \\\[r\[0-9\]+\\\]" 6 } 
} */
+/* To workaround Bugzilla 59448 issue, a request for __ATOMIC_CONSUME is always
+   promoted to __ATOMIC_ACQUIRE, implemented as MEMMODEL_ACQUIRE.  This causes
+   "LDAEX" to be generated instead of "LDREX".  */
+/* { dg-final { scan-assembler-times "ldaex\tr\[0-9\]+, \\\[r\[0-9\]+\\\]" 6 } 
} */
  /* { dg-final { scan-assembler-times "strex\t...?, r\[0-9\]+, 
\\\[r\[0-9\]+\\\]" 6 } } */
  /* { dg-final { scan-assembler-not "dmb" } } */

Re: [PATCH] Fix PR64829

[Kyrill Tkachov]

Hi Richard,

On 28/01/15 14:14, Richard Biener wrote:

This fixes PR64829 where widening shift pattern detection fails to
verify the widening operation is used only in the shift.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.


This patch causes a testsuite fail on an arm-none-eabi cross:
FAIL: gcc.dg/vect/vect-widen-shift-u8.c scan-tree-dump-times vect 
"vect_recog_widen_shift_pattern: detected" 2
FAIL: gcc.dg/vect/vect-widen-shift-u8.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vect_recog_widen_shift_pattern: detected" 2


The widen_shift pattern doesn't get recognised although the loop is 
still vectorised.

Is this something we can avoid?
Or should the test be adjusted?

Thanks,
Kyrill



Richard.

2015-01-28  Richard Biener  

PR tree-optimization/64829
* tree-vect-patterns.c (vect_recog_widen_shift_pattern): Check
that the shift operand has a single use only.

* gcc.dg/vect/pr64829.c: New testcase.

Index: gcc/tree-vect-patterns.c
===
--- gcc/tree-vect-patterns.c(revision 220205)
+++ gcc/tree-vect-patterns.c(working copy)
@@ -1732,9 +1732,11 @@ vect_recog_widen_shift_pattern (vec  
-  /* Check operand 0: it has to be defined by a type promotion.  */

-  if (!type_conversion_p (oprnd0, last_stmt, false, &half_type0, &def_stmt0,
-  &promotion)
+  /* Check operand 0: it has to be defined by a type promotion and it
+ should be only used by the shift.  */
+  if (!has_single_use (oprnd0)
+  || !type_conversion_p (oprnd0, last_stmt, false, &half_type0, &def_stmt0,
+&promotion)
|| !promotion)
   return NULL;
  
Index: gcc/testsuite/gcc.dg/vect/pr64829.c

===
--- gcc/testsuite/gcc.dg/vect/pr64829.c (revision 0)
+++ gcc/testsuite/gcc.dg/vect/pr64829.c (working copy)
@@ -0,0 +1,66 @@
+/* { dg-do compile } */
+
+typedef unsigned char Uint8;
+typedef int Sint32;
+typedef unsigned int Uint32;
+
+typedef union RMColorDataRef
+{
+  Uint8* data8;
+} RMColorDataRef;
+
+typedef struct RMColorData
+{
+  Uint32 dataCount;
+  RMColorDataRef dataRef;
+} RMColorData;
+
+typedef struct RMColorTable
+{
+  Uint8 dataCompsOut;
+  RMColorDataRef dataRef;
+} RMColorTable;
+
+int fail ( const RMColorData * pInColor,
+  RMColorData * pOutColor,
+  const RMColorTable * pColorTable )
+{
+  Uint32 comp;
+  Uint8 nCompOut;
+
+  Sint32 result;
+
+  Uint32 interpFrac1, interpFrac2, interpFrac3;
+  Sint32 val0, val1, val2, val3;
+
+  Uint8 * pOut;
+
+  const Uint8 * pClutData;
+  const Uint8 * pCornerPoint0;
+
+  Uint8 lastOut[((8) > (4) ? (8) : (4))];
+
+  pOut = pOutColor->dataRef.data8;
+  pClutData = pColorTable->dataRef.data8;
+
+  nCompOut = pColorTable->dataCompsOut;
+
+  pCornerPoint0 = pClutData;
+
+  for (comp = 0; comp < nCompOut; comp++)
+{
+  val0 = *pCornerPoint0++;
+
+  result = val0 << 4;
+
+  result += (val1 - val0) * interpFrac1;
+  result += (val2 - val1) * interpFrac2;
+  result += (val3 - val2) * interpFrac3;
+
+  *pOut++ = lastOut[comp] = (Uint8)(result >> 4);
+}
+
+  return (0);
+}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */

[PATCH, i386] Never fix register for PIC when pseudo PIC reg is used

[Ilya Enkovich]

Hi,

Currently ix86_conditional_register_usage code may mark EBX as a fixed register 
if it is called when pic_offset_table_rtx is NULL even if we are going to use 
pseudo PIC register.  It already caused some problem in combination with 
another issue (PR jit/64722).  This patch will probably help to avoid problems 
in the future.

BTW if we don't want to support possibility to switch to the fixed PIC register 
in i386 target then this code may be removed at all.

Bootstrapped and tested on x86_64-unknown-linux-gnu.  OK for trunk?

Thanks,
Ilya
--
2015-01-28  Ilya Enkovich  

* config/i386/i386.c (ix86_conditional_register_usage): Never fix
PIC register if we are going to use a pseudo one.
(ix86_use_pseudo_pic_reg): Move up.


diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index d10d3ff..27316a0 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -4378,6 +4378,19 @@ ix86_offload_options (void)
   return xstrdup ("-foffload-abi=ilp32");
 }
 
+/* Return 1 if pseudo register should be created and used to hold
+   GOT address for PIC code.  */
+static bool
+ix86_use_pseudo_pic_reg (void)
+{
+  if ((TARGET_64BIT
+   && (ix86_cmodel == CM_SMALL_PIC
+  || TARGET_PECOFF))
+  || !flag_pic)
+return false;
+  return true;
+}
+
 /* Update register usage after having seen the compiler flags.  */
 
 static void
@@ -4388,7 +4401,7 @@ ix86_conditional_register_usage (void)
 
   /* The PIC register, if it exists, is fixed.  */
   j = PIC_OFFSET_TABLE_REGNUM;
-  if (j != INVALID_REGNUM)
+  if (j != INVALID_REGNUM && !ix86_use_pseudo_pic_reg ())
 fixed_regs[j] = call_used_regs[j] = 1;
 
   /* For 32-bit targets, squash the REX registers.  */
@@ -6254,19 +6267,6 @@ ix86_maybe_switch_abi (void)
 reinit_regs ();
 }
 
-/* Return 1 if pseudo register should be created and used to hold
-   GOT address for PIC code.  */
-static bool
-ix86_use_pseudo_pic_reg (void)
-{
-  if ((TARGET_64BIT
-   && (ix86_cmodel == CM_SMALL_PIC
-  || TARGET_PECOFF))
-  || !flag_pic)
-return false;
-  return true;
-}
-
 /* Initialize large model PIC register.  */
 
 static void

Re: [patch] Fix warning during libstdc++ build

[Jonathan Wakely]

On 07/01/15 22:49 +, Jonathan Wakely wrote:

This fixes a -Wc++14-compat warning in the new libsupc++/del_ops.cc
file that defines the C++14 sized deallocation function.

Tested x86_64-linux, committed to trunk.



And another instance of the same warning.

Tested x86_64-linux, committed to trunk.

commit 3618d497ea61020de59464500c5cf38a52bc690a
Author: Jonathan Wakely 
Date:   Wed Jan 28 09:52:53 2015 +

	PR libstdc++/64828
	* libsupc++/Makefile.am: Compile del_opvs.cc as C++14.
	* libsupc++/Makefile.in: Regenerate.
	* src/c++11/Makefile.in: Regenerate.

diff --git a/libstdc++-v3/libsupc++/Makefile.am b/libstdc++-v3/libsupc++/Makefile.am
index aace1a6..b87ffbf 100644
--- a/libstdc++-v3/libsupc++/Makefile.am
+++ b/libstdc++-v3/libsupc++/Makefile.am
@@ -182,6 +182,10 @@ del_ops.lo: del_ops.cc
 	$(LTCXXCOMPILE) -std=gnu++14 -Wno-sized-deallocation -c $<
 del_ops.o: del_ops.cc
 	$(CXXCOMPILE) -std=gnu++14 -Wno-sized-deallocation -c $<
+del_opvs.lo: del_opvs.cc
+	$(LTCXXCOMPILE) -std=gnu++14 -Wno-sized-deallocation -c $<
+del_opvs.o: del_opvs.cc
+	$(CXXCOMPILE) -std=gnu++14 -Wno-sized-deallocation -c $<
 
 # AM_CXXFLAGS needs to be in each subdirectory so that it can be
 # modified in a per-library or per-sub-library way.  Need to manually
diff --git a/libstdc++-v3/libsupc++/Makefile.in b/libstdc++-v3/libsupc++/Makefile.in
index 50fee54..0ab0417 100644
--- a/libstdc++-v3/libsupc++/Makefile.in
+++ b/libstdc++-v3/libsupc++/Makefile.in
@@ -875,6 +875,10 @@ del_ops.lo: del_ops.cc
 	$(LTCXXCOMPILE) -std=gnu++14 -Wno-sized-deallocation -c $<
 del_ops.o: del_ops.cc
 	$(CXXCOMPILE) -std=gnu++14 -Wno-sized-deallocation -c $<
+del_opvs.lo: del_opvs.cc
+	$(LTCXXCOMPILE) -std=gnu++14 -Wno-sized-deallocation -c $<
+del_opvs.o: del_opvs.cc
+	$(CXXCOMPILE) -std=gnu++14 -Wno-sized-deallocation -c $<
 
 install-stdHEADERS: $(std_HEADERS)
 	@$(NORMAL_INSTALL)
diff --git a/libstdc++-v3/src/c++11/Makefile.in b/libstdc++-v3/src/c++11/Makefile.in
index 70d5bd7..12b6346 100644
--- a/libstdc++-v3/src/c++11/Makefile.in
+++ b/libstdc++-v3/src/c++11/Makefile.in
@@ -74,10 +74,10 @@ libc__11convenience_la_LIBADD =
 am__objects_2 = ctype_configure_char.lo ctype_members.lo
 am__objects_3 = chrono.lo codecvt.lo condition_variable.lo \
 	cow-stdexcept.lo ctype.lo debug.lo functexcept.lo \
-	functional.lo futex.lo future.lo hash_c++0x.lo hashtable_c++0x.lo \
-	ios.lo limits.lo mutex.lo placeholders.lo random.lo regex.lo \
-	shared_ptr.lo snprintf_lite.lo system_error.lo thread.lo \
-	$(am__objects_1) $(am__objects_2)
+	functional.lo futex.lo future.lo hash_c++0x.lo \
+	hashtable_c++0x.lo ios.lo limits.lo mutex.lo placeholders.lo \
+	random.lo regex.lo shared_ptr.lo snprintf_lite.lo \
+	system_error.lo thread.lo $(am__objects_1) $(am__objects_2)
 @ENABLE_DUAL_ABI_TRUE@am__objects_4 = cow-fstream-inst.lo \
 @ENABLE_DUAL_ABI_TRUE@	cow-sstream-inst.lo cow-string-inst.lo \
 @ENABLE_DUAL_ABI_TRUE@	cow-wstring-inst.lo cxx11-locale-inst.lo \

Re: [PATCH][x86] Update s{r,l}li intrinsics.

[Uros Bizjak]

On Wed, Jan 28, 2015 at 3:29 PM, Ilya Tocar  wrote:
> I'd like to backport this to 4.8/4.9
> Is this ok?

OK, since it just adds new inline function/define names for compatibility.

Uros.

> On 15 Jan 17:17, Ilya Tocar wrote:
>> Hi,
>> Looks like new ISA doc [1] renamed srli,slli intrinsics to bsrli,bslli.
>> This patch adds b* versions, while keeping old srli for backward
>> compatibility.
>> OK for trunk?
>>
>> 1:https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
>>
>> ChangeLog:
>> gcc/
>>   * config/i386/avx2intrin.h (_mm256_bslli_si256,
>>   _mm256_bsrli_si256): New.
>>   * config/i386/emmintrin.h (_mm_bsrli_si128, _mm_bslli_si128):
>>   Ditto.
>>
>> testsuite/
>>   * gcc.target/i386/sse-14.c: Test new intrinsic.
>>   * gcc.target/i386/sse-22.c: Diito.
>> ---
>>  gcc/config/i386/avx2intrin.h   | 18 ++
>>  gcc/config/i386/emmintrin.h| 16 
>>  gcc/testsuite/gcc.target/i386/sse-14.c |  2 ++
>>  gcc/testsuite/gcc.target/i386/sse-22.c |  4 
>>  4 files changed, 40 insertions(+)
>>
>> diff --git a/gcc/config/i386/avx2intrin.h b/gcc/config/i386/avx2intrin.h
>> index 669f1dc..8a30c5b 100644
>> --- a/gcc/config/i386/avx2intrin.h
>> +++ b/gcc/config/i386/avx2intrin.h
>> @@ -645,11 +645,20 @@ _mm256_sign_epi32 (__m256i __X, __m256i __Y)
>>  #ifdef __OPTIMIZE__
>>  extern __inline __m256i
>>  __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
>> +_mm256_bslli_si256 (__m256i __A, const int __N)
>> +{
>> +  return (__m256i)__builtin_ia32_pslldqi256 (__A, __N * 8);
>> +}
>> +
>> +extern __inline __m256i
>> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
>>  _mm256_slli_si256 (__m256i __A, const int __N)
>>  {
>>return (__m256i)__builtin_ia32_pslldqi256 (__A, __N * 8);
>>  }
>>  #else
>> +#define _mm256_bslli_si256(A, N) \
>> +  ((__m256i)__builtin_ia32_pslldqi256 ((__m256i)(A), (int)(N) * 8))
>>  #define _mm256_slli_si256(A, N) \
>>((__m256i)__builtin_ia32_pslldqi256 ((__m256i)(A), (int)(N) * 8))
>>  #endif
>> @@ -727,11 +736,20 @@ _mm256_sra_epi32 (__m256i __A, __m128i __B)
>>  #ifdef __OPTIMIZE__
>>  extern __inline __m256i
>>  __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
>> +_mm256_bsrli_si256 (__m256i __A, const int __N)
>> +{
>> +  return (__m256i)__builtin_ia32_psrldqi256 (__A, __N * 8);
>> +}
>> +
>> +extern __inline __m256i
>> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
>>  _mm256_srli_si256 (__m256i __A, const int __N)
>>  {
>>return (__m256i)__builtin_ia32_psrldqi256 (__A, __N * 8);
>>  }
>>  #else
>> +#define _mm256_bsrli_si256(A, N) \
>> +  ((__m256i)__builtin_ia32_psrldqi256 ((__m256i)(A), (int)(N) * 8))
>>  #define _mm256_srli_si256(A, N) \
>>((__m256i)__builtin_ia32_psrldqi256 ((__m256i)(A), (int)(N) * 8))
>>  #endif
>> diff --git a/gcc/config/i386/emmintrin.h b/gcc/config/i386/emmintrin.h
>> index ad37fac..b19f05a 100644
>> --- a/gcc/config/i386/emmintrin.h
>> +++ b/gcc/config/i386/emmintrin.h
>> @@ -1165,6 +1165,18 @@ _mm_srai_epi32 (__m128i __A, int __B)
>>
>>  #ifdef __OPTIMIZE__
>>  extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
>> __artificial__))
>> +_mm_bsrli_si128 (__m128i __A, const int __N)
>> +{
>> +  return (__m128i)__builtin_ia32_psrldqi128 (__A, __N * 8);
>> +}
>> +
>> +extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
>> __artificial__))
>> +_mm_bslli_si128 (__m128i __A, const int __N)
>> +{
>> +  return (__m128i)__builtin_ia32_pslldqi128 (__A, __N * 8);
>> +}
>> +
>> +extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
>> __artificial__))
>>  _mm_srli_si128 (__m128i __A, const int __N)
>>  {
>>return (__m128i)__builtin_ia32_psrldqi128 (__A, __N * 8);
>> @@ -1176,6 +1188,10 @@ _mm_slli_si128 (__m128i __A, const int __N)
>>return (__m128i)__builtin_ia32_pslldqi128 (__A, __N * 8);
>>  }
>>  #else
>> +#define _mm_bsrli_si128(A, N) \
>> +  ((__m128i)__builtin_ia32_psrldqi128 ((__m128i)(A), (int)(N) * 8))
>> +#define _mm_bslli_si128(A, N) \
>> +  ((__m128i)__builtin_ia32_pslldqi128 ((__m128i)(A), (int)(N) * 8))
>>  #define _mm_srli_si128(A, N) \
>>((__m128i)__builtin_ia32_psrldqi128 ((__m128i)(A), (int)(N) * 8))
>>  #define _mm_slli_si128(A, N) \
>> diff --git a/gcc/testsuite/gcc.target/i386/sse-14.c 
>> b/gcc/testsuite/gcc.target/i386/sse-14.c
>> index f3f6c5c..e8791e3 100644
>> --- a/gcc/testsuite/gcc.target/i386/sse-14.c
>> +++ b/gcc/testsuite/gcc.target/i386/sse-14.c
>> @@ -601,6 +601,8 @@ test_2 (_mm_alignr_pi8, __m64, __m64, __m64, 1)
>>
>>  /* emmintrin.h */
>>  test_2 (_mm_shuffle_pd, __m128d, __m128d, __m128d, 1)
>> +test_1 (_mm_bsrli_si128, __m128i, __m128i, 1)
>> +test_1 (_mm_bslli_si128, __m128i, __m128i, 1)
>>  test_1 (_mm_srli_si128, __m128i, __m128i, 1)
>>  test_1 (_mm_slli_si128, __m128i, __m128i, 1)
>>  test_1 (_mm_extract_epi16, int, __m128i, 1)
>> diff --git a/gcc/testsuite/gcc.targ

Re: [PATCH][x86] Update s{r,l}li intrinsics.

[Ilya Tocar]

I'd like to backport this to 4.8/4.9
Is this ok?

On 15 Jan 17:17, Ilya Tocar wrote:
> Hi,
> Looks like new ISA doc [1] renamed srli,slli intrinsics to bsrli,bslli.
> This patch adds b* versions, while keeping old srli for backward
> compatibility.
> OK for trunk?
> 
> 1:https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
> 
> ChangeLog:
> gcc/
>   * config/i386/avx2intrin.h (_mm256_bslli_si256,
>   _mm256_bsrli_si256): New.
>   * config/i386/emmintrin.h (_mm_bsrli_si128, _mm_bslli_si128):
>   Ditto.
> 
> testsuite/
>   * gcc.target/i386/sse-14.c: Test new intrinsic.
>   * gcc.target/i386/sse-22.c: Diito.
> ---
>  gcc/config/i386/avx2intrin.h   | 18 ++
>  gcc/config/i386/emmintrin.h| 16 
>  gcc/testsuite/gcc.target/i386/sse-14.c |  2 ++
>  gcc/testsuite/gcc.target/i386/sse-22.c |  4 
>  4 files changed, 40 insertions(+)
> 
> diff --git a/gcc/config/i386/avx2intrin.h b/gcc/config/i386/avx2intrin.h
> index 669f1dc..8a30c5b 100644
> --- a/gcc/config/i386/avx2intrin.h
> +++ b/gcc/config/i386/avx2intrin.h
> @@ -645,11 +645,20 @@ _mm256_sign_epi32 (__m256i __X, __m256i __Y)
>  #ifdef __OPTIMIZE__
>  extern __inline __m256i
>  __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> +_mm256_bslli_si256 (__m256i __A, const int __N)
> +{
> +  return (__m256i)__builtin_ia32_pslldqi256 (__A, __N * 8);
> +}
> +
> +extern __inline __m256i
> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
>  _mm256_slli_si256 (__m256i __A, const int __N)
>  {
>return (__m256i)__builtin_ia32_pslldqi256 (__A, __N * 8);
>  }
>  #else
> +#define _mm256_bslli_si256(A, N) \
> +  ((__m256i)__builtin_ia32_pslldqi256 ((__m256i)(A), (int)(N) * 8))
>  #define _mm256_slli_si256(A, N) \
>((__m256i)__builtin_ia32_pslldqi256 ((__m256i)(A), (int)(N) * 8))
>  #endif
> @@ -727,11 +736,20 @@ _mm256_sra_epi32 (__m256i __A, __m128i __B)
>  #ifdef __OPTIMIZE__
>  extern __inline __m256i
>  __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> +_mm256_bsrli_si256 (__m256i __A, const int __N)
> +{
> +  return (__m256i)__builtin_ia32_psrldqi256 (__A, __N * 8);
> +}
> +
> +extern __inline __m256i
> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
>  _mm256_srli_si256 (__m256i __A, const int __N)
>  {
>return (__m256i)__builtin_ia32_psrldqi256 (__A, __N * 8);
>  }
>  #else
> +#define _mm256_bsrli_si256(A, N) \
> +  ((__m256i)__builtin_ia32_psrldqi256 ((__m256i)(A), (int)(N) * 8))
>  #define _mm256_srli_si256(A, N) \
>((__m256i)__builtin_ia32_psrldqi256 ((__m256i)(A), (int)(N) * 8))
>  #endif
> diff --git a/gcc/config/i386/emmintrin.h b/gcc/config/i386/emmintrin.h
> index ad37fac..b19f05a 100644
> --- a/gcc/config/i386/emmintrin.h
> +++ b/gcc/config/i386/emmintrin.h
> @@ -1165,6 +1165,18 @@ _mm_srai_epi32 (__m128i __A, int __B)
>  
>  #ifdef __OPTIMIZE__
>  extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
> +_mm_bsrli_si128 (__m128i __A, const int __N)
> +{
> +  return (__m128i)__builtin_ia32_psrldqi128 (__A, __N * 8);
> +}
> +
> +extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
> +_mm_bslli_si128 (__m128i __A, const int __N)
> +{
> +  return (__m128i)__builtin_ia32_pslldqi128 (__A, __N * 8);
> +}
> +
> +extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
>  _mm_srli_si128 (__m128i __A, const int __N)
>  {
>return (__m128i)__builtin_ia32_psrldqi128 (__A, __N * 8);
> @@ -1176,6 +1188,10 @@ _mm_slli_si128 (__m128i __A, const int __N)
>return (__m128i)__builtin_ia32_pslldqi128 (__A, __N * 8);
>  }
>  #else
> +#define _mm_bsrli_si128(A, N) \
> +  ((__m128i)__builtin_ia32_psrldqi128 ((__m128i)(A), (int)(N) * 8))
> +#define _mm_bslli_si128(A, N) \
> +  ((__m128i)__builtin_ia32_pslldqi128 ((__m128i)(A), (int)(N) * 8))
>  #define _mm_srli_si128(A, N) \
>((__m128i)__builtin_ia32_psrldqi128 ((__m128i)(A), (int)(N) * 8))
>  #define _mm_slli_si128(A, N) \
> diff --git a/gcc/testsuite/gcc.target/i386/sse-14.c 
> b/gcc/testsuite/gcc.target/i386/sse-14.c
> index f3f6c5c..e8791e3 100644
> --- a/gcc/testsuite/gcc.target/i386/sse-14.c
> +++ b/gcc/testsuite/gcc.target/i386/sse-14.c
> @@ -601,6 +601,8 @@ test_2 (_mm_alignr_pi8, __m64, __m64, __m64, 1)
>  
>  /* emmintrin.h */
>  test_2 (_mm_shuffle_pd, __m128d, __m128d, __m128d, 1)
> +test_1 (_mm_bsrli_si128, __m128i, __m128i, 1)
> +test_1 (_mm_bslli_si128, __m128i, __m128i, 1)
>  test_1 (_mm_srli_si128, __m128i, __m128i, 1)
>  test_1 (_mm_slli_si128, __m128i, __m128i, 1)
>  test_1 (_mm_extract_epi16, int, __m128i, 1)
> diff --git a/gcc/testsuite/gcc.target/i386/sse-22.c 
> b/gcc/testsuite/gcc.target/i386/sse-22.c
> index 0d7bd16..5735514 100644
> --- a/gcc/testsuite/gcc.target/i386/sse-22.c
> +++ b/gcc/testsuite/gcc.target/i386/sse-22.c
> @@ -138,6 +138,8 @@ test_1 (_mm_prefetch, void, void *, _MM_HINT_NT

Re: [COMMITTED] Merge libffi with upstream

[Dominique Dhumieres]

> This patch worked for me.  Ok for mainline now? (r220158)

This causes 340 new tests on darwin with -m32, 255 of them failing when 
executes,
see https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03197.html.

Are the tests with '-DABI_NUM=*' supposed to work on darwin?

If yes, I'll open a PR; if no, could they be disabled for darwin.

TIA

Dominique

[PATCH] Fix PR64829

[Richard Biener]

This fixes PR64829 where widening shift pattern detection fails to
verify the widening operation is used only in the shift.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2015-01-28  Richard Biener  

PR tree-optimization/64829
* tree-vect-patterns.c (vect_recog_widen_shift_pattern): Check
that the shift operand has a single use only.

* gcc.dg/vect/pr64829.c: New testcase.

Index: gcc/tree-vect-patterns.c
===
--- gcc/tree-vect-patterns.c(revision 220205)
+++ gcc/tree-vect-patterns.c(working copy)
@@ -1732,9 +1732,11 @@ vect_recog_widen_shift_pattern (vec (4) ? (8) : (4))];
+
+  pOut = pOutColor->dataRef.data8;
+  pClutData = pColorTable->dataRef.data8;
+
+  nCompOut = pColorTable->dataCompsOut;
+
+  pCornerPoint0 = pClutData;
+
+  for (comp = 0; comp < nCompOut; comp++)
+{
+  val0 = *pCornerPoint0++;
+
+  result = val0 << 4;
+
+  result += (val1 - val0) * interpFrac1;
+  result += (val2 - val1) * interpFrac2;
+  result += (val3 - val2) * interpFrac3;
+
+  *pOut++ = lastOut[comp] = (Uint8)(result >> 4);
+}
+
+  return (0);
+}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */

Re: [fixincludes] Fix signbit on Solaris

[Rainer Orth]

Hi Bruce,

this thread is more than half a year old now, but with the GCC 5 release
approaching, we should reach some conclusion.

> On Tue, Jul 1, 2014 at 4:22 AM, Rainer Orth  
> wrote:
>>> It's not yet in autogen 5.9: I've diffed the fixincl.x generated with my
>>> original patch and the amended one and those backslashes after the
>>> leading tab are still there.
>
> 5.9 is 7 years old now.  However, I just looked up the change.  I did
> it 2 years ago.
> It would mean bumping the requirement to 5.17.4, from a mere 1 year ago.
>
>> I've now managed to build autogen 5.18.3 on Solaris 11, but still there
>
> Please send your "managed to build" stories.
> If they are not Guile related, I can try to clean 'em up.
> Building Guile is not for the feint of heart.
>
>> is some trouble: with the following fix
>>
>> /*
>>  * Newer Solaris 10/11 GCC signbit implementations cause strict-aliasing
>>  * warnings.
>>  */
>> fix = {
> [...]
>> };
>>
>> the test passes (not ran a bootstrap yet).  But I had to make two
>> unexpected changes:
>>
>> * In the second c_fix_arg, all \t in charsets had to be replaced by
>>   literal TABs, otherwise they would occur as \\t in fixincl.x.
>
> I made the "here string" largely similar to the shell "here doc",
> excepting there is no such thing as shell expansions (${var} stuff)
> and I (now) erase that backslash-before-whitespace thingy.
>
>> * In test_text, I had to backslash-escape the trailing \, otherwise they
>>   were eaten up.  Whether or not I do this makes no difference for the
>>   generated fixincl.x, but only with the escaping does make check pass.
>
> Right.  It likely gets massaged by a shell script somewhere.
> I'd need to look up how "test-text" gets used in the template.

Did you have a chance to do that yet?

>>> I'm currently fighting to build autogen 5.18.3 and all its dependencies.
>>> Trouble is, if we do require a version newer than 5.5.4 as documented in
>>> install.texi, fixincludes make check will suddenly start to fail for
>>> those whose autogen version isn't recent enough.
>
> Every decade or so it ought to be possible to update by a few years.
>
>> This is certainly something that needs to be decided: if we go this
>> route, we should bump the autogen version requirement in install.texi
>> (to whatever is necessary to support the TAB\ magic).
>
> I think Debian stable has moved up to 5.18.2, if I am remembering
> correctly.  It's a year old (last fall).  I think that is old enough to
> have been spread around by now.

It's your call ultimately.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH][AArch64] Fix illegal assembly 'eon v1, v2, v3'

[James Greenhalgh]

On Wed, Jan 28, 2015 at 12:32:45PM +, Alan Lawrence wrote:
> Ok for stage 4?

This is a regression from 4.9, so once we iron out some nits, it should
be.

> gcc/ChangeLog:
> 
>   * config/aarch64/aarch64.md (*xor_one_cmpl3): Use FP_REGNUM_P
>   as split condition.

And a testcase, please!

> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 
> bc49fbe68a978b3ca069c6d084f542773df84bcb..d4b3f7b03ba0ab570cec5ce862e8c5f38f417ed1
>  100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -3054,7 +3054,7 @@
>(match_operand:GPI 2 "register_operand" "r,w"]
>""
>"eon\\t%0, %1, %2" ;; For GPR registers (only).

This should be:
"@
 eon\\t%0, %1, %2
 #"

which would have forced a split.

Your patch is useful regardless, as I guess we could have ended up
needlessly splitting if we got unlucky with whatever had been left
in which_alternative.

Thanks,
James

> -  "reload_completed && (which_alternative == 1)" ;; For SIMD registers.
> +  "reload_completed && FP_REGNUM_P (REGNO (operands[0]))" ;; For SIMD 
> registers.
>[(set (match_operand:GPI 0 "register_operand" "=w")
>  (xor:GPI (match_operand:GPI 1 "register_operand" "w")
>   (match_operand:GPI 2 "register_operand" "w")))

[PATCH][libstdc++][testsuite][reverted] Remove check for truncation overflow

[Kyrill Tkachov]

Hi all,

This patch reverts the libstdc++ hunk of 
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00768.html, that is the check
for relocation truncation and the marking of the test as UNSUPPORTED if 
it occurs.
The problem with this approach is that when we call 'unsupported 
"message"' in the .exp file the test is marked as
UNSUPPORTED, but since we return the empty string, the test harness adds 
a PASS (test for excess errors) and marks it as
UNRESOLVED. So instead of having a FAIL+UNRESOLVED for each test we get 
an UNSUPPORTED+PASS+UNRESOLVED.
While it's nice to not have the FAILs, the latter combination confuses 
various results compare scripts and is not very helpful.


I couldn't figure out a way to remove the PASS+UNRESOLVED part from the 
libstdc++ testsuite and leave just the UNSUPPORTED message,

so I'm reverting that check until I figure out how to do it properly.
AFAIK this doesn't affect anything beyond aarch64 tests with -mcmodel=tiny

Committed with r220206.

Thanks,
Kyrill

2015-01-28  Kyrylo Tkachov  

* testsuite/lib/libstdc++.exp (v3_target_compile): Remove
check for unsupported.
(v3_target_compile_as_c): Likewise.diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 05ca7d9..b2f7d00 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -486,12 +486,7 @@ proc v3_target_compile { source dest type options } {
 lappend options "timeout=[timeout_value]"
 
 set comp_output [target_compile $source $dest $type $options]
-set unsupported_message [${tool}_check_unsupported_p $comp_output]
 
-if { $unsupported_message != "" } {
-  unsupported "$dest: $unsupported_message"
-  return ""
-}
 return $comp_output
 }
 
@@ -562,12 +557,7 @@ proc v3_target_compile_as_c { source dest type options } {
 lappend options "timeout=[timeout_value]"
 
 set comp_output [target_compile $source $dest $type $options]
-set unsupported_message [${tool}_check_unsupported_p $comp_output]
 
-if { $unsupported_message != "" } {
-  unsupported "$dest: $unsupported_message"
-  return ""
-}
 return $comp_output
 }
 

[testsuite] Run guality tests on Solaris

[Rainer Orth]

Since the testsuite parallelism has been massively increased some time
ago, I'm seing lots of timeouts on slower SPARC hardware (1.2 Ghz
UltraSPARC-T2).  Closer investigation revealed that this happens on
Solaris everywhere, though not so badly that the testsuite 300 second
timeout hits.  The check_guality test in gcc.dg/guality and
g++.dg/guality times out every time.

It turns out that while the gfortran.dg/guality test do run, the gcc.dg
and g++.dg ones don't.  Running check_guality under truss shows that gdb
complains

No symbol table is loaded.  Use the "file" command.

and loops from there, unlike gfortran.dg where the command name is
passed to gdb.  No idea why this doesn't happen on Linux, but the
problem is easily cured by adding the command name (which is the actual
executable gdb tries to attach to) to the gdb command line.

This makes the guality tests run sucessfully on Solaris, even on the
slow T2 box.

However, the guality tests show dozens or even hundreds of FAILs and/or
XPASSes, adding insane amounts of noise to the testsuite results, which
nobody seems to be looking into.  So I wonder what the best course of
action is here: one might consider running them only when a
GCC_TEST_RUN_GUALITY environment variable is set, but skip them by
default until someone acutally interested in improving results here
shows up.

Thoughts?

Anyway, here's the patch I've used.

Ok for mainline?

Rainer


2015-01-28  Rainer Orth  

gcc/testsuite:
* gcc.dg/guality/guality.h (main): Add argv[0] to
guality_gdb_command.

# HG changeset patch
# Parent 26a271b29df9b72e6fbdb554a6a8b5e00d94e5ee
Skip guality tests on Solaris

diff --git a/gcc/testsuite/g++.dg/guality/guality.exp b/gcc/testsuite/g++.dg/guality/guality.exp
--- a/gcc/testsuite/g++.dg/guality/guality.exp
+++ b/gcc/testsuite/g++.dg/guality/guality.exp
@@ -5,7 +5,7 @@ load_lib gcc-gdb-test.exp
 
 # Disable on darwin until radr://7264615 is resolved.
 if { [istarget *-*-darwin*] } {
-  return
+return
 }
 
 if { [istarget "powerpc-ibm-aix*"] } {
diff --git a/gcc/testsuite/gcc.dg/guality/guality.exp b/gcc/testsuite/gcc.dg/guality/guality.exp
--- a/gcc/testsuite/gcc.dg/guality/guality.exp
+++ b/gcc/testsuite/gcc.dg/guality/guality.exp
@@ -5,7 +5,7 @@ load_lib gcc-gdb-test.exp
 
 # Disable on darwin until radr://7264615 is resolved.
 if { [istarget *-*-darwin*] } {
-  return
+return
 }
 
 if { [istarget "powerpc-ibm-aix*"] } {
diff --git a/gcc/testsuite/gcc.dg/guality/guality.h b/gcc/testsuite/gcc.dg/guality/guality.h
--- a/gcc/testsuite/gcc.dg/guality/guality.h
+++ b/gcc/testsuite/gcc.dg/guality/guality.h
@@ -228,6 +228,16 @@ main (int argc, char *argv[])
 	}
 }
 
+  if (argv[0])
+{
+  int len = strlen (guality_gdb_command) + 1 + strlen (argv[0]);
+  char *buf = (char *) __builtin_alloca (len);
+  strcpy (buf, guality_gdb_command);
+  strcat (buf, " ");
+  strcat (buf, argv[0]);
+  guality_gdb_command = buf;
+}
+
   for (i = 1; i < argc; i++)
 if (strcmp (argv[i], "--guality-skip") == 0)
   guality_skip = 1;

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[PATCH][AArch64] Fix illegal assembly 'eon v1, v2, v3'

[Alan Lawrence]

Hi,

The split rule introduced in r218961 uses as its split condition 
'reload_completed && (which_alternative == 1)', but which_alternative does not 
seem to be set reliably during split phases, even after reload. This can lead 
to the split rule not being used even for insns using FP/SIMD registers and 
hence illegal assembler such as 'eon v1, v2, v3'.


The eon_1.c testcase has still been passing but I suspect this relies on some 
other part of the compiler having coincidentally set which_alternative to the 
right value. The failure can be seen with e.g.


#include 

#define force_simd(V1) asm volatile ("mov %d0, %1.d[0]" \
: "=w"(V1) \
: "w"(V1)  \
: /* No clobbers */)

int foo(int64x1_t val4, int64x1_t val6, int64x1_t val7)
{
  int64x1_t val5 = vbic_s64 (val4,
 veor_s64 (val6,
   vsri_n_s64 (val6, val7, 13)));
  force_simd (val5);
  return vget_lane_s64 (val5, 0) == 0 ? 1 : 0;
}

...and on similar examples I have seen cases with reload_completed==1 and 
which_alternative in (-1, 0, 10} yet the insn having register numbers allocated 
within the FP/SIMD register file!


This case was OK with gcc4.9, however, I don't think we have much to gain from 
adding this as a testcase: it depends too much on tickling the register 
allocator and other parts of the compiler to do the right/wrong thing (hence the 
existing eon_1.c testcase still passing), and would do nothing to catch any uses 
of which_alternative in any other split conditions.


Hence, this patch just changes the split condition to use FP_REGNUM_P instead.

Ok for stage 4?

Cheers, Alan

gcc/ChangeLog:

* config/aarch64/aarch64.md (*xor_one_cmpl3): Use FP_REGNUM_P
as split condition.diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index bc49fbe68a978b3ca069c6d084f542773df84bcb..d4b3f7b03ba0ab570cec5ce862e8c5f38f417ed1 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -3054,7 +3054,7 @@
   (match_operand:GPI 2 "register_operand" "r,w"]
   ""
   "eon\\t%0, %1, %2" ;; For GPR registers (only).
-  "reload_completed && (which_alternative == 1)" ;; For SIMD registers.
+  "reload_completed && FP_REGNUM_P (REGNO (operands[0]))" ;; For SIMD registers.
   [(set (match_operand:GPI 0 "register_operand" "=w")
 (xor:GPI (match_operand:GPI 1 "register_operand" "w")
  (match_operand:GPI 2 "register_operand" "w")))

Re: [PATCH] libiberty/argv.c: Use freeargv() instead of free() to avoid memory leak.

[Andrew Burgess]

* Chen Gang S  [2015-01-28 19:34:38 +0800]:

>  libiberty/argv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libiberty/argv.c b/libiberty/argv.c
> index f2727e8..9fdd55b 100644
> --- a/libiberty/argv.c
> +++ b/libiberty/argv.c
> @@ -454,7 +454,7 @@ expandargv (int *argcp, char ***argvp)
>/* Free up memory allocated to process the response file.  We do
>not use freeargv because the individual options in FILE_ARGV
>are now in the main ARGV.  */
> -  free (file_argv);
> +  freeargv (file_argv);

I'm not commenting on the correctness of the patch, however, you will
need to update the comment just above this change.

Personally, I'd also hope that the commit message explains why the
comment is no longer correct, rather than just stating that the change
has been made.

Thanks,
Andrew

[PATCH] Fix libjava version number under cygwin

[Bernd Edlinger]

Hi,


after the recent version bump of the libjava libraries, java under cygwin is 
broken.

The reason is that libgcc/config/i386/cygming-crtbegin.c needs to know the exact
version number to load the symbol _Jv_RegisterClasses from cyggcj-16.dll.

This patch fixes the cyggcj-xx.dll version numbers for cygwin and mingw32 again.

Boot-strapped with java under x86_64-pc-cygwin.
OK for trunk?


Thanks
Bernd.
  

patch-java-cygwin.diff
Description: Binary data