[committed] hppa: Fix conflict between -pg and -mlong-call options

[John David Anglin]

The attached patch fixes an oversight in hppa_profile_hook.  We need to 
mark the SYMBOL_REF
for _mcount as a function label.  When the -mlong-call option is used, 
the call to _mcount is converted
to an indirect call.  In that case, we need the function pointer to 
point to a procedure label
which points to a function descriptor.  This is necessary to correctly 
load the PIC register.  Marking

the SYMBOL_REF causes this to happen.

Tested on hppa-unknown-linux-gnu with no regressions.  Committed to trunk.

This bug caused a build error for gcl.  Thanks to Camm Maguire for 
debugging the problem.


Dave

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

2018-02-10  John David Anglin  

* config/pa/pa.c (hppa_profile_hook): Mark SYMBOL_REF for _mcount as
function label.

Index: config/pa/pa.c
===
--- config/pa/pa.c  (revision 257545)
+++ config/pa/pa.c  (working copy)
@@ -4578,13 +4578,17 @@
  lcla2 and load_offset_label_address insn patterns.  */
   rtx reg = gen_reg_rtx (SImode);
   rtx_code_label *label_rtx = gen_label_rtx ();
-  rtx mcount = gen_rtx_MEM (Pmode, gen_rtx_SYMBOL_REF (Pmode, "_mcount"));
   int reg_parm_stack_space = REG_PARM_STACK_SPACE (NULL_TREE);
-  rtx arg_bytes, begin_label_rtx;
+  rtx arg_bytes, begin_label_rtx, mcount, sym;
   rtx_insn *call_insn;
   char begin_label_name[16];
   bool use_mcount_pcrel_call;
 
+  /* Set up call destination.  */
+  sym = gen_rtx_SYMBOL_REF (Pmode, "_mcount");
+  pa_encode_label (sym);
+  mcount = gen_rtx_MEM (Pmode, sym);
+
   /* If we can reach _mcount with a pc-relative call, we can optimize
  loading the address of the current function.  This requires linker
  long branch stub support.  */

Re: [PATCH] Character length cleanup for Coarray Fortran library

[Janne Blomqvist]

On Sat, Feb 10, 2018 at 9:34 PM, Damian Rouson
 wrote:
>
> I’ll try applying the patch and testing it.

As such, I'm sure that will fail as the patch changes the coarray API
and thus needs corresponding changes on the OpenCoarrays side as well.

>  I have about a 50% success rate with getting patches to apply cleanly.  Is 
> this available on an svn or git branch that I can just checkout rather than 
> attempting to apply the patch?  I find that process to be much more reliable.
>
> Going forward, please submit OpenCoarrays questions or issues via our issues 
> page:
>
> https://github.com/sourceryinstitute/OpenCoarrays/issues

Ok, I just filed https://github.com/sourceryinstitute/OpenCoarrays/issues/497

> Most OpenCoarrays contributors don’t monitor the gfortran mailing list 
> closely so we’re unlikely to see emails to the list in a timely manner.
>
> Also, when making changes that impact OpenCoarrays, please build OpenCoarrays 
> and run our test suite.  We recently made several changes to our installation 
> documentation and installer script based on feedback received from Steve 
> Kargl.  One result is a set of instructions written by Zaak with GCC 
> developers as an intended audience:
>
> https://github.com/sourceryinstitute/OpenCoarrays/blob/master/INSTALL
>
> Several other installation changes inspired by Steve’s feedback are listed 
> here:
>
> https://github.com/sourceryinstitute/OpenCoarrays/issues/478
>
> and these will make it into a release shortly, but are already all available 
> via git clone. I’m looking forward to hosting Oxford University Ph.D. student 
> Daniel Garza, from March 17 to June 2, to work on finishing the integration 
> of OpenCoarrays into the GCC autotools scripts so that OpenCoarrays will be 
> built anytime gfortran is built so hopefully it will be even easier for 
> everyone to build and test with OpenCoarrays soon.

Thanks; I should look into building opencoarrays at some point. For
this patch I was hoping that someone familiar with the OpenCoarrays
code base could do the equivalent fix there and test it, as it rather
mechanical and simple.


-- 
Janne Blomqvist

Re: [PATCH] Character length cleanup for Coarray Fortran library

[Damian Rouson]

 
I’ll try applying the patch and testing it.  I have about a 50% success rate 
with getting patches to apply cleanly.  Is this available on an svn or git 
branch that I can just checkout rather than attempting to apply the patch?  I 
find that process to be much more reliable. 

Going forward, please submit OpenCoarrays questions or issues via our issues 
page:

https://github.com/sourceryinstitute/OpenCoarrays/issues  

Most OpenCoarrays contributors don’t monitor the gfortran mailing list closely 
so we’re unlikely to see emails to the list in a timely manner.  

Also, when making changes that impact OpenCoarrays, please build OpenCoarrays 
and run our test suite.  We recently made several changes to our installation 
documentation and installer script based on feedback received from Steve Kargl. 
 One result is a set of instructions written by Zaak with GCC developers as an 
intended audience:  

https://github.com/sourceryinstitute/OpenCoarrays/blob/master/INSTALL  

Several other installation changes inspired by Steve’s feedback are listed 
here:  

https://github.com/sourceryinstitute/OpenCoarrays/issues/478  

and these will make it into a release shortly, but are already all available 
via git clone. I’m looking forward to hosting Oxford University Ph.D. student 
Daniel Garza, from March 17 to June 2, to work on finishing the integration of 
OpenCoarrays into the GCC autotools scripts so that OpenCoarrays will be built 
anytime gfortran is built so hopefully it will be even easier for everyone to 
build and test with OpenCoarrays soon.  

Damian 


On February 9, 2018 at 8:11:07 AM, Janne Blomqvist 
(blomqvist.ja...@gmail.com(mailto:blomqvist.ja...@gmail.com)) wrote:

