Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

[Janus Weil]

2018-07-16 21:50 GMT+02:00 Thomas Koenig :
> Am 16.07.2018 um 10:06 schrieb Janus Weil:
>>>
>>> However, one point: I think that the warning should be under a separate
>>> warning, which should then be enabled by -Wextra.
>>> -Waggressive-function-elimination, could be reused for this,
>>> or something else
>>
>> I don't actually see such a flag in the manual.
>
> Ah, sorry, I misremembered the option, it is actually
> -Wfunction-elimination.
>
> What I would suggest is to enable -Wfunction-eliminiation with
> -Wextra and also use that for your new warning.

Thanks for the comments. Makes sense. Updated patch attached.

I'll wait two more days to allow for further comments and will commit
this to trunk on Thursday if I hear no further complaints.

Cheers,
Janus
Index: gcc/fortran/dump-parse-tree.c
===
--- gcc/fortran/dump-parse-tree.c	(revision 262563)
+++ gcc/fortran/dump-parse-tree.c	(working copy)
@@ -716,6 +716,8 @@ show_attr (symbol_attribute *attr, const char * mo
 fputs (" ELEMENTAL", dumpfile);
   if (attr->pure)
 fputs (" PURE", dumpfile);
+  if (attr->implicit_pure)
+fputs (" IMPLICIT_PURE", dumpfile);
   if (attr->recursive)
 fputs (" RECURSIVE", dumpfile);
 
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi	(revision 262563)
+++ gcc/fortran/gfortran.texi	(working copy)
@@ -1177,6 +1177,7 @@ might in some way or another become visible to the
 @menu
 * KIND Type Parameters::
 * Internal representation of LOGICAL variables::
+* Evaluation of logical expressions::
 * Thread-safety of the runtime library::
 * Data consistency and durability::
 * Files opened without an explicit ACTION= specifier::
@@ -1251,6 +1252,19 @@ values: @code{1} for @code{.TRUE.} and @code{0} fo
 See also @ref{Argument passing conventions} and @ref{Interoperability with C}.
 
 
+@node Evaluation of logical expressions
+@section Evaluation of logical expressions
+
+The Fortran standard does not require the compiler to evaluate all parts of an
+expression, if they do not contribute to the final result. For logical
+expressions with @code{.AND.} or @code{.OR.} operators, in particular, GNU
+Fortran will optimize out function calls (even to impure functions) if the
+result of the expression can be established without them. However, since not
+all compilers do that, and such an optimization can potentially modify the
+program flow and subsequent results, GNU Fortran throws warnings for such
+situations with the @option{-Wfunction-elimination} flag.
+
+
 @node Thread-safety of the runtime library
 @section Thread-safety of the runtime library
 @cindex thread-safety, threads
Index: gcc/fortran/invoke.texi
===
--- gcc/fortran/invoke.texi	(revision 262563)
+++ gcc/fortran/invoke.texi	(working copy)
@@ -1058,6 +1058,7 @@ off via @option{-Wno-align-commons}. See also @opt
 @cindex warnings, function elimination
 Warn if any calls to functions are eliminated by the optimizations
 enabled by the @option{-ffrontend-optimize} option.
+This option is implied by @option{-Wextra}.
 
 @item -Wrealloc-lhs
 @opindex @code{Wrealloc-lhs}
Index: gcc/fortran/lang.opt
===
--- gcc/fortran/lang.opt	(revision 262563)
+++ gcc/fortran/lang.opt	(working copy)
@@ -250,7 +250,7 @@ Fortran Var(flag_warn_frontend_loop_interchange)
 Warn if loops have been interchanged.
 
 Wfunction-elimination
-Fortran Warning Var(warn_function_elimination)
+Fortran Warning Var(warn_function_elimination) LangEnabledBy(Fortran,Wextra)
 Warn about function call elimination.
 
 Wimplicit-interface
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 262563)
+++ gcc/fortran/resolve.c	(working copy)
@@ -2982,6 +2982,21 @@ pure_function (gfc_expr *e, const char **name)
 }
 
 
+/* Check if the expression is a reference to an implicitly pure function.  */
+
+static int
+implicit_pure_function (gfc_expr *e)
+{
+  gfc_component *comp = gfc_get_proc_ptr_comp (e);
+  if (comp)
+return gfc_implicit_pure (comp->ts.interface);
+  else if (e->value.function.esym)
+return gfc_implicit_pure (e->value.function.esym);
+  else
+return 0;
+}
+
+
 static bool
 impure_stmt_fcn (gfc_expr *e, gfc_symbol *sym,
 		 int *f ATTRIBUTE_UNUSED)
@@ -3034,7 +3049,8 @@ static bool check_pure_function (gfc_expr *e)
 		 "within a PURE procedure", name, >where);
 	  return false;
 	}
-  gfc_unset_implicit_pure (NULL);
+  if (!implicit_pure_function (e))
+	gfc_unset_implicit_pure (NULL);
 }
   return true;
 }
@@ -3822,6 +3838,40 @@ lookup_uop_fuzzy (const char *op, gfc_symtree *uop
 }
 
 
+/* Callback finding an impure function as an operand to an .and. or
+   .or.  expression.  Remember the last function warned about to
+   

Re: [PATCH] [v3][aarch64] Avoid tag collisions for loads falkor

[Siddhesh Poyarekar]

On 07/16/2018 09:59 PM, Kyrill Tkachov wrote:
I think this looks ok now. You'll still need a maintainer to approve it 
though.


Thank you for the review Kyrill, but also apologies for wasting your 
time on it.  I just found that the patch breaks a test so I'm currently 
reviewing it to see what's going on and post an update.  I thought I 
should mention it early here to avoid wasting James' time as well on 
this iteration.


Siddhesh

PING #3 [PATCH] specify large command line option arguments (PR 82063)

[Martin Sebor]

Ping #3: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html

On 07/09/2018 09:13 PM, Martin Sebor wrote:

Ping #2: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html

On 07/03/2018 08:12 PM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html

On 06/24/2018 03:05 PM, Martin Sebor wrote:

Storing integer command line option arguments in type int
limits options such as -Wlarger-than= or -Walloca-larger-than
to at most INT_MAX (see bug 71905).  Larger values wrap around
zero.  The value zero is considered to disable the option,
making it impossible to specify a zero limit.

To get around these limitations, the -Walloc-size-larger-than=
option accepts a string argument that it then parses itself
and interprets as HOST_WIDE_INT.  The option also accepts byte
size suffixes like KB, MB, GiB, etc. to make it convenient to
specify very large limits.

The int limitation is obviously less than ideal in a 64-bit
world.  The treatment of zero as a toggle is just a minor wart.
The special treatment to make it work for just a single option
makes option handling inconsistent.  It should be possible for
any option that takes an integer argument to use the same logic.

The attached patch enhances GCC option processing to do that.
It changes the storage type of option arguments from int to
HOST_WIDE_INT and extends the existing (although undocumented)
option property Host_Wide_Int to specify wide option arguments.
It also introduces the ByteSize property for options for which
specifying the byte-size suffix makes sense.

To make it possible to consider zero as a meaningful argument
value rather than a flag indicating that an option is disabled
the patch also adds a CLVC_SIZE enumerator to the cl_var_type
enumeration, and modifies how options of the kind are handled.

Warning options that take large byte-size arguments can be
disabled by specifying a value equal to or greater than
HOST_WIDE_INT_M1U.  For convenience, aliases in the form of
-Wno-xxx-larger-than have been provided for all the affected
options.

In the patch all the existing -larger-than options are set
to PTRDIFF_MAX.  This makes them effectively enabled, but
because the setting is exceedingly permissive, and because
some of the existing warnings are already set to the same
value and some other checks detect and reject such exceedingly
large values with errors, this change shouldn't noticeably
affect what constructs are diagnosed.

Although all the options are set to PTRDIFF_MAX, I think it
would make sense to consider setting some of them lower, say
to PTRDIFF_MAX / 2.  I'd like to propose that in a followup
patch.

To minimize observable changes the -Walloca-larger-than and
-Wvla-larger-than warnings required more extensive work to
make of the new mechanism because of the "unbounded" argument
handling (the warnings trigger for arguments that are not
visibly constrained), and because of the zero handling
(the warnings also trigger


Martin

[Bug tree-optimization/83693] missing strlen optimization for array of arrays

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77357
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #4 from Martin Sebor  ---
Updated patch committed in r262522 (under bug 77357).

[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 83693, which changed state.

Bug 83693 Summary: missing strlen optimization for array of arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83693

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

Re: Understanding tree_swap_operands_p wrt SSA name versions

[Michael Ploujnikov]

On 2018-07-16 04:30 AM, Richard Biener wrote:
> On Mon, Jul 16, 2018 at 12:19 AM Michael Ploujnikov
>  wrote:
>>
>> On 2018-07-04 04:52 AM, Richard Biener wrote:
>>> On Tue, Jul 3, 2018 at 9:09 PM Jeff Law  wrote:

 On 07/03/2018 11:55 AM, Michael Ploujnikov wrote:
> On 2018-07-03 12:46 PM, Richard Biener wrote:
>> On July 3, 2018 4:56:57 PM GMT+02:00, Michael Ploujnikov 
>>  wrote:
>>> On 2018-06-20 04:23 AM, Richard Biener wrote:
 On Wed, Jun 20, 2018 at 7:31 AM Jeff Law  wrote:
>
> On 06/19/2018 12:30 PM, Michael Ploujnikov wrote:
>> Hi everyone,
>>
>> (I hope this is the right place to ask, if not my apologies; please
>> point me in the right direction)
>>
>> I'm trying to get a better understanding of the following part in
>> tree_swap_operands_p():
>>
>>   /* It is preferable to swap two SSA_NAME to ensure a canonical
>>> form
>>  for commutative and comparison operators.  Ensuring a
>>> canonical
>>  form allows the optimizers to find additional redundancies
>>> without
>>  having to explicitly check for both orderings.  */
>>   if (TREE_CODE (arg0) == SSA_NAME
>>   && TREE_CODE (arg1) == SSA_NAME
>>   && SSA_NAME_VERSION (arg0) > SSA_NAME_VERSION (arg1))
>> return 1;
>>
>> My questions in no particular order: It looks like this was added
>>> in
>> 2004. I couldn't find any info other than what's in the
>>> corresponding
>> commit (cc0bdf913) so I'm wondering if the canonical form/order
>>> still
>> relevant/needed today? Does the ordering have to be done based on
>>> the
>> name versions specifically? Or can it be based on something more
>> intrinsic to the input source code rather than a GCC internal
>>> value, eg:
>> would alphabetic sort order of the variable names be a reasonable
>> replacement?
> Canonicalization is still important and useful.

 Indeed.

> However, canonicalizing on SSA_NAMEs is problematical due to the way
>>> we
> recycle nodes and re-pack them.

 In the past we made sure to not disrupt order - hopefully that didn't
