date:20200829

Re: [PATCH 3/n] ipa: Simplify interface of ipa_call_context::estimate_size_and_time

2020-08-29 Thread Jan Hubicka

> Hi,
> 
> this patch changes ipa_call_context::estimate_size_and_time to store
> its results into member fields of the ipa_call_context class instead
> into pointers it receives as parameters so that it can compute ore
> stuff without cluttering the interface even further.
> 
> Bootstrapped and tested on x86_64-linux.  OK for master on top of the
> previous two patches?

ipa_call_context is intended to be structure holding all parameters that
are needed to produce the estimates (size/time/hints).
Adding the actual estimates there would duplicate it with cache.  What
about keeping them separate and inventing ipa_call_estimates structure
to hold the reults?

Honza
> 
> Thanks,
> 
> Martin
> 
> 
> gcc/ChangeLog:
> 
> 2020-08-28  Martin Jambor  
> 
>   * ipa-fnsummary.h (class ipa_call_context): Changed declaration of
>   estimate_size_and_time to accept two booleans.  Added an overload
>   of the method without any parameters.  New fields m_size,
>   m_min_size, m_time, m_nonspecialized_time and m_hints.
>   * ipa-cp.c (hint_time_bonus): Changed the second parameter from
>   just hints to a const reference to ipa_call_context.
>   (perform_estimation_of_a_value): Adjusted to the new interface of
>   ipa_call_context::estimate_size_and_time.
>   * ipa-fnsummary.c (ipa_call_context::estimate_size_and_time):
>   Modified to store results into member fields of the class.
>   * ipa-inline-analysis.c (do_estimate_edge_time): Adjusted to the
>   new interface of ipa_call_context::estimate_size_and_time.
>   (do_estimate_edge_size): Likewise.
>   (do_estimate_edge_hints): Likewise.
> ---
>  gcc/ipa-cp.c  | 41 -
>  gcc/ipa-fnsummary.c   | 48 +++
>  gcc/ipa-fnsummary.h   | 33 +++
>  gcc/ipa-inline-analysis.c | 45 ++--
>  4 files changed, 94 insertions(+), 73 deletions(-)
> 
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index e37e71bd24f..010ecfc6b43 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -3182,12 +3182,13 @@ devirtualization_time_bonus (struct cgraph_node *node,
>return res;
>  }
>  
> -/* Return time bonus incurred because of HINTS.  */
> +/* Return time bonus incurred because of hints stored in CTX.  */
>  
>  static int
> -hint_time_bonus (cgraph_node *node, ipa_hints hints)
> +hint_time_bonus (cgraph_node *node, const ipa_call_context &ctx)
>  {
>int result = 0;
> +  ipa_hints hints = ctx.m_hints;
>if (hints & (INLINE_HINT_loop_iterations | INLINE_HINT_loop_stride))
>  result += opt_for_fn (node->decl, param_ipa_cp_loop_hint_bonus);
>return result;
> @@ -3387,16 +3388,14 @@ perform_estimation_of_a_value (cgraph_node *node, 
> ipa_call_arg_values *avals,
>  int removable_params_cost, int est_move_cost,
>  ipcp_value_base *val)
>  {
> -  int size, time_benefit;
> -  sreal time, base_time;
> -  ipa_hints hints;
> +  int time_benefit;
>  
>ipa_call_context ctx = ipa_call_context::for_cloned_node (node, avals);
> -  ctx.estimate_size_and_time (&size, NULL, &time, &base_time, &hints);
> +  ctx.estimate_size_and_time ();
>  
> -  base_time -= time;
> -  if (base_time > 65535)
> -base_time = 65535;
> +  sreal time_delta = ctx.m_nonspecialized_time - ctx.m_time;
> +  if (time_delta > 65535)
> +time_delta = 65535;
>  
>/* Extern inline functions have no cloning local time benefits because they
>   will be inlined anyway.  The only reason to clone them is if it enables
> @@ -3404,11 +3403,12 @@ perform_estimation_of_a_value (cgraph_node *node, 
> ipa_call_arg_values *avals,
>if (DECL_EXTERNAL (node->decl) && DECL_DECLARED_INLINE_P (node->decl))
>  time_benefit = 0;
>else
> -time_benefit = base_time.to_int ()
> +time_benefit = time_delta.to_int ()
>+ devirtualization_time_bonus (node, avals)
> -  + hint_time_bonus (node, hints)
> +  + hint_time_bonus (node, ctx)
>+ removable_params_cost + est_move_cost;
>  
> +  int size = ctx.m_size;
>gcc_checking_assert (size >=0);
>/* The inliner-heuristics based estimates may think that in certain
>   contexts some functions do not have any size at all but we want
> @@ -3463,24 +3463,22 @@ estimate_local_effects (struct cgraph_node *node)
>|| (removable_params_cost && node->can_change_signature))
>  {
>struct caller_statistics stats;
> -  ipa_hints hints;
> -  sreal time, base_time;
> -  int size;
>  
>init_caller_stats (&stats);
>node->call_for_symbol_thunks_and_aliases (gather_caller_stats, &stats,
> false);
>ipa_call_context ctx = ipa_call_context::for_cloned_node (node, 
> &avals);
> -  ctx.estimate_size_and_time (&size, NULL, &time, &base_time, &hints);
> +  ctx.estimate_size_and_time ();
>  
> -  time -= devirt_bo

Re: [PATCH] ipa: Merge vectors describing argument values into one type

2020-08-29 Thread Jan Hubicka

> Hi,
> 
> this large patch is a semi-mechanical change which aims to replace
> uses of separate vectors about known scalar values (usually called
> known_vals or known_csts), known aggregate values (known_aggs), known
> virtual call contexts (known_contexts) and known value
> ranges (known_value_ranges) with uses of one type called
> ipa_call_arg_values.  The main benefit is bringing down the number of
> arguments that various call context evaluating functions have.
> Because the new type uses auto_vecs deallocation is simpler and it
> also takes advantage of storage within the auto_vecs themselves,
> eliminating the need for allocating memory when analyzing most
> functions.
> 
> The one place where this patch is not mechanical is the
> node_context_cache_entry RCU cache.  Before the elements contained
> directly ipa_call_context instances which however owned their vectors,
> they did not share them with their users like non-cache contexts.  Now
> the vectors are behind the pointer which means ipa_call_arg_values
> would have to be allocated, for many functions at once, and so it
> could not make use of auto_vecs with generous internal storage.
> 
> I avoided both by reworking the cache to contain copies of all fields
> o interest of ipa_call_context, including the interesting vectors.
> This makes the type a bit more verbose but the main functionality,
> storing to the cache and comparing a context with a cache entry,
> remained very similar.

Can you pleae benchmark this on building Firfox or something similar?
I was running into two problems here. First was overhead of malloc
allocations and that is reason why I am trying to not allocate the
vector when not necessary and also place them on stack rather then heap
for those having short lifetime (not being in cache).

Second problem is memory use - we may end up with quite many contextes
since calls are very numerous.

Honza
> 
> This patch does not unify information about scalar values, aggregate
> values, virtual contexts and value ranges that IPA-CP stores for
> clones it creates.  The main reason is not to make this patch even
> bigger.  Another one is that such change would not be as mechanical,
> the aggregate values for clones are stored in a different format.  I
> am considering doing something similar for them too however, even
> though using ipa_call_arg_values directly would also mean not using
> big auto_vecs in it.
> 
> I have bootstrapped and tested what I believe to be an identical patch
> (before I fixed some comments) on x86_64-linux, I am running LTO
> bootstrap on exactly this patch now.  OK for master if it passes?
> 
> Thanks,
> 
> Martin
> 
> 
> 
> gcc/ChangeLog:
> 
> 2020-08-27  Martin Jambor  
> 
>   * ipa-prop.h (ipa_call_arg_values): New type.
>   (ipa_get_indirect_edge_target): Replaced vector arguments
>   with ipa_call_arg_values in declaration.
>   * ipa-fnsummary.h (ipa_node_context_cache_entry): New forward
>   declaration.
>   (class ipa_call_context): Removed members m_known_vals,
>   m_known_contexts, m_known_aggs, duplicate_from, release and
>   equal_to, new members m_avals, store_to_cache and equivalent_to_p.
>   Adjusted construcotr arguments.
>   (estimate_ipcp_clone_size_and_time): Replaced vector arguments
>   with ipa_call_arg_values in declaration.
>   (evaluate_properties_for_edge): Likewise.
>   * ipa-cp.c (ipa_get_indirect_edge_target): Adjust to work on
>   ipa_call_arg_values rather than on separate vectors.
>   (devirtualization_time_bonus): Likewise.
>   (gather_context_independent_values): Likewise.
>   (perform_estimation_of_a_value): Likewise.
>   (estimate_local_effects): Likewise.
>   (modify_known_vectors_with_val): Adjust both variants to work on
>   ipa_call_arg_values and rename them to copy_known_vectors_add_val.
>   (decide_about_value): Adjust to work on ipa_call_arg_values rather
>   than on separate vectors.
>   (decide_whether_version_node): Likewise.
>   * ipa-fnsummary.c (evaluate_conditions_for_known_args): Adjust to
>   work on ipa_call_arg_values rather than on separate vectors.
>   (evaluate_properties_for_edge): Likewise.
>   (ipa_fn_summary_t::duplicate): Likewise.
>   (estimate_edge_devirt_benefit): Likewise.
>   (estimate_edge_size_and_time): Likewise.
>   (estimate_calls_size_and_time_1): Likewise.
>   (summarize_calls_size_and_time): Adjust calls to
>   estimate_edge_size_and_time.
>   (estimate_calls_size_and_time): Adjust to work on
>   ipa_call_arg_values rather than on separate vectors.
>   (ipa_call_context::ipa_call_context): Likewise.
>   (ipa_call_context::duplicate_from): Removed.
>   (ipa_call_context::release): Likewise.
>   (ipa_call_context::equal_to): Likewise.
>   (ipa_call_context::estimate_size_and_time): Adjust to work on
>   ipa_call_arg_values rather than on separate vectors.
>   (estimate_ipcp_c

[PATCH v2] doc: add 'cd' command before 'make check-gcc' command in install.texi

2020-08-29 Thread Hu Jiangping

This patch add 'cd' command before 'make check-gcc' command
when run the testsuite on selected tests.

Richard and I agree it would be good for clarity and
emphasis to have the cd in the example as well, although
the text above the example was trying to restrict that to
objdir/gcc.

Tested on x86_64. OK for master?

Regards!
Hujp

---
 gcc/doc/install.texi | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5330bf3bb29..1560615bf3c 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2963,8 +2963,9 @@ on a simulator as described at 
@uref{http://gcc.gnu.org/simtest-howto.html}.
 @section How can you run the testsuite on selected tests?
 
 In order to run sets of tests selectively, there are targets
-@samp{make check-gcc} and language specific @samp{make check-c},
-@samp{make check-c++}, @samp{make check-d} @samp{make check-fortran},
+@samp{make check-gcc}, @samp{make check-g++} and language specific
+@samp{make check-c},
+@samp{make check-c++}, @samp{make check-d}, @samp{make check-fortran},
 @samp{make check-ada}, @samp{make check-objc}, @samp{make check-obj-c++},
 @samp{make check-lto}
 in the @file{gcc} subdirectory of the object directory.  You can also
@@ -2975,14 +2976,14 @@ A more selective way to just run all @command{gcc} 
execute tests in the
 testsuite is to use
 
 @smallexample
-make check-gcc RUNTESTFLAGS="execute.exp @var{other-options}"
+cd @var{objdir}/gcc; make check-gcc RUNTESTFLAGS="execute.exp 
@var{other-options}"
 @end smallexample
 
 Likewise, in order to run only the @command{g++} ``old-deja'' tests in
 the testsuite with filenames matching @samp{9805*}, you would use
 
 @smallexample
-make check-g++ RUNTESTFLAGS="old-deja.exp=9805* @var{other-options}"
+cd @var{objdir}/gcc; make check-g++ RUNTESTFLAGS="old-deja.exp=9805* 
@var{other-options}"
 @end smallexample
 
 The file-matching expression following @var{filename}@command{.exp=} is treated
@@ -2991,8 +2992,8 @@ may be passed, although any whitespace must either be 
escaped or surrounded by
 single quotes if multiple expressions are desired. For example,
 
 @smallexample
-make check-g++ RUNTESTFLAGS="old-deja.exp=9805*\ virtual2.c 
@var{other-options}"
-make check-g++ RUNTESTFLAGS="'old-deja.exp=9805* virtual2.c' 
@var{other-options}"
+@dots{}"old-deja.exp=9805*\ virtual2.c @var{other-options}"
+@dots{}"'old-deja.exp=9805* virtual2.c' @var{other-options}"
 @end smallexample
 
 The @file{*.exp} files are located in the testsuite directories of the GCC
@@ -3010,7 +3011,7 @@ You can pass multiple options to the testsuite using the
 work outside the makefiles.  For example,
 
 @smallexample
-make check-g++ RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
+cd @var{objdir}/gcc; make check-g++ 
RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
 @end smallexample
 
 will run the standard @command{g++} testsuites (``unix'' is the target name
@@ -3063,7 +3064,7 @@ make -j@var{N} 
check-@var{testsuite}//@var{test-target}/@var{option1}/@var{optio
 For example,
 
 @smallexample
-make -j3 check-gcc//sh-hms-sim/@{-m1,-m2,-m3,-m3e,-m4@}/@{,-nofpu@}
+cd @var{objdir}/gcc; make -j3 
check-gcc//sh-hms-sim/@{-m1,-m2,-m3,-m3e,-m4@}/@{,-nofpu@}
 @end smallexample
 
 will run three concurrent ``make-gcc'' testsuites, eventually testing all
-- 
2.17.1

Re: [PATCH 0/6] Parallelize Intra-Procedural Optimizations using the LTO Engine.

2020-08-29 Thread Jan Hubicka

> 
> It not only creates hidden symbols, but it also changes the original
> symbol name to avoid clashses with other object files. It could be
> very nice to avoid doing this at all.
> 
> There was once an idea (I don't remember if from Richi or Honza) to
> avoid using partial linking, but instead concatenate the generated
> assembler files into a single assembler file and assemble it.  This
> would remove the requirement of symbol promotion, as they would be
> in the same assembler file, but I am not sure if this would work out
> of the box (i.e. if GCC generates assembler that could be concatenated
> together).

Not out of the box, because we number labels which will clash but we
also do smarter tihngs like producing constant pools based on whole unit
knowledge.

But it should not be technically that hard: simply initialize asm output
before fork to one file, in each fork arrange separate file and avoid
priting the end of file stuff and then concatenate in the main compiler
and work out the places where this breaks...

Honza
> 
> > 
> > > Bootstrapped and Regtested on Linux x86_64.
> > >
> > > Giuliano Belinassi (6):
> > >   Modify gcc driver for parallel compilation
> > >   Implement a new partitioner for parallel compilation
> > >   Implement fork-based parallelism engine
> > >   Add `+' for Jobserver Integration
> > >   Add invoke documentation
> > >   New tests for parallel compilation feature
> > >
> > >  gcc/Makefile.in   |6 +-
> > >  gcc/cgraph.c  |   16 +
> > >  gcc/cgraph.h  |   13 +
> > >  gcc/cgraphunit.c  |  198 ++-
> > >  gcc/common.opt|4 +
> > >  gcc/doc/invoke.texi   |   32 +-
> > >  gcc/gcc.c | 1219 +
> > >  gcc/ipa-fnsummary.c   |2 +-
> > >  gcc/ipa-icf.c |3 +-
> > >  gcc/ipa-visibility.c  |3 +-
> > >  gcc/ipa.c |4 +-
> > >  gcc/jobserver.cc  |  168 +++
> > >  gcc/jobserver.h   |   33 +
> > >  gcc/lto-cgraph.c  |  172 +++
> > >  gcc/{lto => }/lto-partition.c |  463 ++-
> > >  gcc/{lto => }/lto-partition.h |4 +-
> > >  gcc/lto-streamer.h|4 +
> > >  gcc/lto/Make-lang.in  |4 +-
> > >  gcc/lto/lto.c |2 +-
> > >  gcc/params.opt|8 +
> > >  gcc/symtab.c  |   46 +-
> > >  gcc/testsuite/driver/a.c  |6 +
> > >  gcc/testsuite/driver/b.c  |6 +
> > >  gcc/testsuite/driver/driver.exp   |   80 ++
> > >  gcc/testsuite/driver/empty.c  |0
> > >  gcc/testsuite/driver/foo.c|7 +
> > >  .../gcc.dg/parallel-early-constant.c  |   22 +
> > >  gcc/testsuite/gcc.dg/parallel-static-1.c  |   21 +
> > >  gcc/testsuite/gcc.dg/parallel-static-2.c  |   21 +
> > >  .../gcc.dg/parallel-static-clash-1.c  |   23 +
> > >  .../gcc.dg/parallel-static-clash-aux.c|   14 +
> > >  gcc/toplev.c  |   58 +-
> > >  gcc/toplev.h  |3 +
> > >  gcc/tree.c|   23 +-
> > >  gcc/varasm.c  |   26 +-
> > >  intl/Makefile.in  |2 +-
> > >  libbacktrace/Makefile.in  |2 +-
> > >  libcpp/Makefile.in|2 +-
> > >  libdecnumber/Makefile.in  |2 +-
> > >  libiberty/Makefile.in |  212 +--
> > >  zlib/Makefile.in  |   64 +-
> > >  41 files changed, 2539 insertions(+), 459 deletions(-)
> > >  create mode 100644 gcc/jobserver.cc
> > >  create mode 100644 gcc/jobserver.h
> > >  rename gcc/{lto => }/lto-partition.c (78%)
> > >  rename gcc/{lto => }/lto-partition.h (89%)
> > >  create mode 100644 gcc/testsuite/driver/a.c
> > >  create mode 100644 gcc/testsuite/driver/b.c
> > >  create mode 100644 gcc/testsuite/driver/driver.exp
> > >  create mode 100644 gcc/testsuite/driver/empty.c
> > >  create mode 100644 gcc/testsuite/driver/foo.c
> > >  create mode 100644 gcc/testsuite/gcc.dg/parallel-early-constant.c
> > >  create mode 100644 gcc/testsuite/gcc.dg/parallel-static-1.c
> > >  create mode 100644 gcc/testsuite/gcc.dg/parallel-static-2.c
> > >  create mode 100644 gcc/testsuite/gcc.dg/parallel-static-clash-1.c
> > >  create mode 100644 gcc/testsuite/gcc.dg/parallel-static-clash-aux.c
> > >
> > > --
> > > 2.28.0
> > >

Re: [PATCH 3/6] Implement fork-based parallelism engine

2020-08-29 Thread Jan Hubicka

> Hi, Honza.
> 
> Thank you for your detailed review!
> 
> On 08/27, Jan Hubicka wrote:
> > > diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> > > index c0b45795059..22405098dc5 100644
> > > --- a/gcc/cgraph.c
> > > +++ b/gcc/cgraph.c
> > > @@ -226,6 +226,22 @@ cgraph_node::delete_function_version_by_decl (tree 
> > > decl)
> > >decl_node->remove ();
> > >  }
> > >  
> > > +/* Release function dominator info if present.  */
> > > +
> > > +void
> > > +cgraph_node::maybe_release_dominators (void)
> > > +{
> > > +  struct function *fun = DECL_STRUCT_FUNCTION (decl);
> > > +
> > > +  if (fun && fun->cfg)
> > > +{
> > > +  if (dom_info_available_p (fun, CDI_DOMINATORS))
> > > + free_dominance_info (fun, CDI_DOMINATORS);
> > > +  if (dom_info_available_p (fun, CDI_POST_DOMINATORS))
> > > + free_dominance_info (fun, CDI_POST_DOMINATORS);
> > > +}
> > > +}
> > 
> > I am not sure if that needs to be member function, but if so we want to
> > merge it with other places in cgraph.c and cgraphunit.c where dominators
> > are freed.  I do not think you need to check avalability.
> 
> This is necessary to remove some nodes from the callgraph.  For some
> reason, if I node->remove () and it still have the dominance info
> available, it will fail some assertions on the compiler.
> 
> However, with regard to code layout, this can be moved to lto-cgraph.c,
> as it is only used there.

node->remove () is supposed to work here.  I relalize that we remove
random nodes currently only via the unreachable code removal that also
does node->remove_body () so there may be some bug.
> > > +  /* Get symtab node by order.  */
> > > +  static symtab_node *find_by_order (int order);
> > 
> > This is quadratic and moreover seems unused. Why do you add it?
> 
> I added this for debugging, since I used this a lot inside GDB.
> Sure, I can remove this without any problems, or print a warning
> for the developer to avoid calling this in production code.

We could keep this as separate patch, since it is independent of rest of
changes.   Having more debug_* functions is
fine with me, but I would like to having nondebug members since sooner
or later someone will use them in non-debug code.
> > > +  /* FIXME: Find out why body-removed nodes are marked for output.  */
> > > +  if (body_removed)
> > > +return;
> > 
> > Indeed, we should know :)
> 
> Looks like this was due an early problem. I removed this and bootstrap
> is working OK.

Cool, random changes like this looks suspicious :)
> > 
> > This looks odd, we have other places where we parse number from command
> > line :)
> 
> isdigit () is poisoned in GCC. But I guess I should look how -flto=
> does this.