> Following the change to use size_t for Fortran character lengths (PR
> 78534), this patch modifies the Coarray ABI in a similar way. The
> single-image implementation that is included in libgfortran is
> updated, but this needs corresponding work in the OpenCoarray library
> as well for multi-image support. Damian, can you look into that?
>  
> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
>  
> gcc/fortran/ChangeLog:
>  
> 2018-02-09 Janne Blomqvist  
>  
> * gfortran.texi: Update Coarray API description.
> * trans-decl.c (gfc_build_builtin_function_decls): Use size_t for
> character lengths, int for exit codes.
> (generate_coarray_sym_init): Use size_t for character length.
> * trans-intrinsic.c (conv_co_collective): Likewise.
> * trans-stmt.c (gfc_trans_lock_unlock): Likewise.
> (gfc_trans_event_post_wait): Likewise.
> (gfc_trans_sync): Likewise.
>  
> libgfortran/ChangeLog:
>  
> 2018-02-09 Janne Blomqvist  
>  
> * caf/libcaf.h: Remove stdint.h include.
> (_gfortran_caf_register): Use size_t for character length.
> (_gfortran_caf_deregister): Likewise.
> (_gfortran_caf_sync_all): Likewise.
> (_gfortran_caf_sync_memory): Likewise.
> (_gfortran_caf_sync_images): Likewise.
> (_gfortran_caf_stop_numeric): Use int for exit code.
> (_gfortran_caf_stop_str): Use size_t for character length.
> (_gfortran_caf_error_stop_str): Likewise.
> (_gfortran_caf_error_stop): Use int for exit code.
> (_gfortran_caf_co_broadcast): Use size_t for character length.
> (_gfortran_caf_co_sum): Likewise.
> (_gfortran_caf_co_min): Likewise.
> (_gfortran_caf_co_max): Likewise.
> (_gfortran_caf_co_reduce): Likewise.
> (_gfortran_caf_lock): Likewise.
> (_gfortran_caf_unlock): Likewise.
> (_gfortran_caf_event_post): Likewise.
> (_gfortran_caf_event_wait): Likewise.
> * caf/mpi.c (_gfortran_caf_register): Update implementation to
> match prototype.
> (_gfortran_caf_deregister): Likewise.
> (_gfortran_caf_sync_all): Likewise.
> (_gfortran_caf_sync_images): Likewise.
> (_gfortran_caf_error_stop_str): Likewise.
> (_gfortran_caf_error_stop): Likewise.
> * caf/single.c (caf_internal_error): Likewise.
> (_gfortran_caf_register): Likewise.
> (_gfortran_caf_deregister): Likewise.
> (_gfortran_caf_sync_all): Likewise.
> (_gfortran_caf_sync_memory): Likewise.
> (_gfortran_caf_sync_images): Likewise.
> (_gfortran_caf_stop_numeric): Likewise.
> (_gfortran_caf_stop_str): Likewise.
> (_gfortran_caf_error_stop_str): Likewise.
> (_gfortran_caf_error_stop): Likewise.
> (_gfortran_caf_co_broadcast): Likewise.
> (_gfortran_caf_co_sum): Likewise.
> (_gfortran_caf_co_min): Likewise.
> (_gfortran_caf_co_max): Likewise.
> (_gfortran_caf_co_reduce): Likewise.
> (_gfortran_caf_event_post): Likewise.
> (_gfortran_caf_event_wait): Likewise.
> (_gfortran_caf_lock): Likewise.
> (_gfortran_caf_unlock): Likewise.
> ---
> gcc/fortran/gfortran.texi | 32 -
> gcc/fortran/trans-decl.c | 38 +++---
> gcc/fortran/trans-intrinsic.c | 4 ++--
> gcc/fortran/trans-stmt.c | 12 +-
> libgfortran/caf/libcaf.h | 37 ++---
> libgfortran/caf/mpi.c | 28 +++---
> libgfortran/caf/single.c | 55 ++-
> 7 files changed, 103 insertions(+), 103 deletions(-)
>  
> diff --git 

Re: [PATCH] POPCOUNT folding optimizations

[Jeff Law]

On 02/09/2018 05:42 AM, Roger Sayle wrote:
> 
> The following patch implements a number of __builtin_popcount related
> optimizations.
> (i) popcount(x) == 0 can be simplified to x==0, and popcount(x) != 0 to
> x!=0.
> (ii) popcount(x&1) can be simplified to x&1, and for unsigned x,
> popcount(x>>31) to x>>31.
> (iii) popcount (x&6) + popcount(y&16) can be simplified to
> popcount((x&6)|(y&16))
> 
> These may seem obscure transformations, but performing these types of
> POPCOUNT
> operations are often the performance critical steps in some cheminformatics
> applications.
> 
> To implement the above transformations I've introduced the tree_nonzero_bits
> function,
> which is a tree-level version of rtlanal's nonzero_bits used by the RTL
> optimizers.
> 
> The following patch has been tested on x86_64-pc-linux-gnu with a "make
> bootstrap"
> and "make check" with no regressions, and passes for the four new gcc.dg
> test cases.
> 
> Many thanks In advance.  Best regards,
> 
> Roger
> --
> Roger Sayle, PhD.
> NextMove Software Limited
> Innovation Centre (Unit 23), Cambridge Science Park, Cambridge, CB4 0EY
> 
> 2018-02-09  Roger Sayle  
> 
> * fold-const.c (tree_nonzero_bits): New function.
> * fold-const.h (tree_nonzero_bits): Likewise.
> * match.pd (POPCOUNT): New patterns to fold BUILTIN_POPCOUNT and
> friends.  POPCOUNT(x&1) => x&1, POPCOUNT(x)==0 => x==0, etc.
> 
> 2018-02-09  Roger Sayle  
> 
> * gcc.dg/fold-popcount-1.c: New testcase.
> * gcc.dg/fold-popcount-2.c: New testcase.
> * gcc.dg/fold-popcount-3.c: New testcase.
> * gcc.dg/fold-popcount-4.c: New testcase.
Queued for stage1.  THanks Roger.  I hope things are going well.

jeff

Re: [LVU] use asm .loc and get gas to compute views on the side

[Jakub Jelinek]

On Sat, Feb 10, 2018 at 09:26:47AM -0700, Jeff Law wrote:
> > I think it makes sense to disable them by default if gas doesn't support
> > them with that ability to override the auto detection by a configure
> > switch (get the GCC generated ones).  The patch looks too heavy for this
> > stage and as you say we lack support on the consumer side anyways.  We
> > can revisit this patch for GCC 9 or simply document the recommendation
> > of using gas 2.30 or newer.

> Seems reasonable to me as well.

We should have a switch to force gcc generated .debug_line in any case,
similarly how we have -fno-dwarf2-cfi-asm.
E.g. only the gcc generated .debug_line can do DWARF5 .debug_line right now,
gas generated one can't.

Jakub

Re: [Patch, fortran] PR 56691 - [OOP] Allocatable array: wrong offset when passing to CLASS dummy

[Paul Richard Thomas]

Hi All,

Committed as revision 257550. In the course of testing this patch,
Dominique found some problems that turned out to be due to revision
r257065. These latter were encapsulated in PR84155, which was fixed
257356. However, Richi pointed me in the direction of a much cleaner
fix to this PR and it seems that the failing tests that Dominique
found survive this patch :-)

Paul


2018-02-10  Paul Thomas  

PR fortran/84141
PR fortran/84155
* trans-array.c (gfc_array_init_size): Revert the change made
in revision 257356 setting the dtype.
* trans-types.c (gfc_get_dtype): Do not use the cached dtype.
Call gfc_get_dtype_rank_type every time.

PR fortran/56691
* trans-array.c (gfc_conv_expr_descriptor): If the source array
is a descriptor type, use its offset, removing the condition
that is be a class expression.

2018-02-10  Paul Thomas  

PR fortran/56691
* gfortran.dg/type_to_class_4.f03: New test.

On 27 January 2018 at 12:41, Paul Richard Thomas
 wrote:
> I am worried that this fix seems to easy by half and so I am posting
> it for approval, rather than committing it as obvious. I would be
> obliged if somebody would test it thoroughly.
>
> Bootstraps and regtests on FC23/x86_64 - OK for trunk and 7 branch?
>
> Paul
>
> 2018-27-01  Paul Thomas  
>
> PR fortran/56691
> * trans-array.c (gfc_conv_expr_descriptor): If the source array
> is a descriptor type, use its offset, removing the condition
> that is be a class expression.
>
> 2018-27-01  Paul Thomas  
>
> PR fortran/56691
> * gfortran.dg/type_to_class_4.f03: New test.



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

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

[Jeff Law]

