Re: [2/5] C-SKY port: Backend implementation

[Sandra Loosemore]

On 07/26/2018 12:06 AM, 瞿仙淼 wrote:


I wrote a case to reproduce this problem on C-SKY. C code is as follows:
---
int e1, e2;

void func (int a, int b, int c, int d, int f, int g)
{
   e1 = a > b ? f : g;
   e2 = a > b ? c : d;

   return;
}
---

compile to assembler with option “-O3 -S” :
---
func:
   cmplt a1, a0
   ld.w  t1, (sp, 0)
   ld.w  t0, (sp, 4)
   movt  t0, t1
   cmplt a1, a0
   movt  a3, a2
   lrw a1, e2
   lrw a2, e1
   st.w  a3, (a1, 0)
   st.w  t0, (a2, 0)
   rts
---
There is an extra “cmplt a1, a0" in the above code without cse_cc. This 
situation mainly occurs when a relatively short branch jump is converted into a 
conditional execution instruction. And the CSE pass can not reduce the same 
conditional comparison instruction . Here is the rtx sequence after “cse2” pass.

---
(insn 28 13 29 2 (set (reg:CC 33 c)
 (gt:CC (reg/v:SI 77 [ a ])
 (reg/v:SI 78 [ b ]))) func.c:5 1099 {*cmpgtsi}
  (nil))