Seems we simply do atoi and compare with 0 that is invalid.
> > 
> > Messing with WPA/ltrans flags is not good idea.  You already have
> > split_output for parallel build.  I sort of see why you set ltrans, but
> > why WPA?
> 
> Some assertions expected flag_wpa to be present.  Sure, I can add
> split_outputs in these assertions.

Yep, that would be cleaner. 
> > 
> > There is boundary computation in lto-cgraph.c so we should merge the
> > logic...
> 
> Agree.
> 
> > If you keep the lto-partition datastructures it will compute boundary
> > for you and you can just remove the rest (I got that working at one
> > point).
> 
> This is interesting, because I could not get that working out of the
> box. The lto_promote_cross_statics did not provide a fully working
> boundary that I could simple remove everything else. If you take a
> closer look, you will see that I am using the already computed boundary
> as a base, and incrementing that with the extra stuff required
> (mainly inline clones body).

What problems exactly you run into when you remove the extra code?
> > 
> > Aha, that is what it does :)
> > I wonder if creating the file conditionally (and late) can not lead to
> > race condition where we will use same tmp file name for other build
> > executed in parallel by make.
> 
> Hummm. True. Added to my TODO list :)
> Well, I never had any sort of issues with race condition here, even
> after stressing it, but this certainly is not proof that it is free of
> race conditition :)