On 02/10/2018 05:34 AM, Alexandre Oliva wrote:
> Hi, Joseph,
> 
> On Feb  9, 2018, Joseph Myers  wrote:
> 
>> sh4 is:
>> during RTL pass: final
>> In file included from strtof_l.c:45:
>> strtod_l.c: In function 'strtof_l_internal':
>> strtod_l.c:1769:1: internal compiler error: Segmentation fault
>>  }
>>  ^
>> 0xb98e3f crash_signal
>> /scratch/jmyers/glibc-bot/src/gcc/gcc/toplev.c:325
>> 0x856b18 maybe_output_next_view
>> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:1726
>> 0x856b18 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
>> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2714
>> 0xef36bc print_slot
>> /scratch/jmyers/glibc-bot/src/gcc/gcc/config/sh/sh.c:2557
>> 0xef6520 output_far_jump(rtx_insn*, rtx_def*)
>> /scratch/jmyers/glibc-bot/src/gcc/gcc/config/sh/sh.c:2617
>> 0x857098 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
>> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:3101
>> 0x856c26 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
>> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2806
>> 0x858469 final_1
>> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2088
>> 0x8591d8 rest_of_handle_final
>> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:4637
>> 0x8591d8 execute
>> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:4711
> 
>> Since it's in maybe_output_next_view, I think it probably comes from these 
>> patches.
> Thanks for the backtraces.  The problem is that ports call
> final_scan_insn recursively passing NULL for seen, but now there is code
> that actually cares about carrying information around in it.  I decided
> against silencing the errors by testing seen for non-NULL before
> dereferencing it, and instead arranging for the outermost pointer to be
> recovered in recursive calls.  I hope this is enough to cover all the
> cases of final_scan_insn being called from ports.  Could you possibly
> give it a spin, pretty please with sugar on top? ;-)  Thanks a ton,
> 
> (I'll provide a ChangeLog for formal review and hopefully approval once
> it has gone through more than my initial smoke testing on x86_64, but my
> own testing will take some time, and I wanted to give you something that
> at least stood a chance of fixing the problem before crashing in bed :-)
> 
> 
> [LVU] deal with md final_scan_insn
> 
> From: Alexandre Oliva 
> 
> Ports call final_scan_insn with seen == NULL, and then
> maybe_output_next_view crashes because it assumes it's
> non-NULL.  Oops.  Fixed.
A bit icky.  But OK.

Jeff

Re: [PATCH] Fix handling of arguments in statement functions

[Steve Kargl]

On Sat, Feb 10, 2018 at 09:46:57AM -0800, Steve Kargl wrote:
> 
>   PR fortran/35299
>   * gfortran.dg/statement_function_3.f: New test.

This patch should be credited to FX.  I've added

2018-02-10  Francois-Xavier Coudert  

to the ChangeLog entry.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: [PATCH] Improve pow (C, x) -> exp (log (C) * x) optimization (PR middle-end/84309)

[Jakub Jelinek]

On Sat, Feb 10, 2018 at 12:29:42PM +0100, Richard Biener wrote:
> On February 10, 2018 10:44:37 AM GMT+01:00, Jakub Jelinek  
> wrote:
> >On Sat, Feb 10, 2018 at 08:00:04AM +0100, Richard Biener wrote:
> >> On February 10, 2018 12:37:38 AM GMT+01:00, Jakub Jelinek
> > wrote:
> >> >Hi!
> >> >
> >> >Apparently the new pow(C,x) -> exp(log(C)*x) if C > 0 optimization
> >> >breaks some package (Marek should know which), as it has 7ulp error.
> >> >Generally one should be prepared for some errors with -ffast-math.
> >> >
> >> >Though, in this case, if the target has c99 runtime and C is
> >> >a positive 0x1pNN it seems much better to use exp2 over exp, for
> >> >C being 2 pow (2, x) is optimized into exp2 (x) and even for other
> >> >values log2(C) will still be some positive or negative integer, so
> >> >in many cases there won't be any rounding errors in the
> >multiplication.
> >> >
> >> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >> 
> >> OK. I wonder whether there are vectorized variants in libmvec? 
> >
> >Unfortunately libmvec only provides pow and exp, not exp2 nor exp10.
> 
> So maybe delay this folding then, there's already two phases we do for
> math functions.  Not sure if they conveniently align with vectorization...

How would that delay look like?
If use_exp2 is true and (cfun->curr_properties & PROP_gimple_lvec) == 0,
don't fold it?  Then I guess if we vectorize or slp vectorize the pow
as vector pow, we'd need to match.pd it into the exp (log (vec_cst) * x).

Jakub

[PATCH] Fix handling of arguments in statement functions

[Steve Kargl]

All,

The attach patch address 3 issues with statement functions.
First, a dummy argument in a statement function declarations
acquires only its type and type parameters from the containing
scope.  All attributes should be ignores.  The first fix for
PR fortran/84276 disables a check for the INTENT(INOUT,OUT) 
attribute.  The second fix for PR fortran/54223 disables a 
check for missing OPTIONAL arguments as an argument to a 
statement function cannot be optional.

In reviewing the bugs for statement functions, I came across
PR fortran/35229.  There is a long audit trail, but I have come
to agree with comment #3 from FX.  I have taken his suggested
patch for updating the error message.  Note, this issue is 
10 years old, and AFAIK, no one has sent a duplicate PR or an
email to fortran@gnu complaining about the current error 
message.  The new error message simply gives a better locus.
OK to commit?

Release Manager, I can hold the patch until after 8.0/1 is
released, but it is highly unlikely that this patch will 
cause a regression and it does fix two ICE.

2018-02-10  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* interface.c (compare_actual_formal): Add in_statement_function
bool parameter.  Skip check of INTENT attribute for statement
functions.  Arguments to a statement function cannot be optional,
issue error for missing argument.
(gfc_procedure_use, gfc_ppc_use, gfc_arglist_matches_symbol): Use
 in_statement_function.

2018-02-10  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* gfortran.dg/statement_function_1.f90: New test.
* gfortran.dg/statement_function_3.f90: New test.

PR fortran/35299
* gfortran.dg/statement_function_3.f: New test.