(insn 29 28 30 2 (set (reg/v:SI 82 [ g ])
 (if_then_else:SI (eq (reg:CC 33 c)
 (const_int 0 [0]))
 (reg/v:SI 82 [ g ])
 (reg/v:SI 81 [ f ]))) func.c:5 983 {movf}
  (expr_list:REG_DEAD (reg/v:SI 81 [ f ])
 (expr_list:REG_DEAD (reg:CC 33 c)
 (nil
(insn 30 29 31 2 (set (reg:CC 33 c)
 (gt:CC (reg/v:SI 77 [ a ])
 (reg/v:SI 78 [ b ]))) func.c:5 1099 {*cmpgtsi}
  (expr_list:REG_DEAD (reg/v:SI 78 [ b ])
 (expr_list:REG_DEAD (reg/v:SI 77 [ a ])
 (nil
(insn 31 30 18 2 (set (reg/v:SI 80 [ d ])
 (if_then_else:SI (eq (reg:CC 33 c)
 (const_int 0 [0]))
 (reg/v:SI 80 [ d ])
 (reg/v:SI 79 [ c ]))) func.c:5 983 {movf}
  (expr_list:REG_DEAD (reg/v:SI 79 [ c ])
 (expr_list:REG_DEAD (reg:CC 33 c)
 (nil
---

It doesn't seem to check the same conditional comparison instruction .So I 
wrote this to solve this problem, but I am not sure if this is the best way : )

PS, the same conditional comparison instruction cannot be reduced with the 
latest version gcc with C-SKY because I just insert the “cse_cc” after “cse1”, 
when I insert after “cse2”, this problem can be solved very well.


Thanks, this is very helpful.  I've verified this and I'm moving the 
pass as you suggest, adding a more detailed comment to the source to 
explain what the pass is for, and adding your test case to the 
testsuite.  This will be included when I resubmit the patches to address 
other review comments too.


Jeff, does that adequately address your concerns about whether the pass 
is useful?


-Sandra

Re: [RFC] Fix recent popcount change is breaking

[Kugan Vivekanandarajah]

Hi,

On 28 July 2018 at 01:13, Richard Biener  wrote:
> On July 27, 2018 3:33:59 PM GMT+02:00, "Martin Liška"  wrote:
>>On 07/11/2018 02:31 PM, Richard Biener wrote:
>>> Why not simply make popcountdi available in the kernel?  They do have
>>> implementations for other libgcc functions IIRC.
>>
>>Can you please Kugan create Linux kernel bug for that? So that
>>discussion
>>can happen?
>
> There's no discussion necessary, libgcc is the core compiler runtime. If you 
> choose not to use it you have to provide your own implementation.

Created a bug against kernel at
https://bugzilla.kernel.org/show_bug.cgi?id=200671

Thanks,
Kugan
>
> Richard.
>
>>Thanks,
>>Martin
>

New German PO file for 'gcc' (version 8.2.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/gcc/de.po

(This file, 'gcc-8.2.0.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [patch] improve internals documentation for nested function descriptors

[Sandra Loosemore]

On 07/27/2018 03:44 PM, Eric Botcazou wrote:

Apropos of the discussion about improving the docs for
TARGET_CUSTOM_FUNCTION_DESCRIPTORS in the context of the C-SKY port
submission,

https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01454.html

here is the patch I've come up with based on reading the source.  Is
this technically accurate?  Any suggestions on how to improve it further?


""Define this hook to 0 if the target implements custom support"

"custom" was precisely chosen to distinguish this kind of descriptors from the
standard descriptors used on IA-64 or HP-PA, so it's contradictory.  Moreover
I would really start with the "custom" case and not the standard case as was
originally written, the "custom" case being the common case for targets.


This is precisely what I found so confusing about the original text.  To 
me, "custom" implies that the back end is *customized* to have its own 
descriptor implementation to conform to target-specific ABI standards, 
not that it uses a generic implementation in common code.



I'm not really convinced by the substitution misalignment -> tag either, but
if others find the new version more understandable, then OK with me.


I could make the docs say both things, but from the perspective of a 
back end implementor, being explicit that it's a bit mask used to 
differentiate descriptors from any valid function pointer (so you can 
figure out what an appropriate value to define it to is) is more 
critical than describing what target-independent code does with a 
descriptor once it has identified that's what it's got.


-Sandra

Re: [PATCH], Remove undocumented -mtoc-fusion from PowerPC

[Michael Meissner]

On Wed, Jul 18, 2018 at 05:59:50PM -0500, Segher Boessenkool wrote:
> Hi Mike,
> 
> On Fri, Jul 13, 2018 at 04:56:13PM -0400, Michael Meissner wrote:
> > This means rather than keeping the toc fusion around (that nobody used), I
> > would prefer to delete the current code, and replace it with better code as 
> > I
> > implement it.
> 
> 
> > +++ gcc/config/rs6000/constraints.md(working copy)
> 
> > +;; wG is now available.  Previously it was a memory operand suitable for 
> > TOC
> > +;; fusion.
> 
> There are many other constraints unused.  Keep track of all, instead?
> Like we have (at the top of this file)
> ;; Available constraint letters: e k q t u A B C D S T
> you could do something similar for the "w" names.

I just deleted the comment, and reworded the other comment.  Here is the
changes I committed:

2018-07-27  Michael Meissner  

* config/rs6000/constraints.md (wG constraint): Delete, no longer
used.
* config/rs6000/predicates.md (p9_fusion_reg_operand): Rename
predicate to reflect toc fusion has been deleted.
(toc_fusion_mem_raw): Delete, no longer used.
(toc_fusion_mem_wrapped): Likewise.
* config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Delete toc
fusion mask bit.
* config/rs6000/rs6000-protos.h (fusion_wrap_memory_address):
Delete, no longer used.
* config/rs6000/rs6000.c (struct rs6000_reg_addr): Delete fields
meant to be used for toc fusion.
(rs6000_debug_print_mode): Delete toc fusion debugging.
(rs6000_debug_reg_global): Likewise.
(rs6000_init_hard_regno_mode_ok): Delete setting up fields for toc
fusion and secondary reload support that were never used.
(rs6000_option_override_internal): Delete TOC fusion, that was only
partially defined, and it did not work unless you also used the
-mcmodel= switch.
(rs6000_legitimate_address_p): Delete TOC fusion support.
(rs6000_opt_masks): Likewise.
(fusion_wrap_memory_address): Delete function, no longer used.
(fusion_split_address); Delete TOC fusion support.
* config/rs6000/rs6000.h (TARGET_TOC_FUSION_INT): Delete, no
longer used with toc fusion being deleted.
(TARGET_TOC_FUSION_FP): Likewise.
* config/rs6000/rs6000.md (UNSPEC_FUSION_ADDIS): Delete TOC fusion
UNSPEC.
(toc fusion spliter): Delete TOC fusion support.
(toc_fusionload_): Likewise.
(toc_fusionload_di): Likewise.
(fusion_gpr_load_): Delete generator function, this insn no
longer needs to be named.  Rename predicate to delete TOC fusion.
(fusion_gpr___load): Likewise.
(fusion_gpr___store): Likewise.
(fusion_vsx___load): Likewise.
(fusion_vsx___store): Likewise.
(p9 fusion peephole2s): Rename predicate to delete TOC fusion.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/constraints.md
===
--- gcc/config/rs6000/constraints.md(revision 263034)
+++ gcc/config/rs6000/constraints.md(working copy)
@@ -157,11 +157,6 @@ (define_memory_constraint "wF"
   "Memory operand suitable for power9 fusion load/stores"
   (match_operand 0 "fusion_addis_mem_combo_load"))
 
-;; Fusion gpr load.
-(define_memory_constraint "wG"
-  "Memory operand suitable for TOC fusion memory references"
-  (match_operand 0 "toc_fusion_mem_wrapped"))
-
 (define_register_constraint "wH" "rs6000_constraints[RS6000_CONSTRAINT_wH]"
   "Altivec register to hold 32-bit integers or NO_REGS.")
 
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 263034)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -406,13 +406,11 @@ (define_predicate "fpr_reg_operand"
   return FP_REGNO_P (r);
 })
 
-;; Return true if this is a register that can has D-form addressing (GPR and
-;; traditional FPR registers for scalars).  ISA 3.0 (power9) adds D-form
-;; addressing for scalars in Altivec registers.
-;;
-;; If this is a pseudo only allow for GPR fusion in power8.  If we have the
-;; power9 fusion allow the floating point types.
-(define_predicate "toc_fusion_or_p9_reg_operand"
+;; Return true if this is a register that can has D-form addressing (GPR,
+;; traditional FPR registers, and Altivec registers for scalars).  Unlike
+;; power8 fusion, this fusion does not depend on putting the ADDIS instruction
+;; into the GPR register being loaded.
+(define_predicate "p9_fusion_reg_operand"
   (match_code "reg,subreg")
 {
   HOST_WIDE_INT r;
@@ -1664,35 +1662,6 @@ (define_predicate "small_toc_ref"
   return GET_CODE (op) == UNSPEC && XINT (op, 1) == UNSPEC_TOCREL;
 })
 
-;; Match the TOC memory operand that can be fused with an addis instruction.

[PATCH 2/5] dumpfile.c: eliminate special-casing of dump_file/alt_dump_file

[David Malcolm]

With the addition of optinfo, the various dump_* calls had three parts:
- optionally print to dump_file
- optionally print to alt_dump_file
- optionally make an optinfo_item and add it to the pending optinfo,
  creating it for dump_*_loc calls.

However, this split makes it difficult to implement the formatted dumps
later in patch kit, so as enabling work towards that, this patch removes
the above split, so that all dumping within the dump_* API goes through
optinfo_item.

In order to ensure that the dumps to dump_file and alt_dump_file are
processed immediately (rather than being buffered within the pending
optinfo for consolidation), this patch introduces the idea of "immediate"
optinfo_item destinations vs "non-immediate" destinations.

The patch also adds selftest coverage of what's printed, and of scopes.

This adds two allocations per dump_* call when dumping is enabled.
I'm assuming that this isn't a problem, as dump_enabled_p is normally
false.  There are ways of optimizing it if it is an issue (by making
optinfo_item instances become temporaries that borrow the underlying
buffer), but they require nontrivial changes, so I'd prefer to leave
that for another patch kit, if it becomes necessary.

gcc/ChangeLog:
* dump-context.h: Include "pretty-print.h".
(dump_context::refresh_dumps_are_enabled): New decl.
(dump_context::emit_item): New decl.
(class dump_context): Add fields "m_test_pp" and
"m_test_pp_flags".
(temp_dump_context::temp_dump_context): Add param "test_pp_flags".
(temp_dump_context::get_dumped_text): New decl.
(class temp_dump_context): Add field "m_pp".
* dumpfile.c (refresh_dumps_are_enabled): Convert to...
(dump_context::refresh_dumps_are_enabled): ...and add a test for
m_test_pp.
(set_dump_file): Update for above change.
(set_alt_dump_file): Likewise.
(dump_loc): New overload, taking a pretty_printer *.
(dump_context::dump_loc): Call end_any_optinfo.  Dump the location
to any test pretty-printer.
(make_item_for_dump_gimple_stmt): New function, adapted from
optinfo::add_gimple_stmt.
(dump_context::dump_gimple_stmt): Call it, and use the result,
eliminating the direct usage of dump_file and alt_dump_file in
favor of indirectly using them via emit_item.
(make_item_for_dump_gimple_expr): New function, adapted from
optinfo::add_gimple_expr.
(dump_context::dump_gimple_expr): Call it, and use the result,
eliminating the direct usage of dump_file and alt_dump_file in
favor of indirectly using them via emit_item.
(make_item_for_dump_generic_expr): New function, adapted from
optinfo::add_tree.
(dump_context::dump_generic_expr): Call it, and use the result,
eliminating the direct usage of dump_file and alt_dump_file in
favor of indirectly using them via emit_item.
(make_item_for_dump_printf_va): New function, adapted from
optinfo::add_printf_va.
(make_item_for_dump_printf): New function.
(dump_context::dump_printf_va): Call make_item_for_dump_printf_va,
and use the result, eliminating the direct usage of dump_file and
alt_dump_file in favor of indirectly using them via emit_item.
(make_item_for_dump_dec): New function.
(dump_context::dump_dec): Call it, and use the result,
eliminating the direct usage of dump_file and alt_dump_file in
favor of indirectly using them via emit_item.
(make_item_for_dump_symtab_node): New function, adapted from
optinfo::add_symtab_node.
(dump_context::dump_symtab_node): Call it, and use the result,
eliminating the direct usage of dump_file and alt_dump_file in
favor of indirectly using them via emit_item.
(dump_context::begin_scope): Reimplement, avoiding direct usage
of dump_file and alt_dump_file in favor of indirectly using them
via emit_item.
(dump_context::emit_item): New member function.
(temp_dump_context::temp_dump_context): Add param "test_pp_flags".
Set up test pretty-printer on the underlying context.  Call
refresh_dumps_are_enabled.
(temp_dump_context::~temp_dump_context): Call
refresh_dumps_are_enabled.
(temp_dump_context::get_dumped_text): New member function.
(selftest::verify_dumped_text): New function.
(ASSERT_DUMPED_TEXT_EQ): New macro.
(selftest::test_capture_of_dump_calls): Run all tests twice, with
and then without optinfo enabled.  Add uses of
ASSERT_DUMPED_TEXT_EQ to all tests.  Add test of nested scopes.
* dumpfile.h: Update comment for the dump_* API.
* optinfo-emit-json.cc
(selftest::test_building_json_from_dump_calls): Update for new
param for temp_dump_context ctor.
* optinfo.cc (optinfo_item::optinfo_item): Remove "owned"

[PATCH 5/5] Formatted printing for dump_* in the middle-end

[David Malcolm]

This patch converts dump_print and dump_printf_loc from using
printf (and thus ATTRIBUTE_PRINTF) to using a new pretty-printer
based on pp_format, which supports formatting middle-end types.

In particular, the following codes are implemented (in addition
to the standard pretty_printer ones):

   %E: gimple *:
   Equivalent to: dump_gimple_expr (MSG_*, TDF_SLIM, stmt, 0)
   %G: gimple *:
   Equivalent to: dump_gimple_stmt (MSG_*, TDF_SLIM, stmt, 0)
   %T: tree:
   Equivalent to: dump_generic_expr (MSG_*, arg, TDF_SLIM).

Hence it becomes possible to convert e.g.:

  if (dump_enabled_p ())
{
  dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
   "not vectorized: different sized vector "
   "types in statement, ");
  dump_generic_expr (MSG_MISSED_OPTIMIZATION, TDF_SLIM, vectype);
  dump_printf (MSG_MISSED_OPTIMIZATION, " and ");
  dump_generic_expr (MSG_MISSED_OPTIMIZATION, TDF_SLIM, nunits_vectype);
  dump_printf (MSG_MISSED_OPTIMIZATION, "\n");
}

into a one-liner:

  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
 "not vectorized: different sized vector "
 "types in statement, %T and %T\n",
 vectype, nunits_vectype);

Unlike regular pretty-printers, this one captures optinfo_item
instances for the formatted chunks as appropriate, so that when
written out to a JSON optimization record, the relevant parts of
the message are labelled by type, and by source location (so that
e.g. %G is entirely equivalent to using dump_gimple_stmt).

dump_printf and dump_printf_loc become marked with
ATTRIBUTE_GCC_DUMP_PRINTF, which the patch also implements.

gcc/c-family/ChangeLog:
* c-format.c (enum format_type): Add gcc_dump_printf_format_type.
(local_gimple_ptr_node): New decl.
(gcc_dump_printf_length_specs): New.
(gcc_dump_printf_flag_pairs): New.
(gcc_dump_printf_flag_specs): New.
(gcc_dump_printf_char_table): New.
(format_types_orig): Add entry for "gcc_dump_printf".
(init_dynamic_diag_info): Create local_gimple_ptr_node.
Set up length_char_specs and conversion_specs for
gcc_dump_printf_format_type.
(handle_format_attribute): Handle gcc_dump_printf_format_type.
* c-format.h (T89_GIMPLE): New macro.

gcc/ChangeLog:
* dump-context.h: Include "dumpfile.h".
(dump_context::dump_printf_va): Convert final param from va_list
to va_list *.  Convert from ATTRIBUTE_PRINTF to
ATTRIBUTE_GCC_DUMP_PRINTF.
(dump_context::dump_printf_loc_va): Likewise.
* dumpfile.c: Include "stringpool.h".
(make_item_for_dump_printf_va): Delete.
(make_item_for_dump_printf): Delete.
(class dump_pretty_printer): New class.
(dump_pretty_printer::dump_pretty_printer): New ctor.
(dump_pretty_printer::emit_items): New member function.
(dump_pretty_printer::emit_any_pending_textual_chunks): New member
function.
(dump_pretty_printer::emit_item): New member function.
(dump_pretty_printer::stash_item): New member function.
(dump_pretty_printer::format_decoder_cb): New member function.
(dump_pretty_printer::decode_format): New member function.
(dump_context::dump_printf_va): Reimplement in terms of
dump_pretty_printer.
(dump_context::dump_printf_loc_va): Convert final param from va_list
to va_list *.
(dump_context::begin_scope): Reimplement call to
make_item_for_dump_printf.
(dump_printf): Update for change to dump_printf_va.
(dump_printf_loc): Likewise.
(selftest::test_capture_of_dump_calls): Convert "stmt" from
greturn * to gimple *.  Add a test_decl.  Add tests of dump_printf
with %T, %E, and %G.
* dumpfile.h (ATTRIBUTE_GCC_DUMP_PRINTF): New macro.
(dump_printf): Replace ATTRIBUTE_PRINTF_2 with
ATTRIBUTE_GCC_DUMP_PRINTF (2, 3).
(dump_printf_loc): Replace ATTRIBUTE_PRINTF_3 with
ATTRIBUTE_GCC_DUMP_PRINTF (3, 0).

gcc/testsuite/ChangeLog:
* gcc.dg/format/gcc_diag-1.c: Fix typo.  Add test coverage for
gcc_dump_printf.
* gcc.dg/format/gcc_diag-10.c: Add gimple typedef.  Add test
coverage for gcc_dump_printf.
---
 gcc/c-family/c-format.c   |  60 -
 gcc/c-family/c-format.h   |   1 +
 gcc/dump-context.h|   7 +-
 gcc/dumpfile.c| 358 +++---
 gcc/dumpfile.h|  20 +-
 gcc/testsuite/gcc.dg/format/gcc_diag-1.c  |  15 +-
 gcc/testsuite/gcc.dg/format/gcc_diag-10.c |  26 +++
 7 files changed, 448 insertions(+), 39 deletions(-)

diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index 82841e4..b524468 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-form

[PATCH 3/5] C++: clean up cp_printer

[David Malcolm]

This makes it easier to compare cp_printer with gcc_cxxdiag_char_table
in c-format.c.

No functional change intended.

gcc/cp/ChangeLog:
* error.c (cp_printer): In the leading comment, move "%H" and "I"
into alphabetical order, and add missing "%G" and "K".  Within the
switch statement, move cases 'G', 'H', 'I' and 'K" so that the
cases are in alphabetical order.
---
 gcc/cp/error.c | 46 --
 1 file changed, 20 insertions(+), 26 deletions(-)

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index b0d8e32..7a644fd 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -4025,6 +4025,10 @@ defer_phase_2_of_type_diff (deferred_printed_type 
*deferred,
%D   declaration.
%E   expression.
%F   function declaration.
+   %G   gcall *
+   %H   type difference (from).
+   %I   type difference (to).
+   %K   tree
%L  language as used in extern "lang".
%O  binary operator.
%P   function parameter whose position is indicated by an integer.
@@ -4032,9 +4036,7 @@ defer_phase_2_of_type_diff (deferred_printed_type 
*deferred,
%S   substitution (template + args)
%T   type.
%V   cv-qualifier.
-   %X   exception-specification.
-   %H   type difference (from)
-   %I   type difference (to).  */
+   %X   exception-specification.  */
 static bool
 cp_printer (pretty_printer *pp, text_info *text, const char *spec,
int precision, bool wide, bool set_locus, bool verbose,
@@ -4076,6 +4078,21 @@ cp_printer (pretty_printer *pp, text_info *text, const 
char *spec,
   break;
 case 'E': result = expr_to_string (next_tree); break;
 case 'F': result = fndecl_to_string (next_tree, verbose);  break;
+case 'G':
+  percent_G_format (text);
+  return true;
+case 'H':
+  defer_phase_2_of_type_diff (&postprocessor->m_type_a, next_tree,
+ buffer_ptr, verbose, *quoted);
+  return true;
+case 'I':
+  defer_phase_2_of_type_diff (&postprocessor->m_type_b, next_tree,
+ buffer_ptr, verbose, *quoted);
+  return true;
+case 'K':
+  t = va_arg (*text->args_ptr, tree);
+  percent_K_format (text, t);
+  return true;
 case 'L': result = language_to_string (next_lang); break;
 case 'O': result = op_to_string (false, next_tcode);   break;
 case 'P': result = parm_to_string (next_int);  break;
@@ -4090,29 +4107,6 @@ cp_printer (pretty_printer *pp, text_info *text, const 
char *spec,
 case 'V': result = cv_to_string (next_tree, verbose);  break;
 case 'X': result = eh_spec_to_string (next_tree, verbose);  break;
 
-case 'G':
-  percent_G_format (text);
-  return true;
-
-case 'K':
-  t = va_arg (*text->args_ptr, tree);
-  percent_K_format (text, t);
-  return true;
-
-case 'H':
-  {
-   defer_phase_2_of_type_diff (&postprocessor->m_type_a, next_tree,
-   buffer_ptr, verbose, *quoted);
-   return true;
-  }
-
-case 'I':
-  {
-   defer_phase_2_of_type_diff (&postprocessor->m_type_b, next_tree,
-   buffer_ptr, verbose, *quoted);
-   return true;
-  }
-
 default:
   return false;
 }
-- 
1.8.5.3

[PATCH 4/5] c-family: clean up the data tables in c-format.c

[David Malcolm]

The format_char_info tables in c-format.c for our own formats contain
a lot of repetition.

This patch adds a macro to express the conversion specifiers implemented
within pp_format, making it clearer which are custom ones added by the
various diagnostic_format_decoder callbacks.

Doing so uncovered a few mistakes in the data (based on comparison with
the source of the diagnostic_format_decoder callbacks, and the notes
below), which the patch fixes:

- gcc_diag_char_table didn't have 'Z', but it *is* implemented by pp_format.

- removed erroneous 'G' and 'K' entries from gcc_diag_char_table: they're
  implemented by default_tree_printer (and thus in "tdiag") and by the
  C/C++ FEs, but not in pp_format.

- removed "v" (lower case) from gcc_tdiag_char_table and
  gcc_cxxdiag_char_table

Notes:

pretty-print.h uses this for ATTRIBUTE_GCC_PPDIAG, used by pp_printf
and pp_verbatim:

whereas diagnostic-core.h uses this for ATTRIBUTE_GCC_DIAG, used by
the various diagnostic functions:

/* If we haven't already defined a front-end-specific diagnostics
   style, use the generic one.  */

Hence I'm assuming that __gcc_diag__ is for use for when we don't
know what kind of diagnostic_format_decoder we have, and we can
only rely on pp_format's core functionality, where __gcc_tdiag__
is allowed to assume default_tree_printer.

gcc/c-family/ChangeLog:
* c-format.c (PP_FORMAT_CHAR_TABLE): New macro, based on existing
table entries for gcc_diag_char_table, and the 'Z' entry from
gcc_tdiag_char_table, changing the "chain" entry for 'Z' from
&gcc_tdiag_char_table[0] to &gcc_diag_char_table[0].
(gcc_diag_char_table): Use PP_FORMAT_CHAR_TABLE, implicitly
adding missing "Z" for this table.  Remove erroneous "G" and "K"
entries.
(gcc_tdiag_char_table): Use PP_FORMAT_CHAR_TABLE.  Remove "v".
(gcc_cdiag_char_table): Use PP_FORMAT_CHAR_TABLE.
(gcc_cxxdiag_char_table): Use PP_FORMAT_CHAR_TABLE.  Remove "v".

gcc/testsuite/ChangeLog:
* gcc.dg/format/gcc_diag-1.c (foo): Update the %v tests for
tdiag and cxxdiag.
* gcc.dg/format/gcc_diag-10.c (test_diag): Update tests of %G
and %K.
---
 gcc/c-family/c-format.c   | 99 ++-
 gcc/testsuite/gcc.dg/format/gcc_diag-1.c  |  4 +-
 gcc/testsuite/gcc.dg/format/gcc_diag-10.c |  7 +--
 3 files changed, 35 insertions(+), 75 deletions(-)

diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index a0192dd..82841e4 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -679,43 +679,40 @@ static const format_char_info asm_fprintf_char_table[] =
   { NULL,  0, STD_C89, NOLENGTHS, NULL, NULL, NULL }
 };
 
+/* GCC-specific format_char_info arrays.  */
+
+/* The conversion specifiers implemented within pp_format, and thus supported
+   by all pretty_printer instances within GCC.  */
+
+#define PP_FORMAT_CHAR_TABLE \
+  { "di",  0, STD_C89, { T89_I,   BADLEN,  BADLEN,  T89_L,   T9L_LL,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "q",  "",   NULL }, \
+  { "ox",  0, STD_C89, { T89_UI,  BADLEN,  BADLEN,  T89_UL,  T9L_ULL, BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "q",  "",   NULL }, \
+  { "u",   0, STD_C89, { T89_UI,  BADLEN,  BADLEN,  T89_UL,  T9L_ULL, BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "q",  "",   NULL }, \
+  { "c",   0, STD_C89, { T89_I,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "q",  "",   NULL }, \
+  { "s",   1, STD_C89, { T89_C,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "pq", "cR", NULL }, \
+  { "p",   1, STD_C89, { T89_V,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "q",  "c",  NULL }, \
+  { "r",   1, STD_C89, { T89_C,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "","//cR",   NULL 
}, \
+  { "<",   0, STD_C89, NOARGUMENTS, "",  "<",   NULL }, \
+  { ">",   0, STD_C89, NOARGUMENTS, "",  ">",   NULL }, \
+  { "'" ,  0, STD_C89, NOARGUMENTS, "",  "",NULL }, \
+  { "R",   0, STD_C89, NOARGUMENTS, "", "\\",   NULL }, \
+  { "m",   0, STD_C89, NOARGUMENTS, "q", "",   NULL }, \
+  { "Z",   1, STD_C89, { T89_I,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "","", 
&gcc_diag_char_table[0] }
+
 static const format_char_info gcc_diag_char_table[] =
 {
-  /* C89 conversion specifiers.  */
-  { "di",  0, STD_C89, { T89_I,   BADLEN,  BADLEN,  T89_L,   T9L_LL,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "q",  "",   NULL },
-  { "ox",  0, STD_C89, { T89_UI,  BADLEN,  BADLEN,  T89_UL,  T9L_ULL, BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "q",  "",   NULL },
-  { "u",   0, STD_C89, { T89_UI,

[PATCH 0/5] dump_printf support for middle-end types

[David Malcolm]

This patch kit converts dump_print and dump_printf_loc from using
fprintf etc internally to using a new pretty-printer
based on pp_format, which supports formatting middle-end types.

In particular, the following codes are implemented (in addition
to the standard pretty_printer ones):

   %E: gimple *:
   Equivalent to: dump_gimple_expr (MSG_*, TDF_SLIM, stmt, 0)
   %G: gimple *:
   Equivalent to: dump_gimple_stmt (MSG_*, TDF_SLIM, stmt, 0)
   %T: tree:
   Equivalent to: dump_generic_expr (MSG_*, arg, TDF_SLIM).

Hence it becomes possible to convert e.g.:

  if (dump_enabled_p ())
{
  dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
   "not vectorized: different sized vector "
   "types in statement, ");
  dump_generic_expr (MSG_MISSED_OPTIMIZATION, TDF_SLIM, vectype);
  dump_printf (MSG_MISSED_OPTIMIZATION, " and ");
  dump_generic_expr (MSG_MISSED_OPTIMIZATION, TDF_SLIM, nunits_vectype);
  dump_printf (MSG_MISSED_OPTIMIZATION, "\n");
}
  return false;

into a single call to dump_printf_loc:

  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
 "not vectorized: different sized vector "
 "types in statement, %T and %T\n",
 vectype, nunits_vectype);
  return false;

Unlike regular pretty-printers, this captures metadata for the
formatted chunks as appropriate, so that when written out to a
JSON optimization record, the relevant parts of the message are
labelled by type, and by source location (so that
e.g. %G is entirely equivalent to using dump_gimple_stmt).

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for trunk?

I'm hoping to use this in a v3 of:
  "[PATCH 0/5] [RFC v2] Higher-level reporting of vectorization problems"
 https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00446.html
where the above might become:
  return opt_result::failure_at (stmt,
 "not vectorized: different sized vector "
 "types in statement, %T and %T\n",
 vectype, nunits_vectype);
where opt_result::failure_at would encapsulate the "false", and
capture an opt_problem * (when dumps are enabled), for the reasons
discussed in that other kit.

David Malcolm (5):
  Simplify dump_context by adding a dump_loc member function
  dumpfile.c: eliminate special-casing of dump_file/alt_dump_file
  C++: clean up cp_printer
  c-family: clean up the data tables in c-format.c
  Formatted printing for dump_* in the middle-end

 gcc/c-family/c-format.c   |  159 +++--
 gcc/c-family/c-format.h   |1 +
 gcc/cp/error.c|   46 +-
 gcc/dump-context.h|   25 +-
 gcc/dumpfile.c| 1011 ++---
 gcc/dumpfile.h|   54 +-
 gcc/optinfo-emit-json.cc  |2 +-
 gcc/optinfo.cc|  135 +---
 gcc/optinfo.h |   38 +-
 gcc/testsuite/gcc.dg/format/gcc_diag-1.c  |   19 +-
 gcc/testsuite/gcc.dg/format/gcc_diag-10.c |   33 +-
 11 files changed, 998 insertions(+), 525 deletions(-)

-- 
1.8.5.3

[PATCH 1/5] Simplify dump_context by adding a dump_loc member function

[David Malcolm]

This patch removes some duplicated code in dumpfile.c by
reimplementing the various dump_foo_loc calls in terms of dump_foo.

gcc/ChangeLog:
* dump-context.h (dump_context::dump_loc): New decl.
* dumpfile.c (dump_context::dump_loc): New member function.
(dump_context::dump_gimple_stmt_loc): Reimplement using dump_loc
and dump_gimple_stmt.
(dump_context::dump_gimple_expr_loc): Likewise, using
dump_gimple_expr.
(dump_context::dump_generic_expr_loc): Likewise, using
dump_generic_expr.
(dump_context::dump_printf_loc_va): Likewise, using
dump_printf_va.
(dump_context::begin_scope): Explicitly using the global function
"dump_loc", rather than the member function.
---
 gcc/dump-context.h |   2 +
 gcc/dumpfile.c | 119 ++---
 2 files changed, 33 insertions(+), 88 deletions(-)

diff --git a/gcc/dump-context.h b/gcc/dump-context.h
index a191e3a..f6df0b4 100644
--- a/gcc/dump-context.h
+++ b/gcc/dump-context.h
@@ -39,6 +39,8 @@ class dump_context
 
   ~dump_context ();
 
+  void dump_loc (dump_flags_t dump_kind, const dump_location_t &loc);
+
   void dump_gimple_stmt (dump_flags_t dump_kind, dump_flags_t extra_dump_flags,
 gimple *gs, int spc);
 
diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
index 176c9b8..3c8bc38 100644
--- a/gcc/dumpfile.c
+++ b/gcc/dumpfile.c
@@ -474,6 +474,27 @@ dump_context::~dump_context ()
   delete m_pending;
 }
 
+/* Print LOC to the appropriate dump destinations, given DUMP_KIND.
+   If optinfos are enabled, begin a new optinfo.  */
+
+void
+dump_context::dump_loc (dump_flags_t dump_kind, const dump_location_t &loc)
+{
+  location_t srcloc = loc.get_location_t ();
+
+  if (dump_file && (dump_kind & pflags))
+::dump_loc (dump_kind, dump_file, srcloc);
+
+  if (alt_dump_file && (dump_kind & alt_flags))
+::dump_loc (dump_kind, alt_dump_file, srcloc);
+
+  if (optinfo_enabled_p ())
+{
+  optinfo &info = begin_next_optinfo (loc);
+  info.handle_dump_file_kind (dump_kind);
+}
+}
+
 /* Dump gimple statement GS with SPC indentation spaces and
EXTRA_DUMP_FLAGS on the dump streams if DUMP_KIND is enabled.  */
 
@@ -504,25 +525,8 @@ dump_context::dump_gimple_stmt_loc (dump_flags_t dump_kind,
dump_flags_t extra_dump_flags,
gimple *gs, int spc)
 {
-  location_t srcloc = loc.get_location_t ();
-  if (dump_file && (dump_kind & pflags))
-{
-  dump_loc (dump_kind, dump_file, srcloc);
-  print_gimple_stmt (dump_file, gs, spc, dump_flags | extra_dump_flags);
-}
-
-  if (alt_dump_file && (dump_kind & alt_flags))
-{
-  dump_loc (dump_kind, alt_dump_file, srcloc);
-  print_gimple_stmt (alt_dump_file, gs, spc, dump_flags | 
extra_dump_flags);
-}
-
-  if (optinfo_enabled_p ())
-{
-  optinfo &info = begin_next_optinfo (loc);
-  info.handle_dump_file_kind (dump_kind);
-  info.add_gimple_stmt (gs, spc, dump_flags | extra_dump_flags);
-}
+  dump_loc (dump_kind, loc);
+  dump_gimple_stmt (dump_kind, extra_dump_flags, gs, spc);
 }
 
 /* Dump gimple statement GS with SPC indentation spaces and
@@ -557,25 +561,8 @@ dump_context::dump_gimple_expr_loc (dump_flags_t dump_kind,
gimple *gs,
int spc)
 {
-  location_t srcloc = loc.get_location_t ();
-  if (dump_file && (dump_kind & pflags))
-{
-  dump_loc (dump_kind, dump_file, srcloc);
-  print_gimple_expr (dump_file, gs, spc, dump_flags | extra_dump_flags);
-}
-
-  if (alt_dump_file && (dump_kind & alt_flags))
-{
-  dump_loc (dump_kind, alt_dump_file, srcloc);
-  print_gimple_expr (alt_dump_file, gs, spc, dump_flags | 
extra_dump_flags);
-}
-
-  if (optinfo_enabled_p ())
-{
-  optinfo &info = begin_next_optinfo (loc);
-  info.handle_dump_file_kind (dump_kind);
-  info.add_gimple_expr (gs, spc, dump_flags | extra_dump_flags);
-}
+  dump_loc (dump_kind, loc);
+  dump_gimple_expr (dump_kind, extra_dump_flags, gs, spc);
 }
 
 
@@ -611,25 +598,8 @@ dump_context::dump_generic_expr_loc (dump_flags_t 
dump_kind,
 dump_flags_t extra_dump_flags,
 tree t)
 {
-  location_t srcloc = loc.get_location_t ();
-  if (dump_file && (dump_kind & pflags))
-{
-  dump_loc (dump_kind, dump_file, srcloc);
-  print_generic_expr (dump_file, t, dump_flags | extra_dump_flags);
-}
-
-  if (alt_dump_file && (dump_kind & alt_flags))
-{
-  dump_loc (dump_kind, alt_dump_file, srcloc);
-  print_generic_expr (alt_dump_file, t, dump_flags | extra_dump_flags);
-}
-
-  if (optinfo_enabled_p ())
-{
-  optinfo &info = begin_next_optinfo (loc);
-  info.handle_dump_file_kind (dump_kind);
-  info.add_tree (t, dump_flags | extra_dump_flags);
-}
+  dump_loc (dump_

Re: [patch] improve internals documentation for nested function descriptors

[Eric Botcazou]

> Apropos of the discussion about improving the docs for
> TARGET_CUSTOM_FUNCTION_DESCRIPTORS in the context of the C-SKY port
> submission,
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01454.html
> 
> here is the patch I've come up with based on reading the source.  Is
> this technically accurate?  Any suggestions on how to improve it further?

""Define this hook to 0 if the target implements custom support"

"custom" was precisely chosen to distinguish this kind of descriptors from the 
standard descriptors used on IA-64 or HP-PA, so it's contradictory.  Moreover 
I would really start with the "custom" case and not the standard case as was 
originally written, the "custom" case being the common case for targets.

I'm not really convinced by the substitution misalignment -> tag either, but 
if others find the new version more understandable, then OK with me.

-- 
Eric Botcazou

Re: [PATCH] enhance strlen to understand MEM_REF and partial overlaps (PR 86042, 86043)

[Eric Botcazou]

> What I was trying to highlight is that rolling my own solution like
> this makes missing regressions more likely than having a shared
> solution would.

But 'make mail-report.log' is precisely the shared solution, no need to 
reinvent the wheel here.

-- 
Eric Botcazou

Re: [PATCH] Fix DJGPP LTO with debug

[DJ Delorie]

Richard Biener  writes:
> DJ, did you ever run the testsuite with a configuration that has LTO
> enabled?  I don't see any djgpp results posted to gcc-testresults.
> Quick googling doesn't yield anything useful with regarding on how to
> do actual testing with a cross so I only built a i686-pc-msdosdjgpp
> cross cc1/lto1 from x86_64-linux which went fine.

CC's Andris, our current gcc maintainer within DJGPP.  I know he just
built 8.2 binaries for us, I don't know what his testing infrastructure
looks like.

Re: [patch] improve internals documentation for nested function descriptors

[Paul Koning]

> On Jul 27, 2018, at 4:39 PM, Sandra Loosemore  wrote:
> 
> Apropos of the discussion about improving the docs for 
> TARGET_CUSTOM_FUNCTION_DESCRIPTORS in the context of the C-SKY port 
> submission,
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01454.html
> 
> here is the patch I've come up with based on reading the source.  Is this 
> technically accurate?  Any suggestions on how to improve it further?
> 
> -Sandra
> 

Nice.  That tells me a lot more, so I hope to hear confirmation it's accurate.

A nit: "word aligned" -- you used thas as a synonym for "multiple of 4 aligned" 
but some of us have 2-byte words.

On the function descriptor concept generally: it wasn't clear to me whether a 
target that wants to use this mechanism needs to do anything to tell GCC how to 
construct descriptors.  Does GCC have a standard recipe it uses that "should" 
work for any target?  I assume so because there aren't any other target hooks 
or special patterns for this.  It would be helpful to say so explicitly.

paul

[patch] improve internals documentation for nested function descriptors

[Sandra Loosemore]

Apropos of the discussion about improving the docs for 
TARGET_CUSTOM_FUNCTION_DESCRIPTORS in the context of the C-SKY port 
submission,


https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01454.html

here is the patch I've come up with based on reading the source.  Is 
this technically accurate?  Any suggestions on how to improve it further?


-Sandra
2018-07-27  Sandra Loosemore  

	gcc/
	* target.def (custom_function_descriptors): Improve documentation.
	* doc/tm.texi.in (Trampolines): Expand discussion of function
	descriptors and move TARGET_CUSTOM_FUNCTION_DESCRIPTORS to the
	beginning of the section.
	* doc/tm.texi: Regenerated.
diff --git a/gcc/target.def b/gcc/target.def
index 112c772..d67228d 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -4966,21 +4966,21 @@ If this hook is not defined, @var{addr} will be used for function calls.",
 
 DEFHOOKPOD
 (custom_function_descriptors,
- "This hook should be defined to a power of 2 if the target will benefit\n\
-from the use of custom descriptors for nested functions instead of the\n\
-standard trampolines.  Such descriptors are created at run time on the\n\
-stack and made up of data only, but they are non-standard so the generated\n\
-code must be prepared to deal with them.  This hook should be defined to 0\n\
-if the target uses function descriptors for its standard calling sequence,\n\
-like for example HP-PA or IA-64.  Using descriptors for nested functions\n\
+ "Define this hook to 0 if the target implements custom support for\n\
+function descriptors in its standard calling sequence, like for example\n\
+HPPA or IA-64.\n\
+\n\
+If the target can use GCC's generic descriptor mechanism for nested\n\
+functions, define this hook to a power of 2 representing an unused bit\n\
+in function pointers which can be used to tag descriptors and\n\
+differentiate them at run time.  For example, on targets that require\n\
+functions to be word-aligned, a value of either 1 or 2 is appropriate\n\
+unless the architecture already reserves the bit for another purpose,\n\
+such as on ARM.\n\
+\n\
+Using descriptors for nested functions\n\
 eliminates the need for trampolines that reside on the stack and require\n\
-it to be made executable.\n\
-\n\
-The value of the macro is used to parameterize the run-time identification\n\
-scheme implemented to distinguish descriptors from function addresses: it\n\
-gives the number of bytes by which their address is misaligned compared\n\
-with function addresses.  The value of 1 will generally work, unless it is\n\
-already reserved by the target for another purpose, like for example on ARM.",\
+it to be made executable.",\
  int, -1)
 
 /* Return the number of bytes of its own arguments that a function
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index b7b0e8a..e15b604 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -3766,24 +3766,60 @@ These machine description macros help implement varargs:
 @hook TARGET_SETUP_INCOMING_VARARG_BOUNDS
 
 @node Trampolines
-@section Trampolines for Nested Functions
+@section Support for Nested Functions
+@cindex support for nested functions
 @cindex trampolines for nested functions
-@cindex nested functions, trampolines for
-
-A @dfn{trampoline} is a small piece of code that is created at run time
-when the address of a nested function is taken.  It normally resides on
-the stack, in the stack frame of the containing function.  These macros
-tell GCC how to generate code to allocate and initialize a
-trampoline.
-
-The instructions in the trampoline must do two things: load a constant
-address into the static chain register, and jump to the real address of
-the nested function.  On CISC machines such as the m68k, this requires
-two instructions, a move immediate and a jump.  Then the two addresses
-exist in the trampoline as word-long immediate operands.  On RISC
-machines, it is often necessary to load each address into a register in
-two parts.  Then pieces of each address form separate immediate
-operands.
+@cindex descriptors for nested functions
+@cindex nested functions, support for
+
+Taking the address of a nested function requires special compiler
+handling to ensure that the static chain register is loaded when
+the function is invoked via an indirect call.
+
+GCC has traditionally supported nested functions by creating an
+executable @dfn{trampoline} at run time when the address of a nested
+function is taken.  This is a small piece of code which normally
+resides on the stack, in the stack frame of the containing function.
+The trampoline loads the static chain register and then jumps to the
+real address of the nested function.
+
+The use of trampolines requires an executable stack, which is a
+security risk.  To avoid this problem, GCC also supports another
+strategy: using descriptors for nested functions.  Under this model,
+taking the address of a nested function results in a pointer to a
+non-executable function descriptor object.  Initializing the static

Re: RFA: libiberty: avoid UBSAN complaint in cplus-dem.c

[Ian Lance Taylor via gcc-patches]

On Fri, Jul 27, 2018 at 10:12 AM, Tom Tromey  wrote:
> I built gdb with -fsanitize=undefined, and there was a complaint coming
> from cplus-dem.c.  remember_Btype can call memcpy with a NULL pointer,
> which is undefined behavior according to the C standard.
>
> This patch fixes the problem for me.  I tested this by rebuilding gdb
> (with -fsanitize=undefined) and re-running the test suite.
>
> Ok?
>
> Tom
>
> 2018-07-27  Tom Tromey  
>
> * cplus-dem.c (remember_Btype): Don't call memcpy with LEN==0.

This is OK.

Thanks.

Ian

Re: [PATCH 00/11] (v2) Mitigation against unsafe data speculation (CVE-2017-5753)

[John David Anglin]

On 2018-07-27 5:37 AM, Richard Earnshaw wrote:

Port Maintainers: You need to decide what action is required for your
port to handle speculative execution, even if that action is to use
the trivial no-speculation on this architecture.  You must also
consider whether or not a furture implementation of your architecture
might need to deal with this in making that decision.
On hppa, I think we should go with the hook that assumes there is no 
speculative execution.


Nominally, there is branch prediction and speculative execution; but the 
spectre test program

was not able to successfully access memory on my rp3440.

As far as I know, the details of speculative execution on PA-RISC are 
not public.  Jeff would know

best.

Dave

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

New Ukrainian PO file for 'gcc' (version 8.2.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Ukrainian team of translators.  The file is available at:

http://translationproject.org/latest/gcc/uk.po

(This file, 'gcc-8.2.0.uk.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

libgo patch committed: Prune sighandler frames in runtime.sigprof

[Ian Lance Taylor]

This libgo patch by Than McIntosh prunes sighandler frames in
runtime.sigprof.  When writing stack frames to the pprof CPU profile
machinery, it is very important to insure that the frames emitted do
not contain any frames corresponding to artifacts of the profiling
process itself (signal handlers, sigprof, etc).  This patch changes
runtime.sigprof to strip out those frames from the raw stack generated
by "runtime.callers".  This fixes https://golang.org/issue/26595.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 262908)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-39d4d755db7d71b5e770ca435a8b1d1f08f53185
+a2e0ad16555b2698df8e71f4c0fe02e185715bc1
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/runtime/pprof/pprof_test.go
===
--- libgo/go/runtime/pprof/pprof_test.go(revision 262658)
+++ libgo/go/runtime/pprof/pprof_test.go(working copy)
@@ -72,15 +72,24 @@ func cpuHog2(x int) int {
return foo
 }
 
+// Return a list of functions that we don't want to ever appear in CPU
+// profiles. For gccgo, that list includes the sigprof handler itself.
+func avoidFunctions() []string {
+   if runtime.Compiler == "gccgo" {
+   return []string{"runtime.sigprof"}
+   }
+   return nil
+}
+
 func TestCPUProfile(t *testing.T) {
-   testCPUProfile(t, []string{"pprof.cpuHog1"}, func(dur time.Duration) {
+   testCPUProfile(t, []string{"pprof.cpuHog1"}, avoidFunctions(), func(dur 
time.Duration) {
cpuHogger(cpuHog1, &salt1, dur)
})
 }
 
 func TestCPUProfileMultithreaded(t *testing.T) {
defer runtime.GOMAXPROCS(runtime.GOMAXPROCS(2))
-   testCPUProfile(t, []string{"pprof.cpuHog1", "pprof.cpuHog2"}, func(dur 
time.Duration) {
+   testCPUProfile(t, []string{"pprof.cpuHog1", "pprof.cpuHog2"}, 
avoidFunctions(), func(dur time.Duration) {
c := make(chan int)
go func() {
cpuHogger(cpuHog1, &salt1, dur)
@@ -92,7 +101,7 @@ func TestCPUProfileMultithreaded(t *test
 }
 
 func TestCPUProfileInlining(t *testing.T) {
-   testCPUProfile(t, []string{"pprof.inlinedCallee", 
"pprof.inlinedCaller"}, func(dur time.Duration) {
+   testCPUProfile(t, []string{"pprof.inlinedCallee", 
"pprof.inlinedCaller"}, avoidFunctions(), func(dur time.Duration) {
cpuHogger(inlinedCaller, &salt1, dur)
})
 }
@@ -130,7 +139,7 @@ func parseProfile(t *testing.T, valBytes
}
 }
 
-func testCPUProfile(t *testing.T, need []string, f func(dur time.Duration)) {
+func testCPUProfile(t *testing.T, need []string, avoid []string, f func(dur 
time.Duration)) {
switch runtime.GOOS {
case "darwin":
switch runtime.GOARCH {
@@ -169,7 +178,7 @@ func testCPUProfile(t *testing.T, need [
f(duration)
StopCPUProfile()
 
-   if profileOk(t, need, prof, duration) {
+   if profileOk(t, need, avoid, prof, duration) {
return
}
 
@@ -202,11 +211,13 @@ func contains(slice []string, s string)
return false
 }
 
-func profileOk(t *testing.T, need []string, prof bytes.Buffer, duration 
time.Duration) (ok bool) {
+func profileOk(t *testing.T, need []string, avoid []string, prof bytes.Buffer, 
duration time.Duration) (ok bool) {
ok = true
 
-   // Check that profile is well formed and contains need.
+   // Check that profile is well formed, contains 'need', and does not 
contain
+   // anything from 'avoid'.
have := make([]uintptr, len(need))
+   avoidSamples := make([]uintptr, len(avoid))
var samples uintptr
var buf bytes.Buffer
parseProfile(t, prof.Bytes(), func(count uintptr, stk 
[]*profile.Location, labels map[string][]string) {
@@ -229,6 +240,15 @@ func profileOk(t *testing.T, need []stri
}
}
}
+   for i, name := range avoid {
+   for _, loc := range stk {
+   for _, line := range loc.Line {
+   if strings.Contains(line.Function.Name, 
name) {
+   avoidSamples[i] += count
+   }
+   }
+   }
+   }
fmt.Fprintf(&buf, "\n")
})
t.Logf("total %d CPU profile samples collected:\n%s", samples, 
buf.String())
@@ -251,6 +271,14 @@ func profileOk(t *testing.T, need []stri
ok = false
}
 
+   for i, name := range avoid {
+

Re: [PATCH] haiku: Initial build support

[Joseph Myers]

On Fri, 27 Jul 2018, Alexander von Gluck IV wrote:

> >> It's much better for issues to be identified within a day or two of the
> >> commit causing them than many months later, possibly only after a release
> >> has come out with the issue - but that requires an ongoing commitment to
> >> keep monitoring test results, posting them to gcc-testresults and keeping
> >> them in good shape.
> 
> This is good information, however, does GCC have docs for this? We are a
> small team of open source developers with maybe a few man-hours a month
> available to dedicate to gcc maintainership. (no excuses, just trying
> to set the expectations)

Well, install.texi documents the use of contrib/test_summary to post test 
results.

I think the documentation is better for one-off requirements for a patch, 
than for expectations for maintainers on an ongoing basis (in that 
maintainers would typically have been following development for some time, 
and so have seen what maintainers of other architectures and OSes do - for 
example, have seen how AIX people promptly raise issues when a patch 
breaks things for AIX, which is the sort of thing I'd expect target OS 
maintainers to do in general).

> These steps seem like what's needed on a first-class platform (Linux, OS X,
> etc). So the same requirements apply to all new GCC platforms code?

Requirements for OS and architecture ports aren't well-defined and seem 
like a good topic for Cauldron discussion.  But generically, it's 
important that new architecture and OS ports don't get in the way of 
global changes.  This means it's important to have sufficient 
documentation available for architectures for the use of people doing 
global changes, that it's valuable to have simulators (with OS images as 
applicable) with information (e.g. DejaGnu board files) available for 
people wishing to test on the architecture or OS (or hardware systems 
available in the GCC Compile Farm, for architectures and OSes for which 
that works better), and that it's valuable if people can tell at a glance 
at recent gcc-testresults posts what shape the port is in.

And, as a matter of working well with other developers, it's much better 
to find and point out breakage promptly rather than long after the patch 
that broke something went in (and, in particular, in the same development 
stage; if there's a design issue with a patch going in during stage 1 
which requires design changes for some architectures or OSes, it's very 
unhelpful if that's only found much later when trunk is in 
regression-fixes-only mode for the next release).

Also, unmaintained features and unused ports are liable to be removed, and 
having test results posted is important evidence of whether the port is in 
good shape or should be considered for removal.

-- 
Joseph S. Myers
jos...@codesourcery.com

RFA: libiberty: avoid UBSAN complaint in cplus-dem.c

[Tom Tromey]

I built gdb with -fsanitize=undefined, and there was a complaint coming
from cplus-dem.c.  remember_Btype can call memcpy with a NULL pointer,
which is undefined behavior according to the C standard.

This patch fixes the problem for me.  I tested this by rebuilding gdb
(with -fsanitize=undefined) and re-running the test suite.

Ok?

Tom

2018-07-27  Tom Tromey  

* cplus-dem.c (remember_Btype): Don't call memcpy with LEN==0.

diff --git a/libiberty/cplus-dem.c b/libiberty/cplus-dem.c
index 6d58bd899bf..4f29d54d089 100644
--- a/libiberty/cplus-dem.c
+++ b/libiberty/cplus-dem.c
@@ -4471,7 +4471,8 @@ remember_Btype (struct work_stuff *work, const char 
*start,
   char *tem;
 
   tem = XNEWVEC (char, len + 1);
-  memcpy (tem, start, len);
+  if (len > 0)
+memcpy (tem, start, len);
   tem[len] = '\0';
   work -> btypevec[index] = tem;
 }

committed [PATCH] fix typo in tree-ssa-strlen.c (PR 86696)

[Martin Sebor]

I committed this in r263032.

On 07/27/2018 09:53 AM, Martin Sebor wrote:

My yesterday's change to tree-ssa-strlen.c introduced a test
for INTEGER_TYPE where INTEGRAL_TYPE_P should have been used,
causing a subsequent ICE when the latter was supplied.

The attached patch corrects the test and also makes the subsequent
code more robust and be prepared for the test to fail.

Since the change also caused a couple pf regressions in the Ada
test suite, if there are no objections, I will commit the patch
later today to clear up those failures.

Retested on x86_64-linux with no regressions (including in the Ada
test suite).

Martin

Re: [PATCH] haiku: Initial build support

[Joseph Myers]

On Fri, 27 Jul 2018, Ramana Radhakrishnan wrote:

> Joseph,
> 
> A lot of such information seems to come out from a number of reviewers
> only during patch review from new contributors.  Would you mind
> improving https://gcc.gnu.org/contribute.html and especially around
> "Testing patches" or start something like the glibc contribution
> checklist on the wiki that actually makes a lot of this easy to find
> rather than searching in mailing list archives for new contributors ?

I think the information in my comments about proper contents of the patch 
submission is generally already present in contribute.html.

There may be less information about expectations for target architecture / 
OS maintainers running tests on an ongoing basis.  Perhaps at the Cauldron 
we should discuss whether we wish to move towards a requirement of bots 
posting test results for all new architecture and OS ports?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Avoid infinite loop with duplicate anonymous union fields

[Joseph Myers]

On Fri, 27 Jul 2018, Bogdan Harjoc wrote:

> If a struct contains an anonymous union and both have a field with the
> same name, detect_field_duplicates_hash() will replace one of them
> with NULL. If compilation doesn't stop immediately, it may later call
> lookup_field() on the union, which falsely assumes the union's
> LANG_SPECIFIC array is sorted, and may loop indefinitely because of
> this.
> 
> Reproduced on amd64 since gcc-5, on ubuntu-18.04 and gentoo.
> 
> The patch falls back to iterating via DECL_CHAIN if there was an error
> earlier during compilation.

The patch should also add a testcase to the testsuite (which fails before 
and passes after the patch).

> I ran the gcc testsuite with the result (the FAIL seems unrelated to the 
> patch):
> 
> FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors)

You should use contrib/gcc_update --touch to get timestamps in the right 
order when checking out.  This failure is a symptom of badly ordered 
timestamps.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Fixes to testcase for PR tree-optimization/86636

[David Malcolm]

On Fri, 2018-07-27 at 17:43 +0100, Andre Vieira (lists) wrote:
> On 27/07/18 16:39, David Malcolm wrote:
> > On Thu, 2018-07-26 at 13:22 +0100, Andre Vieira (lists) wrote:
> > 
> > [...snip...]
> > 
> > > > > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > > > > b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > > > > new file mode 100644
> > > > > index 000..2fe2f70
> > > > > --- /dev/null
> > > > > +++ b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > > > > @@ -0,0 +1,8 @@
> > > > > +/* { dg-options "-fsave-optimization-record -ftree-loop-
> > > > > vectorize -ftree-parallelize-loops=2" } */
> > > > > +
> > > > > +void
> > > > > +n2 (int ih)
> > > > > +{
> > > > > +  while (ih < 1)
> > > > > +++ih;
> > > > > +}
> > > > > --
> > > > > 1.8.5.3
> > > > > 
> > > 
> > > Hi David,
> > > 
> > > I believe the test in this patch needs a "{ dg-require-effective-
> > > target
> > > pthread }" as -ftree-parallelize-loops seems to be turning on
> > > -pthread.
> > > 
> > > Cheers,
> > > Andre
> > 
> > Thanks; indeed I now see that every test case using
> >   -ftree-parallelize-loops
> > has such a directive.
> > 
> > Also, the test is missing a dg-do compile.
> > 
> > Does the following look correct?  (borderline covered by "obvious
> > fix"
> > rule).
> > 
> > Dave
> > 
> > 
> > gcc/testsuite/ChangeLog:
> > PR tree-optimization/86636
> > * gcc.c-torture/compile/pr86636.c: Add dg-do compile.
> > Add dg-require-effective-target pthread.
> > ---
> >  gcc/testsuite/gcc.c-torture/compile/pr86636.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > index 2fe2f70..8527a0f 100644
> > --- a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > +++ b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > @@ -1,3 +1,5 @@
> > +/* { dg-do compile } */
> > +/* { dg-require-effective-target pthread } */
> >  /* { dg-options "-fsave-optimization-record -ftree-loop-vectorize
> > -ftree-parallelize-loops=2" } */
> >  
> >  void
> > 
> 
> LGTM, but I am not a maintainer. I too would think you might would be
> ok
> with a "obvious fix" here.

Thanks for giving it another pair of eyes; given that, I've committed
it to trunk (r263031) under the "obvious fix" rule.

Dave

Re: [PATCH] enhance strlen to understand MEM_REF and partial overlaps (PR 86042, 86043)

[Martin Sebor]

On 07/27/2018 10:17 AM, Eric Botcazou wrote:

FWIW, there are 128 failures in the GCC test suite on x86_64.
Many of these have been there for weeks (e.g., the lto failures
due to PR86004), even years (guality).  My script to compare
the results against a baseline uses the following regular
expression to extract the names of failing (and other
"interesting") tests.


Why not just use "make mail-report.log" ?


My script downloads the latest result posted to gcc-testresults
for the target I'm building for, iterates over the interesting
test results in my build logs, compares them to the baseline,
and prints a condensed report like the one in the attachment.
This helps me decide what failures to look into and which ones
are probably safe to ignore.  The tests marked with '!' are
regressions in my run vs the baseline.  I only look at those,
and only those I don't recognize (which admittedly is error-prone).

The others are either the same failures or improvements.
(The numbers in parentheses show the difference between the number
of times the test was seen to fail in the baseline vs in my run.)

What I was trying to highlight is that rolling my own solution like
this makes missing regressions more likely than having a shared
solution would.  It's a separate issue that some of these failures
continue to persist despite having the appearance of regressions
the LTO failures), and another problem are the failures in
the guality tests.  These also make it more likely that
a regression will be missed.

Martin
!  FAIL: gcc.dg/attr-nonstring-2.c (4: +4)
   FAIL: gcc.dg/guality/pr54200.c (1)
   FAIL: gcc.dg/guality/pr54519-1.c (4: -12)
   FAIL: gcc.dg/guality/pr54519-2.c (2: -2)
   FAIL: gcc.dg/guality/pr54519-3.c (8: -8)
   FAIL: gcc.dg/guality/pr54519-4.c (2: -2)
   FAIL: gcc.dg/guality/pr54519-5.c (2: -2)
   FAIL: gcc.dg/guality/pr54970.c (29: -29)
   FAIL: gcc.dg/guality/pr56154-1.c (1: -1)
   FAIL: gcc.dg/guality/pr59776.c (8: -8)
   FAIL: gcc.dg/guality/pr68860-1.c (24: -24)
   FAIL: gcc.dg/guality/sra-1.c (6: -6)
   FAIL: gcc.dg/guality/vla-1.c (8: -8)
   FAIL: g++.dg/guality/pr55665.C (1: -1)
!  FAIL: g++.dg/lto/20091002-1 (1: +1)
!  FAIL: g++.dg/lto/pr64043 (1: +1)
!  FAIL: g++.dg/lto/pr65193 (1: +1)
!  FAIL: g++.dg/lto/pr65302 (1: +1)
!  FAIL: g++.dg/lto/pr65316 (1: +1)
!  FAIL: g++.dg/lto/pr65549 (2: +2)
!  FAIL: g++.dg/lto/pr66180 (1: +1)
!  FAIL: g++.dg/lto/pr66705 (1: +1)
!  FAIL: g++.dg/lto/pr68057 (4: +4)
!  FAIL: g++.dg/lto/pr69077 (1: +1)
!  FAIL: g++.dg/lto/pr69133 (1: +1)
!  FAIL: g++.dg/lto/pr69137 (1: +1)
!  FAIL: g++.dg/lto/pr79000 (1: +1)
!  FAIL: g++.dg/lto/pr81940 (1: +1)
!  FAIL: g++.dg/lto/pr85176 (1: +1)
   FAIL: g++.dg/pr80481.C (3)
   FAIL: g++.dg/pr83239.C (2)
!  FAIL: gfortran.dg/derived_constructor_comps_5.f90 (6: +6)
!  FAIL: gfortran.dg/lto/pr79108 (1: +1)
!  FAIL: ./index0-out.go (1: +1)
! UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c (1: +1)
! UNRESOLVED: gcc.dg/tree-prof/pr59003.c (1: +1)
! UNRESOLVED: gcc.dg/tree-prof/wcoverage-mismatch.c (2: +2)
! UNRESOLVED: g++.dg/bprob/g++-bprob-2.C (2: +2)
! UNRESOLVED: gfortran.dg/derived_constructor_comps_5.f90 (3: +3)
  UNRESOLVED: libgomp.oacc-c++/non-scalar-data.C (1: -1)
  XPASS: gcc.dg/guality/example.c (3: -7)
  XPASS: gcc.dg/guality/guality.c (8: -8)
  XPASS: gcc.dg/guality/inline-params.c (5: -5)
  XPASS: gcc.dg/guality/pr41353-1.c (2: -3)
  XPASS: gcc.dg/guality/pr54970.c (5: -5)
warnings found:
 360   Wabi
   7   Wcast-function-type
   4   Wcpp
   6   Wdeprecated-copy
   5   Wformat-truncation=
   8   Wimplicit-fallthrough=
  14   Wincompatible-pointer-types
  49   Wmaybe-uninitialized
  43   Wmisleading-indentation
  12   Wnonnull
   8   Wsign-compare
   4   Wstringop-truncation
  19   Wuninitialized
   2   Wunused-function
  20   Wunused-parameter

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

[Nicolas Pitre]

On Fri, 27 Jul 2018, Wilco Dijkstra wrote:

> Nicolas Pitre wrote:
> 
> >> However if r4 is non-zero, the carry will be set, and the tsths will be 
> >> executed. This
> >> clears the carry and sets the Z flag based on bit 20.
> >
> > No, not at all. The carry is not affected. And that's the point of the 
> > tst instruction here rather than a cmp: it sets the N and Z flags but 
> > leaves C alone as there is no shifter involved.
> 
> No, the carry is always set by logical operations with a shifted immediate. 
> It is only
> unchanged if the immediate uses a zero rotate. So any shifted immediate > 255
> will set the carry.

Holy cow !!!

Who knows all the bugs I must have created in the past 25 years having 
missed this particular subtlety.

Here's the updated patch with your suggestion.
diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index c13bf4cb2f6..c19d05c8a2e 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,9 @@
+2018-07-26  Nicolas Pitre 
+
+   * config/arm/ieee754-df.S: Don't shortcut denormal handling when
+   exponent goes negative. Update my email address.
+   * config/arm/ieee754-sf.S: Likewise.
+
 2018-07-05  James Clarke  
 
* configure: Regenerated.
diff --git a/libgcc/config/arm/ieee754-df.S b/libgcc/config/arm/ieee754-df.S
index 8741aa99245..9a1b2dd2a4e 100644
--- a/libgcc/config/arm/ieee754-df.S
+++ b/libgcc/config/arm/ieee754-df.S
@@ -1,7 +1,7 @@
 /* ieee754-df.S double-precision floating point support for ARM
 
Copyright (C) 2003-2018 Free Software Foundation, Inc.
-   Contributed by Nicolas Pitre (n...@cam.org)
+   Contributed by Nicolas Pitre (n...@fluxnic.net)
 
This file is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
@@ -238,9 +238,10 @@ LSYM(Lad_a):
movsip, ip, lsl #1
adcsxl, xl, xl
adc xh, xh, xh
-   tst xh, #0x0010
-   sub r4, r4, #1
-   bne LSYM(Lad_e)
+   subsr4, r4, #1
+   do_it   hs
+   cmphs   xh, #0x0010
+   bhs LSYM(Lad_e)
 
@ No rounding necessary since ip will always be 0 at this point.
 LSYM(Lad_l):
diff --git a/libgcc/config/arm/ieee754-sf.S b/libgcc/config/arm/ieee754-sf.S
index d80d5e9080c..b8a81279a3c 100644
--- a/libgcc/config/arm/ieee754-sf.S
+++ b/libgcc/config/arm/ieee754-sf.S
@@ -1,7 +1,7 @@
 /* ieee754-sf.S single-precision floating point support for ARM
 
Copyright (C) 2003-2018 Free Software Foundation, Inc.
-   Contributed by Nicolas Pitre (n...@cam.org)
+   Contributed by Nicolas Pitre (n...@fluxnic.net)
 
This file is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
@@ -168,10 +168,11 @@ LSYM(Lad_e):
 LSYM(Lad_a):
movsr1, r1, lsl #1
adc r0, r0, r0
-   tst r0, #0x0080
-   sub r2, r2, #1
-   bne LSYM(Lad_e)
-   
+   subsr2, r2, #1
+   do_it   hs
+   cmphs   r0, #0x0080
+   bhs LSYM(Lad_e)
+
@ No rounding necessary since r1 will always be 0 at this point.
 LSYM(Lad_l):
 

Re: [PATCH] Fixes to testcase for PR tree-optimization/86636

[Andre Vieira (lists)]

On 27/07/18 16:39, David Malcolm wrote:
> On Thu, 2018-07-26 at 13:22 +0100, Andre Vieira (lists) wrote:
> 
> [...snip...]
> 
 diff --git a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
 b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
 new file mode 100644
 index 000..2fe2f70
 --- /dev/null
 +++ b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
 @@ -0,0 +1,8 @@
 +/* { dg-options "-fsave-optimization-record -ftree-loop-
 vectorize -ftree-parallelize-loops=2" } */
 +
 +void
 +n2 (int ih)
 +{
 +  while (ih < 1)
 +++ih;
 +}
 --
 1.8.5.3

>>
>> Hi David,
>>
>> I believe the test in this patch needs a "{ dg-require-effective-
>> target
>> pthread }" as -ftree-parallelize-loops seems to be turning on
>> -pthread.
>>
>> Cheers,
>> Andre
> 
> Thanks; indeed I now see that every test case using
>   -ftree-parallelize-loops
> has such a directive.
> 
> Also, the test is missing a dg-do compile.
> 
> Does the following look correct?  (borderline covered by "obvious fix"
> rule).
> 
> Dave
> 
> 
> gcc/testsuite/ChangeLog:
>   PR tree-optimization/86636
>   * gcc.c-torture/compile/pr86636.c: Add dg-do compile.
>   Add dg-require-effective-target pthread.
> ---
>  gcc/testsuite/gcc.c-torture/compile/pr86636.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr86636.c 
> b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> index 2fe2f70..8527a0f 100644
> --- a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> @@ -1,3 +1,5 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target pthread } */
>  /* { dg-options "-fsave-optimization-record -ftree-loop-vectorize 
> -ftree-parallelize-loops=2" } */
>  
>  void
> 

LGTM, but I am not a maintainer. I too would think you might would be ok
with a "obvious fix" here.

Cheers,
Andre

Re: [PATCH] enhance strlen to understand MEM_REF and partial overlaps (PR 86042, 86043)

[Eric Botcazou]

> FWIW, there are 128 failures in the GCC test suite on x86_64.
> Many of these have been there for weeks (e.g., the lto failures
> due to PR86004), even years (guality).  My script to compare
> the results against a baseline uses the following regular
> expression to extract the names of failing (and other
> "interesting") tests. 

Why not just use "make mail-report.log" ?

-- 
Eric Botcazou

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

[Wilco Dijkstra]

Nicolas Pitre wrote:

>> However if r4 is non-zero, the carry will be set, and the tsths will be 
>> executed. This
>> clears the carry and sets the Z flag based on bit 20.
>
> No, not at all. The carry is not affected. And that's the point of the 
> tst instruction here rather than a cmp: it sets the N and Z flags but 
> leaves C alone as there is no shifter involved.

No, the carry is always set by logical operations with a shifted immediate. It 
is only
unchanged if the immediate uses a zero rotate. So any shifted immediate > 255
will set the carry. This is detailed in the Arm Architecture Reference Manual, 
eg.
see the pseudo code for A32ExpandImm_C in LSL (immediate).

Wilco

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

[Nicolas Pitre]

On Fri, 27 Jul 2018, Nicolas Pitre wrote:

> On Fri, 27 Jul 2018, Wilco Dijkstra wrote:
> 
> > Hi Nicolas,
> > 
> > I think your patch doesn't quite work as expected:
> > 
> > @@ -238,9 +238,10 @@ LSYM(Lad_a):
> > movsip, ip, lsl #1
> > adcsxl, xl, xl
> > adc xh, xh, xh
> > -   tst xh, #0x0010
> > -   sub r4, r4, #1
> > -   bne LSYM(Lad_e)
> > +   subsr4, r4, #1
> > +   do_it   hs
> > +   tsths   xh, #0x0010
> > +   bhi LSYM(Lad_e)
> > 
> > If the exponent in r4 is zero, the carry bit will be clear, so we don't 
> > execute the tsths
> > and fallthrough (the denormal will be normalized and then denormalized 
> > again, but
> > that's so rare it doesn't matter really).
> 
> And that's what is intended.
> 
> > However if r4 is non-zero, the carry will be set, and the tsths will be 
> > executed. This
> > clears the carry and sets the Z flag based on bit 20.
> 
> No, not at all. The carry is not affected. And that's the point of the 
> tst instruction here rather than a cmp: it sets the N and Z flags but 
> leaves C alone as there is no shifter involved.

That being said, a cmp as you suggested would have worked too (with the 
bhi changed to bhs). But the patch as is produces the same behavior.


Nicolas

[PATCH] fix typo in tree-ssa-strlen.c (PR 86696)

[Martin Sebor]

My yesterday's change to tree-ssa-strlen.c introduced a test
for INTEGER_TYPE where INTEGRAL_TYPE_P should have been used,
causing a subsequent ICE when the latter was supplied.

The attached patch corrects the test and also makes the subsequent
code more robust and be prepared for the test to fail.

Since the change also caused a couple pf regressions in the Ada
test suite, if there are no objections, I will commit the patch
later today to clear up those failures.

Retested on x86_64-linux with no regressions (including in the Ada
test suite).

Martin
PR tree-optimization/86696 - ICE in handle_char_store at gcc/tree-ssa-strlen.c:3332

gcc/ChangeLog:

	PR tree-optimization/86696
	* tree-ssa-strlen.c (get_min_string_length): Handle all integer
	types, including enums.
	(handle_char_store): Be prepared for the above function to fail.

gcc/testsuite/ChangeLog:

	PR tree-optimization/86696
	* gcc.dg/pr86696.C: New test.

Index: gcc/testsuite/g++.dg/pr86696.C
===
--- gcc/testsuite/g++.dg/pr86696.C	(nonexistent)
+++ gcc/testsuite/g++.dg/pr86696.C	(working copy)
@@ -0,0 +1,30 @@
+/* PR tree-optimization/86696 - ICE in handle_char_store at
+   gcc/tree-ssa-strlen.c
+   { dg-do compile }
+   { dg-options "-O2 -Wall -std=c++11" } */
+
+typedef char a;
+template  struct c {
+  int d;
+  b e;
+};
+struct f;
+class g {
+public:
+  void h(c);
+};
+enum i {};
+enum j : a { k, l };
+struct f {
+  i m;
+  a n;
+  a o;
+  a p;
+  j family;
+};
+void fn1() {
+  i format{};
+  f info{format, a(), 0, 4, l};
+  g dest;
+  dest.h({format, info});
+}
Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c	(revision 263030)
+++ gcc/tree-ssa-strlen.c	(working copy)
@@ -3150,7 +3150,7 @@ handle_pointer_plus (gimple_stmt_iterator *gsi)
 static HOST_WIDE_INT
 get_min_string_length (tree rhs, bool *full_string_p)
 {
-  if (TREE_CODE (TREE_TYPE (rhs)) == INTEGER_TYPE)
+  if (INTEGRAL_TYPE_P (TREE_TYPE (rhs)))
 {
   if (tree_expr_nonzero_p (rhs))
 	{
@@ -3315,9 +3315,16 @@ handle_char_store (gimple_stmt_iterator *gsi)
 	 Otherwise, we're storing an unknown value at offset OFFSET,
 	 so need to clip the nonzero_chars to OFFSET.  */
 	  bool full_string_p = storing_all_zeros_p;
-	  HOST_WIDE_INT len = (storing_nonzero_p
-			   ? get_min_string_length (rhs, &full_string_p)
-			   : 1);
+	  HOST_WIDE_INT len = 1;
+	  if (storing_nonzero_p)
+	{
+	  /* Try to get the minimum length of the string (or
+		 individual character) being stored.  If it fails,
+		 STORING_NONZERO_P guarantees it's at least 1.  */
+	  len = get_min_string_length (rhs, &full_string_p);
+	  if (len < 0)
+		len = 1;
+	}
 
 	  location_t loc = gimple_location (stmt);
 	  tree oldlen = si->nonzero_chars;

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

[Nicolas Pitre]

On Fri, 27 Jul 2018, Wilco Dijkstra wrote:

> Hi Nicolas,
> 
> I think your patch doesn't quite work as expected:
> 
> @@ -238,9 +238,10 @@ LSYM(Lad_a):
>   movsip, ip, lsl #1
>   adcsxl, xl, xl
>   adc xh, xh, xh
> - tst xh, #0x0010
> - sub r4, r4, #1
> - bne LSYM(Lad_e)
> + subsr4, r4, #1
> + do_it   hs
> + tsths   xh, #0x0010
> + bhi LSYM(Lad_e)
> 
> If the exponent in r4 is zero, the carry bit will be clear, so we don't 
> execute the tsths
> and fallthrough (the denormal will be normalized and then denormalized again, 
> but
> that's so rare it doesn't matter really).

And that's what is intended.

> However if r4 is non-zero, the carry will be set, and the tsths will be 
> executed. This
> clears the carry and sets the Z flag based on bit 20.

No, not at all. The carry is not affected. And that's the point of the 
tst instruction here rather than a cmp: it sets the N and Z flags but 
leaves C alone as there is no shifter involved.


Nicolas

Re: [PATCH] Fix hard regno checks

[Vladimir Makarov]

On 07/23/2018 05:14 AM, Ilya Leoshkevich wrote:

FIRST_PSEUDO_REGISTER is not a hard regno, so comparisons should use
"<" instead of "<=", and ">=" instread of ">".


Thank you for finding these typos.  LRA parts of the patch are ok for me.

Re: [PATCH 09/11] pdp11 - example of a port not needing a speculation barrier

[Richard Biener]

On July 27, 2018 3:27:49 PM GMT+02:00, Paul Koning  
wrote:
>
>
>> On Jul 27, 2018, at 5:37 AM, Richard Earnshaw
> wrote:
>> 
>> 
>> This patch is intended as an example of all that is needed if the
>> target system doesn't support CPUs that have speculative execution.
>> I've chosen the pdp11 port on the basis that it's old enough that
>this
>> is likely to be true for all existing implementations and that there
>> is also little chance of that changing in future!
>> 
>>  * config/pdp11/pdp11.c (TARGET_HAVE_SPECULATION_SAFE_VALUE):
>Redefine
>>  to speculation_safe_value_not_needed.
>> ---
>> gcc/config/pdp11/pdp11.c | 3 +++
>> 1 file changed, 3 insertions(+)
>> 
>> <0009-pdp11-example-of-a-port-not-needing-a-speculation-ba.patch>
>
>Correct, no speculative instruction now, and I don't think any of the
>people constructing PDP11s (yes there are some) are going to be adding
>it.

It's not really about speculative instructions but about things like having a 
branch predictor and ways to recover from badly predicted ones and thus from 
wrongly speculatively executed regular instructions. 

Probably every pipelined CPU implementation nowadays has speculative execution. 

Richard. 

>Thanks Richard.
>
>   paul

Re: [RFC] Fix recent popcount change is breaking

[Richard Biener]

On July 27, 2018 3:33:59 PM GMT+02:00, "Martin Liška"  wrote:
>On 07/11/2018 02:31 PM, Richard Biener wrote:
>> Why not simply make popcountdi available in the kernel?  They do have
>> implementations for other libgcc functions IIRC.
>
>Can you please Kugan create Linux kernel bug for that? So that
>discussion
>can happen?

There's no discussion necessary, libgcc is the core compiler runtime. If you 
choose not to use it you have to provide your own implementation. 

Richard. 

>Thanks,
>Martin

Re: Fwd: [PATCH, rs6000] Replace __uint128_t and __int128_t with __uint128 and __int128 in Power PC built-in documentation

[Kelvin Nilsen]

Thanks for review and approval.  To respond to your question about error 
messages:
> 
> microdoc3.c:22:3: error: invalid parameter combination for AltiVec intrinsic 
> ‘__builtin_vec_vaddcuq’
>u1 = vec_vaddcuq (d2, d3);
>^~

On 7/26/18 9:54 AM, Segher Boessenkool wrote:
> On Thu, Jul 26, 2018 at 08:40:01AM -0500, Kelvin Nilsen wrote:
>> To improve internal consistency and to improve consistency with published 
>> ABI documents, this patch replaces the __uint128_t type with __uint128 and 
>> replaces __int128_t with __int128.
> 
>> Is this ok for trunk?
> 
> Looks good, thanks!  Most (all?) of these functions are not documented
> in the ABI, but this is a step forward anyway.  Okay for trunk.
> 
> What do things like error messages involving these functions look like?
> What types do those say?
> 
> 
> Segher
> 
> 

Re: [PATCH] enhance strlen to understand MEM_REF and partial overlaps (PR 86042, 86043)

[Martin Sebor]

On 07/27/2018 03:05 AM, Eric Botcazou wrote:

I missed your approval and didn't get to committing the patch
until today.  While retesting it on top of fresh trunk I noticed
a few test failures due to other recent strlen changes.  I made
adjustments to the patch to avoid most of them and opened bug
86688 for one that I think needs a separate code change and
xfailed the test cases until the bug gets resolved.


But it has introduced a couple of regressions in the ACATS testsuite:

FAIL:   c52103c
FAIL:   cde0001

=== acats Summary ===
# of expected passes2318
# of unexpected failures2
Native configuration is x86_64-suse-linux-gnu


Yes, I didn't see these failures, sorry.

FWIW, there are 128 failures in the GCC test suite on x86_64.
Many of these have been there for weeks (e.g., the lto failures
due to PR86004), even years (guality).  My script to compare
the results against a baseline uses the following regular
expression to extract the names of failing (and other
"interesting") tests.  As it happens, the Ada logs have
extra spaces before the test names that makes the script
exclude them from the list:

tlist=$(sed -n -e "s/^FAIL: \([^ ]*\) .*/\1/p" \
   -e "s/^XFAIL: \([^ ]*\) .*/\1/p" \
   -e "s/^UNRESOLVED: \([^ ]*\) .*/\1/p" \
   -e "s/^XPASS: \([^ ]*\) .*/\1/p" \
   test_summary.log \
| sort -u)

Martin

[PING] Re: [PATCH] C++: suggestions for misspelled private members (PR c++/84993)

[David Malcolm]

Ping:
  https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00594.html

On Wed, 2018-07-11 at 22:42 -0400, David Malcolm wrote:
> PR c++/84993 identifies a problem with our suggestions for
> misspelled member names in the C++ FE for the case where the
> member is private.
> 
> For example, given:
> 
> class foo
> {
> public:
>   double get_ratio() const { return m_ratio; }
> 
> private:
>   double m_ratio;
> };
> 
> void test(foo *ptr)
> {
>   if (ptr->ratio >= 0.5)
> ;// etc
> }
> 
> ...we currently emit this suggestion:
> 
> : In function 'void test(foo*)':
> :12:12: error: 'class foo' has no member named 'ratio'; did
> you mean 'm_ratio'?
>if (ptr->ratio >= 0.5)
> ^
> m_ratio
> 
> ...but if the user follows this suggestion, they get:
> 
> : In function 'void test(foo*)':
> :12:12: error: 'double foo::m_ratio' is private within this
> context
>if (ptr->m_ratio >= 0.5)
> ^~~
> :7:10: note: declared private here
>double m_ratio;
>   ^~~
> :12:12: note: field 'double foo::m_ratio' can be accessed via
> 'double foo::get_ratio() const'
>if (ptr->m_ratio >= 0.5)
> ^~~
> get_ratio()
> 
> It feels wrong to be emitting a fix-it hint that doesn't compile, so
> this
> patch adds the accessor fix-it hint logic to this case, so that we
> directly
> offer a valid suggestion:
> 
> : In function 'void test(foo*)':
> :12:12: error: 'class foo' has no member named 'ratio'; did
> you mean
> 'double foo::m_ratio'? (accessible via 'double foo::get_ratio()
> const')
>if (ptr->ratio >= 0.5)
> ^
> get_ratio()
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
> adds 105 PASS results to g++.sum.
> 
> OK for trunk?
> 
> gcc/cp/ChangeLog:
>   PR c++/84993
>   * call.c (enforce_access): Move diagnostics to...
>   (complain_about_access): ...this new function.
>   * cp-tree.h (class access_failure_info): Rename split out field
>   "m_field_decl" into "m_decl" and "m_diag_decl".
>   (access_failure_info::record_access_failure): Add tree param.
>   (access_failure_info::was_inaccessible_p): New accessor.
>   (access_failure_info::get_decl): New accessor.
>   (access_failure_info::get_diag_decl): New accessor.
>   (access_failure_info::get_any_accessor): New member function.
>   (access_failure_info::add_fixit_hint): New static member
> function.
>   (complain_about_access): New decl.
>   * typeck.c (access_failure_info::record_access_failure): Update
>   for change to fields.
>   (access_failure_info::maybe_suggest_accessor): Split out
> into...
>   (access_failure_info::get_any_accessor): ...this new
> function...
>   (access_failure_info::add_fixit_hint): ...and this new
> function.
>   (finish_class_member_access_expr): Split out "has no member
> named"
>   error-handling into...
>   (complain_about_unrecognized_member): ...this new function, and
>   check that the guessed name is accessible along the access
> path.
>   Only provide a spell-correction fix-it hint if it is;
> otherwise,
>   attempt to issue an accessor fix-it hint.
> 
> gcc/testsuite/ChangeLog:
>   PR c++/84993
>   * g++.dg/torture/accessor-fixits-9.C: New test.
> ---
>  gcc/cp/call.c|  64 ++
>  gcc/cp/cp-tree.h |  17 ++-
>  gcc/cp/typeck.c  | 150
> +--
>  gcc/testsuite/g++.dg/torture/accessor-fixits-9.C | 119
> ++
>  4 files changed, 282 insertions(+), 68 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/torture/accessor-fixits-9.C
> 
> diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> index 209c1fd..121f0ca 100644
> --- a/gcc/cp/call.c
> +++ b/gcc/cp/call.c
> @@ -6456,6 +6456,38 @@ build_op_delete_call (enum tree_code code,
> tree addr, tree size,
>return error_mark_node;
>  }
>  
> +/* Issue diagnostics about a disallowed access of DECL, using
> DIAG_DECL
> +   in the diagnostics.
> +
> +   If ISSUE_ERROR is true, then issue an error about the
> +   access, followed by a note showing the declaration.
> +   Otherwise, just show the note.  */
> +
> +void
> +complain_about_access (tree decl, tree diag_decl, bool issue_error)
> +{
> +  if (TREE_PRIVATE (decl))
> +{
> +  if (issue_error)
> + error ("%q#D is private within this context", diag_decl);
> +  inform (DECL_SOURCE_LOCATION (diag_decl),
> +   "declared private here");
> +}
> +  else if (TREE_PROTECTED (decl))
> +{
> +  if (issue_error)
> + error ("%q#D is protected within this context", diag_decl);
> +  inform (DECL_SOURCE_LOCATION (diag_decl),
> +   "declared protected here");
> +}
> +  else
> +{
> +  if (issue_error)
> + error ("%q#D is inaccessible within this context",
> diag_decl);
> +  inform (DECL_SOURCE_LOCATION (diag_decl), "declared here");

[PATCH] Fixes to testcase for PR tree-optimization/86636

[David Malcolm]

On Thu, 2018-07-26 at 13:22 +0100, Andre Vieira (lists) wrote:

[...snip...]

> > > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > > b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > > new file mode 100644
> > > index 000..2fe2f70
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > > @@ -0,0 +1,8 @@
> > > +/* { dg-options "-fsave-optimization-record -ftree-loop-
> > > vectorize -ftree-parallelize-loops=2" } */
> > > +
> > > +void
> > > +n2 (int ih)
> > > +{
> > > +  while (ih < 1)
> > > +++ih;
> > > +}
> > > --
> > > 1.8.5.3
> > > 
> 
> Hi David,
> 
> I believe the test in this patch needs a "{ dg-require-effective-
> target
> pthread }" as -ftree-parallelize-loops seems to be turning on
> -pthread.
> 
> Cheers,
> Andre

Thanks; indeed I now see that every test case using
  -ftree-parallelize-loops
has such a directive.

Also, the test is missing a dg-do compile.

Does the following look correct?  (borderline covered by "obvious fix"
rule).

Dave


gcc/testsuite/ChangeLog:
PR tree-optimization/86636
* gcc.c-torture/compile/pr86636.c: Add dg-do compile.
Add dg-require-effective-target pthread.
---
 gcc/testsuite/gcc.c-torture/compile/pr86636.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/testsuite/gcc.c-torture/compile/pr86636.c 
b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
index 2fe2f70..8527a0f 100644
--- a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
@@ -1,3 +1,5 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target pthread } */
 /* { dg-options "-fsave-optimization-record -ftree-loop-vectorize 
-ftree-parallelize-loops=2" } */
 
 void
-- 
1.8.5.3

Re: [PATCH] Fix an UBSAN error in cp/parse.c (PR c++/86653).

[Nathan Sidwell]

On 07/26/2018 04:52 AM, Martin Liška wrote:

Hello.

Quite simple patch that initializes a boolean value before it's used.
The variable is not initialized when an error recovery happens.

Ready for trunk after testing?



ok, thanks

nathan

--
Nathan Sidwell

Re: [RFC] Fix recent popcount change is breaking

[Martin Liška]

On 07/11/2018 02:31 PM, Richard Biener wrote:
> Why not simply make popcountdi available in the kernel?  They do have
> implementations for other libgcc functions IIRC.

Can you please Kugan create Linux kernel bug for that? So that discussion
can happen?

Thanks,
Martin

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

[Wilco Dijkstra]

Hi Nicolas,

I think your patch doesn't quite work as expected:

@@ -238,9 +238,10 @@ LSYM(Lad_a):
movsip, ip, lsl #1
adcsxl, xl, xl
adc xh, xh, xh
-   tst xh, #0x0010
-   sub r4, r4, #1
-   bne LSYM(Lad_e)
+   subsr4, r4, #1
+   do_it   hs
+   tsths   xh, #0x0010
+   bhi LSYM(Lad_e)

If the exponent in r4 is zero, the carry bit will be clear, so we don't execute 
the tsths
and fallthrough (the denormal will be normalized and then denormalized again, 
but
that's so rare it doesn't matter really).

However if r4 is non-zero, the carry will be set, and the tsths will be 
executed. This
clears the carry and sets the Z flag based on bit 20. We will now also always
fallthrough rather than take the branch if bit 20 is non-zero. This may still 
give the
correct answer, however it would add considerable extra overhead... I think 
using
a cmp rather than tst would work.

Wilco

Re: [PATCH 09/11] pdp11 - example of a port not needing a speculation barrier

[Paul Koning]

> On Jul 27, 2018, at 5:37 AM, Richard Earnshaw  
> wrote:
> 
> 
> This patch is intended as an example of all that is needed if the
> target system doesn't support CPUs that have speculative execution.
> I've chosen the pdp11 port on the basis that it's old enough that this
> is likely to be true for all existing implementations and that there
> is also little chance of that changing in future!
> 
>   * config/pdp11/pdp11.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Redefine
>   to speculation_safe_value_not_needed.
> ---
> gcc/config/pdp11/pdp11.c | 3 +++
> 1 file changed, 3 insertions(+)
> 
> <0009-pdp11-example-of-a-port-not-needing-a-speculation-ba.patch>

Correct, no speculative instruction now, and I don't think any of the people 
constructing PDP11s (yes there are some) are going to be adding it.

Thanks Richard.

paul

[PATCH] [MSP430] Fix PR/86662

[Jozef Lawrynowicz]

As reported in PR/86662, use of __int20 in a program built with -mlarge and
-flto causes a segfault for msp430 due to endless recursion in
gimple_get_alias_set.
The attached patch fixes this.
The segfault can be observed on the gcc-7 and gcc-8 branches, and on trunk.
The testcase works in gcc-6

Successfully boostrapped and regtested on x86_64-pc-linux-gnu and msp430-elf.
This fixes many LTO C and C++ tests for msp430 when the testsuite is invoked
with the -mlarge target flag.

Ok for gcc-7-branch, gcc-8-branch, and trunk?

>From 01f8e76dbf50265ae9a3f5f665d27ac8cf811b0c Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Tue, 24 Jul 2018 23:24:41 +0100
Subject: [PATCH][MSP430] Fix PR86662 

2018-07-27  Jozef Lawrynowicz  

	PR target/86662
	* gcc/tree.c (build_common_tree_nodes): Initialize integer_types array
	with all enabled __intN types.

	* gcc/testsuite/gcc.target/msp430/pr86662.c: New test.

---
 gcc/testsuite/gcc.target/msp430/pr86662.c | 13 +
 gcc/tree.c|  3 +--
 2 files changed, 14 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/msp430/pr86662.c

diff --git a/gcc/testsuite/gcc.target/msp430/pr86662.c b/gcc/testsuite/gcc.target/msp430/pr86662.c
new file mode 100644
index 000..1144b3e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/pr86662.c
@@ -0,0 +1,13 @@
+/* PR/86662 */
+
+/* { dg-do link } */
+/* -nostdlib prevents link errors due to mismatched code models for
+   libgloss objects.  */
+/* { dg-options "-mlarge -flto -nostdlib" } */
+/* { dg-skip-if "" { *-*-* } { "-mcpu=msp430" } } */
+
+int main(void)
+{
+  __int20 n = 5;
+  return 0;
+}
diff --git a/gcc/tree.c b/gcc/tree.c
index bace9c8..54384ad 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -9802,8 +9802,7 @@ build_common_tree_nodes (bool signed_char)
   int_n_trees[i].signed_type = make_signed_type (int_n_data[i].bitsize);
   int_n_trees[i].unsigned_type = make_unsigned_type (int_n_data[i].bitsize);
 
-  if (int_n_data[i].bitsize > LONG_LONG_TYPE_SIZE
-	  && int_n_enabled_p[i])
+  if (int_n_enabled_p[i])
 	{
 	  integer_types[itk_intN_0 + i * 2] = int_n_trees[i].signed_type;
 	  integer_types[itk_unsigned_intN_0 + i * 2] = int_n_trees[i].unsigned_type;
-- 
2.7.4

Re: [PATCH] haiku: Initial build support

[Alexander von Gluck IV]

July 27, 2018 6:59 AM, "Ramana Radhakrishnan"  wrote:
> On Thu, Jul 26, 2018 at 6:26 PM, Joseph Myers  wrote:
> 
>> On Mon, 16 Jul 2018, Alexander von Gluck IV wrote:
>> 
>>> * 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:
>>> .
>>> .. and maybe more!
>> 
>> Before this can be reviewed, we'll need copyright assignments (with
>> employer disclaimers where applicable) on file at the FSF from everyone
>> who contributed a legally significant amount of code (more than around 15
>> lines). Without those, reviewers can't safely look at the changes in
>> detail.
>>
>> https://gcc.gnu.org/contribute.html

Can-do.  I'll reach out to those involved.
None of these commits are coorporate sponsored.

>> https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
>> 
>> Then, please make sure that only substantive changes are included - that
>> there are no diff lines that are purely changing trailing whitespace in
>> existing code, for example. Please ensure that all copyright and license
>> notices follow current standards (which means using ranges of years ending
>> in 2018, GPLv3 notices and a URL not an FSF postal address).

>> For changes to existing code, especially, please make sure to include
>> sufficient rationale in the patch submission to explain those changes,
>> why they are needed and the approach taken to them.

Can-do.  The white-space issues definitely need to be corrected.

>> 
>> For new target OS support, I'd expect details to be provided of the test
>> results on that OS for the various architectures supported by GCC. Are
>> you planning, if the support is accepted in GCC, to maintain a bot that
>> keeps running the GCC testsuite for GCC mainline for this OS for the
>> various target architectures supported, at least daily or thereabouts, and
>> posts the results to the gcc-testresults list, and to keep monitoring the
>> test results and fixing OS-specific issues that show up?

We have some (limited) space reserved on our core infrastructure for such
builders. We also have a global network of physical builders managed by
project volunteers and sponsored by Mozilla. (hand-me-downs builders :-))

>> It's much better for issues to be identified within a day or two of the
>> commit causing them than many months later, possibly only after a release
>> has come out with the issue - but that requires an ongoing commitment to
>> keep monitoring test results, posting them to gcc-testresults and keeping
>> them in good shape.

This is good information, however, does GCC have docs for this? We are a
small team of open source developers with maybe a few man-hours a month
available to dedicate to gcc maintainership. (no excuses, just trying
to set the expectations)

These steps seem like what's needed on a first-class platform (Linux, OS X,
etc). So the same requirements apply to all new GCC platforms code?

I'd assume when introducing new platform support, some leeway would be
provided until the platform could be flagged as stable (or jump up a
more "supported" level).  Of course, any changes which would present
risk to unrelated platforms (Linux, etc) would need increased scrutiny.

On a side / unrelated note, we have been upstream in clang / llvm for
quite some time... my goals here are to get gcc to the same level
of support.

> A lot of such information seems to come out from a number of reviewers
> only during patch review from new contributors. Would you mind
> improving https://gcc.gnu.org/contribute.html and especially around
> "Testing patches" or start something like the glibc contribution
> checklist on the wiki that actually makes a lot of this easy to find
> rather than searching in mailing list archives for new contributors ?

+1.  It would be nice to have expectations posted. I came into this 
a little blind based on that article.

>>> diff --git a/libtool.m4 b/libtool.m4
>> 
>> If this an exact backport of a change from upstream libtool git? If so,
>> please give the commit reference. If not, give the URL of the submission
>> to upstream libtool. We don't want local libtool changes that aren't
>> backports or at least proposed upstream without objections, to avoid
>> making future updates from upstream libtool harder.

Yeah, I wasn't 100% on what the best process was here.

We have been in upstream autotools for quite a few years... i'll see
if this needs to be moved to libtool upstream.


 -- Alexander von Gluck IV

[gomp5] Add omp_pause_resource{,_all} support

[Jakub Jelinek]

Hi!

This patch adds omp_pause_resource{,_all} APIs.  So far they do something
only for the host device, where they free the thread pool (if any),
including pthread_join waiting for the threads in that team (this means
we don't create threads as detached anymore, but instead detach them before
pthread_exit).

With this people can e.g. omp_pause_resource_all (omp_pause_soft); and
then use fork () in a process that uses pthreads only inside of libgomp and
have a chance to use OpenMP in the fork child.

Tested on x86_64-linux, committed to gomp-5_0-branch.

2018-07-27  Jakub Jelinek  

* libgomp.map (OMP_5.0): Export omp_pause_resource{,_all}{,_}.
* omp.h.in (omp_pause_resource_t): New typedef.
(omp_pause_resource, omp_pause_resource_all): New prototypes.
* omp_lib.f90.in (omp_pause_resource_kind, omp_pause_soft,
omp_pause_hard): New parameters.
(omp_pause_resource, omp_pause_resource_all): New interfaces.
* omp_lib.h.in (omp_pause_resource_kind, omp_pause_soft,
omp_pause_hard): New parameters.
(omp_pause_resource, omp_pause_resource_all): New externals.
* libgomp.h (gomp_pause_host): New prototype.
* team.c (gomp_thread_attr): Remove comment.
(gomp_thread_start): Call pthread_detach.
(gomp_free_pool_helper): Likewise.
(gomp_team_start): Don't call pthread_attr_setdetachstate.
(gomp_pause_pool_helper, gomp_pause_host): New functions.
* target.c (omp_pause_resource, omp_pause_resource_all): New functions.
* env.c (initialize_env): Don't call pthread_attr_setdetachstate.
* fortran.c (omp_pause_resource, omp_pause_resource_all): Add
ialias_redirect.
(omp_pause_resource_, omp_pause_resource_all_): New functions.
* config/nvptx/team.c (gomp_pause_host): New function.
* config/nvptx/target.c (omp_pause_resource, omp_pause_resource_all):
New functions.
* testsuite/libgomp.c-c++-common/pause-1.c: New test.
* testsuite/libgomp.c-c++-common/pause-2.c: New test.

--- libgomp.map.jj  2018-07-25 15:50:38.595714295 +0200
+++ libgomp.map 2018-07-27 12:30:13.836168988 +0200
@@ -174,6 +174,10 @@ OMP_5.0 {
omp_get_affinity_format_;
omp_set_affinity_format;
omp_set_affinity_format_;
+   omp_pause_resource;
+   omp_pause_resource_;
+   omp_pause_resource_all;
+   omp_pause_resource_all_;
 } OMP_4.5;
 
 GOMP_1.0 {
--- omp.h.in.jj 2018-06-26 16:31:52.071327689 +0200
+++ omp.h.in2018-07-26 16:50:15.568291658 +0200
@@ -83,6 +83,12 @@ typedef struct __attribute__((__aligned_
   char __omp_depend_t__[2 * sizeof (void *)];
 } omp_depend_t;
 
+typedef enum omp_pause_resource_t
+{
+  omp_pause_soft = 1,
+  omp_pause_hard = 2
+} omp_pause_resource_t;
+
 #ifdef __cplusplus
 extern "C" {
 # define __GOMP_NOTHROW throw ()
@@ -178,6 +184,9 @@ extern void omp_display_affinity (const
 extern __SIZE_TYPE__ omp_capture_affinity (char *, __SIZE_TYPE__, const char *)
   __GOMP_NOTHROW;
 
+extern int omp_pause_resource (omp_pause_resource_t, int) __GOMP_NOTHROW;
+extern int omp_pause_resource_all (omp_pause_resource_t) __GOMP_NOTHROW;
+
 #ifdef __cplusplus
 }
 #endif
--- omp_lib.f90.in.jj   2018-05-23 13:14:15.873893636 +0200
+++ omp_lib.f90.in  2018-07-27 13:51:33.178026630 +0200
@@ -30,6 +30,7 @@
 integer, parameter :: omp_sched_kind = 4
 integer, parameter :: omp_proc_bind_kind = 4
 integer, parameter :: omp_lock_hint_kind = 4
+integer, parameter :: omp_pause_resource_kind = 4
 integer (omp_sched_kind), parameter :: omp_sched_static = 1
 integer (omp_sched_kind), parameter :: omp_sched_dynamic = 2
 integer (omp_sched_kind), parameter :: omp_sched_guided = 3
@@ -54,6 +55,10 @@
  parameter :: omp_lock_hint_nonspeculative = 4
 integer (omp_lock_hint_kind), &
  parameter :: omp_lock_hint_speculative = 8
+integer (kind=omp_pause_resource_kind), &
+ parameter :: omp_pause_soft = 1
+integer (kind=omp_pause_resource_kind), &
+ parameter :: omp_pause_hard = 2
   end module
 
   module omp_lib
@@ -460,4 +465,23 @@
   end function omp_capture_affinity
 end interface
 
+interface
+  function omp_pause_resource (kind, device_num)
+use omp_lib_kinds
+integer (4) :: omp_pause_resource
+integer (kind=omp_pause_resource_kind), &
+  intent(in) :: kind
+integer (4) :: device_num
+  end function
+end interface
+
+interface
+  function omp_pause_resource_all (kind)
+use omp_lib_kinds
+integer (4) :: omp_pause_resource_all
+integer (kind=omp_pause_resource_kind), &
+  intent(in) :: kind
+  end function
+end interface
+
   end module omp_lib
--- omp_lib.h.in.jj 2018-05-23 13:21:07

Re: [PATCH 01/11] Add __builtin_speculation_safe_value

[Richard Earnshaw (lists)]

On 27/07/18 13:11, Nathan Sidwell wrote:

> +  if (!COMPLETE_TYPE_P (type))
> +goto incompatible;
> 
> Are incomplete integral types a thing? (forward enum extension?)
> 

I don't think so, at least not at the level of having an instance of
such a type (as opposed to a pointer to one).  Enums, for example, might
be packed by default, so until the type is complete you don't know its
size or alignment.

Anyway, this bit of code is essentially lifted from sync_resolve_size.

R.

Re: [PATCH 01/11] Add __builtin_speculation_safe_value

[Nathan Sidwell]

On 07/27/2018 08:32 AM, Richard Earnshaw (lists) wrote:


The intention is to allow pointer to anything.


Oh, the speculation safe fetch is of the pointer itself, not the thing 
being pointed to.  I'd missed that.  I'm not sure I understand why that 
needs special casing down to the expander (why can't the resolver figure 
the mode?), but you're the expert in that kind of stuff.



I presume resolve_overloaded_builtin already works correctly with
template instantiations, but a templatatized testcase would be nice --
shout if you'd like help constructing one.



Yelp!


added to todo list.

nathan

--
Nathan Sidwell

Re: [GCC][PATCH][Aarch64] Stop redundant zero-extension after UMOV when in DI mode

[Sudakshina Das]

Hi Sam

On 25/07/18 14:08, Sam Tebbs wrote:

On 07/23/2018 05:01 PM, Sudakshina Das wrote:

Hi Sam


On Monday 23 July 2018 11:39 AM, Sam Tebbs wrote:

Hi all,

This patch extends the aarch64_get_lane_zero_extendsi instruction 
definition to

also cover DI mode. This prevents a redundant AND instruction from being
generated due to the pattern failing to be matched.

Example:

typedef char v16qi __attribute__ ((vector_size (16)));

unsigned long long
foo (v16qi a)
{
  return a[0];
}

Previously generated:

foo:
    umov    w0, v0.b[0]
    and x0, x0, 255
    ret

And now generates:

foo:
    umov    w0, v0.b[0]
    ret

Bootstrapped on aarch64-none-linux-gnu and tested on aarch64-none-elf 
with no

regressions.

gcc/
2018-07-23  Sam Tebbs 

    * config/aarch64/aarch64-simd.md
    (*aarch64_get_lane_zero_extendsi):
    Rename to...
(*aarch64_get_lane_zero_extend): ... This.
    Use GPI iterator instead of SI mode.

gcc/testsuite
2018-07-23  Sam Tebbs 

    * gcc.target/aarch64/extract_zero_extend.c: New file

You will need an approval from a maintainer, but I would only add one 
request to this:


diff --git a/gcc/config/aarch64/aarch64-simd.md 
b/gcc/config/aarch64/aarch64-simd.md

index 89e38e6..15fb661 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -3032,15 +3032,16 @@
   [(set_attr "type" "neon_to_gp")]
 )

-(define_insn "*aarch64_get_lane_zero_extendsi"
-  [(set (match_operand:SI 0 "register_operand" "=r")
-    (zero_extend:SI
+(define_insn "*aarch64_get_lane_zero_extend"
+  [(set (match_operand:GPI 0 "register_operand" "=r")
+    (zero_extend:GPI

Since you are adding 4 new patterns with this change, could you add
more cases in your test as well to make sure you have coverage for 
each of them.


Thanks
Sudi


Hi Sudi,

Thanks for the feedback. Here is an updated patch that adds more 
testcases to cover the patterns generated by the different mode 
combinations. The changelog and description from my original email still 
apply.




Thanks it looks good to me! You will still need a maintainer to approve.

Sudi



   (vec_select:
     (match_operand:VDQQH 1 "register_operand" "w")
     (parallel [(match_operand:SI 2 "immediate_operand" "i")]]
   "TARGET_SIMD"
   {
-    operands[2] = aarch64_endian_lane_rtx (mode, INTVAL 
(operands[2]));

+    operands[2] = aarch64_endian_lane_rtx (mode,
+                       INTVAL (operands[2]));
 return "umov\\t%w0, %1.[%2]";
   }
   [(set_attr "type" "neon_to_gp")]

Re: [PATCH] Add malloc predictor (PR middle-end/83023).

[Marc Glisse]

On Fri, 27 Jul 2018, Martin Liška wrote:


So answer is yes, the builtin can be then removed.


Good, thanks. While looking at how widely it is going to apply, I noticed 
that the default, throwing operator new has attribute malloc and 
everything, but the non-throwing variant declared in  doesn't, so it 
won't benefit from the new predictor. I don't know if there is a good 
reason for this disparity...


--
Marc Glisse

Re: [PATCH 01/11] Add __builtin_speculation_safe_value

[Richard Earnshaw (lists)]

On 27/07/18 13:11, Nathan Sidwell wrote:
> On 07/27/2018 05:37 AM, Richard Earnshaw wrote:
> 
> +/* Work out the size of the first argument of a call to
> +   __builtin_speculation_safe_value.  Only pointers and integral types
> +   are permitted.  Return -1 if the argument type is not supported or
> +   the size is too large; 0 if the argument type is a pointer or the
> +   size if it is integral.  */
> +static enum built_in_function
> +speculation_safe_value_resolve_call (tree function, vec
> *params)
> 
> If I'm reading the expander correctly, isn't it 'pointers to integral
> types', not any old pointer?
> 

The intention is to allow pointer to anything.

> so the following needs some adjustment...
> 
> +  if (POINTER_TYPE_P (type))
> +    return BUILT_IN_SPECULATION_SAFE_VALUE_PTR;
> +
> +  if (!INTEGRAL_TYPE_P (type))
> +    goto incompatible;
> 
> +  if (!COMPLETE_TYPE_P (type))
> +    goto incompatible;
> 
> Are incomplete integral types a thing? (forward enum extension?)
> 
> I presume resolve_overloaded_builtin already works correctly with
> template instantiations, but a templatatized testcase would be nice --
> shout if you'd like help constructing one.
> 

Yelp!

> nathan
> 

R.

Re: Build fail on gthr-simple.h targets (Re: AsyncI/O patch committed)

[David Edelsohn]

Thomas,

Correct, the proposed patch does not fix the build failure on AIX.

Please see the information on the GCC Compile Farm wiki page for
instructions to bootstrap on gcc119.
https://gcc.gnu.org/wiki/CompileFarm#Projects_Ideas - at the bottom of
Project ideas.

Thanks, David
On Fri, Jul 27, 2018 at 3:30 AM Thomas Koenig  wrote:
>
> Am 26.07.2018 um 22:54 schrieb Thomas Koenig:
> > Hi Ulrich,
> >
> >> The problem is that io/asynch.h unconditionally uses a couple of
> >> features that are not provided by gthr-simplex, in particular
> >>__gthread_cond_t
> >> and
> >>__gthread_equal / __gthread_self
> >>
> >> According to the documentation in gthr.h, the former is only available
> >> if __GTHREAD_HAS_COND is defined, and the latter are only available if
> >> __GTHREADS_CXX0X is defined.  Neither is true for gthr-simple.h.
> >
> > Thanks for the analysis, and the pointer to the macros.
> >
> > Because the functionality depends on these features, it is best to
> > remove them if it is not present. So, here is a patch which does
> > just that.
> >
> > This was reg-tested on Linux, which showed that the functionality is
> > still there. I tried bootstrapping on AIX on gcc119, but this failed
> > due to an unrelated issue (problem with compiling the inline
> > libraries).
> >
>
> OK, this does not work.
>
> We have found a method of checking on Linux, and this does not work.
> We have also found a way of working in the next couple of days, so
> expect an update in one or two days.
>
> If that is too much time, feel free to revert the async patch
> in the meantime.
>
> Regards
>
> Thomas

Re: [PATCH 01/11] Add __builtin_speculation_safe_value

[Nathan Sidwell]

On 07/27/2018 05:37 AM, Richard Earnshaw wrote:

+/* Work out the size of the first argument of a call to
+   __builtin_speculation_safe_value.  Only pointers and integral types
+   are permitted.  Return -1 if the argument type is not supported or
+   the size is too large; 0 if the argument type is a pointer or the
+   size if it is integral.  */
+static enum built_in_function
+speculation_safe_value_resolve_call (tree function, vec 
*params)


If I'm reading the expander correctly, isn't it 'pointers to integral 
types', not any old pointer?


so the following needs some adjustment...

+  if (POINTER_TYPE_P (type))
+return BUILT_IN_SPECULATION_SAFE_VALUE_PTR;
+
+  if (!INTEGRAL_TYPE_P (type))
+goto incompatible;

+  if (!COMPLETE_TYPE_P (type))
+goto incompatible;

Are incomplete integral types a thing? (forward enum extension?)

I presume resolve_overloaded_builtin already works correctly with 
template instantiations, but a templatatized testcase would be nice -- 
shout if you'd like help constructing one.


nathan

--
Nathan Sidwell

Re: [PATCH] Add malloc predictor (PR middle-end/83023).

[Martin Liška]

On 07/26/2018 05:00 PM, Marc Glisse wrote:
> On Thu, 26 Jul 2018, Martin Liška wrote:
> 
>> Following patch implements new predictors that annotates malloc-like 
>> functions.
>> These almost every time return a non-null value.
> 
> Out of curiosity (the __builtin_expect there doesn't hurt and we don't need 
> to remove it), does it make __builtin_expect unnecessary in the 
> implementation of operator new (libstdc++-v3/libsupc++/new_op.cc)? It looks 
> like
> 
>   while (__builtin_expect ((p = malloc (sz)) == 0, false))
>     {
>   new_handler handler = std::get_new_handler ();
>   if (! handler)
>     _GLIBCXX_THROW_OR_ABORT(bad_alloc());
>   handler ();
>     }
> 
> where being in a loop may trigger opposite heuristics.
> 

Thanks Marc for the pointer, it actually showed one problem with newly added 
predictor.
So first, current trunk does:

Predictions for bb 5
  first match heuristics: 10.00%
  combined heuristics: 10.00%
  __builtin_expect heuristics of edge 5->6: 10.00%
  call heuristics of edge 5->6 (ignored): 33.00%
  loop exit heuristics of edge 5->9 (ignored): 5.50%

removal of the __builtin_expect wrongly selected a different first march 
predictor:

Predictions for bb 5
  first match heuristics: 94.50%
  combined heuristics: 94.50%
  pointer (on trees) heuristics of edge 5->6 (ignored): 30.00%
  malloc returned non-NULL heuristics of edge 5->6 (ignored): 0.04%
  call heuristics of edge 5->6 (ignored): 33.00%
  loop exit heuristics of edge 5->9: 5.50%

I fixed that by moving PRED_MALLOC_NONNULL up in the list, now it's fine:

1 edges in bb 4 predicted to even probabilities
Predictions for bb 5
  first match heuristics: 0.04%
  combined heuristics: 0.04%
  pointer (on trees) heuristics of edge 5->6 (ignored): 30.00%
  malloc returned non-NULL heuristics of edge 5->6: 0.04%
  call heuristics of edge 5->6 (ignored): 33.00%
  loop exit heuristics of edge 5->9 (ignored): 5.50%

So answer is yes, the builtin can be then removed.

Martin


>From ba2aa6cb7367f529ad96ece92e25cd0366a28735 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 26 Jul 2018 15:25:00 +0200
Subject: [PATCH] Add malloc predictor (PR middle-end/83023).

gcc/ChangeLog:

2018-07-26  Martin Liska  

PR middle-end/83023
	* predict.c (expr_expected_value_1): Handle DECL_IS_MALLOC
declarations.
	* predict.def (PRED_MALLOC_NONNULL): New predictor.

gcc/testsuite/ChangeLog:

2018-07-26  Martin Liska  

PR middle-end/83023
	* gcc.dg/predict-16.c: New test.
---
 gcc/predict.c |  8 
 gcc/predict.def   |  5 -
 gcc/testsuite/gcc.dg/predict-16.c | 31 +++
 3 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/predict-16.c

diff --git a/gcc/predict.c b/gcc/predict.c
index a6769eda1c7..a7b2223c697 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -2380,6 +2380,14 @@ expr_expected_value_1 (tree type, tree op0, enum tree_code code,
 		}
 	  return NULL;
 	}
+
+	  if (DECL_IS_MALLOC (decl))
+	{
+	  if (predictor)
+		*predictor = PRED_MALLOC_NONNULL;
+	  return boolean_true_node;
+	}
+
 	  if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
 	switch (DECL_FUNCTION_CODE (decl))
 	  {
diff --git a/gcc/predict.def b/gcc/predict.def
index 4ed97ed165c..426c17f26fd 100644
--- a/gcc/predict.def
+++ b/gcc/predict.def
@@ -88,6 +88,10 @@ DEF_PREDICTOR (PRED_NORETURN, "noreturn call", PROB_VERY_LIKELY,
 DEF_PREDICTOR (PRED_COLD_FUNCTION, "cold function call", PROB_VERY_LIKELY,
 	   PRED_FLAG_FIRST_MATCH)
 
+/* Return value of malloc function is almost always non-null.  */
+DEF_PREDICTOR (PRED_MALLOC_NONNULL, "malloc returned non-NULL", \
+	   PROB_VERY_LIKELY, PRED_FLAG_FIRST_MATCH)
+
 /* Edge causing loop to terminate is probably not taken.  */
 DEF_PREDICTOR (PRED_LOOP_EXIT, "loop exit", HITRATE (89),
 	   PRED_FLAG_FIRST_MATCH)
@@ -169,7 +173,6 @@ DEF_PREDICTOR (PRED_HOT_LABEL, "hot label", HITRATE (85), 0)
 DEF_PREDICTOR (PRED_COLD_LABEL, "cold label", PROB_VERY_LIKELY,
 	   PRED_FLAG_FIRST_MATCH)
 
-
 /* The following predictors are used in Fortran. */
 
 /* Branch leading to an integer overflow are extremely unlikely.  */
diff --git a/gcc/testsuite/gcc.dg/predict-16.c b/gcc/testsuite/gcc.dg/predict-16.c
new file mode 100644
index 000..3a3e943bb79
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/predict-16.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-profile_estimate" } */
+
+#include 
+#include 
+
+void *r;
+void *r2;
+void *r3;
+void *r4;
+
+void *m (size_t s, int c)
+{
+  r = malloc (s);
+  if (r)
+memset (r, 0, s);
+
+  r2 = calloc (s, 0);
+  if (r2)
+memset (r2, 0, s);
+
+  r3 = __builtin_malloc (s);
+  if (r3)
+memset (r3, 0, s);
+
+  r4 = __builtin_calloc (s, 0);
+  if (r4)
+memset (r4, 0, s);
+}
+
+/* { dg-final { scan-tree-dump-times "malloc returned non-NULL heuristics of edge\[^:\]*: 99.96%" 4 "profile_es

Re: [PATCH] haiku: Initial build support

[Ramana Radhakrishnan]

On Thu, Jul 26, 2018 at 6:26 PM, Joseph Myers  wrote:
> On Mon, 16 Jul 2018, Alexander von Gluck IV wrote:
>
>> * 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!
>
> Before this can be reviewed, we'll need copyright assignments (with
> employer disclaimers where applicable) on file at the FSF from everyone
> who contributed a legally significant amount of code (more than around 15
> lines).  Without those, reviewers can't safely look at the changes in
> detail.
>
> https://gcc.gnu.org/contribute.html
>
> https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
>
> Then, please make sure that only substantive changes are included - that
> there are no diff lines that are purely changing trailing whitespace in
> existing code, for example.  Please ensure that all copyright and license
> notices follow current standards (which means using ranges of years ending
> in 2018, GPLv3 notices and a URL not an FSF postal address).  For changes
> to existing code, especially, please make sure to include sufficient
> rationale in the patch submission to explain those changes, why they are
> needed and the approach taken to them.
>
> For new target OS support, I'd expect details to be provided of the test
> results on that OS for the various architectures supported by GCC.  Are
> you planning, if the support is accepted in GCC, to maintain a bot that
> keeps running the GCC testsuite for GCC mainline for this OS for the
> various target architectures supported, at least daily or thereabouts, and
> posts the results to the gcc-testresults list, and to keep monitoring the
> test results and fixing OS-specific issues that show up?  It's much better
> for issues to be identified within a day or two of the commit causing them
> than many months later, possibly only after a release has come out with
> the issue - but that requires an ongoing commitment to keep monitoring
> test results, posting them to gcc-testresults and keeping them in good
> shape.

Joseph,

A lot of such information seems to come out from a number of reviewers
only during patch review from new contributors.  Would you mind
improving https://gcc.gnu.org/contribute.html and especially around
"Testing patches" or start something like the glibc contribution
checklist on the wiki that actually makes a lot of this easy to find
rather than searching in mailing list archives for new contributors ?

regards
Ramana

>
>> diff --git a/libtool.m4 b/libtool.m4
>
> If this an exact backport of a change from upstream libtool git?  If so,
> please give the commit reference.  If not, give the URL of the submission
> to upstream libtool.  We don't want local libtool changes that aren't
> backports or at least proposed upstream without objections, to avoid
> making future updates from upstream libtool harder.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: [PATCH 1/7] Add __builtin_speculation_safe_value

[Joseph Myers]

On Fri, 27 Jul 2018, Richard Earnshaw (lists) wrote:

> The c-c++-common/spec-barrier-1.c test will fail on any target that has
> not been updated (it deliberately doesn't check for
> __HAVE_SPECULATION_BARRIER before trying to use the new intrinsic).  The
> test contains a comment to that effect.  That should be enough to alert
> maintainers if they are tracking testsuite errors.

Introducing a test failure is not enough.  You need to *explicitly* alert 
target maintainers to the need for action, with a self-contained 
explanation not assuming any prior understanding of Spectre and its 
mitigations, and if any backport is to be considered you'll then need to 
track the status of different targets and remind maintainers as needed (so 
that you know when all targets have been updated, or not updated despite 
maintainers having been informed a few months previously without the 
emails bouncing and reminded a few times since, or not updated and the 
maintainers have explicitly acknowledged this and given their OK to a 
backport without updates for their architectures).

A mail to the gcc list (that draws attention in the subject line and the 
first sentence to the need for architecture maintainer action) is the bare 
minimum (you should not assume target maintainers read gcc-patches 
discussions not mentioning their architecture in the subject), but CC:ing 
the architecture maintainers (immediately, or for those not fixed within a 
month or two) provides better assurance that the issue has been properly 
drawn to their attention.

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH] Avoid infinite loop with duplicate anonymous union fields

[Bogdan Harjoc]

(this patch is already uploaded to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86690 )

If a struct contains an anonymous union and both have a field with the
same name, detect_field_duplicates_hash() will replace one of them
with NULL. If compilation doesn't stop immediately, it may later call
lookup_field() on the union, which falsely assumes the union's
LANG_SPECIFIC array is sorted, and may loop indefinitely because of
this.

Reproduced on amd64 since gcc-5, on ubuntu-18.04 and gentoo.

The patch falls back to iterating via DECL_CHAIN if there was an error
earlier during compilation.

I ran the gcc testsuite with the result (the FAIL seems unrelated to the patch):

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

=== gcc Summary ===

# of expected passes135094
# of unexpected failures1
# of expected failures  398
# of unsupported tests  2140
gcc-build/gcc/xgcc  version 8.0.1 20180424 (experimental) (GCC)
--- gcc-8.0.1-20180424/gcc/c/c-typeck.c	2018-07-26 20:00:55.475792602 +0300
+++ gcc-8.0.1-20180424/gcc/c/c-typeck.c	2018-07-26 21:39:13.312629356 +0300
@@ -2207,9 +2207,14 @@
   /* If TYPE_LANG_SPECIFIC is set, then it is a sorted array of pointers
  to the field elements.  Use a binary search on this array to quickly
  find the element.  Otherwise, do a linear search.  TYPE_LANG_SPECIFIC
- will always be set for structures which have many elements.  */
+ will always be set for structures which have many elements.
+ 
+ Duplicate field checking replaces duplicates with NULL_TREE so
+ TYPE_LANG_SPECIFIC arrays are potentially no longer sorted. In that
+ case just iterate using DECL_CHAIN. */
 
-  if (TYPE_LANG_SPECIFIC (type) && TYPE_LANG_SPECIFIC (type)->s)
+  if (TYPE_LANG_SPECIFIC (type) && TYPE_LANG_SPECIFIC (type)->s 
+	  && diagnostic_kind_count(global_dc, DK_ERROR) == 0) 
 {
   int bot, top, half;
   tree *field_array = &TYPE_LANG_SPECIFIC (type)->s->elts[0];

[PATCH 04/11] AArch64 - Add new option -mtrack-speculation

[Richard Earnshaw]

This patch doesn't do anything useful, it simply adds a new command-line
option -mtrack-speculation to AArch64.  Subsequent patches build on this.

* config/aarch64/aarch64.opt (mtrack-speculation): New target option.
---
 gcc/config/aarch64/aarch64.opt | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/config/aarch64/aarch64.opt b/gcc/config/aarch64/aarch64.opt
index 1426b45..bc9b22a 100644
--- a/gcc/config/aarch64/aarch64.opt
+++ b/gcc/config/aarch64/aarch64.opt
@@ -214,3 +214,7 @@ Target RejectNegative Joined Enum(sve_vector_bits) Var(aarch64_sve_vector_bits)
 mverbose-cost-dump
 Common Undocumented Var(flag_aarch64_verbose_cost)
 Enables verbose cost model dumping in the debug dump files.
+
+mtrack-speculation
+Target Var(aarch64_track_speculation)
+Generate code to track when the CPU might be speculating incorrectly.

[PATCH 11/11] rs6000 - add speculation_barrier pattern

[Richard Earnshaw]

This patch reworks the existing rs6000_speculation_barrier pattern to
work with the new __builtin_sepculation_safe_value() intrinsic.  The
change is trivial as it simply requires renaming the existing speculation
barrier pattern.

So the total patch is to delete 14 characters!

* config/rs6000/rs6000.md (speculation_barrier): Renamed from
rs6000_speculation_barrier.
* config/rs6000/rs6000.c (rs6000_expand_builtin): Adjust for
new barrier pattern name.
---
 gcc/config/rs6000/rs6000.c  | 2 +-
 gcc/config/rs6000/rs6000.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 1976072..46c6838 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -16179,7 +16179,7 @@ rs6000_expand_builtin (tree exp, rtx target, rtx subtarget ATTRIBUTE_UNUSED,
 
 case MISC_BUILTIN_SPEC_BARRIER:
   {
-	emit_insn (gen_rs6000_speculation_barrier ());
+	emit_insn (gen_speculation_barrier ());
 	return NULL_RTX;
   }
 
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 44d32d9..03870e9 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -12614,7 +12614,7 @@ (define_insn "group_ending_nop"
   return "ori 2,2,0";
 })
 
-(define_insn "rs6000_speculation_barrier"
+(define_insn "speculation_barrier"
   [(unspec_volatile:BLK [(const_int 0)] UNSPECV_SPEC_BARRIER)]
   ""
   "ori 31,31,0")

[PATCH 05/11] AArch64 - disable CB[N]Z TB[N]Z when tracking speculation

[Richard Earnshaw]

The CB[N]Z and TB[N]Z instructions do not expose the comparison through
the condition code flags.  This makes it impossible to track speculative
execution through such a branch.  We can handle this relatively easily
by simply disabling the patterns in this case.

A side effect of this is that the split patterns for the atomic operations
need to also avoid generating these instructions.  They mostly have simple
fall-backs for this already.

* config/aarch64/aarch64.md (cb1): Disable when
aarch64_track_speculation is true.
(tb1): Likewise.
* config/aarch64/aarch64.c (aarch64_split_compare_regs): Do not
generate CB[N]Z when tracking speculation.
(aarch64_split_compare_and_swap): Likewise.
(aarch64_split_atomic_op): Likewise.
---
 gcc/config/aarch64/aarch64.c  | 33 ++---
 gcc/config/aarch64/aarch64.md |  6 +++---
 2 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 1369704..90849b5 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -14479,7 +14479,16 @@ aarch64_split_compare_and_swap (rtx operands[])
 
   if (strong_zero_p)
 {
-  x = gen_rtx_NE (VOIDmode, rval, const0_rtx);
+  if (aarch64_track_speculation)
+	{
+	  /* Emit an explicit compare instruction, so that we can correctly
+	 track the condition codes.  */
+	  rtx cc_reg = aarch64_gen_compare_reg (NE, rval, const0_rtx);
+	  x = gen_rtx_NE (GET_MODE (cc_reg), cc_reg, const0_rtx);
+	}
+  else
+	x = gen_rtx_NE (VOIDmode, rval, const0_rtx);
+
   x = gen_rtx_IF_THEN_ELSE (VOIDmode, x,
 gen_rtx_LABEL_REF (Pmode, label2), pc_rtx);
   aarch64_emit_unlikely_jump (gen_rtx_SET (pc_rtx, x));
@@ -14497,7 +14506,16 @@ aarch64_split_compare_and_swap (rtx operands[])
 
   if (!is_weak)
 {
-  x = gen_rtx_NE (VOIDmode, scratch, const0_rtx);
+  if (aarch64_track_speculation)
+	{
+	  /* Emit an explicit compare instruction, so that we can correctly
+	 track the condition codes.  */
+	  rtx cc_reg = aarch64_gen_compare_reg (NE, scratch, const0_rtx);
+	  x = gen_rtx_NE (GET_MODE (cc_reg), cc_reg, const0_rtx);
+	}
+  else
+	x = gen_rtx_NE (VOIDmode, scratch, const0_rtx);
+
   x = gen_rtx_IF_THEN_ELSE (VOIDmode, x,
 gen_rtx_LABEL_REF (Pmode, label1), pc_rtx);
   aarch64_emit_unlikely_jump (gen_rtx_SET (pc_rtx, x));
@@ -14833,7 +14851,16 @@ aarch64_split_atomic_op (enum rtx_code code, rtx old_out, rtx new_out, rtx mem,
   aarch64_emit_store_exclusive (mode, cond, mem,
 gen_lowpart (mode, new_out), model_rtx);
 
-  x = gen_rtx_NE (VOIDmode, cond, const0_rtx);
+  if (aarch64_track_speculation)
+{
+  /* Emit an explicit compare instruction, so that we can correctly
+	 track the condition codes.  */
+  rtx cc_reg = aarch64_gen_compare_reg (NE, cond, const0_rtx);
+  x = gen_rtx_NE (GET_MODE (cc_reg), cc_reg, const0_rtx);
+}
+  else
+x = gen_rtx_NE (VOIDmode, cond, const0_rtx);
+
   x = gen_rtx_IF_THEN_ELSE (VOIDmode, x,
 			gen_rtx_LABEL_REF (Pmode, label), pc_rtx);
   aarch64_emit_unlikely_jump (gen_rtx_SET (pc_rtx, x));
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index c135ada..259a07d 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -690,7 +690,7 @@ (define_insn "*cb1"
 (const_int 0))
 			   (label_ref (match_operand 1 "" ""))
 			   (pc)))]
-  ""
+  "!aarch64_track_speculation"
   {
 if (get_attr_length (insn) == 8)
   return aarch64_gen_far_branch (operands, 1, "Lcb", "\\t%0, ");
@@ -720,7 +720,7 @@ (define_insn "*tb1"
 	 (label_ref (match_operand 2 "" ""))
 	 (pc)))
(clobber (reg:CC CC_REGNUM))]
-  ""
+  "!aarch64_track_speculation"
   {
 if (get_attr_length (insn) == 8)
   {
@@ -756,7 +756,7 @@ (define_insn "*cb1"
 			   (label_ref (match_operand 1 "" ""))
 			   (pc)))
(clobber (reg:CC CC_REGNUM))]
-  ""
+  "!aarch64_track_speculation"
   {
 if (get_attr_length (insn) == 8)
   {

[PATCH 07/11] AArch64 - use CSDB based sequences if speculation tracking is enabled

[Richard Earnshaw]

In this final patch, now that we can track speculation through conditional
branches, we can use this information to use a less expensive CSDB based
speculation barrier.

* config/aarch64/iterators.md (ALLI_TI): New iterator.
* config/aarch64/aarch64.md (despeculate_copy): New
expand.
(despeculate_copy_insn): New insn.
(despeculate_copyti_insn): New insn.
(despeculate_simple): New insn
(despeculate_simpleti): New insn.
* config/aarch64/aarch64.c (aarch64_speculation_safe_value): New
function.
(TARGET_SPECULATION_SAFE_VALUE): Redefine to
aarch64_speculation_safe_value.
(aarch64_print_operand): Handle const0_rtx in modifier 'H'.
---
 gcc/config/aarch64/aarch64.c| 48 
 gcc/config/aarch64/aarch64.md   | 97 +
 gcc/config/aarch64/iterators.md |  3 ++
 3 files changed, 148 insertions(+)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index cca465e..fc6eb1c 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6760,6 +6760,12 @@ aarch64_print_operand (FILE *f, rtx x, int code)
   break;
 
 case 'H':
+  if (x == const0_rtx)
+	{
+	  asm_fprintf (f, "xzr");
+	  break;
+	}
+
   if (!REG_P (x) || !GP_REGNUM_P (REGNO (x) + 1))
 	{
 	  output_operand_lossage ("invalid operand for '%%%c'", code);
@@ -17638,6 +17644,45 @@ aarch64_select_early_remat_modes (sbitmap modes)
 }
 }
 
+/* Override the default target speculation_safe_value.  */
+static rtx
+aarch64_speculation_safe_value (machine_mode mode,
+rtx result, rtx val, rtx failval)
+{
+  /* Maybe we should warn if falling back to hard barriers.  They are
+ likely to be noticably more expensive than the alternative below.  */
+  if (!aarch64_track_speculation)
+return default_speculation_safe_value (mode, result, val, failval);
+
+  if (!REG_P (val))
+val = copy_to_mode_reg (mode, val);
+
+  if (!aarch64_reg_or_zero (failval, mode))
+failval = copy_to_mode_reg (mode, failval);
+
+  switch (mode)
+{
+case E_QImode:
+  emit_insn (gen_despeculate_copyqi (result, val, failval));
+  break;
+case E_HImode:
+  emit_insn (gen_despeculate_copyhi (result, val, failval));
+  break;
+case E_SImode:
+  emit_insn (gen_despeculate_copysi (result, val, failval));
+  break;
+case E_DImode:
+  emit_insn (gen_despeculate_copydi (result, val, failval));
+  break;
+case E_TImode:
+  emit_insn (gen_despeculate_copyti (result, val, failval));
+  break;
+default:
+  gcc_unreachable ();
+}
+  return result;
+}
+
 /* Target-specific selftests.  */
 
 #if CHECKING_P
@@ -18110,6 +18155,9 @@ aarch64_libgcc_floating_mode_supported_p
 #undef TARGET_SELECT_EARLY_REMAT_MODES
 #define TARGET_SELECT_EARLY_REMAT_MODES aarch64_select_early_remat_modes
 
+#undef TARGET_SPECULATION_SAFE_VALUE
+#define TARGET_SPECULATION_SAFE_VALUE aarch64_speculation_safe_value
+
 #if CHECKING_P
 #undef TARGET_RUN_TARGET_SELFTESTS
 #define TARGET_RUN_TARGET_SELFTESTS selftest::aarch64_run_selftests
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 528d03d..321a674 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -6129,6 +6129,103 @@ (define_insn "speculation_barrier"
(set_attr "speculation_barrier" "true")]
 )
 
+;; Support for __builtin_speculation_safe_value when we have speculation
+;; tracking enabled.  Use the speculation tracker to decide whether to
+;; copy operand 1 to the target, or to copy the fail value (operand 2).
+(define_expand "despeculate_copy"
+  [(set (match_operand:ALLI_TI 0 "register_operand" "=r")
+	(unspec_volatile:ALLI_TI
+	 [(match_operand:ALLI_TI 1 "register_operand" "r")
+	  (match_operand:ALLI_TI 2 "aarch64_reg_or_zero" "rZ")
+	  (use (reg:DI SPECULATION_TRACKER_REGNUM))
+	  (clobber (reg:CC CC_REGNUM))] UNSPECV_SPECULATION_BARRIER))]
+  ""
+  "
+  {
+if (operands[2] == const0_rtx)
+  {
+	rtx tracker;
+	if (mode == TImode)
+	  tracker = gen_rtx_REG (DImode, SPECULATION_TRACKER_REGNUM);
+	else
+	  tracker = gen_rtx_REG (mode, SPECULATION_TRACKER_REGNUM);
+
+	emit_insn (gen_despeculate_simple (operands[0], operands[1],
+		 tracker));
+	DONE;
+  }
+  }
+  "
+)
+
+;; Patterns to match despeculate_copy.  Note that "hint 0x14" is the
+;; encoding for CSDB, but will work in older versions of the assembler.
+(define_insn "*despeculate_copy_insn"
+  [(set (match_operand:ALLI 0 "register_operand" "=r")
+	(unspec_volatile:ALLI
+	 [(match_operand:ALLI 1 "register_operand" "r")
+	  (match_operand:ALLI 2 "aarch64_reg_or_zero" "rZ")
+	  (use (reg:DI SPECULATION_TRACKER_REGNUM))
+	  (clobber (reg:CC CC_REGNUM))] UNSPECV_SPECULATION_BARRIER))]
+  ""
+  {
+operands[3] = gen_rtx_REG (DImode, SPECULATION_TRACKER_REGNUM);
+output_asm_insn ("cmp\\t%3, #0\;csel\\t%0, %1, %2, ne\;hint\t0x14 // csdb",
+		 o

[PATCH 09/11] pdp11 - example of a port not needing a speculation barrier

[Richard Earnshaw]

This patch is intended as an example of all that is needed if the
target system doesn't support CPUs that have speculative execution.
I've chosen the pdp11 port on the basis that it's old enough that this
is likely to be true for all existing implementations and that there
is also little chance of that changing in future!

* config/pdp11/pdp11.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Redefine
to speculation_safe_value_not_needed.
---
 gcc/config/pdp11/pdp11.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/pdp11/pdp11.c b/gcc/config/pdp11/pdp11.c
index 1bcdaed..62c653f 100644
--- a/gcc/config/pdp11/pdp11.c
+++ b/gcc/config/pdp11/pdp11.c
@@ -291,6 +291,9 @@ static bool pdp11_scalar_mode_supported_p (scalar_mode);
 
 #undef TARGET_INVALID_WITHIN_DOLOOP
 #define TARGET_INVALID_WITHIN_DOLOOP hook_constcharptr_const_rtx_insn_null
+
+#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
+#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
 
 /* A helper function to determine if REGNO should be saved in the
current function's stack frame.  */

[PATCH 10/11] x86 - add speculation_barrier pattern

[Richard Earnshaw]

This patch adds a speculation barrier for x86, based on my
understanding of the required mitigation for that CPU, which is to use
an lfence instruction.

This patch needs some review by an x86 expert and if adjustments are
needed, I'd appreciate it if they could be picked up by the port
maintainer.  This is supposed to serve as an example of how to deploy
the new __builtin_speculation_safe_value() intrinsic on this
architecture.

* config/i386/i386.md (unspecv): Add UNSPECV_SPECULATION_BARRIER.
(speculation_barrier): New insn.
---
 gcc/config/i386/i386.md | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 559ad93..73948c1 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -301,6 +301,9 @@ (define_c_enum "unspecv" [
 
   ;; For CLDEMOTE support
   UNSPECV_CLDEMOTE
+
+  ;; For Speculation Barrier support
+  UNSPECV_SPECULATION_BARRIER
 ])
 
 ;; Constants to represent rounding modes in the ROUND instruction
@@ -20979,6 +20982,13 @@ (define_insn "cldemote"
   [(set_attr "type" "other")
(set_attr "memory" "unknown")])
 
+(define_insn "speculation_barrier"
+  [(unspec_volatile [(const_int 0)] UNSPECV_SPECULATION_BARRIER)]
+  ""
+  "lfence"
+  [(set_attr "type" "other")
+   (set_attr "length" "3")])
+
 (include "mmx.md")
 (include "sse.md")
 (include "sync.md")

[PATCH 08/11] targhooks - provide an alternative hook for targets that never execute speculatively

[Richard Earnshaw]

This hook adds an alternative implementation for the target hook
TARGET_HAVE_SPECULATION_SAFE_VALUE; it can be used by targets that have no
CPU implementations that execute code speculatively.  All that is needed for
such targets now is to add:

 #undef TARGET_HAVE_SPECULATION_SAFE_VALUE
 #define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed.

to where you have your other target hooks and you're done.

gcc:
* targhooks.h (speculation_safe_value_not_needed): New prototype.
* targhooks.c (speculation_safe_value_not_needed): New function.
* target.def (have_speculation_safe_value): Update documentation.
* doc/tm.texi: Regenerated.
---
 gcc/doc/tm.texi | 5 +
 gcc/target.def  | 7 ++-
 gcc/targhooks.c | 7 +++
 gcc/targhooks.h | 1 +
 4 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 15b0ab8..f36e376 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -11959,6 +11959,11 @@ This hook is used to determine the level of target support for
  a pattern named @code{speculation_barrier}.  Else it returns true
  for the first case and whether the pattern is enabled for the current
  compilation for the second case.
+ 
+ For targets that have no processors that can execute instructions
+ speculatively an alternative implemenation of this hook is available:
+ simply redefine this hook to @code{speculation_safe_value_not_needed}
+ along with your other target hooks.
 @end deftypefn
 
 @deftypefn {Target Hook} rtx TARGET_SPECULATION_SAFE_VALUE (machine_mode @var{mode}, rtx @var{result}, rtx @var{val}, rtx @var{failval})
diff --git a/gcc/target.def b/gcc/target.def
index d598067..5599eb4 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -4206,7 +4206,12 @@ DEFHOOK
  The default implementation returns false if the target does not define\n\
  a pattern named @code{speculation_barrier}.  Else it returns true\n\
  for the first case and whether the pattern is enabled for the current\n\
- compilation for the second case.",
+ compilation for the second case.\n\
+ \n\
+ For targets that have no processors that can execute instructions\n\
+ speculatively an alternative implemenation of this hook is available:\n\
+ simply redefine this hook to @code{speculation_safe_value_not_needed}\n\
+ along with your other target hooks.",
 bool, (bool active), default_have_speculation_safe_value)
 
 DEFHOOK
diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index 06de1e3..62051a9 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -2324,6 +2324,13 @@ default_have_speculation_safe_value (bool active)
   return false;
 #endif
 }
+/* Alternative implementation of TARGET_HAVE_SPECULATION_SAFE_VALUE
+   that can be used on targets that never have speculative execution.  */
+bool
+speculation_safe_value_not_needed (bool active)
+{
+  return !active;
+}
 
 /* Default implementation of the speculation-safe-load builtin.  This
implementation simply copies val to result and generates a
diff --git a/gcc/targhooks.h b/gcc/targhooks.h
index 74ffe5f..b716b97 100644
--- a/gcc/targhooks.h
+++ b/gcc/targhooks.h
@@ -286,6 +286,7 @@ extern void default_select_early_remat_modes (sbitmap);
 extern tree default_preferred_else_value (unsigned, tree, unsigned, tree *);
 
 extern bool default_have_speculation_safe_value (bool);
+extern bool speculation_safe_value_not_needed (bool);
 extern rtx default_speculation_safe_value (machine_mode, rtx, rtx, rtx);
 
 #endif /* GCC_TARGHOOKS_H */

[PATCH 01/11] Add __builtin_speculation_safe_value

[Richard Earnshaw]

This patch defines a new intrinsic function
__builtin_speculation_safe_value.  A generic default implementation is
defined which will attempt to use the backend pattern
"speculation_safe_barrier".  If this pattern is not defined, or if it
is not available, then the compiler will emit a warning, but
compilation will continue.

Note that the test spec-barrier-1.c will currently fail on all
targets.  This is deliberate, the failure will go away when
appropriate action is taken for each target backend.

gcc:
* builtin-types.def (BT_FN_PTR_PTR_VAR): New function type.
(BT_FN_I1_I1_VAR, BT_FN_I2_I2_VAR, BT_FN_I4_I4_VAR): Likewise.
(BT_FN_I8_I8_VAR, BT_FN_I16_I16_VAR): Likewise.
* builtin-attrs.def (ATTR_NOVOPS_NOTHROW_LEAF_LIST): New attribute
list.
* builtins.def (BUILT_IN_SPECULATION_SAFE_VALUE_N): New builtin.
(BUILT_IN_SPECULATION_SAFE_VALUE_PTR): New internal builtin.
(BUILT_IN_SPECULATION_SAFE_VALUE_1): Likewise.
(BUILT_IN_SPECULATION_SAFE_VALUE_2): Likewise.
(BUILT_IN_SPECULATION_SAFE_VALUE_4): Likewise.
(BUILT_IN_SPECULATION_SAFE_VALUE_8): Likewise.
(BUILT_IN_SPECULATION_SAFE_VALUE_16): Likewise.
* builtins.c (expand_speculation_safe_value): New function.
(expand_builtin): Call it.
* doc/cpp.texi: Document predefine __HAVE_SPECULATION_SAFE_VALUE.
* doc/extend.texi: Document __builtin_speculation_safe_value.
* doc/md.texi: Document "speculation_barrier" pattern.
* doc/tm.texi.in: Pull in TARGET_SPECULATION_SAFE_VALUE and
TARGET_HAVE_SPECULATION_SAFE_VALUE.
* doc/tm.texi: Regenerated.
* target.def (have_speculation_safe_value, speculation_safe_value): New
hooks.
* targhooks.c (default_have_speculation_safe_value): New function.
(default_speculation_safe_value): New function.
* targhooks.h (default_have_speculation_safe_value): Add prototype.
(default_speculation_safe_value): Add prototype.

c-family:
* c-common.c (speculation_safe_resolve_call): New function.
(speculation_safe_resolve_params): New function.
(speculation_safe_resolve_return): New function.
(resolve_overloaded_builtin): Handle __builtin_speculation_safe_value.
* c-cppbuiltin.c (c_cpp_builtins): Add pre-define for
__HAVE_SPECULATION_SAFE_VALUE.

testsuite:
* c-c++-common/spec-barrier-1.c: New test.
* c-c++-common/spec-barrier-2.c: New test.
* gcc.dg/spec-barrier-3.c: New test.
---
 gcc/builtin-attrs.def   |   2 +
 gcc/builtin-types.def   |   6 +
 gcc/builtins.c  |  60 ++
 gcc/builtins.def|  22 
 gcc/c-family/c-common.c | 164 
 gcc/c-family/c-cppbuiltin.c |   7 +-
 gcc/doc/cpp.texi|   4 +
 gcc/doc/extend.texi |  91 +++
 gcc/doc/md.texi |  15 +++
 gcc/doc/tm.texi |  31 ++
 gcc/doc/tm.texi.in  |   4 +
 gcc/target.def  |  35 ++
 gcc/targhooks.c |  32 ++
 gcc/targhooks.h |   3 +
 gcc/testsuite/c-c++-common/spec-barrier-1.c |  38 +++
 gcc/testsuite/c-c++-common/spec-barrier-2.c |  17 +++
 gcc/testsuite/gcc.dg/spec-barrier-3.c   |  13 +++
 17 files changed, 543 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/c-c++-common/spec-barrier-1.c
 create mode 100644 gcc/testsuite/c-c++-common/spec-barrier-2.c
 create mode 100644 gcc/testsuite/gcc.dg/spec-barrier-3.c

diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
index 300ba65..e245e4d 100644
--- a/gcc/builtin-attrs.def
+++ b/gcc/builtin-attrs.def
@@ -129,6 +129,8 @@ DEF_ATTR_TREE_LIST (ATTR_NOTHROW_LIST, ATTR_NOTHROW, ATTR_NULL, ATTR_NULL)
 
 DEF_ATTR_TREE_LIST (ATTR_NOTHROW_LEAF_LIST, ATTR_LEAF, ATTR_NULL, ATTR_NOTHROW_LIST)
 
+DEF_ATTR_TREE_LIST (ATTR_NOVOPS_NOTHROW_LEAF_LIST, ATTR_NOVOPS, \
+		ATTR_NULL, ATTR_NOTHROW_LEAF_LIST)
 DEF_ATTR_TREE_LIST (ATTR_CONST_NOTHROW_LIST, ATTR_CONST,	\
 			ATTR_NULL, ATTR_NOTHROW_LIST)
 DEF_ATTR_TREE_LIST (ATTR_CONST_NOTHROW_LEAF_LIST, ATTR_CONST,	\
diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index b01095c..70fae35 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -763,6 +763,12 @@ DEF_FUNCTION_TYPE_VAR_1 (BT_FN_VOID_LONG_VAR,
 			 BT_VOID, BT_LONG)
 DEF_FUNCTION_TYPE_VAR_1 (BT_FN_VOID_ULL_VAR,
 			 BT_VOID, BT_ULONGLONG)
+DEF_FUNCTION_TYPE_VAR_1 (BT_FN_PTR_PTR_VAR, BT_PTR, BT_PTR)
+DEF_FUNCTION_TYPE_VAR_1 (BT_FN_I1_I1_VAR, BT_I1, BT_I1)
+DEF_FUNCTION_TYPE_VAR_1 (BT_FN_I2_I2_VAR, BT_I2, BT_I2)
+DEF_FUNCTION_TYPE_VAR_1 (BT_FN_I4_I4_VAR, BT_I4, BT_I4)
+DEF_FUNCTION_TYPE_VAR_1 (BT_FN_I8_I8_VAR, BT_I8, BT_I8)
+DEF_FUNCTIO

[PATCH 06/11] AArch64 - new pass to add conditional-branch speculation tracking

[Richard Earnshaw]

This patch is the main part of the speculation tracking code.  It adds
a new target-specific pass that is run just before the final branch
reorg pass (so that it can clean up any new edge insertions we make).
The pass is only run with -mtrack-speculation is passed on the command
line.

One thing that did come to light as part of this was that the stack pointer
register was not being permitted in comparision instructions.  We rely on
that for moving the tracking state between SP and the scratch register at
function call boundaries.

* config/aarch64/aarch64-speculation.cc: New file.
* config/aarch64/aarch64-passes.def (pass_track_speculation): Add before
pass_reorder_blocks.
* config/aarch64/aarch64-protos.h (make_pass_track_speculation): Add
prototype.
* config/aarch64/aarch64.c (aarch64_conditional_register_usage): Fix
X14 and X15 when tracking speculation.
* config/aarch64/aarch64.md (register name constants): Add
SPECULATION_TRACKER_REGNUM and SPECULATION_SCRATCH_REGNUM.
(unspec): Add UNSPEC_SPECULATION_TRACKER.
(speculation_barrier): New insn attribute.
(cmp): Allow SP in comparisons.
(speculation_tracker): New insn.
(speculation_barrier): Add speculation_barrier attribute.
* config/aarch64/t-aarch64: Add make rule for aarch64-speculation.o.
* config.gcc (aarch64*-*-*): Add aarch64-speculation.o to extra_objs.
* doc/invoke.texi (AArch64 Options): Document -mtrack-speculation.
---
 gcc/config.gcc|   2 +-
 gcc/config/aarch64/aarch64-passes.def |   1 +
 gcc/config/aarch64/aarch64-protos.h   |   3 +-
 gcc/config/aarch64/aarch64-speculation.cc | 494 ++
 gcc/config/aarch64/aarch64.c  |  13 +
 gcc/config/aarch64/aarch64.md |  30 +-
 gcc/config/aarch64/t-aarch64  |  10 +
 gcc/doc/invoke.texi   |  10 +-
 8 files changed, 558 insertions(+), 5 deletions(-)
 create mode 100644 gcc/config/aarch64/aarch64-speculation.cc

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 78e84c2..b17fdba 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 aarch64-speculation.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 87747b4..3d6a254 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_BEFORE (pass_reorder_blocks, 1, pass_track_speculation);
diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index bc11a78..e80ffcf 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -554,7 +554,8 @@ enum aarch64_parse_opt_result aarch64_parse_extension (const char *,
 std::string aarch64_get_extension_string_for_isa_flags (unsigned long,
 			unsigned long);
 
-rtl_opt_pass *make_pass_fma_steering (gcc::context *ctxt);
+rtl_opt_pass *make_pass_fma_steering (gcc::context *);
+rtl_opt_pass *make_pass_track_speculation (gcc::context *);
 
 poly_uint64 aarch64_regmode_natural_size (machine_mode);
 
diff --git a/gcc/config/aarch64/aarch64-speculation.cc b/gcc/config/aarch64/aarch64-speculation.cc
new file mode 100644
index 000..2dd06ae
--- /dev/null
+++ b/gcc/config/aarch64/aarch64-speculation.cc
@@ -0,0 +1,494 @@
+/* Speculation tracking and mitigation (e.g. CVE 2017-5753) for AArch64.
+   Copyright (C) 2018 Free Software Foundation, Inc.
+   Contributed by ARM Ltd.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "target.h"
+#include "rtl.h"
+#include "tree-pass.h"
+#include "profile-count.h"
+#include "cfg.h"
+#include "cfgbuild.h"
+#include "print-rtl.h"
+#include "cfgrtl.h"
+#include "function.h"
+#include "bas

[PATCH 03/11] AArch64 - add speculation barrier

[Richard Earnshaw]

Similar to Arm, this adds an unconditional speculation barrier for AArch64.

* config/aarch64.md (unspecv): Add UNSPECV_SPECULAION_BARRIER.
(speculation_barrier): New insn.
---
 gcc/config/aarch64/aarch64.md | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index a014a01..c135ada 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -205,6 +205,7 @@ (define_c_enum "unspecv" [
 UNSPECV_SET_FPSR		; Represent assign of FPSR content.
 UNSPECV_BLOCKAGE		; Represent a blockage
 UNSPECV_PROBE_STACK_RANGE	; Represent stack range probing.
+UNSPECV_SPECULATION_BARRIER ; Represent speculation barrier.
   ]
 )
 
@@ -6093,6 +6094,15 @@ (define_expand "set_clobber_cc"
 		   (match_operand 1))
 	  (clobber (reg:CC CC_REGNUM))])])
 
+;; Hard speculation barrier.
+(define_insn "speculation_barrier"
+  [(unspec_volatile [(const_int 0)] UNSPECV_SPECULATION_BARRIER)]
+  ""
+  "isb\;dsb\\tsy"
+  [(set_attr "length" "8")
+   (set_attr "type" "block")]
+)
+
 ;; AdvSIMD Stuff
 (include "aarch64-simd.md")
 

[PATCH 00/11] (v2) Mitigation against unsafe data speculation (CVE-2017-5753)

[Richard Earnshaw]

Port Maintainers: You need to decide what action is required for your
port to handle speculative execution, even if that action is to use
the trivial no-speculation on this architecture.  You must also
consider whether or not a furture implementation of your architecture
might need to deal with this in making that decision.

The patches I posted earlier this year for mitigating against
CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
which it became obvious that a rethink was needed.  This mail, and the
following patches attempt to address that feedback and present a new
approach to mitigating against this form of attack surface.

There were two major issues with the original approach:

- The speculation bounds were too tightly constrained - essentially
  they had to represent and upper and lower bound on a pointer, or a
  pointer offset.
- The speculation constraints could only cover the immediately preceding
  branch, which often did not fit well with the structure of the existing
  code.

An additional criticism was that the shape of the intrinsic did not
fit particularly well with systems that used a single speculation
barrier that essentially had to wait until all preceding speculation
had to be resolved.

To address all of the above, these patches adopt a new approach, based
in part on a posting by Chandler Carruth to the LLVM developers list
(https://lists.llvm.org/pipermail/llvm-dev/2018-March/122085.html),
but which we have extended to deal with inter-function speculation.
The patches divide the problem into two halves.

The first half is some target-specific code to track the speculation
condition through the generated code to provide an internal variable
which can tell us whether or not the CPU's control flow speculation
matches the data flow calculations.  The idea is that the internal
variable starts with the value TRUE and if the CPU's control flow
speculation ever causes a jump to the wrong block of code the variable
becomes false until such time as the incorrect control flow
speculation gets unwound.

The second half is that a new intrinsic function is introduced that is
much simpler than we had before.  The basic version of the intrinsic
is now simply:

  T var = __builtin_speculation_safe_value (T unsafe_var);

Full details of the syntax can be found in the documentation patch, in
patch 1.  In summary, when not speculating the intrinsic returns
unsafe_var; when speculating then if it can be shown that the
speculative flow has diverged from the intended control flow then zero
is returned.  An optional second argument can be used to return an
alternative value to zero.  The builtin may cause execution to pause
until the speculation state is resolved.

There are eleven patches in this set, as follows.

1) Introduces the new intrinsic __builtin_sepculation_safe_value.
2) Adds a basic hard barrier implementation for AArch32 (arm) state.
3) Adds a basic hard barrier implementation for AArch64 state.
4) Adds a new command-line option -mtrack-speculation (currently a no-op).
5) Disables CB[N]Z and TB[N]Z when -mtrack-speculation.
6) Adds the new speculation tracking pass for AArch64
7) Uses the new speculation tracking pass to generate CSDB-based barrier
   sequences
8) Provides an alternative hook implementation for use on targets that never
   speculatively execute
9) Provides an trivial example of using that hook in the pdp11 backend.
10) Provides a possible implementation of the hard barrier for x86
11) Updates the PowerPC backend which already had a suitable barrier under
a different name.

I haven't added a speculation-tracking pass for AArch32 at this time.
It is possible to do this, but would require quite a lot of rework for
the arm backend due to the limited number of registers that are
available.

Although patch 6 is AArch64 specific, I'd appreciate a review from
someone more familiar with the branch edge code than myself.  There
appear to be a number of tricky issues with more complex edges so I'd
like a second opinion on that code in case I've missed an important
case.

R.

Richard Earnshaw (11):
  Add __builtin_speculation_safe_value
  Arm - add speculation_barrier pattern
  AArch64 - add speculation barrier
  AArch64 - Add new option -mtrack-speculation
  AArch64 - disable CB[N]Z TB[N]Z when tracking speculation
  AArch64 - new pass to add conditional-branch speculation tracking
  AArch64 - use CSDB based sequences if speculation tracking is enabled
  targhooks - provide an alternative hook for targets that never execute
speculatively
  pdp11 - example of a port not needing a speculation barrier
  x86 - add speculation_barrier pattern
  rs6000 - add speculation_barrier pattern

 gcc/builtin-attrs.def   |   2 +
 gcc/builtin-types.def   |   6 +
 gcc/builtins.c  |  60 
 gcc/builtins.def|  22 ++
 gcc/c-family/c-common.c | 164 

[PATCH 02/11] Arm - add speculation_barrier pattern

[Richard Earnshaw]

This patch defines a speculation barrier for AArch32.

* config/arm/unspecs.md (unspecv): Add VUNSPEC_SPECULATION_BARRIER.
* config/arm/arm.md (speculation_barrier): New expand.
(speculation_barrier_insn): New pattern.
---
 gcc/config/arm/arm.md | 21 +
 gcc/config/arm/unspecs.md |  1 +
 2 files changed, 22 insertions(+)

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 361a026..ca2a2f5 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -12012,6 +12012,27 @@ (define_insn ""
   [(set_attr "length" "4")
(set_attr "type" "coproc")])
 
+(define_expand "speculation_barrier"
+  [(unspec_volatile [(const_int 0)] VUNSPEC_SPECULATION_BARRIER)]
+  "TARGET_EITHER"
+  "
+/* Don't emit anything for Thumb1 and suppress the warning from the
+   generic expansion.  */
+if (!TARGET_32BIT)
+   DONE;
+  "
+)
+
+;; Generate a hard speculation barrier when we have not enabled speculation
+;; tracking.
+(define_insn "*speculation_barrier_insn"
+  [(unspec_volatile [(const_int 0)] VUNSPEC_SPECULATION_BARRIER)]
+  "TARGET_32BIT"
+  "isb\;dsb\\tsy"
+  [(set_attr "type" "block")
+   (set_attr "length" "8")]
+)
+
 ;; Vector bits common to IWMMXT and Neon
 (include "vec-common.md")
 ;; Load the Intel Wireless Multimedia Extension patterns
diff --git a/gcc/config/arm/unspecs.md b/gcc/config/arm/unspecs.md
index b05f85e..1941673 100644
--- a/gcc/config/arm/unspecs.md
+++ b/gcc/config/arm/unspecs.md
@@ -168,6 +168,7 @@ (define_c_enum "unspecv" [
   VUNSPEC_MCRR2		; Represent the coprocessor mcrr2 instruction.
   VUNSPEC_MRRC		; Represent the coprocessor mrrc instruction.
   VUNSPEC_MRRC2		; Represent the coprocessor mrrc2 instruction.
+  VUNSPEC_SPECULATION_BARRIER ; Represents an unconditional speculation barrier.
 ])
 
 ;; Enumerators for NEON unspecs.

Re: [PATCH] enhance strlen to understand MEM_REF and partial overlaps (PR 86042, 86043)

[Eric Botcazou]

> I missed your approval and didn't get to committing the patch
> until today.  While retesting it on top of fresh trunk I noticed
> a few test failures due to other recent strlen changes.  I made
> adjustments to the patch to avoid most of them and opened bug
> 86688 for one that I think needs a separate code change and
> xfailed the test cases until the bug gets resolved.

But it has introduced a couple of regressions in the ACATS testsuite:

FAIL:   c52103c
FAIL:   cde0001

=== acats Summary ===
# of expected passes2318
# of unexpected failures2
Native configuration is x86_64-suse-linux-gnu


+===GNAT BUG DETECTED==+
| 9.0.0 20180727 (experimental) [trunk revision 263028] (x86_64-suse-linux) 
GCC error:|
| in handle_char_store, at tree-ssa-strlen.c:3332  |
| Error detected around c52103c.adb:43:1   |

-- 
Eric Botcazou

Re: [PATCH 1/7] Add __builtin_speculation_safe_value

[Richard Earnshaw (lists)]

On 27/07/18 01:46, Paul Koning wrote:
> 
> 
>> On Jul 26, 2018, at 7:34 PM, Joseph Myers  wrote:
>>
>> On Wed, 25 Jul 2018, Richard Earnshaw (lists) wrote:
>>
> Port maintainers DO need to decide what to do about speculation, even if
> it is explicitly that no mitigation is needed.

 Agreed.  But I didn't yet see a request for maintainers to decide that?

>>>
>>> consider it made, then :-)
>>
>> I suggest the following as an appropriate process for anything needing 
>> attention from architecture maintainers:
>>
>> * Send a message to the gcc list, starting its own thread, CC:ed to all 
>> target architecture maintainers, stating explicitly in its first sentence 
>> that it is about something needing action from all such maintainers.
> 
> Yes, because it was not clear to me that a patch discussion about a 
> speculation builtin was something that every target maintainer was supposed 
> to look at.  "Speculation" is not a term that shows up in my target...
> 
>> ...
>> * Over the next few months, send occasional reminders, each including a 
>> list of the ports that have not been updated.
> 
> Would the GCC Wiki be a good place to collect all the responses and track 
> what is still open?  If not, what is a good way to do the tracking?
> 
>   paul
> 

The c-c++-common/spec-barrier-1.c test will fail on any target that has
not been updated (it deliberately doesn't check for
__HAVE_SPECULATION_BARRIER before trying to use the new intrinsic).  The
test contains a comment to that effect.  That should be enough to alert
maintainers if they are tracking testsuite errors.

I'll be posting some examples for how to handle various types of target
shortly.  Target maintainers should then be able to decide which action
they need to take.

R.

Re: Build fail on gthr-simple.h targets (Re: AsyncI/O patch committed)

[Thomas Koenig]

Am 26.07.2018 um 22:54 schrieb Thomas Koenig:

Hi Ulrich,


The problem is that io/asynch.h unconditionally uses a couple of
features that are not provided by gthr-simplex, in particular
   __gthread_cond_t
and
   __gthread_equal / __gthread_self

According to the documentation in gthr.h, the former is only available
if __GTHREAD_HAS_COND is defined, and the latter are only available if
__GTHREADS_CXX0X is defined.  Neither is true for gthr-simple.h.


Thanks for the analysis, and the pointer to the macros.

Because the functionality depends on these features, it is best to
remove them if it is not present. So, here is a patch which does
just that.

This was reg-tested on Linux, which showed that the functionality is
still there. I tried bootstrapping on AIX on gcc119, but this failed
due to an unrelated issue (problem with compiling the inline
libraries).



OK, this does not work.

We have found a method of checking on Linux, and this does not work.
We have also found a way of working in the next couple of days, so
expect an update in one or two days.

If that is too much time, feel free to revert the async patch
in the meantime.

Regards

Thomas

[PATCH] Fix DJGPP LTO with debug

[Richard Biener]

This patch from jwjager...@gmail.com clones the fixes done for
mingw and darwin to make LTO work together with -g in GCC 8+.

It's said to build OK in a djgpp configuration and I expect similar
results as for mingw and darwin.

The original application the reporter ran into the issue with isn't
fixed because of latent issues when combining a -g0 compile with
a -g link (the default for those targets).

Bootstrapped on x86_64-unknown-linux-gnu, ok for trunk and GCC 8 branch?

DJ, did you ever run the testsuite with a configuration that has LTO
enabled?  I don't see any djgpp results posted to gcc-testresults.
Quick googling doesn't yield anything useful with regarding on how to
do actual testing with a cross so I only built a i686-pc-msdosdjgpp
cross cc1/lto1 from x86_64-linux which went fine.

Thanks,
Richard.

2018-07-27 Jan Willem Jagersma  

PR target/86651
* dwarf2out.c (dwarf2out_early_finish): Do not generate assembly in LTO
mode for COFF targets.
* defaults.h (TARGET_COFF): Define.
* config/i386/djgpp.h (TARGET_ASM_LTO_START, TARGET_ASM_LTO_END,
TARGET_COFF): Define.
(i386_djgpp_asm_lto_start, i386_djgpp_asm_lto_end): Declare.
* config/i386/djgpp.c (saved_debug_info_level): New static variable.
(i386_djgpp_asm_lto_start, i386_djgpp_asm_lto_end): New functions.

diff --git a/gcc/config/i386/djgpp.c b/gcc/config/i386/djgpp.c
index f168eed6f06..d187c3a7452 100644
--- a/gcc/config/i386/djgpp.c
+++ b/gcc/config/i386/djgpp.c
@@ -47,3 +47,20 @@ i386_djgpp_asm_named_section(const char *name, unsigned int 
flags,
 
   fprintf (asm_out_file, "\t.section\t%s,\"%s\"\n", name, flagchars);
 }
+
+/* Kludge because of missing COFF support for early LTO debug.  */
+
+static enum debug_info_levels saved_debug_info_level;
+
+void
+i386_djgpp_asm_lto_start (void)
+{
+  saved_debug_info_level = debug_info_level;
+  debug_info_level = DINFO_LEVEL_NONE;
+}
+
+void
+i386_djgpp_asm_lto_end (void)
+{
+  debug_info_level = saved_debug_info_level;
+}
diff --git a/gcc/config/i386/djgpp.h b/gcc/config/i386/djgpp.h
index 01774cea4d6..dd8c71b833a 100644
--- a/gcc/config/i386/djgpp.h
+++ b/gcc/config/i386/djgpp.h
@@ -157,8 +157,19 @@ along with GCC; see the file COPYING3.  If not see
 #undef MAKE_DECL_ONE_ONLY
 #define MAKE_DECL_ONE_ONLY(DECL) (DECL_WEAK (DECL) = 1)
 
+#undef TARGET_COFF
+#define TARGET_COFF 1
+
+/* Kludge because of missing COFF support for early LTO debug.  */
+#undef  TARGET_ASM_LTO_START
+#define TARGET_ASM_LTO_START i386_djgpp_asm_lto_start
+#undef  TARGET_ASM_LTO_END
+#define TARGET_ASM_LTO_END i386_djgpp_asm_lto_end
+
 /* Function protypes for gcc/i386/djgpp.c */
 
 void
 i386_djgpp_asm_named_section(const char *name, unsigned int flags,
 tree decl);
+void i386_djgpp_asm_lto_start (void);
+void i386_djgpp_asm_lto_end (void);
diff --git a/gcc/defaults.h b/gcc/defaults.h
index 78a08a33f12..9035b333be8 100644
--- a/gcc/defaults.h
+++ b/gcc/defaults.h
@@ -1282,6 +1282,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. 
 If not, see
 #define TARGET_PECOFF 0
 #endif
 
+#ifndef TARGET_COFF
+#define TARGET_COFF 0
+#endif
+
 #ifndef EH_RETURN_HANDLER_RTX
 #define EH_RETURN_HANDLER_RTX NULL
 #endif
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 8377cbc5dd1..c75aadbaa2c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -31938,10 +31938,10 @@ dwarf2out_early_finish (const char *filename)
 
   /* Do not generate DWARF assembler now when not producing LTO bytecode.  */
   if ((!flag_generate_lto && !flag_generate_offload)
-  /* FIXME: Disable debug info generation for PE-COFF targets since the
+  /* FIXME: Disable debug info generation for (PE-)COFF targets since the
 copy_lto_debug_sections operation of the simple object support in
 libiberty is not implemented for them yet.  */
-  || TARGET_PECOFF)
+  || TARGET_PECOFF || TARGET_COFF)
 return;
 
   /* Now as we are going to output for LTO initialize sections and labels