I really do not know how this works, since we create other files with
delay too.  I suppose we get a tmp filename that is tested to be unique
and then we simply assume that we can derive names from it.

Honza

RE: [PATCH] testsuite: add -fno-tree-fre in gcc.dg/guality

2020-08-29 Thread Hu, Jiangping

Hi, Jakub

Thank you for your detailed explanation. 
I will try to compare the results of rtl expand as Richard have
suggested, to see if I can find anything. May be I can make
another patch.

Thanks again.

Regards!
Hujp

> On Thu, Aug 27, 2020 at 11:13:50AM +, Hu, Jiangping wrote:
> > I'm not sure about if the case should fail.
> > So, I add Jakub who committed this testcase.
> >
> > I thought the case should success, but for changes of gcc of
> > years, now it failed. So I think that may be some optimization
> > are unnecessary for this testcase, and I found the FRE.
> 
> The intent of the guality testsuite is to track regressions in debug info
> quality.  Because the testing matrix is huge
> (different targets x different -O* options x different gdb versions),
> it isn't really feasible to keep xfails for them accurately, so all we
> care
> about is whether we don't regress compared to older gcc releases for the
> same target, same -O* options and same gdb version.
> If we do regress e.g. because of some added optimization, the intent is
> that it is analyzed why it regressed and if possible some improvements
> in the debug info generation are added to deal with the optimization if
> possible.
> So adding -fno-tree-* is not the right solution, the majority of people
> will
> not use such options in their codes and so they will observe the debug
> info
> quality degradation there.
> 
>   Jakub
> 
>

[Patch, fortran] PR96495 - [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type

2020-08-29 Thread Paul Richard Thomas via Gcc-patches

This patch detects a scalar function result that has allocatable components
and is being used inside a scalarization loop. Before this patch, the
components would be deallocated and nullified within the scalarization loop
and so would cause a segfault on the second cycle of the loop.

The stored result has to be found by identifying the expression in the loop
ss chain. This is then used for the deallocation of the allocatable
components in the loop post block, which keeps gimple happy and prevents
the segfault.

Regtests on FC31/x86_64 - OK for master?

Paul

This patch fixes PR96495 - frees result components outside loop.

2020-29-08  Paul Thomas  

gcc/fortran
PR fortran/96495
* trans-expr.c (gfc_conv_procedure_call): Take the deallocation
of allocatable result components of a scalar result outside the
scalarization loop. Find and use the stored result.

gcc/testsuite/
PR fortran/96495
* gfortran.dg/alloc_comp_result_2.f90 : New test.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 36ff9b5cbc6..a690839f591 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6421,6 +6421,26 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 
 	  if (!finalized && !e->must_finalize)
 	{
+	  bool scalar_res_outside_loop;
+	  scalar_res_outside_loop = e->expr_type == EXPR_FUNCTION
+	&& parm_rank == 0
+	&& parmse.loop;
+
+	  if (scalar_res_outside_loop)
+		{
+		  /* Go through the ss chain to find the argument and use
+		 the stored value.  */
+		  gfc_ss *tmp_ss = parmse.loop->ss;
+		  for (; tmp_ss; tmp_ss = tmp_ss->next)
+		if (tmp_ss->info
+			&& tmp_ss->info->expr == e
+			&& tmp_ss->info->data.scalar.value != NULL_TREE)
+		  {
+			tmp = tmp_ss->info->data.scalar.value;
+			break;
+		  }
+		}
+
 	  if ((e->ts.type == BT_CLASS
 		   && GFC_CLASS_TYPE_P (TREE_TYPE (tmp)))
 		  || e->ts.type == BT_DERIVED)
@@ -6429,7 +6449,11 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 	  else if (e->ts.type == BT_CLASS)
 		tmp = gfc_deallocate_alloc_comp (CLASS_DATA (e)->ts.u.derived,
 		 tmp, parm_rank);
-	  gfc_prepend_expr_to_block (&post, tmp);
+
+	  if (scalar_res_outside_loop)
+		gfc_add_expr_to_block (&parmse.loop->post, tmp);
+	  else
+		gfc_prepend_expr_to_block (&post, tmp);
 	}
 }
 
! { dg-do run }
!
! Test the fix for PR96495 - segfaults at runtime at locations below.
!
! Contributed by Paul Luckner  
!
module foo_m

  implicit none

  type foo
integer, allocatable :: j(:)
  end type

  interface operator(.unary.)
module procedure neg_foo
  end interface

  interface operator(.binary.)
module procedure foo_sub_foo
  end interface

  interface operator(.binaryElemental.)
module procedure foo_add_foo
  end interface

contains

  elemental function foo_add_foo(f, g) result(h)
!! an example for an elemental binary operator
type(foo), intent(in) :: f, g
type(foo) :: h

allocate (h%j(size(f%j)), source = f%j+g%j)
  end function

  elemental function foo_sub_foo(f, g) result(h)
!! an example for an elemental binary operator
type(foo), intent(in) :: f, g
type(foo) :: h

allocate (h%j(size(f%j)), source = f%j-3*g%j)
  end function

  pure function neg_foo(f) result(g)
!! an example for a unary operator
type(foo), intent(in) :: f
type(foo) :: g

allocate (g%j(size(f%j)), source = -f%j)
  end function

end module