-- 
Steve
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c	(revision 257464)
+++ gcc/fortran/interface.c	(working copy)
@@ -2835,7 +2835,8 @@ lookup_arg_fuzzy (const char *arg, gfc_formal_arglist 
 
 static bool
 compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
-	 	   int ranks_must_agree, int is_elemental, locus *where)
+	 	   int ranks_must_agree, int is_elemental,
+		   bool in_statement_function, locus *where)
 {
   gfc_actual_arglist **new_arg, *a, *actual;
   gfc_formal_arglist *f;
@@ -3204,8 +3205,9 @@ compare_actual_formal (gfc_actual_arglist **ap, gfc_fo
 	}
 
   /* Check intent = OUT/INOUT for definable actual argument.  */
-  if ((f->sym->attr.intent == INTENT_OUT
-	  || f->sym->attr.intent == INTENT_INOUT))
+  if (!in_statement_function
+	  && (f->sym->attr.intent == INTENT_OUT
+	  || f->sym->attr.intent == INTENT_INOUT))
 	{
 	  const char* context = (where
  ? _("actual argument to INTENT = OUT/INOUT")
@@ -3310,7 +3312,8 @@ compare_actual_formal (gfc_actual_arglist **ap, gfc_fo
 		   "at %L", where);
 	  return false;
 	}
-  if (!f->sym->attr.optional)
+  if (!f->sym->attr.optional
+	  || (in_statement_function && f->sym->attr.optional))
 	{
 	  if (where)
 	gfc_error ("Missing actual argument for argument %qs at %L",
@@ -3598,6 +3601,7 @@ check_intents (gfc_formal_arglist *f, gfc_actual_argli
 bool
 gfc_procedure_use (gfc_symbol *sym, gfc_actual_arglist **ap, locus *where)
 {
+  gfc_actual_arglist *a;
   gfc_formal_arglist *dummy_args;
 
   /* Warn about calls with an implicit interface.  Special case
@@ -3631,8 +3635,6 @@ gfc_procedure_use (gfc_symbol *sym, gfc_actual_arglist
 
   if (sym->attr.if_source == IFSRC_UNKNOWN)
 {
-  gfc_actual_arglist *a;
-
   if (sym->attr.pointer)
 	{
 	  gfc_error ("The pointer object %qs at %L must have an explicit "
@@ -3724,9 +3726,12 @@ gfc_procedure_use (gfc_symbol *sym, gfc_actual_arglist
 
   dummy_args = gfc_sym_get_dummy_args (sym);
 
-  if (!compare_actual_formal (ap, dummy_args, 0, sym->attr.elemental, where))
+  /* For a statement function, check that types and type parameters of actual
+ arguments and dummy arguments match.  */
+  if (!compare_actual_formal (ap, dummy_args, 0, sym->attr.elemental,
+			  sym->attr.proc == PROC_ST_FUNCTION, where))
 return false;
-
+ 
   if (!check_intents (dummy_args, *ap))
 return false;
 
@@ -3773,7 +3778,7 @@ gfc_ppc_use (gfc_component *comp, gfc_actual_arglist *
 }
 
   if (!compare_actual_formal (ap, comp->ts.interface->formal, 0,
-			  comp->attr.elemental, where))
+			  comp->attr.elemental, false, where))
 return;
 
   check_intents (comp->ts.interface->formal, *ap);
@@ -3798,7 +3803,7 @@ gfc_arglist_matches_symbol (gfc_actual_arglist** args,
   dummy_args = gfc_sym_get_dummy_args (sym);
 
   r = !sym->attr.elemental;
-  if (compare_actual_formal (args, dummy_args, r, !r, NULL))
+  if (compare_actual_formal (args, dummy_args, r, !r, false, NULL))
 {
   check_intents (dummy_args, *args);
   if 

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

[Jeff Law]

On 02/10/2018 06:04 AM, Alexandre Oliva wrote:
> On Feb 10, 2018, Jeff Law  wrote:
> 
>> So given what I've seen in the ARM port, I don't think we can generally
>> assume any insn advances the PC.
> 
> Ugh.  Thanks, I'll adjust the patch to not count call insns, I guess.
> 
> Maybe what we should have is some target hook that, instead of vowing
> for ATTR_length (or not), tells us whether an insn might not advance the
> PC, with a default that assumes "reasonable" behavior and some more
> conservative alternatives for targets that do messy stuff.  I'll give
> that some more thought.
> 
>> So in the end I don't think you can assume that any given insn advances
>> the PC.  The closest we have is the length attribute, but it has always
>> supposed to have been conservatively correct for the purposes of branch
>> shortening.  ie, it can never return a length less than the actual
>> length, but it is allowed to return a length longer than the actual length.
> 
> Interesting.  I recall some cases back in my SH days in which I needed
> it to be quite precise; I guess this distorted my general expectation.
> Oh well...  Back to the drawing board WRT the locview table
> optimizations.  Maybe we'll find out my concern about them was
> unjustified, and the space they take up is tolerable.  Or maybe we can
> find some way to get the most out of them without actually breaking
> anything.  We'll see...
We have had ports at times try to be very accurate.  You mention the sh,
I also tried for high accuracy on the PA at one time.  I think it was to
support jumps in call delay slots where you have to compute the
difference of two labels.  I eventually gave up and fixed gas :-)  But
the process was still helpful in improving delay slot filling and
instruction scheduling.

jeff

Re: [LVU] use asm .loc and get gas to compute views on the side

[Jeff Law]

On 02/10/2018 06:34 AM, Richard Biener wrote:
> On February 10, 2018 1:53:41 PM GMT+01:00, Alexandre Oliva 
>  wrote:
>> I was shocked when you, richi, reported huge debug info growth after
>> the
>> LVU and IEPM patches went in.  At first, I suspected IEPM, due to
>> possibly keeping more lexical blocks around, but my investigation
>> showed
>> a lot of the growth was actually due to switching from asm-generated
>> line number sections to gcc-generated ones, which we do when locviews
>> are requested but the assembler has no support for view assignments in
>> .loc directives.
>>
>> It then occurred to me that we could compute view numbers on the side,
>> and I jumped at it before recalling there were complications I was
>> already familiar with, namely that .loc directives (without views)
>> don't
>> necessarily bind to '.': they bind to the next instruction, which might
>> even be in a different section.  This makes for some complications,
>> verbosely described in comments in dwarf2out.c.  I'm reasonably happy
>> with the result, that passed visual inspection on some reasonably
>> tricky
>> cases, but there's unfortunately no way I can think of to test
>> mechanically that the views we get from gas-generated line number
>> programs correspond to the views we compute from the labels introduced
>> by the patch.  Although we might get view numbers wrong in some unknown
>> cases, that we'll only notice for real once we have loc view support in
>> debuggers, since actual insns are sync (reset) points for views, odds
>> are they will be in sync at most points of interest.
>>
>> So, do you think the far more compact debug_line sections are worth the
>> risk of some out-of-sync view counts, for those who already use gas,
>> just not 2.30?  Or should we instead default to disabling views when
>> the
>> assembler doesn't have native support for them, as you had suggested?
>>
>> (I haven't looked yet into the other debug_info growth, most certainly
>> caused by IEPM-preserved lexical blocks; that's next up, but I'll need
>> another sleep cycle first, I'm afraid)
>>
>> WDYT?
> 
> I think it makes sense to disable them by default if gas doesn't support them 
> with that ability to override the auto detection by a configure switch (get 
> the GCC generated ones). The patch looks too heavy for this stage and as you 
> say we lack support on the consumer side anyways. We can revisit this patch 
> for GCC 9 or simply document the recommendation of using gas 2.30 or newer. 
Seems reasonable to me as well.
jeff

Re: [PATCH] Improve pow (C, x) -> exp (log (C) * x) optimization (PR middle-end/84309)

[Richard Biener]

On February 10, 2018 3:26:46 PM GMT+01:00, Jakub Jelinek  
wrote:
>On Sat, Feb 10, 2018 at 12:29:42PM +0100, Richard Biener wrote:
>> On February 10, 2018 10:44:37 AM GMT+01:00, Jakub Jelinek
> wrote:
>> >On Sat, Feb 10, 2018 at 08:00:04AM +0100, Richard Biener wrote:
>> >> On February 10, 2018 12:37:38 AM GMT+01:00, Jakub Jelinek
>> > wrote:
>> >> >Hi!
>> >> >
>> >> >Apparently the new pow(C,x) -> exp(log(C)*x) if C > 0
>optimization
>> >> >breaks some package (Marek should know which), as it has 7ulp
>error.
>> >> >Generally one should be prepared for some errors with
>-ffast-math.
>> >> >
>> >> >Though, in this case, if the target has c99 runtime and C is
>> >> >a positive 0x1pNN it seems much better to use exp2 over exp, for
>> >> >C being 2 pow (2, x) is optimized into exp2 (x) and even for
>other
>> >> >values log2(C) will still be some positive or negative integer,
>so
>> >> >in many cases there won't be any rounding errors in the
>> >multiplication.
>> >> >
>> >> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
>trunk?
>> >> 
>> >> OK. I wonder whether there are vectorized variants in libmvec? 
>> >
>> >Unfortunately libmvec only provides pow and exp, not exp2 nor exp10.
>> 
>> So maybe delay this folding then, there's already two phases we do
>for
>> math functions.  Not sure if they conveniently align with
>vectorization...
>
>How would that delay look like?
>If use_exp2 is true and (cfun->curr_properties & PROP_gimple_lvec) ==
>0,
>don't fold it?  

I think we have a canonicalize_math phase and an optimization one. But I'm not 
sure this transform matches either case. 

Then I guess if we vectorize or slp vectorize the pow
>as vector pow, we'd need to match.pd it into the exp (log (vec_cst) *
>x).

Yes.  Of course extending libmvec would be much preferred... 

Richard. 

>
>   Jakub

Re: [LVU] use asm .loc and get gas to compute views on the side

[Richard Biener]

On February 10, 2018 1:53:41 PM GMT+01:00, Alexandre Oliva  
wrote:
>I was shocked when you, richi, reported huge debug info growth after
>the
>LVU and IEPM patches went in.  At first, I suspected IEPM, due to
>possibly keeping more lexical blocks around, but my investigation
>showed
>a lot of the growth was actually due to switching from asm-generated
>line number sections to gcc-generated ones, which we do when locviews
>are requested but the assembler has no support for view assignments in
>.loc directives.
>
>It then occurred to me that we could compute view numbers on the side,
>and I jumped at it before recalling there were complications I was
>already familiar with, namely that .loc directives (without views)
>don't
>necessarily bind to '.': they bind to the next instruction, which might
>even be in a different section.  This makes for some complications,
>verbosely described in comments in dwarf2out.c.  I'm reasonably happy
>with the result, that passed visual inspection on some reasonably
>tricky
>cases, but there's unfortunately no way I can think of to test
>mechanically that the views we get from gas-generated line number
>programs correspond to the views we compute from the labels introduced
>by the patch.  Although we might get view numbers wrong in some unknown
>cases, that we'll only notice for real once we have loc view support in
>debuggers, since actual insns are sync (reset) points for views, odds
>are they will be in sync at most points of interest.
>
>So, do you think the far more compact debug_line sections are worth the
>risk of some out-of-sync view counts, for those who already use gas,
>just not 2.30?  Or should we instead default to disabling views when
>the
>assembler doesn't have native support for them, as you had suggested?
>
>(I haven't looked yet into the other debug_info growth, most certainly
>caused by IEPM-preserved lexical blocks; that's next up, but I'll need
>another sleep cycle first, I'm afraid)
>
>WDYT?

I think it makes sense to disable them by default if gas doesn't support them 
with that ability to override the auto detection by a configure switch (get the 
GCC generated ones). The patch looks too heavy for this stage and as you say we 
lack support on the consumer side anyways. We can revisit this patch for GCC 9 
or simply document the recommendation of using gas 2.30 or newer. 

Richard. 
>
>
>introduce asm-fallback view computation mode
>
>
>---
> gcc/config.in|6 +
> gcc/configure|   55 ++-
> gcc/configure.ac |   23 
>gcc/dwarf2out.c  |  282
>++
> gcc/final.c  |   15 +++
> 5 files changed, 360 insertions(+), 21 deletions(-)
>
>diff --git a/gcc/config.in b/gcc/config.in
>index 5bccb408016b..f31f79763fb4 100644
>--- a/gcc/config.in
>+++ b/gcc/config.in
>@@ -315,6 +315,12 @@
> #endif
> 
> 
>+/* Define if your assembler supports computing views from labels. */
>+#ifndef USED_FOR_TARGET
>+#undef HAVE_AS_COMPUTED_DEBUG_VIEW
>+#endif
>+
>+
> /* Define if your assembler supports the DCI/ICI instructions. */
> #ifndef USED_FOR_TARGET
> #undef HAVE_AS_DCI
>diff --git a/gcc/configure b/gcc/configure
>index b12628725b67..758737daf296 100755
>--- a/gcc/configure
>+++ b/gcc/configure
>@@ -27843,7 +27843,7 @@ else
>   gcc_cv_as_dwarf2_debug_view=no
> if test $in_tree_gas = yes; then
> if test $in_tree_gas_is_elf = yes \
>-  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 27 \) \*
>1000 + 0`
>+  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 30 \) \*
>1000 + 0`
>   then gcc_cv_as_dwarf2_debug_view=yes
> fi
>   elif test x$gcc_cv_as != x; then
>@@ -27870,6 +27870,59 @@ if test $gcc_cv_as_dwarf2_debug_view = yes;
>then
> $as_echo "#define HAVE_AS_DWARF2_DEBUG_VIEW 1" >>confdefs.h
> 
> fi
>+
>+
>+  conftest_s="\
>+  .data
>+  .LVUL0:
>+  .set .LVU0, 0
>+  .LVUL1:
>+  .set .LVU1, (.LVU0 + 1) * !(.LVUL1 > .LVUL0)
>+  .space 1
>+  .LVUL2:
>+  .set .LVU2, (.LVU1 + 1) * !(.LVUL2 > .LVUL1)
>+
>+  .uleb128 .LVU0
>+  .uleb128 .LVU1
>+  .uleb128 .LVU2
>+"
>+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for
>dwarf2 debug_view support fallback" >&5
>+$as_echo_n "checking assembler for dwarf2 debug_view support
>fallback... " >&6; }
>+if test "${gcc_cv_as_dwarf2_debug_view_fallback+set}" = set; then :
>+  $as_echo_n "(cached) " >&6
>+else
>+  gcc_cv_as_dwarf2_debug_view_fallback=no
>+if test $in_tree_gas = yes; then
>+if test $in_tree_gas_is_elf = yes \
>+  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 30 \) \*
>1000 + 0`
>+  then gcc_cv_as_dwarf2_debug_view_fallback=yes
>+fi
>+  elif test x$gcc_cv_as != x; then
>+$as_echo "$conftest_s" > conftest.s
>+if { ac_try='$gcc_cv_as $gcc_cv_as_flags  -o conftest.o conftest.s
>>&5'
>+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
>+  (eval $ac_try) 2>&5
>+  ac_status=$?
>+  $as_echo 

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

[Alexandre Oliva]

On Feb 10, 2018, Jeff Law  wrote:

> So given what I've seen in the ARM port, I don't think we can generally
> assume any insn advances the PC.

Ugh.  Thanks, I'll adjust the patch to not count call insns, I guess.

Maybe what we should have is some target hook that, instead of vowing
for ATTR_length (or not), tells us whether an insn might not advance the
PC, with a default that assumes "reasonable" behavior and some more
conservative alternatives for targets that do messy stuff.  I'll give
that some more thought.

> So in the end I don't think you can assume that any given insn advances
> the PC.  The closest we have is the length attribute, but it has always
> supposed to have been conservatively correct for the purposes of branch
> shortening.  ie, it can never return a length less than the actual
> length, but it is allowed to return a length longer than the actual length.

Interesting.  I recall some cases back in my SH days in which I needed
it to be quite precise; I guess this distorted my general expectation.
Oh well...  Back to the drawing board WRT the locview table
optimizations.  Maybe we'll find out my concern about them was
unjustified, and the space they take up is tolerable.  Or maybe we can
find some way to get the most out of them without actually breaking
anything.  We'll see...

-- 
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

[LVU] use asm .loc and get gas to compute views on the side

[Alexandre Oliva]

I was shocked when you, richi, reported huge debug info growth after the
LVU and IEPM patches went in.  At first, I suspected IEPM, due to
possibly keeping more lexical blocks around, but my investigation showed
a lot of the growth was actually due to switching from asm-generated
line number sections to gcc-generated ones, which we do when locviews
are requested but the assembler has no support for view assignments in
.loc directives.

It then occurred to me that we could compute view numbers on the side,
and I jumped at it before recalling there were complications I was
already familiar with, namely that .loc directives (without views) don't
necessarily bind to '.': they bind to the next instruction, which might
even be in a different section.  This makes for some complications,
verbosely described in comments in dwarf2out.c.  I'm reasonably happy
with the result, that passed visual inspection on some reasonably tricky
cases, but there's unfortunately no way I can think of to test
mechanically that the views we get from gas-generated line number
programs correspond to the views we compute from the labels introduced
by the patch.  Although we might get view numbers wrong in some unknown
cases, that we'll only notice for real once we have loc view support in
debuggers, since actual insns are sync (reset) points for views, odds
are they will be in sync at most points of interest.

So, do you think the far more compact debug_line sections are worth the
risk of some out-of-sync view counts, for those who already use gas,
just not 2.30?  Or should we instead default to disabling views when the
assembler doesn't have native support for them, as you had suggested?

(I haven't looked yet into the other debug_info growth, most certainly
caused by IEPM-preserved lexical blocks; that's next up, but I'll need
another sleep cycle first, I'm afraid)

WDYT?


introduce asm-fallback view computation mode


---
 gcc/config.in|6 +
 gcc/configure|   55 ++-
 gcc/configure.ac |   23 
 gcc/dwarf2out.c  |  282 ++
 gcc/final.c  |   15 +++
 5 files changed, 360 insertions(+), 21 deletions(-)

diff --git a/gcc/config.in b/gcc/config.in
index 5bccb408016b..f31f79763fb4 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -315,6 +315,12 @@
 #endif
 
 
+/* Define if your assembler supports computing views from labels. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_COMPUTED_DEBUG_VIEW
+#endif
+
+
 /* Define if your assembler supports the DCI/ICI instructions. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_DCI
diff --git a/gcc/configure b/gcc/configure
index b12628725b67..758737daf296 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -27843,7 +27843,7 @@ else
   gcc_cv_as_dwarf2_debug_view=no
 if test $in_tree_gas = yes; then
 if test $in_tree_gas_is_elf = yes \
-  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 27 \) \* 1000 + 0`
+  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 30 \) \* 1000 + 0`
   then gcc_cv_as_dwarf2_debug_view=yes
 fi
   elif test x$gcc_cv_as != x; then
@@ -27870,6 +27870,59 @@ if test $gcc_cv_as_dwarf2_debug_view = yes; then
 $as_echo "#define HAVE_AS_DWARF2_DEBUG_VIEW 1" >>confdefs.h
 
 fi
+
+
+   conftest_s="\
+   .data
+   .LVUL0:
+   .set .LVU0, 0
+   .LVUL1:
+   .set .LVU1, (.LVU0 + 1) * !(.LVUL1 > .LVUL0)
+   .space 1
+   .LVUL2:
+   .set .LVU2, (.LVU1 + 1) * !(.LVUL2 > .LVUL1)
+
+   .uleb128 .LVU0
+   .uleb128 .LVU1
+   .uleb128 .LVU2
+"
+   { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for dwarf2 
debug_view support fallback" >&5
+$as_echo_n "checking assembler for dwarf2 debug_view support fallback... " 
>&6; }
+if test "${gcc_cv_as_dwarf2_debug_view_fallback+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_dwarf2_debug_view_fallback=no
+if test $in_tree_gas = yes; then
+if test $in_tree_gas_is_elf = yes \
+  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 30 \) \* 1000 + 0`
+  then gcc_cv_as_dwarf2_debug_view_fallback=yes
+fi
+  elif test x$gcc_cv_as != x; then
+$as_echo "$conftest_s" > conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags  -o conftest.o conftest.s >&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+then
+   gcc_cv_as_dwarf2_debug_view_fallback=yes
+else
+  echo "configure: failed program was" >&5
+  cat conftest.s >&5
+fi
+rm -f conftest.o conftest.s
+  fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$gcc_cv_as_dwarf2_debug_view_fallback" >&5
+$as_echo "$gcc_cv_as_dwarf2_debug_view_fallback" >&6; }
+if test $gcc_cv_as_dwarf2_debug_view_fallback = yes; then
+
+$as_echo "#define HAVE_AS_COMPUTED_DEBUG_VIEW 1" >>confdefs.h
+
+fi
+
+
 fi
  fi
 
diff --git a/gcc/configure.ac 

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

[Alexandre Oliva]

Hi, Joseph,

On Feb  9, 2018, Joseph Myers  wrote:

> sh4 is:

> during RTL pass: final
> In file included from strtof_l.c:45:
> strtod_l.c: In function 'strtof_l_internal':
> strtod_l.c:1769:1: internal compiler error: Segmentation fault
>  }
>  ^
> 0xb98e3f crash_signal
> /scratch/jmyers/glibc-bot/src/gcc/gcc/toplev.c:325
> 0x856b18 maybe_output_next_view
> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:1726
> 0x856b18 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2714
> 0xef36bc print_slot
> /scratch/jmyers/glibc-bot/src/gcc/gcc/config/sh/sh.c:2557
> 0xef6520 output_far_jump(rtx_insn*, rtx_def*)
> /scratch/jmyers/glibc-bot/src/gcc/gcc/config/sh/sh.c:2617
> 0x857098 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:3101
> 0x856c26 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2806
> 0x858469 final_1
> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:2088
> 0x8591d8 rest_of_handle_final
> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:4637
> 0x8591d8 execute
> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:4711


> Since it's in maybe_output_next_view, I think it probably comes from these 
> patches.

Thanks for the backtraces.  The problem is that ports call
final_scan_insn recursively passing NULL for seen, but now there is code
that actually cares about carrying information around in it.  I decided
against silencing the errors by testing seen for non-NULL before
dereferencing it, and instead arranging for the outermost pointer to be
recovered in recursive calls.  I hope this is enough to cover all the
cases of final_scan_insn being called from ports.  Could you possibly
give it a spin, pretty please with sugar on top? ;-)  Thanks a ton,