>>> change
 so the re-packing shoudln't invaidate previous canonicalization:

 static void
 release_free_names_and_compact_live_names (function *fun)
 {
 ...
   /* And compact the SSA number space.  We make sure to not change
>>> the
  relative order of SSA versions.  */
   for (i = 1, j = 1; i < fun->gimple_df->ssa_names->length (); ++i)
 {


> I think defining additional rules for canonicalization prior to
>>> using
> SSA_NAME_VERSION as the fallback would be looked upon favorably.

 I don't see a good reason to do that, it will be harder to spot
>>> canonicalization
 issues and it will take extra compile-time.

> Note however, that many of the _DECL nodes referenced by SSA_NAMEs
>>> are
> temporaries generated by the compiler and do not correspond to any
> declared/defined object in the original source.  So you'll still
>>> need
> the SSA_NAME_VERSION (or something as stable or better)
>>> canonicalization
> to handle those cases.

 And not all SSA_NAMEs have underlying _DECL nodes (or IDENTIFIER_NODE
>>> names).

 Richard.

> Jeff
>>>
>>> After a bit more digging I found that insert_phi_nodes inserts PHIs in
>>> the order of UIDs, which indirectly affects the order of vars in
>>> old_ssa_names, which in turn affects the order in which
>>> make_ssa_name_fn
>>> is called to pick SSA versions from FREE_SSANAMES so in the end
>>> ordering by SSA_NAME_VERSION's is more or less equivalent to ordering
>>> by
>>> UIDs. I'm trying to figure out if there's a way to avoid depending on
>>> UIDs being ordered in a certain way. So if tree_swap_operands_p stays
>>> the same I'm wondering if there's some other info available at the
>>> point
>>> of insert_phi_nodes that would be a good replacement for UID. From my
>>> very limited experience with a very small source input, and if I
>>> understand things correctly, all of the var_infos have a var which is
>>> DECL_P and thus should have an IDENTIFIER_NODE. Is that true in the
>>> general case? I don't fully understand what are all the things that
>>> insert_phi_nodes iterates over.
>>
>> Why do you want to remove the dependence on UID ordering? It's pervasive 
>> throughout the whole compilation...
>>
>> Richard.
>>
>>> - Michael
>>
>
>
> Well, I'm working on a reduction of the 

[Bug target/83868] i386: Clean up thunk function generation

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Eric Gallager from comment #1)
> (In reply to H.J. Lu from comment #0)
> > output_indirect_thunk_function and ix86_code_end should be generated
> > the way in which normal thunks are output from middle-end.
> 
> Which way is that?

See:

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01357.html

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

[qinzhao at gcc dot gnu.org]

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-17
 Ever confirmed|0   |1

--- Comment #6 from qinzhao at gcc dot gnu.org ---
Yes, I can repeat the failure on gcc112. will continue debugging it

[Bug target/83868] i386: Clean up thunk function generation

[egallager at gcc dot gnu.org]

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

--- Comment #1 from Eric Gallager  ---
(In reply to H.J. Lu from comment #0)
> output_indirect_thunk_function and ix86_code_end should be generated
> the way in which normal thunks are output from middle-end.

Which way is that?

[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #3)
> I wouldn't be surprised if the build fails with -Wnarrowing (but maybe that
> should be fixed anyway, so we can build with non-GNU compilers that default
> to C++11 or later).

Well yes, that was my ulterior motive for suggesting it... 
;-)

Re: [GCC][PATCH][Aarch64] Exploiting BFXIL when OR-ing two AND-operations with appropriate bitmasks

[Richard Henderson]

On 07/16/2018 10:10 AM, Sam Tebbs wrote:
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -1439,6 +1439,14 @@ aarch64_hard_regno_caller_save_mode (unsigned regno, 
> unsigned,
>  return SImode;
>  }
>  
> +/* Implement IS_LEFT_CONSECUTIVE.  Check if an integer's bits are consecutive
> +   ones from the MSB.  */
> +bool
> +aarch64_is_left_consecutive (HOST_WIDE_INT i)
> +{
> +  return (i | (i - 1)) == HOST_WIDE_INT_M1;
> +}
> +
...
> +(define_insn "*aarch64_bfxil"
> +  [(set (match_operand:DI 0 "register_operand" "=r")
> +(ior:DI (and:DI (match_operand:DI 1 "register_operand" "r")
> + (match_operand 3 "const_int_operand"))
> + (and:DI (match_operand:DI 2 "register_operand" "0")
> + (match_operand 4 "const_int_operand"]
> +  "INTVAL (operands[3]) == ~INTVAL (operands[4])
> +&& aarch64_is_left_consecutive (INTVAL (operands[4]))"

Better is to use a define_predicate to merge both that second test and the
const_int_operand.

(I'm not sure about the "left_consecutive" language either.
Isn't it more descriptive to say that op3 is a power of 2 minus 1?)

(define_predicate "pow2m1_operand"
  (and (match_code "const_int")
   (match_test "exact_pow2 (INTVAL(op) + 1) > 0")))

and use

  (match_operand:DI 3 "pow2m1_operand")

and then just the

  INTVAL (operands[3]) == ~INTVAL (operands[4])

test.

Also, don't omit the modes for the constants.
Also, there's no reason this applies only to DI mode;
use the GPI iterator and % in the output template.

> +HOST_WIDE_INT op3 = INTVAL (operands[3]);
> +operands[3] = GEN_INT (ceil_log2 (op3));
> +output_asm_insn ("bfxil\\t%0, %1, 0, %3", operands);
> +return "";

You can just return the string that you passed to output_asm_insn.

> +  }
> +  [(set_attr "type" "bfx")]

The other aliases of the BFM insn use type "bfm";
"bfx" appears to be aliases of UBFM and SBFM.
Not that it appears to matter to the scheduling
descriptions, but it is inconsistent.


r~

[PATCH] haiku: Initial build support

[Alexander von Gluck IV]

* We have been dragging these around since gcc 4.x.
* Some tweaks will likely be needed, but this gets our foot
  in the door.

Authors:
  Fredrik Holmqvist
  Jerome Duval
  Augustin Cavalier
  François Revol
  Simon South
  Jessica Hamilton
  Ithamar R. Adema
  Oliver Tappe
  Jonathan Schleifer
  .. and maybe more!
---
 config.rpath  |   2 +
 config/acx.m4 |  36 ++-
 configure |  53 ++--
 configure.ac  |  60 ++--
 gcc/config.gcc|  49 +++-
 gcc/config.host   |  10 +-
 gcc/config/arm/haiku.h|  80 ++
 gcc/config/arm/t-haiku|  21 ++
 gcc/config/haiku-spec.h   |  38 +++
 gcc/config/haiku-stdint.h |  55 
 gcc/config/haiku.h| 217 ++
 gcc/config/i386/haiku.h   |  77 +
 gcc/config/i386/haiku64.h | 135 +
 gcc/config/i386/t-haiku64 |  16 ++
 gcc/config/m68k/haiku.h   | 268 ++
 gcc/config/mips/haiku.h   |  44 +++
 gcc/config/rs6000/haiku.h |  56 
 gcc/config/t-haiku|   4 +
 gcc/configure |  22 +-
 libgcc/config.host|  22 ++
 libgcc/config/t-haiku |   3 +
 libstdc++-v3/config/os/haiku/ctype_base.h |  61 
 .../config/os/haiku/ctype_configure_char.cc   |  99 +++
 libstdc++-v3/config/os/haiku/ctype_inline.h   | 168 +++
 .../config/os/haiku/error_constants.h | 178 
 libstdc++-v3/config/os/haiku/os_defines.h |  48 
 libstdc++-v3/configure|  85 +-
 libstdc++-v3/configure.host   |   2 +-
 libstdc++-v3/crossconfig.m4   |  40 +++
 libtool.m4|   8 +-
 30 files changed, 1883 insertions(+), 74 deletions(-)
 create mode 100644 gcc/config/arm/haiku.h
 create mode 100644 gcc/config/arm/t-haiku
 create mode 100644 gcc/config/haiku-spec.h
 create mode 100644 gcc/config/haiku-stdint.h
 create mode 100644 gcc/config/haiku.h
 create mode 100644 gcc/config/i386/haiku.h
 create mode 100644 gcc/config/i386/haiku64.h
 create mode 100644 gcc/config/i386/t-haiku64
 create mode 100644 gcc/config/m68k/haiku.h
 create mode 100644 gcc/config/mips/haiku.h
 create mode 100644 gcc/config/rs6000/haiku.h
 create mode 100644 gcc/config/t-haiku
 create mode 100644 libgcc/config/t-haiku
 create mode 100644 libstdc++-v3/config/os/haiku/ctype_base.h
 create mode 100644 libstdc++-v3/config/os/haiku/ctype_configure_char.cc
 create mode 100644 libstdc++-v3/config/os/haiku/ctype_inline.h
 create mode 100644 libstdc++-v3/config/os/haiku/error_constants.h
 create mode 100644 libstdc++-v3/config/os/haiku/os_defines.h

diff --git a/config.rpath b/config.rpath
index 4dea75957c2..5bcc5be17e4 100755
--- a/config.rpath
+++ b/config.rpath
@@ -161,6 +161,8 @@ if test "$with_gnu_ld" = yes; then
   ;;
 netbsd*)
   ;;
+haiku*)
+  ;;
 solaris* | sysv5*)
   if $LD -v 2>&1 | egrep 'BFD 2\.8' > /dev/null; then
 ld_shlibs=no
diff --git a/config/acx.m4 b/config/acx.m4
index 87c1b5e2932..7a511a9a1c0 100644
--- a/config/acx.m4
+++ b/config/acx.m4
@@ -428,24 +428,30 @@ dnl for the parameter format "cmp file1 file2 skip1 
skip2" which is
 dnl accepted by cmp on some systems.
 AC_DEFUN([ACX_PROG_CMP_IGNORE_INITIAL],
 [AC_CACHE_CHECK([how to compare bootstrapped objects], gcc_cv_prog_cmp_skip,
-[ echo abfoo >t1
-  echo cdfoo >t2
-  gcc_cv_prog_cmp_skip='tail -c +17 $$f1 > tmp-foo1; tail -c +17 $$f2 > 
tmp-foo2; cmp tmp-foo1 tmp-foo2'
-  if cmp t1 t2 2 2 > /dev/null 2>&1; then
-if cmp t1 t2 1 1 > /dev/null 2>&1; then
-  :
-else
-  gcc_cv_prog_cmp_skip='cmp $$f1 $$f2 16 16'
+[# comparing object files via cmp doesn't work on haiku (files will seemingly
+  # always differ), so we disassemble both files and compare the results:
+  if uname -o | grep -iq haiku; then
+gcc_cv_prog_cmp_skip='objdump -Dz $$f1 | tail +6 >tmp-foo1; objdump -Dz 
$$f2 | tail +6 >tmp-foo2; cmp tmp-foo1 tmp-foo2'
+  else
+echo abfoo >t1
+echo cdfoo >t2
+gcc_cv_prog_cmp_skip='tail -c +17 $$f1 > tmp-foo1; tail -c +17 $$f2 > 
tmp-foo2; cmp tmp-foo1 tmp-foo2'
+if cmp t1 t2 2 2 > /dev/null 2>&1; then
+  if cmp t1 t2 1 1 > /dev/null 2>&1; then
+:
+  else
+gcc_cv_prog_cmp_skip='cmp $$f1 $$f2 16 16'
+  fi
 fi
-  fi
-  if cmp --ignore-initial=2 t1 t2 > /dev/null 2>&1; then
-if cmp --ignore-initial=1 t1 t2 > /dev/null 2>&1; then
-  :
-else
-  gcc_cv_prog_cmp_skip='cmp --ignore-initial=16 $$f1 $$f2'
+if cmp --ignore-initial=2 t1 t2 > /dev/null 2>&1; then
+  if cmp 

Re: [RFC][debug] Add -fadd-debug-nops

[Alexandre Oliva]

On Jul 16, 2018, Tom de Vries  wrote:

> On 07/16/2018 03:34 PM, Jakub Jelinek wrote:
>> So is this essentially a workaround for GDB not supporting the statement
>> frontiers?

> AFAIU now, the concept of location views addresses this problem, so yes.

Nice!  A preview for what can be obtained with LVu support in the
debugger!

> Right, but in the mean time I don't mind having an option that lets me
> filter out noise in guality test results.

FWIW, I'm a bit concerned about working around legitimate problems, as
in modifying testcases so that they pass.  This hides actual problems,
that we'd like to fix eventually by adjusting the compiler, not the
testcases.

That said, thank you for the attention you've given to the guality
testsuite recently.  It's appreciated.

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist

[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
(In reply to Matt Bentley from comment #13)
> Well it's more that you're doing- at any rate, the issue you've noted is
> easily bypassed by changing the "reinterpret_cast(__first)" to
> "reinterpret_cast(&*(__first))".

Also, independent of the non-contiguous problem, using reinterpret_cast here is
unnecessary (any non-const pointer can be implicitly converted to void*) and
would prevent adding constexpr to the algorithm (as required for C++2a).

[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
(In reply to Matt Bentley from comment #16)
> Yup - arguably it would be nice to have an overload for vector iterators
> that does the same thing.

We already handle that, see the __niter_base functions which unwrap std::vector
and std::basic_string iterators into pointers.

Re: [PATCH] Add baseline symbols for riscv64-linux-gnu

[Jonathan Wakely]

On 16/07/18 16:37 -0700, Jim Wilson wrote:

On Mon, Jul 16, 2018 at 3:24 AM, Andreas Schwab  wrote:

* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: New file.



I'm not familiar with the details of these baseline symbol files.

When I try running "make new-abi-baseline" on my Fedora riscv64-linux
system using top of tree, I get 35 extra lines in the
baseline_symbols.txt.new file.  It looks like 33 of them are because I
have
OBJECT:0:GLIBCXX_3.4.26
and yours only goes up to 3.4.25.  The other two are TLS entries.

TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11

Not sure why there are no TLS entries in your file, and two in mine.


I don't know about RISC-V but for other GNU/Linux targets those
symbols are not always present, so should not be listed in the
baseline (otherwise when they're absent you get errors about missing
symbols).


The testsuite does pass with a message about 33 added symbols and 2
undesignated symbols which are the TLS symbols.


The added symbols all have the new GLIBCXX_3.4.26 symbol version, so
are allowed as additions on top of the GLIBCXX_3.4.25 baseline defined
by the baseline_symbols.txt file.

The 3.4.26 version is still "open" and having new symbols added to it,
so it makes sense for the baseline to only go up to 3.4.25 for now.

[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

[mattreecebentley at gmail dot com]

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

--- Comment #16 from Matt Bentley  ---
(In reply to Jonathan Wakely from comment #15)

> Look at how this exact problem is already solved elsewhere in the same file.
> All the algorithms that dispatch to a __builtin_memxxx function use similar
> techniques, detecting when the iterators are pointers for a start.

Yup - arguably it would be nice to have an overload for vector iterators that
does the same thing.


> And see https://gcc.gnu.org/contribute.html#legal for why code pasted into
> bugzilla without the necessary paperwork is unhelpful (and possibly even
> counter-productive if we end up having to re-invent the same wheel without
> using your code).

I've read it, it says copyright assignments are unneeded for small
contributions. Also, this wasn't patch code, just spitballing code.


> Indeed. It's a forward iterator. Even a random access iterator doesn't
> guarantee you can do that (e.g. std::deque::iterator is random access but
> not contiguous).

Yep, got it.

[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to Matt Bentley from comment #14)
> (In reply to Matt Bentley from comment #13)
> > (In reply to Jonathan Wakely from comment #12)
> > > Also you're doing a reinterpret_cast from an arbitrary iterator type, 
> > > which
> > > is not necessarily a pointer, or even a random access iterator.
> > > 
> > > Since you don't have a copyright assignment in place please leave the 
> > > patch
> > > to us, this is less than helpful :-)
> > 
> > Well it's more that you're doing-

I'm thinking about how to actually fix it, with a patch that works and could be
accepted into libstdc++.

Look at how this exact problem is already solved elsewhere in the same file.
All the algorithms that dispatch to a __builtin_memxxx function use similar
techniques, detecting when the iterators are pointers for a start.

And see https://gcc.gnu.org/contribute.html#legal for why code pasted into
bugzilla without the necessary paperwork is unhelpful (and possibly even
counter-productive if we end up having to re-invent the same wheel without
using your code).

> at any rate, the issue you've noted is
> > easily bypassed by changing the "reinterpret_cast(__first)" to
> > "reinterpret_cast(&*(__first))".
> > Cheers.
> 
> My bad, I missed the point about the memory not necessarily being contiguous.

Indeed. It's a forward iterator. Even a random access iterator doesn't
guarantee you can do that (e.g. std::deque::iterator is random access but not
contiguous).

Re: [PATCH] Add baseline symbols for riscv64-linux-gnu

[Jim Wilson]

On Mon, Jul 16, 2018 at 3:24 AM, Andreas Schwab  wrote:
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: New file.
>

I'm not familiar with the details of these baseline symbol files.

When I try running "make new-abi-baseline" on my Fedora riscv64-linux
system using top of tree, I get 35 extra lines in the
baseline_symbols.txt.new file.  It looks like 33 of them are because I
have
OBJECT:0:GLIBCXX_3.4.26
and yours only goes up to 3.4.25.  The other two are TLS entries.
> TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
> TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
Not sure why there are no TLS entries in your file, and two in mine.
The testsuite does pass with a message about 33 added symbols and 2
undesignated symbols which are the TLS symbols.

Anyways, it passed, so your patch is OK.

Jim

[Bug fortran/83184] Out of memory or ICE with option -fdec

[foreese at gcc dot gnu.org]

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

--- Comment #7 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 23:35:39 2018
New Revision: 262759

URL: https://gcc.gnu.org/viewcvs?rev=262759=gcc=rev
Log:
2018-07-16  Fritz Reese  

gcc/testsuite/ChangeLog:

PR fortran/83184
Backport from trunk.
* gfortran.dg/assumed_rank_14.f90: New testcase.
* gfortran.dg/assumed_rank_15.f90: New testcase.
* gfortran.dg/dec_structure_8.f90: Update error messages.
* gfortran.dg/dec_structure_23.f90: Update error messages.

gcc/fortran/ChangeLog:

PR fortran/83184
Backport from trunk.
* decl.c (match_old_style_init): Initialize locus of variable expr when
creating a data variable.
(match_clist_expr): Verify array is explicit shape/size before
attempting to allocate constant array constructor.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/assumed_rank_14.f90
  - copied unchanged from r262747,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/assumed_rank_14.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/assumed_rank_15.f90
  - copied unchanged from r262747,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/assumed_rank_15.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dec_structure_23.f90
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dec_structure_8.f90

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

[Bug target/86414] AIX generates wrong for divide and multiply for KC mode

[carll at gcc dot gnu.org]

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

--- Comment #1 from Carl Love  ---
Author: carll
Date: Mon Jul 16 23:35:25 2018
New Revision: 262758

URL: https://gcc.gnu.org/viewcvs?rev=262758=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2018-07-16  Carl Love  

Forgot the PR number on the commit log.
PR target/86414

   2018-07-16  Carl Love  

PR target/86414
* gcc.target/powerpc/divkc3-2.c: Add dg-require-effective-target
longdouble128.
* gcc.target/powerpc/divkc3-3.c: Ditto.
* gcc.target/powerpc/mulkc3-2.c: Ditto.
* gcc.target/powerpc/mulkc3-3.c: Ditto.
* gcc.target/powerpc/fold-vec-mergehl-double.c: Update counts.
* gcc.target/powerpc/pr85456.c: Make check Linux and AIX specific.

Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

[mattreecebentley at gmail dot com]

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

--- Comment #14 from Matt Bentley  ---
(In reply to Matt Bentley from comment #13)
> (In reply to Jonathan Wakely from comment #12)
> > Also you're doing a reinterpret_cast from an arbitrary iterator type, which
> > is not necessarily a pointer, or even a random access iterator.
> > 
> > Since you don't have a copyright assignment in place please leave the patch
> > to us, this is less than helpful :-)
> 
> Well it's more that you're doing- at any rate, the issue you've noted is
> easily bypassed by changing the "reinterpret_cast(__first)" to
> "reinterpret_cast(&*(__first))".
> Cheers.

My bad, I missed the point about the memory not necessarily being contiguous.

[Bug tree-optimization/86520] AArch64: Two 8-bit accesses coalesced into a single 16-bit access

[swarren at nvidia dot com]

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

--- Comment #6 from Stephen Warren  ---
> Note that library code also assumes that misaligned accesses are safe:
> that is the default for AArch64.

I assume you're talking about gcc's default, not any architectural default? The
ARMv8 ARM states that SCTLR_ELx.A doesn't have an architecturally defined reset
value (i.e. default).

(Sorry if this shows up twice; I typed it this morning and thought I submitted
it, but it hasn't shown up).

Thanks.

[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

[mattreecebentley at gmail dot com]

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

--- Comment #13 from Matt Bentley  ---
(In reply to Jonathan Wakely from comment #12)
> Also you're doing a reinterpret_cast from an arbitrary iterator type, which
> is not necessarily a pointer, or even a random access iterator.
> 
> Since you don't have a copyright assignment in place please leave the patch
> to us, this is less than helpful :-)

Well it's more that you're doing- at any rate, the issue you've noted is easily
bypassed by changing the "reinterpret_cast(__first)" to
"reinterpret_cast(&*(__first))".
Cheers.

[PATCH 6/6] rs6000: New testcase fp-convert.c

[Segher Boessenkool]

This tests the generated code for all conversions between floating point
point types, binary and decimal.


2018-07-16  Segher Boessenkool  

gcc/testsuite/
* gcc.target/powerpc/convert-fp-128.c: New testcase.
* gcc.target/powerpc/convert-fp-64.c: New testcase.

---
 gcc/testsuite/gcc.target/powerpc/convert-fp-128.c | 99 +++
 gcc/testsuite/gcc.target/powerpc/convert-fp-64.c  | 61 ++
 2 files changed, 160 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/convert-fp-128.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/convert-fp-64.c

diff --git a/gcc/testsuite/gcc.target/powerpc/convert-fp-128.c 
b/gcc/testsuite/gcc.target/powerpc/convert-fp-128.c
new file mode 100644
index 000..67896d9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/convert-fp-128.c
@@ -0,0 +1,99 @@
+/* { dg-options "-O2" } */
+/* { dg-require-effective-target longdouble128 } */
+/* { dg-require-effective-target dfp } */
+
+#define conv(M,N) mode_##N conv##M##N(mode_##M x) { return x; }
+
+#define mode_sf float
+#define mode_df double
+typedef float __attribute__((mode(IF))) mode_if;
+typedef float __attribute__((mode(KF))) mode_kf;
+#define mode_sd _Decimal32
+#define mode_dd _Decimal64
+#define mode_td _Decimal128
+
+#ifdef __FLOAT128_TYPE__
+#define conv1(M) \
+   conv(M,sf) conv(M,df) conv(M,if) conv(M,kf) \
+   conv(M,sd) conv(M,dd) conv(M,td)
+#define conv2 \
+   conv1(sf) conv1(df) conv1(if) conv1(kf) \
+   conv1(sd) conv1(dd) conv1(td)
+#else
+#define conv1(M) \
+   conv(M,sf) conv(M,df) conv(M,if) \
+   conv(M,sd) conv(M,dd) conv(M,td)
+#define conv2 \
+   conv1(sf) conv1(df) conv1(if) \
+   conv1(sd) conv1(dd) conv1(td)
+#endif
+
+conv2
+
+
+
+/* { dg-final { scan-assembler-times {\mbl\M} 24 { target { ! hard_dfp } } } } 
*/
+/* { dg-final { scan-assembler-times {\mbl\M} 19 { target { hard_dfp && { ! 
ppc_float128 } } } } } */
+/* { dg-final { scan-assembler-times {\mbl\M} 31 { target { hard_dfp && { 
ppc_float128 && { ! ppc_float128_insns } } } } } } */
+/* { dg-final { scan-assembler-times {\mbl\M} 27 { target { hard_dfp && { 
ppc_float128 && { ppc_float128_insns } } } } } } */
+
+
+/* { dg-final { scan-assembler-times {\mbl __extendsfkf2\M} 1 { target { 
ppc_float128 && { ! ppc_float128_insns } } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendsfsd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendsfdd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendsftd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __extenddfkf2\M} 1 { target { 
ppc_float128 && { ! ppc_float128_insns } } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_truncdfsd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extenddfdd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extenddftd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __trunctfkf2\M} 1 { target { 
ppc_float128 } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_trunctfsd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_trunctfdd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendtftd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __trunckfsf2\M} 1 { target { 
ppc_float128 && { ! ppc_float128_insns } } } } } */
+/* { dg-final { scan-assembler-times {\mbl __trunckfdf2\M} 1 { target { 
ppc_float128 && { ! ppc_float128_insns } } } } } */
+/* { dg-final { scan-assembler-times {\mbl __extendkftf2\M} 1 { target { 
ppc_float128 } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_trunckfsd\M} 1 { target { 
ppc_float128 } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_trunckfdd\M} 1 { target { 
ppc_float128 } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendkftd\M} 1 { target { 
ppc_float128 } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_truncsdsf\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendsddf\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendsdtf\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendsdkf\M} 1 { target { 
ppc_float128 } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendsddd2\M} 1 { target { ! 
dfp } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendsdtd2\M} 1 { target { ! 
dfp } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_truncddsf\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_truncdddf\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendddtf\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendddkf\M} 1 { target { 
ppc_float128 } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_truncddsd2\M} 1 { target { ! 
dfp } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_extendddtd2\M} 1 { target { ! 
dfp } } } } */
+/* { dg-final { scan-assembler-times {\mbl __dpd_trunctdsf\M} 1 } } */
+/* { dg-final { 

[PATCH 1/6] rs6000: Use more correct names for some trunc/extend libcalls

[Segher Boessenkool]

They had source and destination swapped in the name.


2018-07-16  Segher Boessenkool  

* config/rs6000/rs6000.c (init_float128_ibm): Use more correct names
for the conversions between TDmode and IFmode.
(init_float128_ieee): Use more correct names for the conversions
between TDmode and KFmode.

---
 gcc/config/rs6000/rs6000.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 1976072..f95aa59 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -17849,10 +17849,10 @@ init_float128_ibm (machine_mode mode)
 {
   set_conv_libfunc (sext_optab, mode, SDmode, "__dpd_extendsdtf2");
   set_conv_libfunc (sext_optab, mode, DDmode, "__dpd_extendddtf2");
-  set_conv_libfunc (trunc_optab, mode, TDmode, "__dpd_trunctftd2");
+  set_conv_libfunc (trunc_optab, mode, TDmode, "__dpd_trunctdtf2");
   set_conv_libfunc (trunc_optab, SDmode, mode, "__dpd_trunctfsd2");
   set_conv_libfunc (trunc_optab, DDmode, mode, "__dpd_trunctfdd2");
-  set_conv_libfunc (sext_optab, TDmode, mode, "__dpd_extendtdtf2");
+  set_conv_libfunc (sext_optab, TDmode, mode, "__dpd_extendtftd2");
 
   if (TARGET_POWERPC64)
{
@@ -17953,10 +17953,10 @@ init_float128_ieee (machine_mode mode)
 
   set_conv_libfunc (sext_optab, mode, SDmode, "__dpd_extendsdkf2");
   set_conv_libfunc (sext_optab, mode, DDmode, "__dpd_extendddkf2");
-  set_conv_libfunc (trunc_optab, mode, TDmode, "__dpd_trunckftd2");
+  set_conv_libfunc (trunc_optab, mode, TDmode, "__dpd_trunctdkf2");
   set_conv_libfunc (trunc_optab, SDmode, mode, "__dpd_trunckfsd2");
   set_conv_libfunc (trunc_optab, DDmode, mode, "__dpd_trunckfdd2");
-  set_conv_libfunc (sext_optab, TDmode, mode, "__dpd_extendtdkf2");
+  set_conv_libfunc (sext_optab, TDmode, mode, "__dpd_extendkftd2");
 
   set_conv_libfunc (sfix_optab, SImode, mode, "__fixkfsi");
   set_conv_libfunc (ufix_optab, SImode, mode, "__fixunskfsi");
-- 
1.8.3.1

[PATCH 5/6] rs6000: New testsuite selectors

[Segher Boessenkool]

This introduces four new selectors for use with Power testcases:
longdouble64, ppc_float128, ppc_float128_insns, powerpc_vsx.


2018-07-16  Segher Boessenkool  

gcc/testsuite/
* lib/target-supports.exp (check_effective_target_longdouble64,
check_effective_target_ppc_float128,
check_effective_target_ppc_float128_insns,
check_effective_target_powerpc_vsx): New.

---
 gcc/testsuite/lib/target-supports.exp | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index ec4a35d..c2d814c 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2684,6 +2684,15 @@ proc check_effective_target_longdouble128 { } {
 }]
 }
 
+# Return 1 if the target supports long double of 64 bits,
+# 0 otherwise.
+
+proc check_effective_target_longdouble64 { } {
+return [check_no_compiler_messages longdouble64 object {
+   int dummy[sizeof(long double) == 8 ? 1 : -1];
+}]
+}
+
 # Return 1 if the target supports double of 64 bits,
 # 0 otherwise.
 
@@ -5141,6 +5150,36 @@ proc check_effective_target_powerpc_float128_hw_ok { } {
 }
 }
 
+# Return 1 if current options define float128, 0 otherwise.
+
+proc check_effective_target_ppc_float128 { } {
+return [check_no_compiler_messages_nocache ppc_float128 object {
+   #ifndef __FLOAT128__
+ nope no good
+   #endif
+}]
+}
+
+# Return 1 if current options generate float128 insns, 0 otherwise.
+
+proc check_effective_target_ppc_float128_insns { } {
+return [check_no_compiler_messages_nocache ppc_float128 object {
+   #ifndef __FLOAT128_HARDWARE__
+ nope no good
+   #endif
+}]
+}
+
+# Return 1 if current options generate VSX instructions, 0 otherwise.
+
+proc check_effective_target_powerpc_vsx { } {
+return [check_no_compiler_messages_nocache powerpc_vsx object {
+   #ifndef __VSX__
+ nope no vsx
+   #endif
+}]
+}
+
 # Return 1 if this is a PowerPC target supporting -mvsx
 
 proc check_effective_target_powerpc_vsx_ok { } {
-- 
1.8.3.1

[PATCH 3/6] rs6000: Improve truncifsf2

[Segher Boessenkool]

The current implementation leaves an unnecessary register move.  It is
easier to just expand things in the expander already.  This patch does
that.


2018-07-16  Segher Boessenkool  

* config/rs6000/rs6000.md (truncsf2): Expand truncates of
double-double modes to SFmode directly directly.
(truncsf2_fprs): Delete.

---
 gcc/config/rs6000/rs6000.md | 23 +--
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 44d32d9..94a0f7d 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -7702,28 +7702,15 @@ (define_expand "truncsf2"
 {
   if (FLOAT128_IEEE_P (mode))
 rs6000_expand_float128_convert (operands[0], operands[1], false);
-  else if (mode == TFmode)
-emit_insn (gen_trunctfsf2_fprs (operands[0], operands[1]));
-  else if (mode == IFmode)
-emit_insn (gen_truncifsf2_fprs (operands[0], operands[1]));
   else
-gcc_unreachable ();
+{
+  rtx tmp = gen_reg_rtx (DFmode);
+  emit_insn (gen_truncdf2 (tmp, operands[1]));
+  emit_insn (gen_truncdfsf2 (operands[0], tmp));
+}
   DONE;
 })
 
-(define_insn_and_split "truncsf2_fprs"
-  [(set (match_operand:SF 0 "gpc_reg_operand" "=f")
-   (float_truncate:SF (match_operand:IBM128 1 "gpc_reg_operand" "d")))
-   (clobber (match_scratch:DF 2 "=d"))]
-  "TARGET_HARD_FLOAT && TARGET_LONG_DOUBLE_128 && FLOAT128_IBM_P (mode)"
-  "#"
-  "&& reload_completed"
-  [(set (match_dup 2)
-   (float_truncate:DF (match_dup 1)))
-   (set (match_dup 0)
-   (float_truncate:SF (match_dup 2)))]
-  "")
-
 (define_expand "floatsi2"
   [(parallel [(set (match_operand:FLOAT128 0 "gpc_reg_operand")
   (float:FLOAT128 (match_operand:SI 1 "gpc_reg_operand")))
-- 
1.8.3.1

[PATCH 4/6] rs6000: Fix testsuite bug in check_ppc_float128_hw_available

[Segher Boessenkool]

The test program for ppc_float128_hw_available would always return
false, since there is a syntax error in that test program.


2018-07-16  Segher Boessenkool  

gcc/testsuite/
* lib/target-supports.exp (check_ppc_float128_hw_available): Fix
syntax error.

---
 gcc/testsuite/lib/target-supports.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 99613fd..ec4a35d 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2182,7 +2182,7 @@ proc check_ppc_float128_hw_available { } {
__float128 w = -1.0q;
 
__asm__ ("xsaddqp %0,%1,%2" : "+v" (w) : "v" (x), "v" (y));
-   return ((z != 3.0q) || (z != w);
+   return ((z != 3.0q) || (z != w));
}
} $options
}
-- 
1.8.3.1

[PATCH 2/6] rs6000: Use correct names for some trunc/extend libcalls

[Segher Boessenkool]

The libcalls for trunc and extend of a decimal float to a binary float,
and vice versa, do not have "2" in the name, although all other such
conversions do.


2018-07-16  Segher Boessenkool  

* config/rs6000/rs6000.c (init_float128_ibm): Use the correct names
for conversions between IFmode and the decimal floating point modes.
(init_float128_ieee): Use the correct names for conversions between
KFmode and the decimal floating point modes.

---
 gcc/config/rs6000/rs6000.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index f95aa59..62b8ea3 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -17847,12 +17847,12 @@ init_float128_ibm (machine_mode mode)
  names.  */
   if (mode == IFmode)
 {
-  set_conv_libfunc (sext_optab, mode, SDmode, "__dpd_extendsdtf2");
-  set_conv_libfunc (sext_optab, mode, DDmode, "__dpd_extendddtf2");
-  set_conv_libfunc (trunc_optab, mode, TDmode, "__dpd_trunctdtf2");
-  set_conv_libfunc (trunc_optab, SDmode, mode, "__dpd_trunctfsd2");
-  set_conv_libfunc (trunc_optab, DDmode, mode, "__dpd_trunctfdd2");
-  set_conv_libfunc (sext_optab, TDmode, mode, "__dpd_extendtftd2");
+  set_conv_libfunc (sext_optab, mode, SDmode, "__dpd_extendsdtf");
+  set_conv_libfunc (sext_optab, mode, DDmode, "__dpd_extendddtf");
+  set_conv_libfunc (trunc_optab, mode, TDmode, "__dpd_trunctdtf");
+  set_conv_libfunc (trunc_optab, SDmode, mode, "__dpd_trunctfsd");
+  set_conv_libfunc (trunc_optab, DDmode, mode, "__dpd_trunctfdd");
+  set_conv_libfunc (sext_optab, TDmode, mode, "__dpd_extendtftd");
 
   if (TARGET_POWERPC64)
{
@@ -17951,12 +17951,12 @@ init_float128_ieee (machine_mode mode)
   if (mode != TFmode && FLOAT128_IBM_P (TFmode))
set_conv_libfunc (trunc_optab, TFmode, mode, "__extendkftf2");
 
-  set_conv_libfunc (sext_optab, mode, SDmode, "__dpd_extendsdkf2");
-  set_conv_libfunc (sext_optab, mode, DDmode, "__dpd_extendddkf2");
-  set_conv_libfunc (trunc_optab, mode, TDmode, "__dpd_trunctdkf2");
-  set_conv_libfunc (trunc_optab, SDmode, mode, "__dpd_trunckfsd2");
-  set_conv_libfunc (trunc_optab, DDmode, mode, "__dpd_trunckfdd2");
-  set_conv_libfunc (sext_optab, TDmode, mode, "__dpd_extendkftd2");
+  set_conv_libfunc (sext_optab, mode, SDmode, "__dpd_extendsdkf");
+  set_conv_libfunc (sext_optab, mode, DDmode, "__dpd_extendddkf");
+  set_conv_libfunc (trunc_optab, mode, TDmode, "__dpd_trunctdkf");
+  set_conv_libfunc (trunc_optab, SDmode, mode, "__dpd_trunckfsd");
+  set_conv_libfunc (trunc_optab, DDmode, mode, "__dpd_trunckfdd");
+  set_conv_libfunc (sext_optab, TDmode, mode, "__dpd_extendkftd");
 
   set_conv_libfunc (sfix_optab, SImode, mode, "__fixkfsi");
   set_conv_libfunc (ufix_optab, SImode, mode, "__fixunskfsi");
-- 
1.8.3.1

[PATCH 0/6] rs6000: Test all rs6000 floating point conversions

[Segher Boessenkool]

This series adds new codegen tests for converting any of our seven
floating point modes to any of those seven.  It also fixes a bunch of
bugs so that these testcases pass.

Tested on powerpc64-linux {-m32,-m64} (a power7); on powerpc64le-linux,
both on power8 and on power9; and on AIX.

Also tested the new testcases with options
{-mlong-double-64,-mlong-double-128}
{-mabi=ibmlongdouble,-mabi=ieeelongdouble}
{-mcpu=power4,-mcpu=970,-mcpu=power6,-mcpu=power7,-mcpu=power9}
{-mabi=elfv1/-mbig,-mabi=elfv2/-mlittle}
{-m32,-m64}
(but not -mabi=ieeelongdouble before power7 because that is not
supported).

Committing to trunk.


Segher


Segher Boessenkool (6):
  rs6000: Use more correct names for some trunc/extend libcalls
  rs6000: Use correct names for some trunc/extend libcalls
  rs6000: Improve truncifsf2
  rs6000: Fix testsuite bug in check_ppc_float128_hw_available
  rs6000: New testsuite selectors
  rs6000: New testcase fp-convert.c

 gcc/config/rs6000/rs6000.c| 24 +++---
 gcc/config/rs6000/rs6000.md   | 23 ++
 gcc/testsuite/gcc.target/powerpc/convert-fp-128.c | 99 +++
 gcc/testsuite/gcc.target/powerpc/convert-fp-64.c  | 61 ++
 gcc/testsuite/lib/target-supports.exp | 41 +-
 5 files changed, 217 insertions(+), 31 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/convert-fp-128.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/convert-fp-64.c

-- 
1.8.3.1

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

[qing.zhao at oracle dot com]

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

--- Comment #5 from Qing Zhao  ---
> --- Comment #4 from seurer at gcc dot gnu.org ---
> I also just tried it on gcc110 and indeed it does not fail there.  However, it
> does fail on gcc112.
thanks a lot. will try on gcc112.

[Bug fortran/86325] Error on valid code with pointer class components using -finit-derived

[foreese at gcc dot gnu.org]

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

--- Comment #4 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 22:25:54 2018
New Revision: 262751

URL: https://gcc.gnu.org/viewcvs?rev=262751=gcc=rev
Log:
2018-07-16  Fritz Reese  

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/fortran/module.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

[Bug fortran/83183] Out of memory with option -finit-derived

[foreese at gcc dot gnu.org]

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

--- Comment #5 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 22:25:54 2018
New Revision: 262751

URL: https://gcc.gnu.org/viewcvs?rev=262751=gcc=rev
Log:
2018-07-16  Fritz Reese  

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/fortran/module.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[foreese at gcc dot gnu.org]

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

--- Comment #17 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 22:25:54 2018
New Revision: 262751

URL: https://gcc.gnu.org/viewcvs?rev=262751=gcc=rev
Log:
2018-07-16  Fritz Reese  

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262746,
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/fortran/module.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[clhamilto at gmail dot com]

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

--- Comment #2 from Curtis Hamilton  ---
Created attachment 44402
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44402=edit
Requested generated file

I cannot find a definition for 'cmsghdr' in any header file.  The only
reference I see in in "mksysinfo.sh".  See below:

build.log:-rw-rw-r--  0 2000   2000 3481 Mar 25 10:29
rustc-1.25.0-src/src/libcompiler_builtins/compiler-rt/test/msan/Linux/cmsghdr.cc
work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:
 RoundUpTo(sizeof(__sanitizer_cmsghdr), sizeof(uptr));
work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:
   if (p + sizeof(__sanitizer_cmsghdr) > control_end) break;
work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:
   __sanitizer_cmsghdr *cmsg = (__sanitizer_cmsghdr *)p;
work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:CHECK_TYPE_SIZE(cmsghdr);
work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:CHECK_SIZE_AND_OFFSET(cmsghdr,
cmsg_len);
work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:CHECK_SIZE_AND_OFFSET(cmsghdr,
cmsg_level);
work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:CHECK_SIZE_AND_OFFSET(cmsghdr,
cmsg_type);
work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:
 struct __sanitizer_cmsghdr {
work/gcc-7.3.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:
 struct __sanitizer_cmsghdr {
work/gcc-7.3.0/libsanitizer/tsan/tsan_platform_linux.cc:  struct cmsghdr *cmsg
= CMSG_FIRSTHDR(msg);
work/gcc-7.3.0/gcc/testsuite/gcc.c-torture/compile/20080613-1.c:struct cmsghdr 
 {
work/gcc-7.3.0/gcc/testsuite/gcc.c-torture/compile/20080613-1.c:inline struct
cmsghdr * cmsg_put(struct cmsghdr *cm, int type, void *data, size_t len)
work/gcc-7.3.0/gcc/testsuite/gcc.c-torture/compile/20080613-1.c:struct
cmsghdr *cm;
work/gcc-7.3.0/libgo/mksysinfo.sh:# The cmsghdr struct.
work/gcc-7.3.0/libgo/mksysinfo.sh:cmsghdr=`grep '^type _cmsghdr '
gen-sysinfo.go`
work/gcc-7.3.0/libgo/mksysinfo.sh:if test -n "$cmsghdr"; then
work/gcc-7.3.0/libgo/mksysinfo.sh:  cmsghdr_len=`echo $cmsghdr | sed -n -e
's/^.*cmsg_len \([^ ]*\);.*$/\1/p'`
work/gcc-7.3.0/libgo/mksysinfo.sh:  echo "type Cmsghdr_len_t $cmsghdr_len" >>
${OUT}
work/gcc-7.3.0/libgo/mksysinfo.sh:  echo "$cmsghdr" | \
work/gcc-7.3.0/libgo/mksysinfo.sh:  sed -e 's/_cmsghdr/Cmsghdr/' \
work/gcc-7.3.0/libgo/mksysinfo.sh:set cmsghdr Cmsghdr ip_mreq IPMreq ip_mreqn
IPMreqn ipv6_mreq IPv6Mreq \

Let me know if you want to look at any of these.

Regards,

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
I also just tried it on gcc110 and indeed it does not fail there.  However, it
does fail on gcc112.

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

[Jeff Law]

On 07/05/2018 08:48 AM, Thomas Preudhomme wrote:
> In case of high register pressure in PIC mode, address of the stack
> protector's guard can be spilled on ARM targets as shown in PR85434,
> thus allowing an attacker to control what the canary would be compared
> against. ARM does lack stack_protect_set and stack_protect_test insn
> patterns, defining them does not help as the address is expanded
> regularly and the patterns only deal with the copy and test of the
> guard with the canary.
> 
> This problem does not occur for x86 targets because the PIC access and
> the test can be done in the same instruction. Aarch64 is exempt too
> because PIC access insn pattern are mov of UNSPEC which prevents it from
> the second access in the epilogue being CSEd in cse_local pass with the
> first access in the prologue.
> 
> The approach followed here is to create new "combined" set and test
> standard pattern names that take the unexpanded guard and do the set or
> test. This allows the target to use an opaque pattern (eg. using UNSPEC)
> to hide the individual instructions being generated to the compiler and
> split the pattern into generic load, compare and branch instruction
> after register allocator, therefore avoiding any spilling. This is here
> implemented for the ARM targets. For targets not implementing these new
> standard pattern names, the existing stack_protect_set and
> stack_protect_test pattern names are used.
> 
> To be able to split PIC access after register allocation, the functions
> had to be augmented to force a new PIC register load and to control
> which register it loads into. This is because sharing the PIC register
> between prologue and epilogue could lead to spilling due to CSE again
> which an attacker could use to control what the canary gets compared
> against.
> 
> ChangeLog entries are as follows:
> 
> *** gcc/ChangeLog ***
> 
> 2018-07-05  Thomas Preud'homme  
> 
> PR target/85434
> * target-insns.def (stack_protect_combined_set): Define new standard
> pattern name.
> (stack_protect_combined_test): Likewise.
> * cfgexpand.c (stack_protect_prologue): Try new
> stack_protect_combined_set pattern first.
> * function.c (stack_protect_epilogue): Try new
> stack_protect_combined_test pattern first.
> * config/arm/arm.c (require_pic_register): Add pic_reg and compute_now
> parameters to control which register to use as PIC register and force
> reloading PIC register respectively.
> (legitimize_pic_address): Expose above new parameters in prototype and
> adapt recursive calls accordingly.
> (arm_legitimize_address): Adapt to new legitimize_pic_address
> prototype.
> (thumb_legitimize_address): Likewise.
> (arm_emit_call_insn): Adapt to new require_pic_register prototype.
> * config/arm/arm-protos.h (legitimize_pic_address): Adapt to prototype
> change.
> * config/arm/arm.md (movsi expander): Adapt to legitimize_pic_address
> prototype change.
> (stack_protect_combined_set): New insn_and_split pattern.
> (stack_protect_set): New insn pattern.
> (stack_protect_combined_test): New insn_and_split pattern.
> (stack_protect_test): New insn pattern.
> * config/arm/unspecs.md (UNSPEC_SP_SET): New unspec.
> (UNSPEC_SP_TEST): Likewise.
> * doc/md.texi (stack_protect_combined_set): Document new standard
> pattern name.
> (stack_protect_set): Clarify that the operand for guard's address is
> legal.
> (stack_protect_combined_test): Document new standard pattern name.
> (stack_protect_test): Clarify that the operand for guard's address is
> legal.
> 
> *** gcc/testsuite/ChangeLog ***
> 
> 2018-07-05  Thomas Preud'homme  
> 
> PR target/85434
> * gcc.target/arm/pr85434.c: New test.
> 
> Testing: Bootstrapped on ARM in both Arm and Thumb-2 mode as well as on
> Aarch64. Testsuite shows no regression on these 3 variants either both
> with default flags and with -fstack-protector-all.
> 
> Is this ok for trunk? If yes, would this be acceptable as a backport to
> GCC 6, 7 and 8 provided that no regression is found?
> 
> Best regards,
> 
> Thomas
> 
> 
> 0001-PR85434-Prevent-spilling-of-stack-protector-guard-s-.patch
> 
> 
> From d917d48c2005e46154383589f203d06f3c6167e0 Mon Sep 17 00:00:00 2001
> From: Thomas Preud'homme 
> Date: Tue, 8 May 2018 15:47:05 +0100
> Subject: [PATCH] PR85434: Prevent spilling of stack protector guard's address
>  on ARM
> 
> In case of high register pressure in PIC mode, address of the stack
> protector's guard can be spilled on ARM targets as shown in PR85434,
> thus allowing an attacker to control what the canary would be compared
> against. ARM does lack stack_protect_set and stack_protect_test insn
> patterns, defining them does not help as the address is expanded
> regularly and the patterns only deal with the copy and test of the
> guard with the canary.
> 
> This problem does not occur for x86 targets because the PIC access and
> 

[Bug target/81283] Quirks around 32-bit PowerPC built-in Atomics

[kallisti5 at unixzen dot com]

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

Alexander von Gluck  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Alexander von Gluck  ---
Sorry for the late reply on this one.  I'm pretty sure I did this and it worked
:-)

Re: ICE building a libsupc++ file, pdp11 target

[Paul Koning]

> On Jul 13, 2018, at 3:12 PM, U.Mutlu  wrote:
> 
> Paul Koning wrote on 07/13/2018 08:56 PM:
>> 
>> 
>>> On Jul 13, 2018, at 2:52 PM, U.Mutlu  wrote:
>>> 
>>> Paul Koning wrote on 07/13/2018 08:27 PM:
 I'm trying to see if I can build the pdp11 target for languages other than 
 just C, and the answer is for the most part yes.  But I' running into an 
 ICE I can't figure out.  It's way before the back end comes into the 
 picture as far as I can see, and there's nothing particularly strange 
 looking in the input file that suggests anything.
 
 Any suggestions on where to look?  The failure is:
 
 libtool: compile:  /Users/pkoning/Documents/svn/buildpdp+/./gcc/xgcc 
 -shared-libgcc -B/Users/pkoning/Documents/svn/buildpdp+/./gcc -nostdinc++ 
 -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src 
 -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src/.libs 
 -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/libsupc++/.libs
  -B/usr/local/pdp11-aout/pdp11-aout/bin/ 
 -B/usr/local/pdp11-aout/pdp11-aout/lib/ -isystem 
 /usr/local/pdp11-aout/pdp11-aout/include -isystem 
 /usr/local/pdp11-aout/pdp11-aout/sys-include 
 -I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/../libgcc 
 -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include/pdp11-aout
  -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include 
 -I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/libsupc++ 
 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
 -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 
 -std=gnu++1z -c ../../../../gcc/l
> ib
>>> stdc++-v3/libsupc++/new_opa.cc -o new_opa.o
 cc1plus: warning: -Wabi won't warn about anything [-Wabi]
 cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, 
 which is also used by default
 cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
 ../../../../gcc/libstdc++-v3/libsupc++/new_opa.cc:112:1: internal compiler 
 error: in import_export_decl, at cp/decl2.c:2877
  }
  ^
 libbacktrace could not find executable to open
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See  for instructions.
 make[3]: *** [new_opa.lo] Error 1
>>> 
>>> 
>>> It's failing at the last gcc_assert() below (file 
>>> ../gcc_src/gcc/cp/decl2.c:2877 ):
>> 
>> Sorry, I should have been more explicit.  I saw that, but my question is: 
>> what is the underlying problem that triggers the assert?  The comment is not 
>> much help to me.  And more specifically: what could a target be doing wrong 
>> that would make an early stage of the compiler fail like this on what seems 
>> like a pretty straightforward source file?
>> 
>> Many of the other libstdc++ bits compile just fine, as do plenty of 
>> testsuite cases and some test files of my own.
>> 
> 
> /* In a VAR_DECL, FUNCTION_DECL, NAMESPACE_DECL or TYPE_DECL,
>   nonzero means name is to be accessible from outside this translation unit.
>   In an IDENTIFIER_NODE, nonzero means an external declaration
>   accessible from outside this translation unit was previously seen
>   for this name in an inner scope.  */
> #define TREE_PUBLIC(NODE) ((NODE)->base.public_flag)
> 
> 
> Ie. it has todo with the value of the member var public_flag of the tree decl.

I'm still on the same question as before.  Why do I get an ICE in the tree 
phase of the compiler, complaining about flags of a declaration, based on 
something I apparently have wrong in my target description?  I can build C++ 
for other targets, so this isn't a general bug.  But I'm not used to target 
(back end) stuff affecting the compiler before I even get to the RTL part.  And 
in this case, looking at the failing code gives me no clue at all.  I can't do 
anything with the "tree" object to find out what it describes; it's a VAR_DECL 
but I don't know what to look at. I tried turning on tree dump files, those 
gave no clue either.  And there is nothing in the manuals.

paul

[Bug tree-optimization/86526] [9 Regression] ICE in builtin_memcpy_read_str, at builtins.c:3017

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 16 21:25:22 2018
New Revision: 262750

URL: https://gcc.gnu.org/viewcvs?rev=262750=gcc=rev
Log:
PR tree-optimization/86526
* builtins.c (expand_builtin_memcmp): Formatting fixes.
(inline_expand_builtin_string_cmp): Likewise.
(inline_string_cmp): Likewise.  Use c_readstr instead of
builtin_memcpy_read_str.  Add unit_mode temporary.

* gcc.c-torture/compile/pr86526.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr86526.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH 1/4] Clean up of new format of -falign-FOO.

[Jeff Law]

On 07/04/2018 04:23 AM, marxin wrote:
> gcc/ChangeLog:
> 
> 2018-07-11  Martin Liska  
> 
>   * align.h: New file.
>   * config/alpha/alpha.c (alpha_align_insns_1): Use align_functions 
> directly.
>   * config/i386/i386.c (ix86_avoid_jump_mispredicts): Use new return type
>   align_flags of label_to_alignment.
>   * config/m32r/m32r.h (LOOP_ALIGN): Wrap returned values into align_flags
>   class.
>   * config/m68k/m68k.c: Do not use removed align_labels_value and
>   align_loops_value.
>   * config/nds32/nds32.h (JUMP_ALIGN): Wrap result into align_flags class.
>   (LOOP_ALIGN): Likewise.
>   (LABEL_ALIGN): Likewise.
>   * config/powerpcspe/powerpcspe.c (TARGET_ASM_LOOP_ALIGN_MAX_SKIP):
>   Remove not used macro.
>   (rs6000_loop_align): Change return type to align_flags.
>   (rs6000_loop_align_max_skip): Remove.
>   * config/rs6000/rs6000-protos.h (rs6000_loop_align):
>   Change return type to align_flags.
>   * config/rs6000/rs6000.c (TARGET_ASM_LOOP_ALIGN_MAX_SKIP):
>   Remove not used macro.
>   (rs6000_loop_align):  Change return type to align_flags.
>   (rs6000_loop_align_max_skip): Remove.
>   * config/rx/rx.h (JUMP_ALIGN): Wrap integer values
>   * config/rx/rx-protos.h (rx_align_for_label): Make it
> static function.
>   * config/rx/rx.c (rx_align_for_label): Change return type
> to align_flags.
>   (rx_max_skip_for_label): Remove TARGET_ASM_*_ALIGN_MAX_SKIP
> macro definitions.
>   into align_flags class.
>   (LABEL_ALIGN): Likewise.
>   (LOOP_ALIGN): Likewise.
>   * config/s390/s390.c (s390_label_align): Use align_flags
>   class member.
>   (s390_asm_output_function_label): Likewise.
>   * config/sh/sh.c (sh_override_options_after_change):
>   Use align_flags class directly without macros.
>   (find_barrier): Likewise.
>   (barrier_align): Likewise.
>   (sh_loop_align): Likewise.
>   * config/spu/spu.c (spu_option_override):
>   Use align_flags_tuple::get_value instead of removed macros.
>   (spu_sched_init): Likewise.
>   * config/spu/spu.h (GTY): Likewise.
>   * config/visium/visium.c (visium_option_override):
>   Set "8" as default secondary alignment.
>   * config/visium/visium.h (SUBALIGN_LOG): Define to 3
>   in order to guarantee secondary alignment of 8.
>   * coretypes.h: Include align.h header file.
>   * doc/tm.texi: Remove TARGET_ASM_JUMP_ALIGN_MAX_SKIP,
>   TARGET_ASM_LOOP_ALIGN_MAX_SKIP, TARGET_ASM_LABEL_ALIGN_MAX_SKIP
> and TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP macros.
>   * doc/tm.texi.in: Likewise.
>   * final.c (struct label_alignment): Remove not used structure.
>   (LABEL_ALIGN): Change type to align_flags.
>   (LOOP_ALIGN): Likewise.
>   (JUMP_ALIGN): Likewise.
>   (default_loop_align_max_skip): Remove.
>   (default_label_align_max_skip): Likewise.
>   (default_jump_align_max_skip): Likewise.
>   (default_label_align_after_barrier_max_skip):
>   (LABEL_TO_ALIGNMENT): Change to access label_align vector.
>   (LABEL_TO_MAX_SKIP): Remove.
>   (label_to_alignment): Return align_flags type instead of integer.
>   (label_to_max_skip): Remove.
>   (align_fuzz): Use align_flags type.
>   (compute_alignments): Use align_flags type and use align_flags::max
>   to combine multiple alignments.
>   (grow_label_align): Grow vec instead of C array.
>   (update_alignments): Assign just LABEL_TO_ALIGNMENT.
>   (shorten_branches):  Use align_flags type and use align_flags::max
>   to combine multiple alignments.
>   (final_scan_insn_1): Remove usage of secondary alignment that comes
>   from label alignment, but instead use proper secondary alignment
>   which is computed in grow_label_align.
>   * flags.h (struct align_flags_tuple): Move to align.h.
>   (struct align_flags): Likewise.
>   (state_align_loops): Rename to align_loops.
>   (state_align_jumps): Rename to align_jumps.
>   (state_align_labels): Rename to align_labels.
>   (state_align_functions): Rename to align_functions.
>   (align_loops_log): Remove.
>   (align_jumps_log): Remove.
>   (align_labels_log): Remove.
>   (align_functions_log): Remove.
>   (align_loops_max_skip): Remove.
>   (align_jumps_max_skip): Remove.
>   (align_labels_max_skip): Remove.
>   (align_functions_max_skip): Remove.
>   (align_loops_value): Remove.
>   (align_jumps_value): Remove.
>   (align_labels_value): Remove.
>   (align_functions_value): Remove.
>   * output.h (label_to_alignment): Change return type to align_flags.
>   (label_to_max_skip): Remove.
>   * target.def: Remove loop_align_max_skip, label_align_max_skip,
>   jump_align_max_skip macros.
>   * targhooks.h (default_loop_align_max_skip): Remove.
>   

Re: [RFC] Update coding conventions to restrict use of non-const references

[Martin Sebor]

On 07/16/2018 02:19 AM, Richard Sandiford wrote:

Aldy Hernandez  writes:

On Thu, Jul 12, 2018 at 1:41 PM Jonathan Wakely  wrote:


On Thu, 12 Jul 2018 at 11:41, Richard Sandiford wrote:

+Only use non-constant references in the following situations:
+
+
+
+when they are necessary to conform to a standard interface, such as
+the first argument to a non-member operator+=


And the return value of such operators (which also applies to member
operators, which is the more conventional way to write compound
assignment operators).


+in a return value, when providing access to something that is known
+to be nonnull
+
+
+
+In other situations the convention is to use pointers instead.
+
+
+
+HOST_WIDE_INT do_arith (..., bool *overflow);   // OK
+HOST_WIDE_INT do_arith (..., bool overflow);   // Please avoid


I understand the objection to using references for out parameters (an
alternative to pointers is to return a struct with the wide int result
and the overflow flag), but ...


Putting everything in a new struct is just going through more hoops to
avoid a common language idiom that everyone in C++ is used to.




+int *elt = array[i];  // OK
+int elt = array[i];   // Please avoid


... this seems unnecessary. If the function is so long that the fact
elt is a reference can easily get lost, the problem is the length of
the function, not the use of a reference.


Agreed.

Richard (Sandiford), this really looks like going out of your way to
enforce a personal style issue across the entire code base.  It's sad
that we try to come up with new ways to make it even harder for new
developers to contribute to GCC.


It's not enforcing a personal style issue so much as trying to stop
the source base from becoming even more inconsistent, admittedly in one
particular area only.

Before the switch to C++, GCC was one of the most consistent source
bases I'd seen (more so even than LLVM IMO, having worked on both).
It's clearly less so now.  The problem isn't just legacy C-era code vs.
new C++ code, but different styles being used for the C++ code.

(It was interesting that Martin complained earlier in the thread about
how inconsistent GCC was.  I imagine that's the impression that new
developers would have now, rather than being glad that they can use
references to return things.)


Just to be clear: mine wasn't meant to be a complaint so much
as an observation.  With a code base as large as GCC and with
so many people contributing to it, I wouldn't expect too much
more consistency unless it was enforced by tools.

I don't have a problem with adopting a new convention per se.
What I find a poor use of time and effort is relying on code
review as the only enforcement of a consistent coding style.
It gets especially frustrating when the same piece of code
that is acceptable to one reviewer is not good enough for
another only because it doesn't follow some convention that
GCC isn't consistent with to begin with (which to me seems
like it's more than those GCC is consistent with).

Martin

PS Here are some examples of documented GCC coding conventions
that I have noticed are either very inconsistent or virtually
ignored ignored (this isn't a survey):

  *  logical not!xvs  ! x  thousands of violations
  *  cast   (foo) x   vs  (foo)x   ditto
  *  C++-style casts vs C-stylemostly ignored
  *  explicit ctorsignored
  *  in class member definitions

Re: [PATCH] Fix inline memcpy ICE (PR tree-optimization/86526)

[Jeff Law]

On 07/16/2018 02:41 PM, Jakub Jelinek wrote:
> Hi!
> 
> builtin_memcpy_read_str is a function meant to be called just as a callback
> and verifies that we don't cross a '\0' boundary in the string.  For
> inline_string_cmp, we've checked that the length returned from c_getstr
> is fine, so we can cross as many embedded NULs as there are within the
> TREE_STRING_LENGTH.
> 
> The rest of the patch is just a temporary to avoid using as_a twice in
> each loop iteration, and lots of formatting fixes, mostly to avoid trailing
> whitespace.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2018-07-16  Jakub Jelinek  
> 
>   PR tree-optimization/86526
>   * builtins.c (expand_builtin_memcmp): Formatting fixes.
>   (inline_expand_builtin_string_cmp): Likewise.
>   (inline_string_cmp): Likewise.  Use c_readstr instead of
>   builtin_memcpy_read_str.  Add unit_mode temporary.
> 
>   * gcc.c-torture/compile/pr86526.c: New test.
OK.

This looks like it'll fix the m68k linux kernel build failure I saw over
the weekend as well.

jeff

[Bug fortran/83184] Out of memory or ICE with option -fdec

[foreese at gcc dot gnu.org]

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

--- Comment #6 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 20:55:32 2018
New Revision: 262748

URL: https://gcc.gnu.org/viewcvs?rev=262748=gcc=rev
Log:
2018-07-16  Fritz Reese  

  gcc/testsuite/ChangeLog:

PR fortran/83184
* gfortran.dg/dec_structure_23.f90: Oops, "un-fix" error messages.


Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/dec_structure_23.f90

[PATCH] Fix inline memcpy ICE (PR tree-optimization/86526)

[Jakub Jelinek]

Hi!

builtin_memcpy_read_str is a function meant to be called just as a callback
and verifies that we don't cross a '\0' boundary in the string.  For
inline_string_cmp, we've checked that the length returned from c_getstr
is fine, so we can cross as many embedded NULs as there are within the
TREE_STRING_LENGTH.

The rest of the patch is just a temporary to avoid using as_a twice in
each loop iteration, and lots of formatting fixes, mostly to avoid trailing
whitespace.

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

2018-07-16  Jakub Jelinek  

PR tree-optimization/86526
* builtins.c (expand_builtin_memcmp): Formatting fixes.
(inline_expand_builtin_string_cmp): Likewise.
(inline_string_cmp): Likewise.  Use c_readstr instead of
builtin_memcpy_read_str.  Add unit_mode temporary.

* gcc.c-torture/compile/pr86526.c: New test.

--- gcc/builtins.c.jj   2018-07-16 09:42:25.743985945 +0200
+++ gcc/builtins.c  2018-07-16 11:47:46.535014889 +0200
@@ -4454,19 +4454,19 @@ expand_builtin_memcmp (tree exp, rtx tar
   no_overflow = check_access (exp, /*dst=*/NULL_TREE, /*src=*/NULL_TREE,
  len, /*maxread=*/NULL_TREE, size,
  /*objsize=*/NULL_TREE);
-  if (no_overflow) 
+  if (no_overflow)
 {
   size = compute_objsize (arg2, 0);
   no_overflow = check_access (exp, /*dst=*/NULL_TREE, /*src=*/NULL_TREE,
  len,  /*maxread=*/NULL_TREE, size,
  /*objsize=*/NULL_TREE);
-} 
+}
 
-  /* Due to the performance benefit, always inline the calls first 
+  /* Due to the performance benefit, always inline the calls first
  when result_eq is false.  */
   rtx result = NULL_RTX;
-   
-  if (!result_eq && fcode != BUILT_IN_BCMP && no_overflow) 
+
+  if (!result_eq && fcode != BUILT_IN_BCMP && no_overflow)
 {
   result = inline_expand_builtin_string_cmp (exp, target, true);
   if (result)
@@ -6748,7 +6748,7 @@ expand_builtin_goacc_parlevel_id_size (t
   return target;
 }
 
-/* Expand a string compare operation using a sequence of char comparison 
+/* Expand a string compare operation using a sequence of char comparison
to get rid of the calling overhead, with result going to TARGET if
that's convenient.
 
@@ -6757,7 +6757,7 @@ expand_builtin_goacc_parlevel_id_size (t
LENGTH is the number of chars to compare;
CONST_STR_N indicates which source string is the constant string;
IS_MEMCMP indicates whether it's a memcmp or strcmp.
-   
+  
to: (assume const_str_n is 2, i.e., arg2 is a constant string)
 
target = var_str[0] - const_str[0];
@@ -6772,41 +6772,38 @@ expand_builtin_goacc_parlevel_id_size (t
   */
 
 static rtx
-inline_string_cmp (rtx target, tree var_str, const char* const_str, 
+inline_string_cmp (rtx target, tree var_str, const char *const_str,
   unsigned HOST_WIDE_INT length,
   int const_str_n, machine_mode mode,
-  bool is_memcmp) 
+  bool is_memcmp)
 {
   HOST_WIDE_INT offset = 0;
-  rtx var_rtx_array 
+  rtx var_rtx_array
 = get_memory_rtx (var_str, build_int_cst (unsigned_type_node,length));
   rtx var_rtx = NULL_RTX;
-  rtx const_rtx = NULL_RTX; 
-  rtx result = target ? target : gen_reg_rtx (mode); 
-  rtx_code_label *ne_label = gen_label_rtx ();  
+  rtx const_rtx = NULL_RTX;
+  rtx result = target ? target : gen_reg_rtx (mode);
+  rtx_code_label *ne_label = gen_label_rtx ();
   tree unit_type_node = is_memcmp ? unsigned_char_type_node : char_type_node;
+  scalar_int_mode unit_mode
+= as_a  TYPE_MODE (unit_type_node);
 
   start_sequence ();
 
   for (unsigned HOST_WIDE_INT i = 0; i < length; i++)
 {
-  var_rtx 
+  var_rtx
= adjust_address (var_rtx_array, TYPE_MODE (unit_type_node), offset);
-  const_rtx 
-   = builtin_memcpy_read_str (CONST_CAST (char *, const_str),
-  offset,
-  as_a  
-  TYPE_MODE (unit_type_node));
+  const_rtx = c_readstr (const_str + offset, unit_mode);
   rtx op0 = (const_str_n == 1) ? const_rtx : var_rtx;
   rtx op1 = (const_str_n == 1) ? var_rtx : const_rtx;
-  
-  result = expand_simple_binop (mode, MINUS, op0, op1, 
-   result, is_memcmp ? 1 : 0, OPTAB_WIDEN);
-  if (i < length - 1) 
-emit_cmp_and_jump_insns (result, CONST0_RTX (mode), NE, NULL_RTX,
-mode, true, ne_label);
-  offset 
-   += GET_MODE_SIZE (as_a  TYPE_MODE (unit_type_node));
+
+  result = expand_simple_binop (mode, MINUS, op0, op1,
+   result, is_memcmp ? 1 : 0, OPTAB_WIDEN);
+  if (i < length - 1)
+   emit_cmp_and_jump_insns (result, CONST0_RTX (mode), NE, NULL_RTX,
+mode, true, ne_label);
+  offset += 

Re: [PATCH, rs6000] Fix AIX test case failures

[Segher Boessenkool]

On Fri, Jul 13, 2018 at 04:15:26PM -0700, Carl Love wrote:
> Segher, David:
> 
> I reworked the patch per the first option that David gave.  The tests
> divkc3-2.c, divkc3-3.c, mulkc3-2.c and mulkc3-3.c pass on Power 9 Linux
> as they did before.  The tests are unsupported on Power8 Linux as they
> were before.  Now, the tests are reported as unsupported on AIX rather
> then failing on AIX.
> 
> Please let me know if you both approve the updated patch below.  Thanks
> for the input and help on this.

You need only one approval ;-)

(The patch is fine.  Thanks!)


Segher



> 2018-07-13  Carl Love  
> 
>   * gcc.target/powerpc/divkc3-2.c: Add dg-require-effective-target
>   longdouble128.
>   * gcc.target/powerpc/divkc3-3.c: Ditto.
>   * gcc.target/powerpc/mulkc3-2.c: Ditto.
>   * gcc.target/powerpc/mulkc3-3.c: Ditto.
>   * gcc.target/powerpc/fold-vec-mergehl-double.c: Update counts.
>   * gcc.target/powerpc/pr85456.c: Make check Linux and AIX specific.

Re: [PATCH 1/4] Clean up of new format of -falign-FOO.

[Pat Haugen]

testsuite/gcc.target/powerpc/loop_align.c fails with this patch. It just needs 
a simple tweak to the scan-assembler line since we're no longer generating the 
",,31" portion on the .p2align.

-Pat

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions

[Thomas Koenig]

Am 16.07.2018 um 10:06 schrieb Janus Weil:

However, one point: I think that the warning should be under a separate
warning, which should then be enabled by -Wextra.
-Waggressive-function-elimination, could be reused for this,
or something else

I don't actually see such a flag in the manual.


Ah, sorry, I misremembered the option, it is actually
-Wfunction-elimination.

What I would suggest is to enable -Wfunction-eliminiation with
-Wextra and also use that for your new warning.

(I would also suggest to enable -faggressive-function-elimination
at least for -Ofast, but that is another matter).

Regards

Thomas

Targeted Global B2B Companies emails list

[carol . young]

Hi,

I just wanted to check if you would be interested in a list of Managed  
Service Providers (MSPs) and Managed Security Service Providers (MSSPs)?


We also have the data intelligence of:

•   Managed Service Providers (MSP’s) – 25,000 unique companies
•   Managed Security Service Providers (MSSP’s) – 7,520 unique companies
•   IT Decision Makers – 6million across all industry
•   Business Decision Makers – 10 million across all industry
•   Value Added Resellers- VARs
•   Independent Software Vendors- ISVs
•   System Integrators- SIs
•   VoIP Service Providers.
•   Telecommunications Service Providers (TSPs)
•   Application Service Providers (ASPs)
•   IT Managed Services Providers (ITMSP)
•   Storage Service Providers (SSPs)

Kindly review and let me know if I can share more information on this.

I look forward to hearing from you.

Regards,
Carol Young
Marketing Specialist

[PATCH] Make function clone name numbering independent.

[Michael Ploujnikov]

Hi,

This patch is a small part of the work I'm doing to make function 
codegen/assembly independent from one another as mentioned in: 
https://gcc.gnu.org/ml/gcc/2018-07/msg00210.html. It deals with clone_fn_id_num 
rather than object UIDs and I figured it's better to make my first submission 
with a smaller, simpler and self-contained patch.

This changes clone_function_name_1 such that clone names are based on a 
per-function rather than a global counter so that the number of clones of one 
function doesn't affect the numbering of clone names of other functions.

This should have minimal impact as the only user of the clone names that I 
found (https://gcc.gnu.org/ml/gcc/2013-03/msg00268.html) doesn't actually care 
about the specific numeric values.


Thanks
- Michael

gcc:
2018-07-16  Michael Ploujnikov  

   Make function clone name numbering independent.
   * cgraphclones.c: Replace clone_fn_id_num with clone_fn_ids.
   (clone_function_name_1): Use it.

testsuite:
2018-07-16  Michael Ploujnikov  

Clone id counters should be completely independent from one another.
* gcc/testsuite/gcc.dg/independent-cloneids-1.c: New test.


---
 gcc/cgraphclones.c| 11 ++--
 gcc/testsuite/gcc.dg/independent-cloneids-1.c | 38 +++
 2 files changed, 47 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/independent-cloneids-1.c

diff --git gcc/cgraphclones.c gcc/cgraphclones.c
index 69572b9..c5a40bd 100644
--- gcc/cgraphclones.c
+++ gcc/cgraphclones.c
@@ -528,7 +528,7 @@ cgraph_node::create_clone (tree new_decl, gcov_type 
gcov_count, int freq,
   return new_node;
 }
 
-static GTY(()) unsigned int clone_fn_id_num;
+static GTY(()) hash_map *clone_fn_ids;
 
 /* Return a new assembler name for a clone with SUFFIX of a decl named
NAME.  */
@@ -543,7 +543,14 @@ clone_function_name_1 (const char *name, const char 
*suffix)
   memcpy (prefix, name, len);
   strcpy (prefix + len + 1, suffix);
   prefix[len] = symbol_table::symbol_suffix_separator ();
-  ASM_FORMAT_PRIVATE_NAME (tmp_name, prefix, clone_fn_id_num++);
+  unsigned int *suffix_counter;
+  if (!clone_fn_ids) {
+/* Initialize the per-function counter hash table if this is the first 
call */
+clone_fn_ids = hash_map::create_ggc (1000);
+  }
+  suffix_counter = _fn_ids->get_or_insert(name);
+  ASM_FORMAT_PRIVATE_NAME (tmp_name, prefix, *suffix_counter);
+  *suffix_counter = *suffix_counter + 1;
   return get_identifier (tmp_name);
 }
 
diff --git gcc/testsuite/gcc.dg/independent-cloneids-1.c 
gcc/testsuite/gcc.dg/independent-cloneids-1.c
new file mode 100644
index 000..d723e20
--- /dev/null
+++ gcc/testsuite/gcc.dg/independent-cloneids-1.c
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fipa-cp -fipa-cp-clone -fdump-ipa-cp"  } */
+
+extern int printf (const char *, ...);
+
+static int __attribute__ ((noinline))
+foo (int arg)
+{
+  return 7 * arg;
+}
+
+static int __attribute__ ((noinline))
+bar (int arg)
+{
+  return arg * arg;
+}
+
+int
+baz (int arg)
+{
+  printf("%d\n", bar (3));
+  printf("%d\n", bar (4));
+  printf("%d\n", foo (5));
+  printf("%d\n", foo (6));
+  /* adding or removing the following call should not affect foo
+ function's clone numbering */
+  printf("%d\n", bar (7));
+  return foo (8);
+}
+
+/* { dg-final { scan-ipa-dump "Function bar.constprop.0" "cp" } } */
+/* { dg-final { scan-ipa-dump "Function bar.constprop.1" "cp" } } */
+/* { dg-final { scan-ipa-dump "Function bar.constprop.3" "cp" } } */
+/* { dg-final { scan-ipa-dump "Function foo.constprop.0" "cp" } } */
+/* { dg-final { scan-ipa-dump "Function foo.constprop.1" "cp" } } */
+/* { dg-final { scan-ipa-dump "Function foo.constprop.2" "cp" } } */
+/* { dg-final { scan-ipa-dump-not "Function foo.constprop.3" "cp" } } */
+/* { dg-final { scan-ipa-dump-not "Function foo.constprop.4" "cp" } } */
-- 
2.7.4



signature.asc
Description: OpenPGP digital signature

[Bug fortran/83184] Out of memory or ICE with option -fdec

[foreese at gcc dot gnu.org]

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

--- Comment #5 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 19:10:39 2018
New Revision: 262747

URL: https://gcc.gnu.org/viewcvs?rev=262747=gcc=rev
Log:
2018-07-16  Fritz Reese  

gcc/testsuite/ChangeLog:

PR fortran/83184
Backport from trunk.
* gfortran.dg/assumed_rank_14.f90: New testcase.
* gfortran.dg/assumed_rank_15.f90: New testcase.
* gfortran.dg/dec_structure_8.f90: Update error messages.
* gfortran.dg/dec_structure_23.f90: Update error messages.

gcc/fortran/ChangeLog:

PR fortran/83184
Backport from trunk.
* decl.c (match_old_style_init): Initialize locus of variable expr when
creating a data variable.
(match_clist_expr): Verify array is explicit shape/size before
attempting to allocate constant array constructor.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/assumed_rank_14.f90
  - copied unchanged from r262744,
trunk/gcc/testsuite/gfortran.dg/assumed_rank_14.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/assumed_rank_15.f90
  - copied unchanged from r262744,
trunk/gcc/testsuite/gfortran.dg/assumed_rank_15.f90
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/dec_structure_23.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/dec_structure_8.f90

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' modified)

[Bug fortran/83183] Out of memory with option -finit-derived

[foreese at gcc dot gnu.org]

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

--- Comment #4 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 18:59:44 2018
New Revision: 262746

URL: https://gcc.gnu.org/viewcvs?rev=262746=gcc=rev
Log:
2018-07-16  Fritz Reese  

Backport r262442 and r262743.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/expr.c
branches/gcc-8-branch/gcc/fortran/module.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' modified)

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[foreese at gcc dot gnu.org]

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

--- Comment #16 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 18:59:44 2018
New Revision: 262746

URL: https://gcc.gnu.org/viewcvs?rev=262746=gcc=rev
Log:
2018-07-16  Fritz Reese  

Backport r262442 and r262743.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/expr.c
branches/gcc-8-branch/gcc/fortran/module.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' modified)

[Bug fortran/86325] Error on valid code with pointer class components using -finit-derived

[foreese at gcc dot gnu.org]

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

--- Comment #3 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 18:59:44 2018
New Revision: 262746

URL: https://gcc.gnu.org/viewcvs?rev=262746=gcc=rev
Log:
2018-07-16  Fritz Reese  

Backport r262442 and r262743.

gcc/fortran/ChangeLog:

Backport from trunk:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.

PR fortran/83183
PR fortran/86325
* expr.c (class_allocatable, class_pointer, comp_allocatable,
comp_pointer): New helpers.
(component_initializer): Generate EXPR_NULL for allocatable or pointer
components. Do not generate initializers for components within
BT_CLASS.
Do not assign to comp->initializer.
(gfc_generate_initializer): Use new helpers; move code to generate
EXPR_NULL for class allocatable components into
component_initializer().

gcc/testsuite/ChangeLog:

Backport from trunk:

PR fortran/83183
PR fortran/86325
* gfortran.dg/init_flag_18.f90: New testcase.
* gfortran.dg/init_flag_19.f03: New testcase.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_18.f90
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_18.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/init_flag_19.f03
  - copied unchanged from r262442,
trunk/gcc/testsuite/gfortran.dg/init_flag_19.f03
Modified:
branches/gcc-8-branch/   (props changed)
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/expr.c
branches/gcc-8-branch/gcc/fortran/module.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-8-branch/
('svn:mergeinfo' modified)

[Bug fortran/82865] Option -fdec collides with PDT

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Fritz Reese  ---
Marking as resolved again since the 7-branch backport was reverted; the patch
is applied to trunk and 8-branch.

[Bug fortran/82173] [meta-bug] Parameterized derived type errors

[foreese at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173
Bug 82173 depends on bug 82865, which changed state.

Bug 82865 Summary: Option -fdec collides with PDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/86325] Error on valid code with pointer class components using -finit-derived

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83183,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86417
 Resolution|--- |FIXED

--- Comment #2 from Fritz Reese  ---
Fixed in r262442.

[Bug fortran/83184] Out of memory or ICE with option -fdec

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Fritz Reese  ---
Fixed in 262744.

Re: [PATCH, cvs] Clarify that powerpc64le-linux-gnu is a primary platform

[Jeff Law]

On 07/16/2018 12:30 PM, Bill Schmidt wrote:
> Hi,
> 
> I occasionally get questions about powerpc64le-linux-gnu being a primary 
> platform
> for GCC, since the release criteria don't specifically call it out (see
> https://gcc.gnu.org/gcc-8/criteria.html).  Currently powerpc64-linux-gnu (for
> big-endian) is listed instead, which is misleading.  I wonder if we could make
> it clearer that both endianness flavors are considered primary platforms.  One
> possibility is below, but I'd be happy with any other way of getting this 
> across.
> 
> Thanks for considering!
I think given the clearly stated direction for linux on power that we
should make ppc64le the primary target per your patch.

jeff

[Bug fortran/83183] Out of memory with option -finit-derived

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86417
 Resolution|--- |FIXED

--- Comment #3 from Fritz Reese  ---
Fixed in r262442 (note: exposed PR 86417, which has since been fixed as well in
r262743)

[PATCH, cvs] Clarify that powerpc64le-linux-gnu is a primary platform

[Bill Schmidt]

Hi,

I occasionally get questions about powerpc64le-linux-gnu being a primary 
platform
for GCC, since the release criteria don't specifically call it out (see
https://gcc.gnu.org/gcc-8/criteria.html).  Currently powerpc64-linux-gnu (for
big-endian) is listed instead, which is misleading.  I wonder if we could make
it clearer that both endianness flavors are considered primary platforms.  One
possibility is below, but I'd be happy with any other way of getting this 
across.

Thanks for considering!

Bill


Index: criteria.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/criteria.html,v
retrieving revision 1.2
diff -r1.2 criteria.html
110c110
< powerpc64-unknown-linux-gnu
---
> powerpc64{,le}-unknown-linux-gnu

[Bug target/86541] New: Use SSE to emulate __attribute__((vector_size(8)))

[rth at gcc dot gnu.org]

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

Bug ID: 86541
   Summary: Use SSE to emulate __attribute__((vector_size(8)))
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

In order to be more compatible across platforms, it would be
helpful if vector_size(8) was better supported for i386/x86_64.

The vast majority of the operations can be supported easily
with existing vector_size(16) instructions, and using either
(V)MOVQ to zero-extend the input or VPBROADCASTD/MOVDDUP to
replicate the input across the xmm register.

For integer operations it probably doesn't matter, but fp
operations would have different exception characteristics
with a zero-extension.  Replicating the inputs across the
lanes would avoid extra fp exceptions.

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Fritz Reese  ---
(In reply to janus from comment #13)
> (In reply to Fritz Reese from comment #12)
> > If we set the component's locus when it is loaded from a module, the
> > following patch fixes the issue and retains sane location information for
> > the component and its initializer:
> > 
> > diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
> > index b120501beb7..27d68f6b1b5 100644
> > --- a/gcc/fortran/module.c
> > +++ b/gcc/fortran/module.c
> > @@ -2848,6 +2848,8 @@ mio_component (gfc_component *c, int vtype)
> >if (c->attr.proc_pointer)
> >  mio_typebound_proc (>tb);
> >  
> > +  c->loc = gfc_current_locus;
> > +
> >mio_rparen ();
> >  }
> >  
> > [..]
> > 
> > I am currently running regression tests to verify these patches. If both
> > pass and I have not missed something obvious I would prefer adding location
> > info to the component when loading from a module (the first patch).
> 
> I agree that this is probably the best way to fix it. If the patch regtests
> well, it's ok for trunk from my side. Thanks for having a look!

Thanks for the confirmation. I have committed to trunk (without a new testcase,
as alloc-comp-3.f90 exposes the regression).

[Bug fortran/83184] Out of memory or ICE with option -fdec

[foreese at gcc dot gnu.org]

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

--- Comment #3 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 18:24:50 2018
New Revision: 262744

URL: https://gcc.gnu.org/viewcvs?rev=262744=gcc=rev
Log:
2018-07-16  Fritz Reese  

Fix handling of invalid assumed-shape/size arrays in legacy initializer
lists.

gcc/fortran/ChangeLog:

PR fortran/83184
* decl.c (match_old_style_init): Initialize locus of variable expr when
creating a data variable.
(match_clist_expr): Verify array is explicit shape/size before
attempting to allocate constant array constructor.

gcc/testsuite/ChangeLog:

PR fortran/83184
* gfortran.dg/assumed_rank_14.f90: New testcase.
* gfortran.dg/assumed_rank_15.f90: New testcase.
* gfortran.dg/dec_structure_8.f90: Update error messages.
* gfortran.dg/dec_structure_23.f90: Update error messages.


Added:
trunk/gcc/testsuite/gfortran.dg/assumed_rank_14.f90
trunk/gcc/testsuite/gfortran.dg/assumed_rank_15.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dec_structure_23.f90
trunk/gcc/testsuite/gfortran.dg/dec_structure_8.f90

[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522

[edlinger at gcc dot gnu.org]

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

--- Comment #5 from Bernd Edlinger  ---
FYI the patch for pr85528 does not contain the hunk from comment #3

I think it is probably more restrictive than necessary.

Happy hacking!

[Bug fortran/86417] [9 Regression] FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 (test for excess errors)

[foreese at gcc dot gnu.org]

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

--- Comment #14 from Fritz Reese  ---
Author: foreese
Date: Mon Jul 16 18:16:00 2018
New Revision: 262743

URL: https://gcc.gnu.org/viewcvs?rev=262743=gcc=rev
Log:
2018-07-16  Fritz Reese  

gcc/fortran/ChangeLog:

PR fortran/86417
* module.c (mio_component): Set component->loc when loading from
module.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c

Re: [RFC] Induction variable candidates not sufficiently general

[Kelvin Nilsen]

char *argv[]) {

  char *text_input = "this is some text that should be longer";
  unsigned long long int len_limit = strlen (text_input);
  int pos = 0;

  int cur_match = 0;
  int depth = 0;

  int result = bt_skip_func(len_limit, text_input + 3, (long long) 3, 
(unsigned long long) 1);
}
.file   "ivsimple.long.c"
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl bt_skip_func
.type   bt_skip_func, @function
bt_skip_func:
.LFB22:
.cfi_startproc
subf 5,5,4   # 13   [c=4 l=4]  *subfdi3
std 28,-32(1)# 107  [c=4 l=4]  *movdi_internal64/0
std 29,-24(1)# 108  [c=4 l=4]  *movdi_internal64/0
addi 8,6,1   # 14   [c=4 l=4]  *adddi3/1
std 30,-16(1)# 109  [c=4 l=4]  *movdi_internal64/0
std 31,-8(1) # 110  [c=4 l=4]  *movdi_internal64/0
.cfi_offset 28, -32
.cfi_offset 29, -24
.cfi_offset 30, -16
.cfi_offset 31, -8
addi 12,5,1  # 18   [c=4 l=4]  *adddi3/1
addi 30,5,2  # 29   [c=4 l=4]  *adddi3/1
addi 28,5,3  # 40   [c=4 l=4]  *adddi3/1
addi 11,4,1  # 19   [c=4 l=4]  *adddi3/1
addi 31,4,2  # 30   [c=4 l=4]  *adddi3/1
addi 29,4,3  # 41   [c=4 l=4]  *adddi3/1
b .L2# 153  [c=4 l=4]  jump
.p2align 4,,15
.L4:
lbzx 10,12,6 # 20   [c=8 l=4]  zero_extendqisi2/0
lbzx 7,11,6  # 21   [c=8 l=4]  zero_extendqisi2/0
cmpw 7,10,7  # 22   [c=4 l=4]  *cmpsi_signed
bne 7,.L5# 23   [c=4 l=4]  *rs6000.md:12311
beq 5,.L3# 27   [c=4 l=4]  *rs6000.md:12311
lbzx 10,30,6 # 31   [c=8 l=4]  zero_extendqisi2/0
lbzx 7,31,6  # 32   [c=8 l=4]  zero_extendqisi2/0
addi 8,8,4   # 51   [c=4 l=4]  *adddi3/1
cmpw 7,10,7  # 33   [c=4 l=4]  *cmpsi_signed
bne 7,.L3# 34   [c=4 l=4]  *rs6000.md:12311
addi 9,6,3   # 36   [c=4 l=4]  *adddi3/1
cmpld 7,3,9  # 37   [c=4 l=4]  *cmpdi_unsigned
beq 7,.L3# 38   [c=4 l=4]  *rs6000.md:12311
lbzx 10,28,6 # 42   [c=8 l=4]  zero_extendqisi2/0
lbzx 7,29,6  # 43   [c=8 l=4]  zero_extendqisi2/0
addi 6,6,4   # 47   [c=4 l=4]  *adddi3/1
cmpld 5,3,6  # 48   [c=4 l=4]  *cmpdi_unsigned
cmpw 7,10,7  # 44   [c=4 l=4]  *cmpsi_signed
bne 7,.L3# 45   [c=4 l=4]  *rs6000.md:12311
beq 5,.L6# 49   [c=4 l=4]  *rs6000.md:12311
lbzx 9,5,6   # 52   [c=8 l=4]  zero_extendqisi2/0
lbzx 10,4,6  # 53   [c=8 l=4]  zero_extendqisi2/0
cmpw 7,9,10  # 54   [c=4 l=4]  *cmpsi_signed
bne 7,.L7# 55   [c=4 l=4]  *rs6000.md:12311
.L2:
cmpld 7,3,8  # 59   [c=4 l=4]  *cmpdi_unsigned
addi 9,6,2   # 25   [c=4 l=4]  *adddi3/1
cmpld 5,3,9  # 26   [c=4 l=4]  *cmpdi_unsigned
bne 7,.L4# 60   [c=4 l=4]  *rs6000.md:12311
.L6:
mr 9,3   # 7[c=4 l=4]  *movdi_internal64/2
.L3:
ld 28,-32(1) # 113  [c=8 l=4]  *movdi_internal64/1
ld 29,-24(1) # 114  [c=8 l=4]  *movdi_internal64/1
ld 30,-16(1) # 115  [c=8 l=4]  *movdi_internal64/1
ld 31,-8(1)  # 116  [c=8 l=4]  *movdi_internal64/1
extsw 3,9# 69   [c=4 l=4]  extendsidi2/1
.cfi_remember_state
.cfi_restore 31
.cfi_restore 30
.cfi_restore 29
.cfi_restore 28
blr  # 118  [c=4 l=4]  simple_return
.p2align 4,,15
.L5:
.cfi_restore_state
ld 28,-32(1) # 131  [c=8 l=4]  *movdi_internal64/1
ld 29,-24(1) # 132  [c=8 l=4]  *movdi_internal64/1
ld 30,-16(1) # 133  [c=8 l=4]  *movdi_internal64/1
ld 31,-8(1)  # 134  [c=8 l=4]  *movdi_internal64/1
mr 9,8   # 8[c=4 l=4]  *movdi_internal64/2
extsw 3,9# 128  [c=4 l=4]  extendsidi2/1
.cfi_remember_state
.cfi_restore 31
.cfi_restore 30
.cfi_restore 29
.cfi_restore 28
blr  # 136  [c=4 l=4]  simple_return
.p2align 4,,15
.L7:
.cfi_restore_state
ld 28,-32(1) # 144  [c=8 l=4]  *movdi_internal64/1
ld 29,-24(1) # 145  [c=8 l=4]  *movdi_internal64/1
ld 30,-16(1) # 146  [c=8 l=4]  *movdi_internal64/1
ld 31,-8(1)  # 147  [c=8 l=4]  *movdi_internal64/1
mr 9,6   # 9[c=4 l=4]  *movdi_internal64/2
extsw 3,9# 141  [c=4 l=4]  extendsidi2/1
.cfi_restore 31
.cfi_restore 30
.cfi_restore 29
.cfi_restore 28
blr  # 149  [c=4 l=4]  simple_return
.long 0
.byte 0,0,0,0,0,4,0,0
.cfi_endproc
.LFE22:
.size   bt_skip_func,.-bt_skip_func

[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations

[edlinger at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 86528, which changed state.

Bug 86528 Summary: [9 Regression] strlen of constant string malfunction -- had 
to back out fix for PR middle-end/77357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86528

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/86528] [9 Regression] strlen of constant string malfunction -- had to back out fix for PR middle-end/77357

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Bernd Edlinger  ---
Thanks for reporting!

[Bug middle-end/86528] [9 Regression] strlen of constant string malfunction -- had to back out fix for PR middle-end/77357

[edlinger at gcc dot gnu.org]

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

--- Comment #6 from Bernd Edlinger  ---
Author: edlinger
Date: Mon Jul 16 18:03:15 2018
New Revision: 262742

URL: https://gcc.gnu.org/viewcvs?rev=262742=gcc=rev
Log:
gcc:
2018-07-16  Bernd Edlinger  

PR middle-end/86528
* builtins.c (check_access): Bail out if range[0] is no INTEGER_CST.
* expr.c (string_constant): Fix the element size of ARRAY_TYPE.

testsuite:
2018-07-16  Bernd Edlinger  

PR middle-end/86528
* gcc.c-torture/execute/pr86528.c: New test.
* gcc.dg/Wrestrict-10.c (test_arr_strcat_2): Fix typo.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr86528.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wrestrict-10.c

Re: [PATCH] Fix middle-end/86528

[Richard Biener]

On July 16, 2018 5:36:22 PM GMT+02:00, Bernd Edlinger 
 wrote:
>Hi,
>
>this fixes PR middle-end/86528.
>
>
>Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>Is it OK for trunk?

OK. 

Richard. 

>
>Thanks
>Bernd.

Re: [PATCH] Fix middle-end/86528

[Martin Sebor]

On 07/16/2018 09:36 AM, Bernd Edlinger wrote:

Hi,

this fixes PR middle-end/86528.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks -- the string_constant change also fixes bug 86532.

There is another problem in the subsequent handling of
the CONSTRUCTOR -- it ignores the non-constant VARIDX.  Fixing
that is easy but unfortunately prevents many strlen calls that
could be folded from folding (and makes the newly added tests
fail). For instance:

  static const char a[2][3] = { "1", "12" };
  if (strlen ([1][i]) > 2)
abort ();

That needs some other changes to handle.  Let me take care of
that.

Martin

[PATCH] scripts/create_testsuite_files: Fix typo in comment.

[Jonathan Wakely]

Committed to trunk.


commit 2a123b20c5bbb6b54d157281e2dbe546a28086f5
Author: Jonathan Wakely 
Date:   Mon Jul 16 18:41:31 2018 +0100

* scripts/create_testsuite_files: Fix typo in comment.

diff --git a/libstdc++-v3/scripts/create_testsuite_files 
b/libstdc++-v3/scripts/create_testsuite_files
index 2686c87273d..156304c2ad2 100755
--- a/libstdc++-v3/scripts/create_testsuite_files
+++ b/libstdc++-v3/scripts/create_testsuite_files
@@ -11,7 +11,7 @@
 # existing files are listed in "testsuite_files" in the output
 # directory.  Subsequent runs pull the list from that file, allowing
 # users to trim the list down to problematic tests, or just run
-# paticular directories or sub-directories of tests.
+# particular directories or sub-directories of tests.
 #
 # Selecting individual tests can also be done with RUNTESTFLAGS, but
 # that doesn't really do all that we are trying to accomplish here.

[Bug libstdc++/86537] std::less specialization for std::shared_ptr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk. This isn't a regression, so shouldn't be backported to the
release branches.

[Bug c++/86533] [9.0 regression] Compile error on valid code: error: no matching function for call to 'std::allocator::allocator(const _Tp_alloc_type&)' { return _Map_alloc_type(_M_get

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jonathan Wakely  ---
OK, thanks for confirming it.

[Bug tree-optimization/86520] AArch64: Two 8-bit accesses coalesced into a single 16-bit access

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #5 from Andrew Pinski  ---
(In reply to Stephen Warren from comment #4)
> Andrew,
> 
> > > any all Linaro gcc 7.x releases
> > 
> > Yes because they backported the patch which fixed this issue.
> 
> Given Richard's explanation, there is no bug in gcc, and hence there is no
> fix for Linaro to have back-ported. So, I'm confused exactly what your
> comment above means. What bug and back-ported fix are you referring to?

I am saying the opposite.  Linaro GCC 7 backported the improvement that does
the combining.  I read your summary as you were requesting the combining of the
stores and not complaining about them.

[Bug libstdc++/86537] std::less specialization for std::shared_ptr

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Jul 16 17:13:41 2018
New Revision: 262739

URL: https://gcc.gnu.org/viewcvs?rev=262739=gcc=rev
Log:
PR libstdc++/86537 remove less> partial specialization

The standard doesn't specify this partial specialization (it was
required after the changes in N2637 but then should have been removed
following LWG 1262). Its presence is observable because it causes
different results when operator< has been overloaded for a shared_ptr
specialization.

PR libstdc++/86537
* include/bits/shared_ptr.h (less>): Remove
non-standard partial specialization.
* include/bits/shared_ptr_base.h (_Sp_less): Remove class definition.
(less<__shared_ptr<_Tp, _Lp>): Remove partial specialization.
* testsuite/20_util/shared_ptr/comparison/86537.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/comparison/86537.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr.h
trunk/libstdc++-v3/include/bits/shared_ptr_base.h

[PATCH] PR libstdc++/86537 remove less> partial specialization

[Jonathan Wakely]

The standard doesn't specify this partial specialization (it was
required after the changes in N2637 but then should have been removed
following LWG 1262). Its presence is observable because it causes
different results when operator< has been overloaded for a shared_ptr
specialization.

PR libstdc++/86537
* include/bits/shared_ptr.h (less>): Remove
non-standard partial specialization.
* include/bits/shared_ptr_base.h (_Sp_less): Remove class definition.
(less<__shared_ptr<_Tp, _Lp>): Remove partial specialization.
* testsuite/20_util/shared_ptr/comparison/86537.cc: New test.

Tested powerpc64le-linux, committed to trunk.


commit 1c48999500e277c2ff1e742214857faef842f80c
Author: Jonathan Wakely 
Date:   Mon Jul 16 16:52:19 2018 +0100

PR libstdc++/86537 remove less> partial specialization

The standard doesn't specify this partial specialization (it was
required after the changes in N2637 but then should have been removed
following LWG 1262). Its presence is observable because it causes
different results when operator< has been overloaded for a shared_ptr
specialization.

PR libstdc++/86537
* include/bits/shared_ptr.h (less>): Remove
non-standard partial specialization.
* include/bits/shared_ptr_base.h (_Sp_less): Remove class 
definition.
(less<__shared_ptr<_Tp, _Lp>): Remove partial specialization.
* testsuite/20_util/shared_ptr/comparison/86537.cc: New test.

diff --git a/libstdc++-v3/include/bits/shared_ptr.h 
b/libstdc++-v3/include/bits/shared_ptr.h
index 2a54145083d..2a82f186328 100644
--- a/libstdc++-v3/include/bits/shared_ptr.h
+++ b/libstdc++-v3/include/bits/shared_ptr.h
@@ -480,10 +480,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 operator>=(nullptr_t, const shared_ptr<_Tp>& __a) noexcept
 { return !(nullptr < __a); }
 
-  template
-struct less> : public _Sp_less>
-{ };
-
   // 20.7.2.2.8 shared_ptr specialized algorithms.
   template
 inline void
diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h 
b/libstdc++-v3/include/bits/shared_ptr_base.h
index 887edbd7879..f3994da158f 100644
--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -1502,22 +1502,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 operator>=(nullptr_t, const __shared_ptr<_Tp, _Lp>& __a) noexcept
 { return !(nullptr < __a); }
 
-  template
-struct _Sp_less : public binary_function<_Sp, _Sp, bool>
-{
-  bool
-  operator()(const _Sp& __lhs, const _Sp& __rhs) const noexcept
-  {
-   typedef typename _Sp::element_type element_type;
-   return std::less()(__lhs.get(), __rhs.get());
-  }
-};
-
-  template
-struct less<__shared_ptr<_Tp, _Lp>>
-: public _Sp_less<__shared_ptr<_Tp, _Lp>>
-{ };
-
   // 20.7.2.2.8 shared_ptr specialized algorithms.
   template
 inline void
diff --git a/libstdc++-v3/testsuite/20_util/shared_ptr/comparison/86537.cc 
b/libstdc++-v3/testsuite/20_util/shared_ptr/comparison/86537.cc
new file mode 100644
index 000..c8440a38ad0
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/shared_ptr/comparison/86537.cc
@@ -0,0 +1,69 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run { target c++11 } }
+
+#include 
+#include 
+
+struct Should_not_happen { };
+
+struct X { };
+
+namespace std {
+  template<> struct less {
+bool operator()(X*, X*) const { throw Should_not_happen(); }
+  };
+}
+
+bool custom_op_called = false;
+
+bool
+operator<(const std::shared_ptr&, const std::shared_ptr&)
+{
+  custom_op_called = true;
+  return false;
+}
+
+void
+test01()
+{
+  const std::shared_ptr sp;
+  bool b = sp < sp;
+  VERIFY( !b );
+  VERIFY( custom_op_called );
+
+  std::less> lt;
+  custom_op_called = false;
+  b = lt(sp, sp);
+  VERIFY( !b );
+  VERIFY( custom_op_called ); // PR libstdc++/86537 and LWG DR 1262
+
+#if __cplusplus >= 201402L
+  std::less<> ltv;
+  custom_op_called = false;
+  b = ltv(sp, sp);
+  VERIFY( !b );
+  VERIFY( custom_op_called );
+#endif
+}
+
+int
+main()
+{
+  test01();
+}

Re: [GCC][PATCH][Aarch64] Exploiting BFXIL when OR-ing two AND-operations with appropriate bitmasks

[Sam Tebbs]

Hi Sudi,

Thanks for noticing that, I have attached an improved patch file that 
fixes this issue.


Below is an updated description and changelog:

This patch adds an optimisation that exploits the AArch64 BFXIL instruction
when or-ing the result of two bitwise and operations with non-overlapping
bitmasks (e.g. (a & 0x) | (b & 0x)).

Example:

unsigned long long combine(unsigned long long a, unsigned long long b) {
  return (a & 0xll) | (b & 0xll);
}

void read(unsigned long long a, unsigned long long b, unsigned long long 
*c) {

  *c = combine(a, b);
}

When compiled with -O2, read would result in:

read:
  and   x5, x1, #0x
  and   x4, x0, #0x
  orr   x4, x4, x5
  str   x4, [x2]
  ret

But with this patch results in:

read:
  mov    x4, x0
  bfxil    x4, x1, 0, 32
  str    x4, [x2]
  ret

Bootstrapped and regtested on aarch64-none-linux-gnu and 
aarch64-none-elf with no regressions.



gcc/
2018-07-11  Sam Tebbs  

    * config/aarch64/aarch64.md (*aarch64_bfxil, *aarch64_bfxil_alt):
    Define.
    * config/aarch64/aarch64-protos.h (aarch64_is_left_consecutive):
    Define.
    * config/aarch64/aarch64.c (aarch64_is_left_consecutive): New 
function.


gcc/testsuite
2018-07-11  Sam Tebbs  

    * gcc.target/aarch64/combine_bfxil.c: New file.
    * gcc.target/aarch64/combine_bfxil_2.c: New file.


On 07/16/2018 11:54 AM, Sudakshina Das wrote:

Hi Sam

On 13/07/18 17:09, Sam Tebbs wrote:

Hi all,

This patch adds an optimisation that exploits the AArch64 BFXIL 
instruction
when or-ing the result of two bitwise and operations with 
non-overlapping

bitmasks (e.g. (a & 0x) | (b & 0x)).

Example:

unsigned long long combine(unsigned long long a, unsigned long long b) {
   return (a & 0xll) | (b & 0xll);
}

void read2(unsigned long long a, unsigned long long b, unsigned long 
long *c,

   unsigned long long *d) {
   *c = combine(a, b); *d = combine(b, a);
}

When compiled with -O2, read2 would result in:

read2:
   and   x5, x1, #0x
   and   x4, x0, #0x
   orr   x4, x4, x5
   and   x1, x1, #0x
   and   x0, x0, #0x
   str   x4, [x2]
   orr   x0, x0, x1
   str   x0, [x3]
   ret

But with this patch results in:

read2:
   mov   x4, x1
   bfxil x4, x0, 0, 32
   str   x4, [x2]
   bfxil x0, x1, 0, 32
   str   x0, [x3]
   ret
   Bootstrapped and regtested on aarch64-none-linux-gnu and 
aarch64-none-elf with no regressions.


I am not a maintainer but I have a question about this patch. I may be 
missing something or reading

it wrong. So feel free to point it out:

+(define_insn "*aarch64_bfxil"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+    (ior:DI (and:DI (match_operand:DI 1 "register_operand" "r")
+            (match_operand 3 "const_int_operand"))
+        (and:DI (match_operand:DI 2 "register_operand" "0")
+            (match_operand 4 "const_int_operand"]
+  "INTVAL (operands[3]) == ~INTVAL (operands[4])
+    && aarch64_is_left_consecutive (INTVAL (operands[3]))"
+  {
+    HOST_WIDE_INT op4 = INTVAL (operands[4]);
+    operands[3] = GEN_INT (64 - ceil_log2 (op4));
+    output_asm_insn ("bfxil\\t%0, %1, 0, %3", operands);

In the BFXIL you are reading %3 LSB bits from operand 1 and putting it 
in the LSBs of %0.

This means that the pattern should be masking the 32-%3 MSB of %0 and
%3 LSB of %1. So shouldn't operand 4 is LEFT_CONSECUTIVE>

Can you please compare a simpler version of the above example you gave to
make sure the generated assembly is equivalent before and after the 
patch:


void read2(unsigned long long a, unsigned long long b, unsigned long 
long *c) {

  *c = combine(a, b);
}


From the above text

read2:
  and   x5, x1, #0x
  and   x4, x0, #0x
  orr   x4, x4, x5

read2:
  mov   x4, x1
  bfxil x4, x0, 0, 32

This does not seem equivalent to me.

Thanks
Sudi

+    return "";
+  }
+  [(set_attr "type" "bfx")]
+)

gcc/
2018-07-11  Sam Tebbs  

 * config/aarch64/aarch64.md (*aarch64_bfxil, 
*aarch64_bfxil_alt):

 Define.
 * config/aarch64/aarch64-protos.h 
(aarch64_is_left_consecutive):

 Define.
 * config/aarch64/aarch64.c (aarch64_is_left_consecutive): 
New function.


gcc/testsuite
2018-07-11  Sam Tebbs  

 * gcc.target/aarch64/combine_bfxil.c: New file.
 * gcc.target/aarch64/combine_bfxil_2.c: New file.






diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index 514ddc4..b025cd6 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -558,4 +558,6 @@ rtl_opt_pass *make_pass_fma_steering (gcc::context *ctxt);
 
 poly_uint64 aarch64_regmode_natural_size (machine_mode);
 
+bool aarch64_is_left_consecutive (HOST_WIDE_INT);
+
 #endif /* GCC_AARCH64_PROTOS_H */
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c

[Bug middle-end/86540] New: pr77445-2.c and ssa-dom-thread-7.c regressions since May 20, 2018

[sje at gcc dot gnu.org]

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

Bug ID: 86540
   Summary: pr77445-2.c and ssa-dom-thread-7.c regressions since
May 20, 2018
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

According to Christophe Lyon, Martin Liska is aware of these failures and will
fix them but I wanted to create a bug report to ensure they do not get
forgotten.

I see these regressions on aarch64 but I am not sure if they are platform
specific.

https://gcc.gnu.org/ml/gcc/2018-06/msg00289.html
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01479.html

[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86528

--- Comment #4 from Martin Sebor  ---
A reduced test case not involving loops is below.  There are a couple of places
in the constant_string() function where the handling of non-constant array
indices isn't correct and needs to be adjusted.  See also bug 86528.

static const char a[2][3] = { "1", "12" };
static const char b[2][2][5] = { { "1", "12" }, { "123", "1234" } };

int main ()
{
  {
volatile int i = 1;
int n = __builtin_strlen (a[i]);
n += __builtin_strlen (a[0]);

if (n != 3)
  __builtin_abort ();
  }

  {
 volatile int i = 1;
 int n = __builtin_strlen (b[1][i]);
 n += __builtin_strlen (b[1][0]);
 if (n != 7)
   __builtin_abort ();
  }
}

Re: [PATCH][GCC][AArch64] Updated stack-clash implementation supporting 64k probes. [patch (1/6)]

[Jeff Law]

On 07/16/2018 07:54 AM, Tamar Christina wrote:
> The 07/13/2018 17:46, Jeff Law wrote:
>> On 07/12/2018 11:39 AM, Tamar Christina wrote:
> +
> +  /* Round size to the nearest multiple of guard_size, and calculate the
> + residual as the difference between the original size and the rounded
> + size. */
> +  HOST_WIDE_INT rounded_size = size & -guard_size;
> +  HOST_WIDE_INT residual = size - rounded_size;
> +
> +  /* We can handle a small number of allocations/probes inline.  
> Otherwise
> + punt to a loop.  */
> +  if (rounded_size <= STACK_CLASH_MAX_UNROLL_PAGES * guard_size)
> +{
> +  for (HOST_WIDE_INT i = 0; i < rounded_size; i += guard_size)
> + {
> +   aarch64_sub_sp (NULL, temp2, guard_size, true);
> +   emit_stack_probe (plus_constant (Pmode, stack_pointer_rtx,
> +STACK_CLASH_CALLER_GUARD));
> + }
 So the only concern with this code is that it'll be inefficient and
 possibly incorrect for probe sizes larger than ARITH_FACTOR.
 Ultimately, that's a case I don't think we really care that much about.
 I wouldn't lose sleep if the port clamped the requested probing interval
 at ARITH_FACTOR.

>>> I'm a bit confused here, the ARITH_FACTOR seems to have to do with the Ada
>>> stack probing implementation, which isn't used by this new code aside
>>> from the part that emits the actual probe when doing a variable or large
>>> allocation in aarch64_output_probe_stack_range.
>>>
>>> Clamping the probing interval at ARITH_FACTOR means we can't do 64KB
>>> probing intervals. 
>> It may have been a misunderstanding on my part.  My understanding is
>> that ARITH_FACTOR represents the largest immediate constant we could
>> handle in this code using a single insn.  Anything above ARITH_FACTOR
>> needed a scratch register and I couldn't convince myself that we had a
>> suitable scratch register available.
>>
>> But I'm really not well versed on the aarch64 architecture or the
>> various implementation details in aarch64.c.  So I'm happy to defer to
>> you and others @ ARM on what's best to do here.
> 
> Ah no, that 12 bit immediate for str offset is unscaled. Scaled it's 15 bits 
> for the 64bit store case.
> So the actual limit is 32760, so it's quite a bit larger than ARITH_FACTOR.
> 
> The value of STACK_CLASH_CALLER_GUARD is fixed in the back-end and can't be
> changed, and if it's made too big will just give a compile error.
ACK.  Thanks for explaining.


> 
>>
>>
 That can be problematical in a couple cases.  First it can run afoul of
 combine-stack-adjustments.  Essentially that pass will combine a series
 of stack adjustments into a single insn so your unrolled probing turns
 into something like this:

   multi-page stack adjust
   probe first page
   probe second page
   probe third page
   and so on..

>>> This is something we actually do want, particularly in the case of 4KB pages
>>> as the immediates would fit in the store.  It's one of the things we were
>>> thinking about for future improvements.
>>>
 That violates the design constraint that we never allocate more than a
 page at a time.
>>> Would there be a big issue here if we didn't adhere to this constraint?
>> Yes, because it enlarges a window for exploitation.  Consider signal
>> delivery occurring after the adjustment but before the probes.  The
>> signal handler could then be running on a clashed heap/stack.
>>
> 
> Ah, you're quite right.. I didn't factor in asynchronous events during the 
> stack
> probing.  I have restored the barriers and added some documentation on why 
> they're
> needed.
Sounds good.


> 
>>>
 Do you happen to have a libc.so and ld.so compiled with this code?  I've
 got a scanner here which will look at a DSO and flag obviously invalid
 stack allocations.  If you've got a suitable libc.so and ld.so I can run
 them through the scanner.


 Along similar lines, have you run the glibc testsuite with this stuff
 enabled by default.  That proved useful to find codegen issues,
 particularly with the register inheritance in the epilogue.

>>> I'm running one now, I'll send the two binaries once I get the results back
>>> from the run. Thanks!
>> Great.  Looking forward getting those  .so files I can can throw them
>> into the scanner.
> 
> I have finished running the glibc testsuite and there were no new regressions.
Great.  And as mentioned privately, scanning looks reasonable.

So I've got no concerns at this point.  If the aarch64 maintainers are
OK with the changes this stuff can go in.

jeff

[Bug middle-end/86539] New: OpenMP wrong-code with taskloop and references

[jakub at gcc dot gnu.org]

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

Bug ID: 86539
   Summary: OpenMP wrong-code with taskloop and references
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

int a[384];

__attribute__((noipa)) void
foo (int , int )
{
  #pragma omp taskloop shared (a) collapse(3)
  for (int i = 0; i < 1; i++)
for (int *p =  p <  p++)
  for (int j = 0; j < 1; j++)
if (p < [128] || p >= [256])
  __builtin_abort ();
else
  p[0]++;
}

int
main ()
{
  #pragma omp parallel
  #pragma omp single
foo (a[128], a[256]);
  for (int i = 0; i < 384; i++)
if (a[i] != (i >= 128 && i < 256))
  __builtin_abort ();
  return 0;
}

is miscompiled with -fopenmp.  It internally wants to firstprivatize a few
temporaries, but as reference to pointer conversions are considered useless
during gimplification and later, the temporaries that are created for it have
reference type rather than pointer type.  Firstprivate clause with reference
type decls is handled by creating a new decl for what it points to as well as
the reference (pointer), rather than just privatizing the reference (pointer)
itself.

[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
Hi Martin,
how about:

--- gcc/expr.c.jj   2018-07-09 22:33:48.0 +0200
+++ gcc/expr.c  2018-07-16 17:18:47.919177047 +0200
@@ -11359,6 +11359,9 @@ string_constant (tree arg, tree *ptr_off
   return array;
 }

+  if (varidx != NULL_TREE)
+return NULL_TREE;
+
   if (!VAR_P (array) && TREE_CODE (array) != CONST_DECL)
 return NULL_TREE;

Re: [C++ Patch] Check permerror return value

[Nathan Sidwell]

On 07/16/2018 07:46 AM, Paolo Carlini wrote:

Hi,

over the last weeks, while working on various diagnostic issues, I 
noticed a few defective permerror + inform pairs. Tested x86_64-linux.




ok, thanks


--
Nathan Sidwell

[Bug c++/86533] [9.0 regression] Compile error on valid code: error: no matching function for call to 'std::allocator::allocator(const _Tp_alloc_type&)' { return _Map_alloc_type(_M_get

[juergen.reuter at desy dot de]

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

--- Comment #3 from Jürgen Reuter  ---
(In reply to Jonathan Wakely from comment #2)
> My best guess is that you've messed up your GCC installation, because
> _GLIBCXX20_CONSTEXPR should be defined in  like so:
> 
> #ifndef _GLIBCXX20_CONSTEXPR
> # if __cplusplus > 201703L
> #  define _GLIBCXX20_CONSTEXPR constexpr
> # else
> #  define _GLIBCXX20_CONSTEXPR
> # endif
> #endif
> 
> If you have a headers using that macro then you should have the definition
> of that macro too.
> 
> Without preprocessed source there's no way to tell.

Yes, indeed you are correct, the gcc build was screwed up. Sometimes when you
do svn up on the gcc trunk, it compiles including bootstrap, but there was an
incompatible change which you recognize later. The safer way is to always do a
completely new build instead of just an update. Sorry for the false alarm.

Re: [PATCH] [v3][aarch64] Avoid tag collisions for loads falkor

[Kyrill Tkachov]

Hi Siddhesh,

On 16/07/18 11:00, Siddhesh Poyarekar wrote:

Hi,

This is a rewrite of the tag collision avoidance patch that Kugan had
written as a machine reorg pass back in February.

The falkor hardware prefetching system uses a combination of the
source, destination and offset to decide which prefetcher unit to
train with the load.  This is great when loads in a loop are
sequential but sub-optimal if there are unrelated loads in a loop that
tag to the same prefetcher unit.

This pass attempts to rename the desination register of such colliding
loads using routines available in regrename.c so that their tags do
not collide.  This shows some performance gains with mcf and xalancbmk
(~5% each) and will be tweaked further.  The pass is placed near the
fag end of the pass list so that subsequent passes don't inadvertantly
end up undoing the renames.

A full gcc bootstrap and testsuite ran successfully on aarch64, i.e. it
did not introduce any new regressions.  I also did a make-check with
-mcpu=falkor to ensure that there were no regressions.  The couple of
regressions I found were target-specific and were related to scheduling
and cost differences and are not correctness issues.

Changes from v2:
- Ignore SVE instead of asserting that falkor does not support sve

Changes from v1:

- Fixed up issues pointed out by Kyrill
- Avoid renaming R0/V0 since they could be return values
- Fixed minor formatting issues.

2018-07-02  Siddhesh Poyarekar  
Kugan Vivekanandarajah  

* config/aarch64/falkor-tag-collision-avoidance.c: New file.
* config.gcc (extra_objs): Build it.
* config/aarch64/t-aarch64 (falkor-tag-collision-avoidance.o):
Likewise.
* config/aarch64/aarch64-passes.def
(pass_tag_collision_avoidance): New pass.
* config/aarch64/aarch64.c (qdf24xx_tunings): Add
AARCH64_EXTRA_TUNE_RENAME_LOAD_REGS to tuning_flags.
(aarch64_classify_address): Remove static qualifier.
(aarch64_address_info, aarch64_address_type): Move to...
* config/aarch64/aarch64-protos.h: ... here.
(make_pass_tag_collision_avoidance): New function.
* config/aarch64/aarch64-tuning-flags.def (rename_load_regs):
New tuning flag.


I think this looks ok now. You'll still need a maintainer to approve it though.

Thanks for iterating on this,
Kyrill


CC: james.greenha...@arm.com
CC: kyrylo.tkac...@foss.arm.com
---
  gcc/config.gcc|   2 +-
  gcc/config/aarch64/aarch64-passes.def |   1 +
  gcc/config/aarch64/aarch64-protos.h   |  49 +
  gcc/config/aarch64/aarch64-tuning-flags.def   |   2 +
  gcc/config/aarch64/aarch64.c  |  48 +-
  .../aarch64/falkor-tag-collision-avoidance.c  | 857 ++
  gcc/config/aarch64/t-aarch64  |   9 +
  7 files changed, 922 insertions(+), 46 deletions(-)
  create mode 100644 gcc/config/aarch64/falkor-tag-collision-avoidance.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 63162aab676..c66dda0770e 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -304,7 +304,7 @@ aarch64*-*-*)
extra_headers="arm_fp16.h arm_neon.h arm_acle.h"
c_target_objs="aarch64-c.o"
cxx_target_objs="aarch64-c.o"
-   extra_objs="aarch64-builtins.o aarch-common.o cortex-a57-fma-steering.o"
+   extra_objs="aarch64-builtins.o aarch-common.o cortex-a57-fma-steering.o 
falkor-tag-collision-avoidance.o"
target_gtfiles="\$(srcdir)/config/aarch64/aarch64-builtins.c"
target_has_targetm_common=yes
;;
diff --git a/gcc/config/aarch64/aarch64-passes.def 
b/gcc/config/aarch64/aarch64-passes.def
index 87747b420b0..f61a8870aa1 100644
--- a/gcc/config/aarch64/aarch64-passes.def
+++ b/gcc/config/aarch64/aarch64-passes.def
@@ -19,3 +19,4 @@
 .  */
  
  INSERT_PASS_AFTER (pass_regrename, 1, pass_fma_steering);

+INSERT_PASS_AFTER (pass_machine_reorg, 1, pass_tag_collision_avoidance);
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 87c6ae20278..0a4558c2023 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -283,6 +283,49 @@ struct tune_params
const struct cpu_prefetch_tune *prefetch;
  };
  
+/* Classifies an address.

+
+   ADDRESS_REG_IMM
+   A simple base register plus immediate offset.
+
+   ADDRESS_REG_WB
+   A base register indexed by immediate offset with writeback.
+
+   ADDRESS_REG_REG
+   A base register indexed by (optionally scaled) register.
+
+   ADDRESS_REG_UXTW
+   A base register indexed by (optionally scaled) zero-extended register.
+
+   ADDRESS_REG_SXTW
+   A base register indexed by (optionally scaled) sign-extended register.
+
+   ADDRESS_LO_SUM
+   A LO_SUM rtx with a base register and "LO12" symbol relocation.
+
+   ADDRESS_SYMBOLIC:
+   A constant symbolic address, in pc-relative literal pool.  */
+
+enum 

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

[qing.zhao at oracle dot com]

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

--- Comment #3 from Qing Zhao  ---
> --- Comment #2 from seurer at gcc dot gnu.org ---
> What system are you testing on?  I've seen the same failure on power 8 and
> power 9 LE systems and power 7 and power 8 BE systems.

I am using the GCC farm machine gcc110:
[qinzhao@gcc1-power7 ~]$ uname -a
Linux gcc1-power7.osuosl.org 3.10.0-514.26.2.el7.ppc64 #1 SMP Mon Jul 10
02:26:53 GMT 2017 ppc64 ppc64 ppc64 GNU/Linux
let me know this is not the right machine to repeat the error.

[Bug libstdc++/86537] std::less specialization for std::shared_ptr

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The changes from lwg 1262 were implemented by r171293 but we never got rid of
the partial specialization of std::less.

Re: [2/2] Add AddressSanitizer annotations to std::string.

[Mikhail Kashkarov]

Rebased and update patch (typos, add missing annotations),
add ASan teststo verify string annotation.


On 06/28/2018 11:09 AM, Mikhail Kashkarov wrote:
> ^ gentle ping.
>
>
> On 06/08/2018 05:54 PM, Mikhail Kashkarov wrote:
>> Hello,
>>
>> I've updated patches for std::string sanitization and disabling CXX11
>> string SSO usage for correct sanitization.
>>
>>>>       _M_destroy(_M_allocated_capacity);
>>>>+    else
>>>>+      __annotate_delete();
>>>
>>>Do these calls definitely optimize away completely when not
>>>sanitizing? Even for -O1, -Os and -Og?
>>>
>>>For std::vector annotation I used macros to add these annotations, so
>>>there is no change to the generated code when annotations are
>>>disabled. But it makes the code quite ugly.
>>
>> I've checked asm code for string-inst.o and it looks like this calls are
>> optimized away, but there are some light changes after patch fir .
>>
>>> Right, I was wondering specifically about the 
>>> instantiations. I could be wrong but I don't think anything in
>>>  creates, destroys or modifies a std::basic_string.
>>
>> I was confused by reinterpret_cast's on strings in fstream.tcc, looks
>> like this is not needed, you are right.
>>
>>>>   // calling 4.0.x+ _S_create.
>>>>   __p->_M_set_sharable();
>>>>+#if _GLIBCXX_SANITIZER_ANNOTATE_STRING
>>>>+  __p->_M_length = 0;
>>>>+#endif
>>>
>>> Why is this needed? I think a comment explaining it would help (like
>>> the one above explaining why calling _M_set_sharable() is needed).
>>
>> Checked current version without this change, looks like now it works,
>> reverted.
>>
>> Short summary:
>> The reason for changing strings layout under sanitization is to place string
>> char buffer on heap for correct aligning in 32-bit environments,
>> both pre-CXX11 and CXX11 strings ABI.
>>
>> | Sanitize string | string type | ABI is changed? | 32-bit | 64-bit |
>> |-+-+-++|
>> | FULL    | SSO-string  | yes | +  | +  |
>> | | COW-string  | yes | +  | +  |
>> |-+-+-++|
>> | PARTIAL | SSO-string  | no  | -+(*)  | +  |
>> | | COW-string  | no  | -  | +  |
>> *only longs strings are sanitized for 32-bit
>>
>> Some functions with new define looks a bit messy without changing internal
>> functions(operator=), I'm also not sure if disabling string SSO usage define
>> should also affects other parts that relies on basic_string class size
>> (checks
>> with static_assert in exceptions/shim-facets).
>>
>>
>> Any thoughts?
>>
>> On 05/29/2018 06:55 PM, Jonathan Wakely wrote:
>>> On 29/05/18 18:18 +0300, Kashkarov Mikhail wrote:
 Jonathan Wakely  writes:
>> --- a/libstdc++-v3/include/bits/fstream.tcc
>> +++ b/libstdc++-v3/include/bits/fstream.tcc
>> @@ -1081,6 +1081,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>
>>     // Inhibit implicit instantiations for required instantiations,
>>     // which are defined via explicit instantiations elsewhere.
>> +#if !_GLIBCXX_SANITIZE_STRING
>> #if _GLIBCXX_EXTERN_TEMPLATE
>>     extern template class basic_filebuf;
>>     extern template class basic_ifstream;
>> @@ -1094,6 +1095,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>     extern template class basic_fstream;
>> #endif
>> #endif
>> +#endif // !_GLIBCXX_SANITIZE_STRING
> Why do we need to disable these explicit instantiation declarations?
> Are they affected by the std::string layout changes? Is that just
> because of the constructors taking std::string, or something else?
 Libstdc++ build is not sanitized, so macroses that requires
 AddressSanitizer support will not applied and these templates will be
 instantate without support for ASan annotations.
>>> Right, I was wondering specifically about the 
>>> instantiations. I could be wrong but I don't think anything in
>>>  creates, destroys or modifies a std::basic_string.
>>>
>>>
>>>
>>>
>>>

-- 
Best regards,
Kashkarov Mikhail
Samsung R Institute Russia

From c08b3073e8d7d785425e972a0381cbbb9e3c2f58 Mon Sep 17 00:00:00 2001
From: Mikhail Kashkarov 
Date: Fri, 8 Jun 2018 14:11:11 +0300
Subject: [PATCH 2/3] Add AddressSanitizer annotations to std::string.

	* include/bits/c++config: define
	(_GLIBCXX_SANITIZE_STRING_PARTIAL, _GLIBCXX_SANITIZE_STRING_FULL)
	(_GLIBCXX_SANTIZE_STRING, _GLIBCXX_SANITIZER_ANNOTATE_STRING)
	(_GLIBCXX_SANITIZER_DISABLE_LOCAL_STRING_ANNOTATION)
	(_GLIBCXX_SANITIZER_ALIGN_COW_STRING)
	* doc/xml/manual/using.xml: document GLIBCXX_SANITIZE_STRING_PARTIAL,
	_GLIBCXX_SANITIZE_STRING_FULL
	* include/bits/basic_string.h [_GLIBCXX_USE_DUAL_ABI]
	(_asan_traits<_CharT, _Alloc>, _asan_traits<_CharT, allocator<_CharT>)
	(_asan_traits::__annotate_delete, 

[Bug libstdc++/86537] std::less specialization for std::shared_ptr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
I added the partial specialization in r141512 to meet the updated requirements
in https://wg21.link/n2637 in particular:

For templates greater, less, greater_equal, and less_equal,
the partial specializations for shared_ptr yield a total order,
even if the built-in operators <, >, <=, >= do not.  Moreover,
less >::operator()(a, b) shall return
std::less::operator()(a.get(), b.get()).

However, https://wg21.link/lwg1262 replaced that wording and removed the need
for a partial specialization of std::less. Despite filing that issue myself I
apparently never fixed GCC.

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Nathan Sidwell]

On 07/16/2018 12:04 PM, Richard Biener wrote:


Just use a spare bit in function_decl, then we can simply stream it.


If there's one, then sure.  (you've reminded me that there are a bunch 
of mutually disjoint flags in function_decl that could be collapsed to 
an enumeration.  This may be another such bit.)


nathan

--
Nathan Sidwell

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Richard Biener]

On July 16, 2018 4:30:42 PM GMT+02:00, Nathan Sidwell  wrote:
>On 07/16/2018 03:23 AM, Martin Liška wrote:
>> Hi.
>> 
>> For purpose of --coverage I would like to distinguish lambda
>functions
>> among DECL_ARTIFICIAL functions. Currently, cp-tree.h provides macro:
>> 
>> /* Test if FUNCTION_DECL is a lambda function.  */
>> #define LAMBDA_FUNCTION_P(FNDECL)\
>>(DECL_DECLARES_FUNCTION_P (FNDECL)\
>> && DECL_OVERLOADED_OPERATOR_P (FNDECL)   \
>> && DECL_OVERLOADED_OPERATOR_IS (FNDECL, CALL_EXPR)   \
>> && LAMBDA_TYPE_P (CP_DECL_CONTEXT (FNDECL)))
>> 
>> That's FE-specific function that probably should not be called from
>> middle-end. Any idea how to distinguish lambdas?
>
>You're going to need a language hook.  Lambda fns are just regular 
>member fns outside the front-end.  Make the hook more than 
>'lambda_fn_p', so it can extend to other exciting C++ features. 
>Perhaps 
>something like:
>
>enum synthetic_fn_kind {
>   sfk_none,
>   sfk_cxx_lambda,
>};
>synthetic_fn_kind (*categorize_artificial_fn) (tree decl);
>
>We'll have to expose the union of FE's such sythetic fns to the middle 
>end, but at least not how the FE distinguishes them.
>
>Hm, but isn't this info lost if we're in LTO at this point?  Not sure
>if 
>we'll need to propagate this through the LTO streaming.  I guess that's
>
>a later bug to handle though.

Just use a spare bit in function_decl, then we can simply stream it. 

Richard. 

>nathan

[Bug target/86538] New: GCC should define a macro to specify if LSE is enabled or not

[sje at gcc dot gnu.org]

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

Bug ID: 86538
   Summary: GCC should define a macro to specify if LSE is enabled
or not
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

Right now there is no predefined macro in GCC that can tell if LSE is enable or
not.  If you compile with -march=armv8.1-a+lse or -march=armv8.1-a+nolse you
get the same set of predefined macros and so there is no way a user can tell
if they can/should use LSE instructions.  Other features (CRYPTO, RDMA, SVE,
AES, SHA, etc. do have macros associated with  them.   (See
aarch64_update_cpp_builtins in gcc/config/aarch64/aarch64-c.c)

[Bug middle-end/86505] [6/7/8/9 Regression] __builtin_va_arg_pack_len() computes the number of arguments wrongly

[rpirrera at aitek dot it]

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

--- Comment #2 from rpirrera at aitek dot it ---
Any news on the fix?

Targetted B2B companies contact list

[laruel . horton]

Hi,

Would you be interested in Bentley Systems Users List for your sales and  
marketing campaigns?


We can provide you Database from North America, Latin America, EMEA, and  
APAC.


Information Fields – Name, Title, Email, Phone Numbers, Company Name, and  
Company Details like Physical Address, Web Address, Revenue Size, Employee  
Size and industry.


Below are the few targeted lists you might be interested: Autodesk,  
Keynote, Intergraph, Oracle, Jasper soft, SAP Business Objects, IBM Cognos,  
TIBCO Spotfire, Hadoop, Oracle BI, Sisense and Many more.


Bentley Systems Specialties: Bentley MXROAD, Bentley Architecture, Bentley  
Map, Bentley InRoads, CulvertMaster,


Please review and let me know if you are interested and I will get back to  
you with more information for the same.


Regards,

Laruel Horton
Demand Generation-Database Coordinator

To opt-out response ‘Remove’ in the subject line.

[Bug c++/86533] [9.0 regression] Compile error on valid code: error: no matching function for call to 'std::allocator::allocator(const _Tp_alloc_type&)' { return _Map_alloc_type(_M_get

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
My best guess is that you've messed up your GCC installation, because
_GLIBCXX20_CONSTEXPR should be defined in  like so:

#ifndef _GLIBCXX20_CONSTEXPR
# if __cplusplus > 201703L
#  define _GLIBCXX20_CONSTEXPR constexpr
# else
#  define _GLIBCXX20_CONSTEXPR
# endif
#endif

If you have a headers using that macro then you should have the definition of
that macro too.

Without preprocessed source there's no way to tell.

[Bug libstdc++/86537] std::less specialization for std::shared_ptr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-16
Version|4.8.5   |8.1.0
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
N.B. GCC 4.8.5 has been unsupported for years, bugs will only be addressed for
supported versions.

I'm confirming this as a bug, the testcase shows non-conformance IMHO.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
Can you attach a copy of the generated file gen-sysinfo.go?

What does the definition of, say, cmsghdr look like in  (or some
header file included by that one)?