program main_tmp

  use foo_m

  implicit none

  type(foo) f, g(2)

  allocate (f%j(3))
  f%j = [2, 3, 4]

  g = f
  if (any (g(2)%j .ne. [2, 3, 4])) stop 1

  g = g .binaryElemental. (f .binary. f) ! threw "Segmentation fault"
  if (any (g(2)%j .ne. [-2,-3,-4])) stop 2

  g = g .binaryElemental. (  .unary.  f) ! threw "Segmentation fault"
  if (any (g(2)%j .ne. [-4,-6,-8])) stop 3

end program

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

2020-08-29 Thread Mark Wielaard

Hi,

On Wed, Aug 26, 2020 at 04:38:21PM -0700, H.J. Lu wrote:
> On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard  wrote:
> > Would it be possible to have something like the following in gas, so
> > that it doesn't try generating a .debug_line section if there already
> > is one, even when -gdwarf-N is given (unless the assembly also
> > contains .loc directives because that shows the user is really
> > confused)?
> >
> > diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
> > index e4ba56d82ba..c0c09f4e9d0 100644
> > --- a/gas/dwarf2dbg.c
> > +++ b/gas/dwarf2dbg.c
> > @@ -2626,7 +2626,7 @@ dwarf2_init (void)
> >
> >
> >  /* Finish the dwarf2 debug sections.  We emit .debug.line if there
> > -   were any .file/.loc directives, or --gdwarf2 was given, or if the
> > +   were any .file/.loc directives, or --gdwarf2 was given, and if the
> > file has a non-empty .debug_info section and an empty .debug_line
> > section.  If we emit .debug_line, and the .debug_info section is
> > empty, we also emit .debug_info, .debug_aranges and .debug_abbrev.
> > @@ -2650,9 +2650,16 @@ dwarf2_finish (void)
> >empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg);
> >
> >/* We can't construct a new debug_line section if we already have one.
> > - Give an error.  */
> > + Give an error if we have seen any .loc, otherwise trust the user
> > + knows what they are doing and want to generate the .debug_line
> > + (and all other debug sections) themselves.  */
> >if (all_segs && !empty_debug_line)
> > -as_fatal ("duplicate .debug_line sections");
> > +{
> > +  if (dwarf2_loc_directive_seen)
> > +   as_fatal ("duplicate .debug_line sections");
> > +  else
> > +   return;
> > +}
> >
> >if ((!all_segs && emit_other_sections)
> >|| (!emit_other_sections && !empty_debug_line))
> >
>
> I have run into this issue before.  "as -g" shouldn't silently
> generate incorrect debug info when input assembly codes already
> contain debug directives.  AS should either issue an error or
> ignore -g.

Right, that is what this patch does for .debug_line.  gas already
doesn't generate .debug_info, .debug_aranges and .debug_abbrev if
.debug_info is non-empty, even if -g is given.

> In either case, we need a testcase  to verify it.

Right, and the documentation needs to be update.  But first we have to
know whether the gas maintainers think this is the right approach.

Cheers,

Mark

[PATCH] RISC-V/libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

2020-08-29 Thread Maciej W. Rozycki via Gcc-patches

Use `-fasynchronous-unwind-tables' rather than `-fexceptions 
-fnon-call-exceptions' in LIB2_DIVMOD_FUNCS compilation flags so as to 
provide unwind tables for the affected functions while not pulling the 
unwinder proper, which is not required here.