(I'll provide a ChangeLog for formal review and hopefully approval once
it has gone through more than my initial smoke testing on x86_64, but my
own testing will take some time, and I wanted to give you something that
at least stood a chance of fixing the problem before crashing in bed :-)


[LVU] deal with md final_scan_insn

From: Alexandre Oliva 

Ports call final_scan_insn with seen == NULL, and then
maybe_output_next_view crashes because it assumes it's
non-NULL.  Oops.  Fixed.
---
 gcc/final.c |   34 +++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/gcc/final.c b/gcc/final.c
index c311c198da67..a60be5ddc31c 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -2236,9 +2236,9 @@ asm_show_source (const char *filename, int linenum)
debug information.  We force the emission of a line note after
both NOTE_INSN_PROLOGUE_END and NOTE_INSN_FUNCTION_BEG.  */
 
-rtx_insn *
-final_scan_insn (rtx_insn *insn, FILE *file, int optimize_p ATTRIBUTE_UNUSED,
-int nopeepholes ATTRIBUTE_UNUSED, int *seen)
+static rtx_insn *
+final_scan_insn_1 (rtx_insn *insn, FILE *file, int optimize_p ATTRIBUTE_UNUSED,
+  int nopeepholes ATTRIBUTE_UNUSED, int *seen)
 {
 #if HAVE_cc0
   rtx set;
@@ -3204,6 +3204,34 @@ final_scan_insn (rtx_insn *insn, FILE *file, int 
optimize_p ATTRIBUTE_UNUSED,
 }
   return NEXT_INSN (insn);
 }
+
+/* This is a wrapper around final_scan_insn_1 that allows ports to
+   call it recursively without a known value for SEEN.  The value is
+   saved at the outermost call, and recovered for recursive calls.  */
+
+rtx_insn *
+final_scan_insn (rtx_insn *insn, FILE *file, int optimize_p,
+int nopeepholes, int *seen)
+{
+  static int *enclosing_seen;
+  static int recursion_counter;
+
+  gcc_assert (seen || recursion_counter);
+  gcc_assert (!recursion_counter || !seen || seen == enclosing_seen);
+
+  if (!recursion_counter++)
+enclosing_seen = seen;
+  else if (!seen)
+seen = enclosing_seen;
+
+  rtx_insn *ret = final_scan_insn_1 (insn, file, optimize_p, nopeepholes, 
seen);
+  
+  if (!--recursion_counter)
+enclosing_seen = NULL;
+
+  return ret;
+}
+
 
 /* Return whether a source line note needs to be emitted before INSN.
Sets IS_STMT to TRUE if the line should be marked as a possible




>> (It's possible more failures might appear on other architectures once the 
>> bot builds the glibc testsuite, that's just failures from building GCC and 
>> glibc.)

> hppa has a similar ICE building glibc tests, also in 
> maybe_output_next_view, so probably also from these patches:

> during RTL pass: final
> test-tgmath2.c: In function 'test_fma_3':
> test-tgmath2.c:421:1: internal compiler error: Segmentation fault
>  }
>  ^
> 0xb7525f crash_signal
> /scratch/jmyers/glibc-bot/src/gcc/gcc/toplev.c:325
> 0x835f14 maybe_output_next_view
> /scratch/jmyers/glibc-bot/src/gcc/gcc/final.c:1726
> 0x835f14 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
> 

Re: [PATCH] Improve pow (C, x) -> exp (log (C) * x) optimization (PR middle-end/84309)

[Marek Polacek]

On Sat, Feb 10, 2018 at 12:37:38AM +0100, Jakub Jelinek wrote:
> Hi!
> 
> Apparently the new pow(C,x) -> exp(log(C)*x) if C > 0 optimization
> breaks some package (Marek should know which), as it has 7ulp error.
> Generally one should be prepared for some errors with -ffast-math.

I reduced it from "test-cachunker" in package casync.

Marek

Re: [Patch, Fortran] PR 84273: Reject allocatable passed-object dummy argument (proc_ptr_47.f90)

[Paul Richard Thomas]

Hi Janus,

As Steve said, welcome back!

I hope that you will post the news of this fix and the correction of
the testcases on clf. Talking of which, have you posted the problems
that others have found as PRs?

It was one of my long deferred tasks to make a start on validating the
testsuite and to remove non-standard features.

Thanks for the patch.

Paul


On 9 February 2018 at 23:21, Steve Kargl
 wrote:
> On Fri, Feb 09, 2018 at 06:13:34PM +0100, Janus Weil wrote:
>>
>> the attached patch fixes some checking code for PASS arguments in
>> procedure-pointer components, which does not properly account for the
>> fact that the PASS argument needs to be polymorphic.
>>
>> [The reason for this issue is probably that PPCs were mostly
>> implemented before polymorphism was available. The corresponding
>> pass-arg checks for TBPs are ok.]
>>
>> The patch also fixes an invalid test case (which was detected thanks
>> to Neil Carlson). It regtests cleanly on x86_64-linux-gnu. Ok for
>> trunk?
>
> Janus,
>
> The patch looks ok to me.  Trunk is in regression and doc
> fixes only mode, so you'll probably need to ping Jakub or
> Richard (ie., release engineer) for an ok.
>
> PS: Welcome back!  We can definitely use your talent.
>
> --
> Steve



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

Re: [PATCH] Improve pow (C, x) -> exp (log (C) * x) optimization (PR middle-end/84309)

[Richard Biener]

On February 10, 2018 10:44:37 AM GMT+01:00, Jakub Jelinek  
wrote:
>On Sat, Feb 10, 2018 at 08:00:04AM +0100, Richard Biener wrote:
>> On February 10, 2018 12:37:38 AM GMT+01:00, Jakub Jelinek
> wrote:
>> >Hi!
>> >
>> >Apparently the new pow(C,x) -> exp(log(C)*x) if C > 0 optimization
>> >breaks some package (Marek should know which), as it has 7ulp error.
>> >Generally one should be prepared for some errors with -ffast-math.
>> >
>> >Though, in this case, if the target has c99 runtime and C is
>> >a positive 0x1pNN it seems much better to use exp2 over exp, for
>> >C being 2 pow (2, x) is optimized into exp2 (x) and even for other
>> >values log2(C) will still be some positive or negative integer, so
>> >in many cases there won't be any rounding errors in the
>multiplication.
>> >
>> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>> 
>> OK. I wonder whether there are vectorized variants in libmvec? 
>
>Unfortunately libmvec only provides pow and exp, not exp2 nor exp10.

So maybe delay this folding then, there's already two phases we do for math 
functions. Not sure if they conveniently align with vectorization... 

>Wonder how much work it would be to provide also that.
>
>Joseph, is exp2 in glibc .5ulp accurate like exp for double, or not?
>Anything known about their relative performance?
>
>> >Perhaps we should do something similar if C is a power of 10 (use
>exp10
>> >and log10).
>> >
>> >2018-02-10  Jakub Jelinek  
>> >
>> >PR middle-end/84309
>> >* match.pd (pow(C,x) -> exp(log(C)*x)): Optimize instead into
>> >exp2(log2(C)*x) if C is a power of 2 and c99 runtime is available.
>> >
>> >* gcc.dg/pr84309.c: New test.
>> > 
>> >--- gcc/match.pd.jj 2018-01-26 12:43:23.208922420 +0100
>> >+++ gcc/match.pd2018-02-09 18:48:26.412021408 +0100
>> >@@ -3992,15 +3992,33 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>> >(logs (pows @0 @1))
>> >(mult @1 (logs @0
>> > 
>> >- /* pow(C,x) -> exp(log(C)*x) if C > 0.  */
>> >+ /* pow(C,x) -> exp(log(C)*x) if C > 0,
>> >+or if C is a positive power of 2,
>> >+pow(C,x) -> exp2(log2(C)*x).  */
>> >  (for pows (POW)
>> >   exps (EXP)
>> >   logs (LOG)
>> >+  exp2s (EXP2)
>> >+  log2s (LOG2)
>> >   (simplify
>> >(pows REAL_CST@0 @1)
>> >-(if (real_compare (GT_EXPR, TREE_REAL_CST_PTR (@0), )
>> >-&& real_isfinite (TREE_REAL_CST_PTR (@0)))
>> >- (exps (mult (logs @0) @1)
>> >+   (if (real_compare (GT_EXPR, TREE_REAL_CST_PTR (@0), )
>> >+   && real_isfinite (TREE_REAL_CST_PTR (@0)))
>> >+(with {
>> >+   const REAL_VALUE_TYPE *const value = TREE_REAL_CST_PTR (@0);
>> >+   bool use_exp2 = false;
>> >+   if (targetm.libc_has_function (function_c99_misc)
>> >+  && value->cl == rvc_normal)
>> >+{
>> >+  REAL_VALUE_TYPE frac_rvt = *value;
>> >+  SET_REAL_EXP (_rvt, 1);
>> >+  if (real_equal (_rvt, ))
>> >+use_exp2 = true;
>> >+}
>> >+ }
>> >+ (if (use_exp2)
>> >+   (exp2s (mult (log2s @0) @1))
>> >+   (exps (mult (logs @0) @1)))
>> > 
>> >  (for sqrts (SQRT)
>> >   cbrts (CBRT)
>> >--- gcc/testsuite/gcc.dg/pr84309.c.jj   2018-02-09 18:54:52.254787678
>> >+0100
>> >+++ gcc/testsuite/gcc.dg/pr84309.c  2018-02-09 18:59:02.343636178
>+0100
>> >@@ -0,0 +1,14 @@
>> >+/* PR middle-end/84309 */
>> >+/* { dg-do run { target c99_runtime } } */
>> >+/* { dg-options "-O2 -ffast-math" } */
>> >+
>> >+int
>> >+main ()
>> >+{
>> >+  unsigned long a = 1024;
>> >+  unsigned long b = 16 * 1024;
>> >+  unsigned long c = __builtin_pow (2, (__builtin_log2 (a) +
>> >__builtin_log2 (b)) / 2);
>> >+  if (c != 4096)
>> >+__builtin_abort ();
>> >+  return 0;
>> >+}
>
>   Jakub

[committed] Fix shrink-wrapping memory leak (PR rtl-optimization/84308)

[Jakub Jelinek]

Hi!

We are leaking the todo vector in spread_components, fixed thusly,
bootstrapped/regtested on x86_64-linux and i686-linux, committed to
trunk as obvious.

2018-02-10  Jakub Jelinek  

PR rtl-optimization/84308
* shrink-wrap.c (spread_components): Release todo vector.

--- gcc/shrink-wrap.c.jj2018-01-03 10:19:55.0 +0100
+++ gcc/shrink-wrap.c   2018-02-09 13:19:10.019553075 +0100
@@ -1370,6 +1370,8 @@ spread_components (sbitmap components)
   bitmap_clear_bit (seen, bb->index);
 }
 
+  todo.release ();
+
   /* Finally, mark everything not not needed both forwards and backwards.  */
 
   FOR_EACH_BB_FN (bb, cfun)

Jakub

Re: [PATCH] Improve pow (C, x) -> exp (log (C) * x) optimization (PR middle-end/84309)

[Jakub Jelinek]

On Sat, Feb 10, 2018 at 08:00:04AM +0100, Richard Biener wrote:
> On February 10, 2018 12:37:38 AM GMT+01:00, Jakub Jelinek  
> wrote:
> >Hi!
> >
> >Apparently the new pow(C,x) -> exp(log(C)*x) if C > 0 optimization
> >breaks some package (Marek should know which), as it has 7ulp error.
> >Generally one should be prepared for some errors with -ffast-math.
> >
> >Though, in this case, if the target has c99 runtime and C is
> >a positive 0x1pNN it seems much better to use exp2 over exp, for
> >C being 2 pow (2, x) is optimized into exp2 (x) and even for other
> >values log2(C) will still be some positive or negative integer, so
> >in many cases there won't be any rounding errors in the multiplication.
> >
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> OK. I wonder whether there are vectorized variants in libmvec? 

Unfortunately libmvec only provides pow and exp, not exp2 nor exp10.
Wonder how much work it would be to provide also that.

Joseph, is exp2 in glibc .5ulp accurate like exp for double, or not?
Anything known about their relative performance?

> >Perhaps we should do something similar if C is a power of 10 (use exp10
> >and log10).
> >
> >2018-02-10  Jakub Jelinek  
> >
> > PR middle-end/84309
> > * match.pd (pow(C,x) -> exp(log(C)*x)): Optimize instead into
> > exp2(log2(C)*x) if C is a power of 2 and c99 runtime is available.
> >
> > * gcc.dg/pr84309.c: New test.
> > 
> >--- gcc/match.pd.jj  2018-01-26 12:43:23.208922420 +0100
> >+++ gcc/match.pd 2018-02-09 18:48:26.412021408 +0100
> >@@ -3992,15 +3992,33 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >(logs (pows @0 @1))
> >(mult @1 (logs @0
> > 
> >- /* pow(C,x) -> exp(log(C)*x) if C > 0.  */
> >+ /* pow(C,x) -> exp(log(C)*x) if C > 0,
> >+or if C is a positive power of 2,
> >+pow(C,x) -> exp2(log2(C)*x).  */
> >  (for pows (POW)
> >   exps (EXP)
> >   logs (LOG)
> >+  exp2s (EXP2)
> >+  log2s (LOG2)
> >   (simplify
> >(pows REAL_CST@0 @1)
> >-(if (real_compare (GT_EXPR, TREE_REAL_CST_PTR (@0), )
> >- && real_isfinite (TREE_REAL_CST_PTR (@0)))
> >- (exps (mult (logs @0) @1)
> >+   (if (real_compare (GT_EXPR, TREE_REAL_CST_PTR (@0), )
> >+&& real_isfinite (TREE_REAL_CST_PTR (@0)))
> >+(with {
> >+   const REAL_VALUE_TYPE *const value = TREE_REAL_CST_PTR (@0);
> >+   bool use_exp2 = false;
> >+   if (targetm.libc_has_function (function_c99_misc)
> >+   && value->cl == rvc_normal)
> >+ {
> >+   REAL_VALUE_TYPE frac_rvt = *value;
> >+   SET_REAL_EXP (_rvt, 1);
> >+   if (real_equal (_rvt, ))
> >+ use_exp2 = true;
> >+ }
> >+ }
> >+ (if (use_exp2)
> >+   (exp2s (mult (log2s @0) @1))
> >+   (exps (mult (logs @0) @1)))
> > 
> >  (for sqrts (SQRT)
> >   cbrts (CBRT)
> >--- gcc/testsuite/gcc.dg/pr84309.c.jj2018-02-09 18:54:52.254787678
> >+0100
> >+++ gcc/testsuite/gcc.dg/pr84309.c   2018-02-09 18:59:02.343636178 +0100
> >@@ -0,0 +1,14 @@
> >+/* PR middle-end/84309 */
> >+/* { dg-do run { target c99_runtime } } */
> >+/* { dg-options "-O2 -ffast-math" } */
> >+
> >+int
> >+main ()
> >+{
> >+  unsigned long a = 1024;
> >+  unsigned long b = 16 * 1024;
> >+  unsigned long c = __builtin_pow (2, (__builtin_log2 (a) +
> >__builtin_log2 (b)) / 2);
> >+  if (c != 4096)
> >+__builtin_abort ();
> >+  return 0;
> >+}

Jakub