Beyond saving program space it fixes a RISC-V glibc build error due to 
unsatisfied `malloc' and `free' references from the unwinder causing 
link errors with `ld.so' where libgcc has been built at -O0.

libgcc/
* config/riscv/t-elf (LIB2_DIVMOD_EXCEPTION_FLAGS): New 
variable.
---
Hi,

 As Mon, Aug 31st (a bank holiday in England) will be my last day at 
Western Digital and I won't be able to submit patches on behalf of the 
company afterwards here is a replacement change for RISC-V only in case 
the generic one discussed here:

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

2020-08-29 Thread H.J. Lu via Gcc-patches

On Sat, Aug 29, 2020 at 5:24 AM Mark Wielaard  wrote:
>
> Hi,
>
> On Wed, Aug 26, 2020 at 04:38:21PM -0700, H.J. Lu wrote:
> > On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard  wrote:
> > > Would it be possible to have something like the following in gas, so
> > > that it doesn't try generating a .debug_line section if there already
> > > is one, even when -gdwarf-N is given (unless the assembly also
> > > contains .loc directives because that shows the user is really
> > > confused)?
> > >
> > > diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
> > > index e4ba56d82ba..c0c09f4e9d0 100644
> > > --- a/gas/dwarf2dbg.c
> > > +++ b/gas/dwarf2dbg.c
> > > @@ -2626,7 +2626,7 @@ dwarf2_init (void)
> > >
> > >
> > >  /* Finish the dwarf2 debug sections.  We emit .debug.line if there
> > > -   were any .file/.loc directives, or --gdwarf2 was given, or if the
> > > +   were any .file/.loc directives, or --gdwarf2 was given, and if the
> > > file has a non-empty .debug_info section and an empty .debug_line
> > > section.  If we emit .debug_line, and the .debug_info section is
> > > empty, we also emit .debug_info, .debug_aranges and .debug_abbrev.
> > > @@ -2650,9 +2650,16 @@ dwarf2_finish (void)
> > >empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg);
> > >
> > >/* We can't construct a new debug_line section if we already have one.
> > > - Give an error.  */
> > > + Give an error if we have seen any .loc, otherwise trust the user
> > > + knows what they are doing and want to generate the .debug_line
> > > + (and all other debug sections) themselves.  */
> > >if (all_segs && !empty_debug_line)
> > > -as_fatal ("duplicate .debug_line sections");
> > > +{
> > > +  if (dwarf2_loc_directive_seen)
> > > +   as_fatal ("duplicate .debug_line sections");
> > > +  else
> > > +   return;
> > > +}
> > >
> > >if ((!all_segs && emit_other_sections)
> > >|| (!emit_other_sections && !empty_debug_line))
> > >
> >
> > I have run into this issue before.  "as -g" shouldn't silently
> > generate incorrect debug info when input assembly codes already
> > contain debug directives.  AS should either issue an error or
> > ignore -g.
>
> Right, that is what this patch does for .debug_line.  gas already
> doesn't generate .debug_info, .debug_aranges and .debug_abbrev if
> .debug_info is non-empty, even if -g is given.
>
> > In either case, we need a testcase  to verify it.
>
> Right, and the documentation needs to be update.  But first we have to
> know whether the gas maintainers think this is the right approach.
>

-g should be ignored in this case.


-- 
H.J.

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

2020-08-29 Thread Mark Wielaard

Hi,

On Sat, Aug 29, 2020 at 07:34:35AM -0700, H.J. Lu wrote:
> On Sat, Aug 29, 2020 at 5:24 AM Mark Wielaard  wrote:
> > On Wed, Aug 26, 2020 at 04:38:21PM -0700, H.J. Lu wrote:
> > > On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard  wrote:
> > > > Would it be possible to have something like the following in gas, so
> > > > that it doesn't try generating a .debug_line section if there already
> > > > is one, even when -gdwarf-N is given (unless the assembly also
> > > > contains .loc directives because that shows the user is really
> > > > confused)?
> > > >
> > > > diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
> > > > index e4ba56d82ba..c0c09f4e9d0 100644
> > > > --- a/gas/dwarf2dbg.c
> > > > +++ b/gas/dwarf2dbg.c
> > > > @@ -2626,7 +2626,7 @@ dwarf2_init (void)
> > > >
> > > >
> > > >  /* Finish the dwarf2 debug sections.  We emit .debug.line if there
> > > > -   were any .file/.loc directives, or --gdwarf2 was given, or if the
> > > > +   were any .file/.loc directives, or --gdwarf2 was given, and if the
> > > > file has a non-empty .debug_info section and an empty .debug_line
> > > > section.  If we emit .debug_line, and the .debug_info section is
> > > > empty, we also emit .debug_info, .debug_aranges and .debug_abbrev.
> > > > @@ -2650,9 +2650,16 @@ dwarf2_finish (void)
> > > >empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg);
> > > >
> > > >/* We can't construct a new debug_line section if we already have 
> > > > one.
> > > > - Give an error.  */
> > > > + Give an error if we have seen any .loc, otherwise trust the user
> > > > + knows what they are doing and want to generate the .debug_line
> > > > + (and all other debug sections) themselves.  */
> > > >if (all_segs && !empty_debug_line)
> > > > -as_fatal ("duplicate .debug_line sections");
> > > > +{
> > > > +  if (dwarf2_loc_directive_seen)
> > > > +   as_fatal ("duplicate .debug_line sections");
> > > > +  else
> > > > +   return;
> > > > +}
> > > >
> > > >if ((!all_segs && emit_other_sections)
> > > >|| (!emit_other_sections && !empty_debug_line))
> > >
> > > I have run into this issue before.  "as -g" shouldn't silently
> > > generate incorrect debug info when input assembly codes already
> > > contain debug directives.  AS should either issue an error or
> > > ignore -g.
> >
> > Right, that is what this patch does for .debug_line.  gas already
> > doesn't generate .debug_info, .debug_aranges and .debug_abbrev if
> > .debug_info is non-empty, even if -g is given.
> >
> > > In either case, we need a testcase  to verify it.
> >
> > Right, and the documentation needs to be update.  But first we have to
> > know whether the gas maintainers think this is the right approach.
> 
> -g should be ignored in this case.

I am not sure what you mean by "in this case", or what precisely it
means to "ignore -g".

My proposal, and what my strawman patch implements, is that gas will
generate a .debug_line section when -g is given and the debug types is
DWARF (just as it does now). Unless there is a non-empty .debug_line
section already created by the input assembly and the input assembly
does not contain any .loc directive then gas will not try to generate
a .debug_line section itself but leaves the non-empty .debug_line as
is (currently gas will generate an error in this case). But if the
input assembly does contain both .loc directives and creates a
non-empty .debug line section gas will still generate an error (as it
does now, whether or not the input assembly contains any .loc
directives).

Does this sound sane?

Thanks,

Mark

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

2020-08-29 Thread H.J. Lu via Gcc-patches

On Sat, Aug 29, 2020 at 8:23 AM Mark Wielaard  wrote:
>
> Hi,
>
> On Sat, Aug 29, 2020 at 07:34:35AM -0700, H.J. Lu wrote:
> > On Sat, Aug 29, 2020 at 5:24 AM Mark Wielaard  wrote:
> > > On Wed, Aug 26, 2020 at 04:38:21PM -0700, H.J. Lu wrote:
> > > > On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard  wrote:
> > > > > Would it be possible to have something like the following in gas, so
> > > > > that it doesn't try generating a .debug_line section if there already
> > > > > is one, even when -gdwarf-N is given (unless the assembly also
> > > > > contains .loc directives because that shows the user is really
> > > > > confused)?
> > > > >
> > > > > diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
> > > > > index e4ba56d82ba..c0c09f4e9d0 100644
> > > > > --- a/gas/dwarf2dbg.c
> > > > > +++ b/gas/dwarf2dbg.c
> > > > > @@ -2626,7 +2626,7 @@ dwarf2_init (void)
> > > > >
> > > > >
> > > > >  /* Finish the dwarf2 debug sections.  We emit .debug.line if there
> > > > > -   were any .file/.loc directives, or --gdwarf2 was given, or if the
> > > > > +   were any .file/.loc directives, or --gdwarf2 was given, and if the
> > > > > file has a non-empty .debug_info section and an empty .debug_line
> > > > > section.  If we emit .debug_line, and the .debug_info section is
> > > > > empty, we also emit .debug_info, .debug_aranges and .debug_abbrev.
> > > > > @@ -2650,9 +2650,16 @@ dwarf2_finish (void)
> > > > >empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg);
> > > > >
> > > > >/* We can't construct a new debug_line section if we already have 
> > > > > one.
> > > > > - Give an error.  */
> > > > > + Give an error if we have seen any .loc, otherwise trust the user
> > > > > + knows what they are doing and want to generate the .debug_line
> > > > > + (and all other debug sections) themselves.  */
> > > > >if (all_segs && !empty_debug_line)
> > > > > -as_fatal ("duplicate .debug_line sections");
> > > > > +{
> > > > > +  if (dwarf2_loc_directive_seen)
> > > > > +   as_fatal ("duplicate .debug_line sections");
> > > > > +  else
> > > > > +   return;
> > > > > +}
> > > > >
> > > > >if ((!all_segs && emit_other_sections)
> > > > >|| (!emit_other_sections && !empty_debug_line))
> > > >
> > > > I have run into this issue before.  "as -g" shouldn't silently
> > > > generate incorrect debug info when input assembly codes already
> > > > contain debug directives.  AS should either issue an error or
> > > > ignore -g.
> > >
> > > Right, that is what this patch does for .debug_line.  gas already
> > > doesn't generate .debug_info, .debug_aranges and .debug_abbrev if
> > > .debug_info is non-empty, even if -g is given.
> > >
> > > > In either case, we need a testcase  to verify it.
> > >
> > > Right, and the documentation needs to be update.  But first we have to
> > > know whether the gas maintainers think this is the right approach.
> >
> > -g should be ignored in this case.
>
> I am not sure what you mean by "in this case", or what precisely it
> means to "ignore -g".
>
> My proposal, and what my strawman patch implements, is that gas will
> generate a .debug_line section when -g is given and the debug types is
> DWARF (just as it does now). Unless there is a non-empty .debug_line
> section already created by the input assembly and the input assembly
> does not contain any .loc directive then gas will not try to generate
> a .debug_line section itself but leaves the non-empty .debug_line as
> is (currently gas will generate an error in this case). But if the
> input assembly does contain both .loc directives and creates a
> non-empty .debug line section gas will still generate an error (as it
> does now, whether or not the input assembly contains any .loc
> directives).
>
> Does this sound sane?

What if there is a .file directive,  but without .loc directive, like

$ gcc -c x.c -Wa,-g


-- 
H.J.

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

2020-08-29 Thread Mark Wielaard

Hi,

On Sat, Aug 29, 2020 at 08:43:30AM -0700, H.J. Lu wrote:
> On Sat, Aug 29, 2020 at 8:23 AM Mark Wielaard  wrote:
> > My proposal, and what my strawman patch implements, is that gas will
> > generate a .debug_line section when -g is given and the debug types is
> > DWARF (just as it does now). Unless there is a non-empty .debug_line
> > section already created by the input assembly and the input assembly
> > does not contain any .loc directive then gas will not try to generate
> > a .debug_line section itself but leaves the non-empty .debug_line as
> > is (currently gas will generate an error in this case). But if the
> > input assembly does contain both .loc directives and creates a
> > non-empty .debug line section gas will still generate an error (as it
> > does now, whether or not the input assembly contains any .loc
> > directives).
> >
> > Does this sound sane?
> 
> What if there is a .file directive,  but without .loc directive, like
> 
> $ gcc -c x.c -Wa,-g

That situation does not change, since in that case no .debug_*
sections are generated in the assembly file, so gas will generate
everything it currently generates.

Cheers,

Mark

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

2020-08-29 Thread H.J. Lu via Gcc-patches

On Sat, Aug 29, 2020 at 9:33 AM Mark Wielaard  wrote:
>
> Hi,
>
> On Sat, Aug 29, 2020 at 08:43:30AM -0700, H.J. Lu wrote:
> > On Sat, Aug 29, 2020 at 8:23 AM Mark Wielaard  wrote:
> > > My proposal, and what my strawman patch implements, is that gas will
> > > generate a .debug_line section when -g is given and the debug types is
> > > DWARF (just as it does now). Unless there is a non-empty .debug_line
> > > section already created by the input assembly and the input assembly
> > > does not contain any .loc directive then gas will not try to generate
> > > a .debug_line section itself but leaves the non-empty .debug_line as
> > > is (currently gas will generate an error in this case). But if the
> > > input assembly does contain both .loc directives and creates a
> > > non-empty .debug line section gas will still generate an error (as it
> > > does now, whether or not the input assembly contains any .loc
> > > directives).
> > >
> > > Does this sound sane?
> >
> > What if there is a .file directive,  but without .loc directive, like
> >
> > $ gcc -c x.c -Wa,-g
>
> That situation does not change, since in that case no .debug_*
> sections are generated in the assembly file, so gas will generate
> everything it currently generates.
>

Will line info be correct in this case?


-- 
H.J.

Re: [committed] libstdc++: Fix std::gcd and std::lcm for unsigned integers [PR 92978]

2020-08-29 Thread Jonathan Wakely via Gcc-patches


On 28/08/20 23:53 +0100, Jonathan Wakely wrote:

On 29/08/20 00:20 +0200, Daniel KrÃ¼gler wrote:

Am Sa., 29. Aug. 2020 um 00:12 Uhr schrieb Jonathan Wakely via
Libstdc++ :


This fixes a bug with mixed signed and unsigned types, where converting
a negative value to the unsigned result type alters the value. The
solution is to obtain the absolute values of the arguments immediately
and to perform the actual GCD or LCM algorithm on two arguments of the
same type.

In order to operate on the most negative number without overflow when
taking its absolute, use an unsigned type for the result of the abs
operation. For example, -INT_MIN will overflow, but -(unsigned)INT_MIN
is (unsigned)INT_MAX+1U which is the correct value.

libstdc++-v3/ChangeLog:

   PR libstdc++/92978
   * include/std/numeric (__abs_integral): Replace with ...
   (__detail::__absu): New function template that returns an
   unsigned type, guaranteeing it can represent the most
   negative signed value.
   (__detail::__gcd, __detail::__lcm): Require arguments to
   be unsigned and therefore already non-negative.
   (gcd, lcm): Convert arguments to absolute value as unsigned
   type before calling __detail::__gcd or __detail::__lcm.
   * include/experimental/numeric (gcd, lcm): Likewise.
   * testsuite/26_numerics/gcd/gcd_neg.cc: Adjust expected
   errors.
   * testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.
   * testsuite/26_numerics/gcd/92978.cc: New test.
   * testsuite/26_numerics/lcm/92978.cc: New test.
   * testsuite/experimental/numeric/92978.cc: New test.

Tested powerpc64le-linux. Committed to trunk.


Shouldn't the overload of __absu

void __absu(bool) = delete;

still also be a template or is just the diff presentation confusing me?


Good point! It's called as __absu(v) so it needs to be a function
template for the deleted one to be a candidate.

I'm not sure we really need it, since all the callers have a
static_assert ensuring it's not a bool. But if we have it, it should
be correct.


I've just pushed this fix, after testing on powerpc64le-linux.

Thanks for the review, Daniel.


commit 0789600c597ff1f8ac06e84ffb584c853d1675d1
Author: Jonathan Wakely 
Date:   Sat Aug 29 18:24:08 2020

libstdc++: Fix deleted overload of __absu(bool)

libstdc++-v3/ChangeLog:

* include/std/numeric (__detail::__absu(bool)): Make deleted
function a function template, so it will be chosen for calls
with an explicit template argument list.
* testsuite/26_numerics/gcd/gcd_neg.cc: Add dg-prune-output.
* testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.

diff --git a/libstdc++-v3/include/std/numeric b/libstdc++-v3/include/std/numeric
index 8f2ed5c6a5e..bd70a52019b 100644
--- a/libstdc++-v3/include/std/numeric
+++ b/libstdc++-v3/include/std/numeric
@@ -95,7 +95,7 @@ namespace __detail
   return __val < 0 ? -(_Up)__val : (_Up)__val;
 }
 
-  void __absu(bool) = delete;
+  template void __absu(bool) = delete;
 
   // GCD implementation
   template
diff --git a/libstdc++-v3/testsuite/26_numerics/gcd/gcd_neg.cc b/libstdc++-v3/testsuite/26_numerics/gcd/gcd_neg.cc
index 707148a2670..2e56bc650a7 100644
--- a/libstdc++-v3/testsuite/26_numerics/gcd/gcd_neg.cc
+++ b/libstdc++-v3/testsuite/26_numerics/gcd/gcd_neg.cc
@@ -50,4 +50,5 @@ test01()
 // { dg-error "must be integers" "" { target *-*-* } 135 }
 // { dg-error "must not be bool" "" { target *-*-* } 136 }
 // { dg-error "must not be bool" "" { target *-*-* } 137 }
+// { dg-prune-output "deleted function" }
 // { dg-prune-output "incomplete type .*make_unsigned" }
diff --git a/libstdc++-v3/testsuite/26_numerics/lcm/lcm_neg.cc b/libstdc++-v3/testsuite/26_numerics/lcm/lcm_neg.cc
index d4aa6b59da8..9e83fdcae0b 100644
--- a/libstdc++-v3/testsuite/26_numerics/lcm/lcm_neg.cc
+++ b/libstdc++-v3/testsuite/26_numerics/lcm/lcm_neg.cc
@@ -50,4 +50,5 @@ test01()
 // { dg-error "must be integers" "" { target *-*-* } 149 }
 // { dg-error "must not be bool" "" { target *-*-* } 150 }
 // { dg-error "must not be bool" "" { target *-*-* } 151 }
+// { dg-prune-output "deleted function" }
 // { dg-prune-output "incomplete type .*make_unsigned" }

Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC)

2020-08-29 Thread Mark Wielaard




H.J. Lu wrote:
> On Sat, Aug 29, 2020 at 9:33 AM Mark Wielaard  wrote:
>> Hi,
>>
>> On Sat, Aug 29, 2020 at 08:43:30AM -0700, H.J. Lu wrote:
>>> On Sat, Aug 29, 2020 at 8:23 AM Mark Wielaard  wrote:
 My proposal, and what my strawman patch implements, is that gas will
 generate a .debug_line section when -g is given and the debug types is
 DWARF (just as it does now). Unless there is a non-empty .debug_line
 section already created by the input assembly and the input assembly
 does not contain any .loc directive then gas will not try to generate
 a .debug_line section itself but leaves the non-empty .debug_line as
 is (currently gas will generate an error in this case). But if the
 input assembly does contain both .loc directives and creates a
 non-empty .debug line section gas will still generate an error (as it
 does now, whether or not the input assembly contains any .loc
 directives).

 Does this sound sane?
>>>
>>> What if there is a .file directive,  but without .loc directive, like
>>>
>>> $ gcc -c x.c -Wa,-g
>>
>> That situation does not change, since in that case no .debug_*
>> sections are generated in the assembly file, so gas will generate
>> everything it currently generates.
>
> Will line info be correct in this case?

Nothing about how gas generates the line table will change with the above 
proposal. It only changes the behaviour when the assembly already contains a 
line table.

Re: [PATCH] ipa: Merge vectors describing argument values into one type

2020-08-29 Thread Martin Jambor

Hi,

On Sat, Aug 29 2020, Jan Hubicka wrote:
>> Hi,
>> 
>> this large patch is a semi-mechanical change which aims to replace
>> uses of separate vectors about known scalar values (usually called
>> known_vals or known_csts), known aggregate values (known_aggs), known
>> virtual call contexts (known_contexts) and known value
>> ranges (known_value_ranges) with uses of one type called
>> ipa_call_arg_values.  The main benefit is bringing down the number of
>> arguments that various call context evaluating functions have.
>> Because the new type uses auto_vecs deallocation is simpler and it
>> also takes advantage of storage within the auto_vecs themselves,
>> eliminating the need for allocating memory when analyzing most
>> functions.
>> 
>> The one place where this patch is not mechanical is the
>> node_context_cache_entry RCU cache.  Before the elements contained
>> directly ipa_call_context instances which however owned their vectors,
>> they did not share them with their users like non-cache contexts.  Now
>> the vectors are behind the pointer which means ipa_call_arg_values
>> would have to be allocated, for many functions at once, and so it
>> could not make use of auto_vecs with generous internal storage.
>> 
>> I avoided both by reworking the cache to contain copies of all fields
>> o interest of ipa_call_context, including the interesting vectors.
>> This makes the type a bit more verbose but the main functionality,
>> storing to the cache and comparing a context with a cache entry,
>> remained very similar.
>
> Can you pleae benchmark this on building Firfox or something similar?
> I was running into two problems here. First was overhead of malloc
> allocations and that is reason why I am trying to not allocate the
> vector when not necessary and also place them on stack rather then heap
> for those having short lifetime (not being in cache).
>
> Second problem is memory use - we may end up with quite many contextes
> since calls are very numerous.
>

I can but the patch does not change where the vectors are allocated and
does not store more stuff to cache than the current code.  In fact,
because the new cache does not store m_node, it saves one pointer.

When I wrote the patch "copies of all fields of interest of
ipa_call_context" I meant in the source code of GCC, from one class into
another, not when the cache operates.  The storing mechanism was created
by modifying the current duplicate_from so that it operates on two types
instead of one, it still meticulously makes sure it copies only useful
data and all that.

But sure, I will double check the series does not increase memory use.

Martin

Re: [PATCH 3/n] ipa: Simplify interface of ipa_call_context::estimate_size_and_time

2020-08-29 Thread Martin Jambor

Hi,

On Sat, Aug 29 2020, Jan Hubicka wrote:
>> Hi,
>> 
>> this patch changes ipa_call_context::estimate_size_and_time to store
>> its results into member fields of the ipa_call_context class instead
>> into pointers it receives as parameters so that it can compute ore
>> stuff without cluttering the interface even further.
>> 
>> Bootstrapped and tested on x86_64-linux.  OK for master on top of the
>> previous two patches?
>
> ipa_call_context is intended to be structure holding all parameters that
> are needed to produce the estimates (size/time/hints).

even today it only "holds" the data when it resides in the RCU cache,
otherwise it points to data "owned" by the caller.  Admittedly, my first
patch makes the cache data structure separate, making ipa_class_context
only a utility for calculating the estimates - but given how all the
code is structured, it does not really work as the grand encapsulator of
all context data when passing it from a function to function.

> Adding the actual estimates there would duplicate it with cache.

The first patch in the series makes the cache items not contain
ipa_call_context directly, so in my patch series at least, the estimates
are not duplicated.

> What
> about keeping them separate and inventing ipa_call_estimates structure
> to hold the reults?

I can but unless you do not like the first patch and want me to re-write
it or just not do anything like it, I don't think it matters because the
structures will almost always lie next to each other on the user's
stack.

Martin

>> 
>> 
>> gcc/ChangeLog:
>> 
>> 2020-08-28  Martin Jambor  
>> 
>>  * ipa-fnsummary.h (class ipa_call_context): Changed declaration of
>>  estimate_size_and_time to accept two booleans.  Added an overload
>>  of the method without any parameters.  New fields m_size,
>>  m_min_size, m_time, m_nonspecialized_time and m_hints.
>>  * ipa-cp.c (hint_time_bonus): Changed the second parameter from
>>  just hints to a const reference to ipa_call_context.
>>  (perform_estimation_of_a_value): Adjusted to the new interface of
>>  ipa_call_context::estimate_size_and_time.
>>  * ipa-fnsummary.c (ipa_call_context::estimate_size_and_time):
>>  Modified to store results into member fields of the class.
>>  * ipa-inline-analysis.c (do_estimate_edge_time): Adjusted to the
>>  new interface of ipa_call_context::estimate_size_and_time.
>>  (do_estimate_edge_size): Likewise.
>>  (do_estimate_edge_hints): Likewise.

Re: [PATCH 3/n] ipa: Simplify interface of ipa_call_context::estimate_size_and_time

2020-08-29 Thread Jan Hubicka

> Hi,
> 
> On Sat, Aug 29 2020, Jan Hubicka wrote:
> >> Hi,
> >> 
> >> this patch changes ipa_call_context::estimate_size_and_time to store
> >> its results into member fields of the ipa_call_context class instead
> >> into pointers it receives as parameters so that it can compute ore
> >> stuff without cluttering the interface even further.
> >> 
> >> Bootstrapped and tested on x86_64-linux.  OK for master on top of the
> >> previous two patches?
> >
> > ipa_call_context is intended to be structure holding all parameters that
> > are needed to produce the estimates (size/time/hints).
> 
> even today it only "holds" the data when it resides in the RCU cache,
> otherwise it points to data "owned" by the caller.  Admittedly, my first
> patch makes the cache data structure separate, making ipa_class_context
> only a utility for calculating the estimates - but given how all the
> code is structured, it does not really work as the grand encapsulator of
> all context data when passing it from a function to function.
> 
> > Adding the actual estimates there would duplicate it with cache.
> 
> The first patch in the series makes the cache items not contain
> ipa_call_context directly, so in my patch series at least, the estimates
> are not duplicated.

ipa_call_context defines the context estimates depends on.  This puts
all the info to one place and makes the cache well defined - it assigns
contexts to estimates. From this point of view I do not quite like
duplicating this logic (copying things into different datastructure) and
making contxt to also contain the esitmates since these are, well, not
context of the call.

I am happy with merging the analysis results into something like
class function_body_estimate holding all the values.

Games with the ownerhip you mention above was not original plan.
While perfing inliner I noticed that we spend measurable time in malloc
and that mostly goes to alocaitng the vectors (which we did for long
time).  Perhaps cleaner solution is to have
ipa_context_base which is derived by ipa_context and ipa_cached_context
where first preallocats on stack while second allocates on heap?

Honza
> 
> > What
> > about keeping them separate and inventing ipa_call_estimates structure
> > to hold the reults?
> 
> I can but unless you do not like the first patch and want me to re-write
> it or just not do anything like it, I don't think it matters because the
> structures will almost always lie next to each other on the user's
> stack.
> 
> Martin
> 
> >> 
> >> 
> >> gcc/ChangeLog:
> >> 
> >> 2020-08-28  Martin Jambor  
> >> 
> >>* ipa-fnsummary.h (class ipa_call_context): Changed declaration of
> >>estimate_size_and_time to accept two booleans.  Added an overload
> >>of the method without any parameters.  New fields m_size,
> >>m_min_size, m_time, m_nonspecialized_time and m_hints.
> >>* ipa-cp.c (hint_time_bonus): Changed the second parameter from
> >>just hints to a const reference to ipa_call_context.
> >>(perform_estimation_of_a_value): Adjusted to the new interface of
> >>ipa_call_context::estimate_size_and_time.
> >>* ipa-fnsummary.c (ipa_call_context::estimate_size_and_time):
> >>Modified to store results into member fields of the class.
> >>* ipa-inline-analysis.c (do_estimate_edge_time): Adjusted to the
> >>new interface of ipa_call_context::estimate_size_and_time.
> >>(do_estimate_edge_size): Likewise.
> >>(do_estimate_edge_hints): Likewise.

Re: [PATCH] gcov-profile: clarify profile-exclude-files documentation [PR96285]

2020-08-29 Thread Göran Uddeborg

Jeff Law:
> On Fri, 2020-07-24 at 15:42 +0200, Martin Liška wrote:
> > Please install the patch.
> I'm pretty sure Goran doesn't have write access.  So I committed the patch for
> him.

Thanks! (As I don't have write access, I didn't understand the
instruction was directed at me; I thought it was aimed to the list in
general.)

[r11-349 Regression] FAIL: gfortran.dg/gomp/target1.f90 -O (test for excess errors) on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

f884bef2105d748fd7869cd641cbb4f6b6bb is the first bad commit
commit f884bef2105d748fd7869cd641cbb4f6b6bb
Author: Tobias Burnus 
Date:   Wed May 13 10:06:45 2020 +0200

[Fortran] OpenMP - permit lastprivate in distribute + SIMD fixes (PR94690)

caused

FAIL: gfortran.dg/gomp/target1.f90   -O  (internal compiler error)
FAIL: gfortran.dg/gomp/target1.f90   -O  (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-349/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/target1.f90 --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-2623 Regression] FAIL: gcc.target/i386/vectorize8.c (test for excess errors) on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

99e4891ed552aca4ca147671701edd0b31015f66 is the first bad commit
commit 99e4891ed552aca4ca147671701edd0b31015f66
Author: liuhongt 
Date:   Mon Jul 20 10:13:58 2020 +0800

Using UNSPEC for vector compare to mask register.

caused

FAIL: gcc.target/i386/vectorize8.c (internal compiler error)
FAIL: gcc.target/i386/vectorize8.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2623/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/vectorize8.c --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-571 Regression] FAIL: gcc.target/i386/pr92658-avx512f.c scan-assembler-times vpmovqw 1 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

e740f3d73144abbca1ad98a04825c6bd63314a0b is the first bad commit
commit e740f3d73144abbca1ad98a04825c6bd63314a0b
Author: liuhongt 
Date:   Wed May 20 15:53:14 2020 +0800

Add missing vector truncmn2 expanders [PR92658]

caused

FAIL: gcc.target/i386/pr92658-avx512f.c scan-assembler-times vpmovdb 1
FAIL: gcc.target/i386/pr92658-avx512f.c scan-assembler-times vpmovdw 1
FAIL: gcc.target/i386/pr92658-avx512f.c scan-assembler-times vpmovqd 1
FAIL: gcc.target/i386/pr92658-avx512f.c scan-assembler-times vpmovqw 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-571/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr92658-avx512f.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-894 Regression] FAIL: gcc.target/i386/pr92658-avx512bw-trunc.c scan-assembler-times vpmovwb 3 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0b99f67639956eaadfc8da6a704e0e1edbafc18 is the first bad commit
commit c0b99f67639956eaadfc8da6a704e0e1edbafc18
Author: liuhongt 
Date:   Thu Jun 4 13:22:09 2020 +0800

Fix uppercase in trunc2.

caused

FAIL: gcc.target/i386/pr92658-avx512bw-trunc.c scan-assembler-times vpmovwb 3

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-894/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr92658-avx512bw-trunc.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-571 Regression] FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized "VEC_PACK_TRUNC" 1 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

e740f3d73144abbca1ad98a04825c6bd63314a0b is the first bad commit
commit e740f3d73144abbca1ad98a04825c6bd63314a0b
Author: liuhongt 
Date:   Wed May 20 15:53:14 2020 +0800

Add missing vector truncmn2 expanders [PR92658]

caused

FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized 
"BIT_FIELD_REF" 2
FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized 
"VEC_PACK_TRUNC" 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-571/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr92645-4.c --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-1518 Regression] FAIL: gcc.target/i386/pr78904-4a.c scan-assembler [ \t]movb[\t ]+%.h, t on Linux/x86_64 (-m32 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

e95395926a84a2406faefe0995295d199d595440 is the first bad commit
commit e95395926a84a2406faefe0995295d199d595440
Author: Uros Bizjak 
Date:   Thu Jun 18 20:12:48 2020 +0200

i386: Fix mode of ZERO_EXTRACT RTXes, remove ext_register_operand predicate.

caused

FAIL: gcc.target/i386/pr78904-4a.c scan-assembler [ \t]movb[\t ]+%.h, t

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-1518/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr78904-4a.c --target_board='unix{-m32\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-2588 Regression] FAIL: gcc.target/i386/minmax-9.c scan-assembler-times test 3 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c072fd236dc08f990bfcffd98b27f211a39bb404 is the first bad commit
commit c072fd236dc08f990bfcffd98b27f211a39bb404
Author: Roger Sayle 
Date:   Thu Aug 6 09:15:25 2020 +0100

x86_64: Integer min/max improvements.

caused

FAIL: gcc.target/i386/minmax-9.c scan-assembler-times test 3

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2588/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/minmax-9.c --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-2588 Regression] FAIL: gcc.target/i386/minmax-10.c scan-assembler-times test 6 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c072fd236dc08f990bfcffd98b27f211a39bb404 is the first bad commit
commit c072fd236dc08f990bfcffd98b27f211a39bb404
Author: Roger Sayle 
Date:   Thu Aug 6 09:15:25 2020 +0100

x86_64: Integer min/max improvements.

caused

FAIL: gcc.target/i386/minmax-10.c scan-assembler-not cmp
FAIL: gcc.target/i386/minmax-10.c scan-assembler-times test 6

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2588/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/minmax-10.c --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_float_6.c scan-assembler-times vfnmsub[123]+ss 32 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_float_6.c scan-assembler-times vfmadd[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_6.c scan-assembler-times vfmsub[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_6.c scan-assembler-times vfnmadd[123]+ss 32
FAIL: gcc.target/i386/l_fma_float_6.c scan-assembler-times vfnmsub[123]+ss 32

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_float_6.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_float_5.c scan-assembler-times vfnmsub[123]+ss 32 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_float_5.c scan-assembler-times vfmadd[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_5.c scan-assembler-times vfmsub[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_5.c scan-assembler-times vfnmadd[123]+ss 32
FAIL: gcc.target/i386/l_fma_float_5.c scan-assembler-times vfnmsub[123]+ss 32

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_float_5.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_float_4.c scan-assembler-times vfnmsub[123]+ss 32 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_float_4.c scan-assembler-times vfmadd[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_4.c scan-assembler-times vfmsub[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_4.c scan-assembler-times vfnmadd[123]+ss 32
FAIL: gcc.target/i386/l_fma_float_4.c scan-assembler-times vfnmsub[123]+ss 32

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_float_4.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_float_3.c scan-assembler-times vfnmsub[123]+ss 32 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_float_3.c scan-assembler-times vfmadd[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_3.c scan-assembler-times vfmsub[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_3.c scan-assembler-times vfnmadd[123]+ss 32
FAIL: gcc.target/i386/l_fma_float_3.c scan-assembler-times vfnmsub[123]+ss 32

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_float_3.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_float_2.c scan-assembler-times vfnmsub[123]+ss 32 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_float_2.c scan-assembler-times vfmadd[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_2.c scan-assembler-times vfmsub[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_2.c scan-assembler-times vfnmadd[123]+ss 32
FAIL: gcc.target/i386/l_fma_float_2.c scan-assembler-times vfnmsub[123]+ss 32

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_float_2.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_float_1.c scan-assembler-times vfnmsub[123]+ss 32 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_float_1.c scan-assembler-times vfmadd[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_1.c scan-assembler-times vfmsub[123]+ss 96
FAIL: gcc.target/i386/l_fma_float_1.c scan-assembler-times vfnmadd[123]+ss 32
FAIL: gcc.target/i386/l_fma_float_1.c scan-assembler-times vfnmsub[123]+ss 32

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_float_1.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_double_6.c scan-assembler-times vfnmsub[123]+sd 16 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_double_6.c scan-assembler-times vfmadd[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_6.c scan-assembler-times vfmsub[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_6.c scan-assembler-times vfnmadd[123]+sd 16
FAIL: gcc.target/i386/l_fma_double_6.c scan-assembler-times vfnmsub[123]+sd 16

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_double_6.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_double_5.c scan-assembler-times vfnmsub[123]+sd 16 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_double_5.c scan-assembler-times vfmadd[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_5.c scan-assembler-times vfmsub[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_5.c scan-assembler-times vfnmadd[123]+sd 16
FAIL: gcc.target/i386/l_fma_double_5.c scan-assembler-times vfnmsub[123]+sd 16

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_double_5.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_double_4.c scan-assembler-times vfnmsub[123]+sd 16 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_double_4.c scan-assembler-times vfmadd[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_4.c scan-assembler-times vfmsub[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_4.c scan-assembler-times vfnmadd[123]+sd 16
FAIL: gcc.target/i386/l_fma_double_4.c scan-assembler-times vfnmsub[123]+sd 16

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_double_4.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_double_3.c scan-assembler-times vfnmsub[123]+sd 16 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_double_3.c scan-assembler-times vfmadd[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_3.c scan-assembler-times vfmsub[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_3.c scan-assembler-times vfnmadd[123]+sd 16
FAIL: gcc.target/i386/l_fma_double_3.c scan-assembler-times vfnmsub[123]+sd 16

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_double_3.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_double_2.c scan-assembler-times vfnmsub[123]+sd 16 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_double_2.c scan-assembler-times vfmadd[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_2.c scan-assembler-times vfmsub[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_2.c scan-assembler-times vfnmadd[123]+sd 16
FAIL: gcc.target/i386/l_fma_double_2.c scan-assembler-times vfnmsub[123]+sd 16

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_double_2.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-350 Regression] FAIL: gcc.target/i386/l_fma_double_1.c scan-assembler-times vfnmsub[123]+sd 16 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

c0c39a765b0714aed36fced6fbba452a6619acb0 is the first bad commit
commit c0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

caused

FAIL: gcc.target/i386/l_fma_double_1.c scan-assembler-times vfmadd[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_1.c scan-assembler-times vfmsub[123]+sd 48
FAIL: gcc.target/i386/l_fma_double_1.c scan-assembler-times vfnmadd[123]+sd 16
FAIL: gcc.target/i386/l_fma_double_1.c scan-assembler-times vfnmsub[123]+sd 16

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-350/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/l_fma_double_1.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-1301 Regression] FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times vpmullw[^\n]*zmm 2 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

54cdb2f5a5b01a482d7cbce30e7b738558eecf59 is the first bad commit
commit 54cdb2f5a5b01a482d7cbce30e7b738558eecf59
Author: liuhongt 
Date:   Wed Jun 3 17:25:47 2020 +0800

Optimize multiplication for V8QI,V16QI,V32QI under TARGET_AVX512BW.

caused

FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times vpmovwb 2
FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times vpmovzxbw 4
FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times 
vpmullw[^\n]*zmm 2

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-1301/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512bw-pr95488-1.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-2928 Regression] FAIL: gcc.dg/Wstringop-overread.c (test for warnings, line 84) on Linux/x86_64 (-m32 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

d14c547abd484d3540b692bb8048c4a6efe92c8b is the first bad commit
commit d14c547abd484d3540b692bb8048c4a6efe92c8b
Author: Martin Sebor 
Date:   Fri Aug 28 13:13:28 2020 -0600

Add -Wstringop-overread for reading past the end by string functions.

caused

FAIL: gcc.dg/Wstringop-overread.c (test for excess errors)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 100)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 110)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 167)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 177)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 279)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 289)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 338)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 372)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 374)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 532)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 566)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 568)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 74)
FAIL: gcc.dg/Wstringop-overread.c  (test for warnings, line 84)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2928/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gcc.dg/Wstringop-overread.c --target_board='unix{-m32\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-1851 Regression] FAIL: gcc.dg/vect/slp-46.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 on Linux/x86_64 (-m64 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

dccbf1e2a6e544f71b4a5795f0c79015db019fc3 is the first bad commit
commit dccbf1e2a6e544f71b4a5795f0c79015db019fc3
Author: Richard Biener 
Date:   Mon Jul 6 16:26:50 2020 +0200

tree-optimization/96075 - fix bogus misalignment calculation

caused

FAIL: gcc.dg/vect/slp-46.c -flto -ffat-lto-objects  scan-tree-dump-times vect 
"vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-46.c scan-tree-dump-times vect "vectorizing stmts using 
SLP" 2

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-1851/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/slp-46.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-2904 Regression] FAIL: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1 on Linux/x86_64 (-m32 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07 is the first bad commit
commit 9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07
Author: Richard Biener 
Date:   Thu Aug 27 13:04:19 2020 +0200

streamline TARGET_MEM_REF dumping

caused

FAIL: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2904/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/scev-5.c --target_board='unix{-m32\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-2904 Regression] FAIL: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1 on Linux/x86_64 (-m32 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07 is the first bad commit
commit 9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07
Author: Richard Biener 
Date:   Thu Aug 27 13:04:19 2020 +0200

streamline TARGET_MEM_REF dumping

caused

FAIL: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2904/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/scev-4.c --target_board='unix{-m32\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-2904 Regression] FAIL: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1 on Linux/x86_64 (-m32 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07 is the first bad commit
commit 9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07
Author: Richard Biener 
Date:   Thu Aug 27 13:04:19 2020 +0200

streamline TARGET_MEM_REF dumping

caused

FAIL: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2904/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/scev-3.c --target_board='unix{-m32\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-2928 Regression] FAIL: c-c++-common/Warray-bounds-6.c -Wc++-compat (test for excess errors) on Linux/x86_64 (-m32 -march=cascadelake)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

d14c547abd484d3540b692bb8048c4a6efe92c8b is the first bad commit
commit d14c547abd484d3540b692bb8048c4a6efe92c8b
Author: Martin Sebor 
Date:   Fri Aug 28 13:13:28 2020 -0600

Add -Wstringop-overread for reading past the end by string functions.

caused

FAIL: c-c++-common/Warray-bounds-6.c  -Wc++-compat  (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2928/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=c-c++-common/Warray-bounds-6.c --target_board='unix{-m32\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-349 Regression] FAIL: gfortran.dg/gomp/target1.f90 -O (test for excess errors) on Linux/x86_64 (-m64)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

f884bef2105d748fd7869cd641cbb4f6b6bb is the first bad commit
commit f884bef2105d748fd7869cd641cbb4f6b6bb
Author: Tobias Burnus 
Date:   Wed May 13 10:06:45 2020 +0200

[Fortran] OpenMP - permit lastprivate in distribute + SIMD fixes (PR94690)

caused

FAIL: gfortran.dg/gomp/target1.f90   -O  (internal compiler error)
FAIL: gfortran.dg/gomp/target1.f90   -O  (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-349/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/target1.f90 --target_board='unix{-m64}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-2904 Regression] FAIL: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1 on Linux/x86_64 (-m32)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07 is the first bad commit
commit 9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07
Author: Richard Biener 
Date:   Thu Aug 27 13:04:19 2020 +0200

streamline TARGET_MEM_REF dumping

caused

FAIL: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2904/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/scev-5.c --target_board='unix{-m32}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-2904 Regression] FAIL: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1 on Linux/x86_64 (-m32)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07 is the first bad commit
commit 9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07
Author: Richard Biener 
Date:   Thu Aug 27 13:04:19 2020 +0200

streamline TARGET_MEM_REF dumping

caused

FAIL: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2904/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/scev-4.c --target_board='unix{-m32}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r11-2904 Regression] FAIL: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1 on Linux/x86_64 (-m32)

2020-08-29 Thread sunil.k.pandey via Gcc-patches

On Linux/x86_64,

9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07 is the first bad commit
commit 9ceb3b8d8f6dd088f3efd590aae9e54a265e5b07
Author: Richard Biener 
Date:   Thu Aug 27 13:04:19 2020 +0200

streamline TARGET_MEM_REF dumping

caused

FAIL: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-2904/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/scev-3.c --target_board='unix{-m32}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

51 matches

Mail list logo