[committed] Fix problem reloading floating-point operands in xmpyu patterns on 64-bit parisc

[John David Anglin]

On 64-bit targets, 32-bit values are typically extended to 64-bits.  So, the 
32-bit
SImode operands in the xmpyu patterns end up being loaded as 64-bit values into 
a
a floating-point register.  The value is then implicitly narrowed to 32 bits by
pa_print_operand().

In the case the operand needs to be reloaded, we need to indicate to reload that
DI to SI mode class changes are okay.  Otherwise, we end up with an invalid 
SUBREG
insn.  The attached change fixes this problem.

Tested on hppa64-hp-hpux11.11.  Committed to active branches.

Dave
-- 
John David Anglin  dave.ang...@bell.net
2019-05-24  John David Anglin  

PR target/90530
* config/pa/pa.c (pa_can_change_mode_class): Accept mode changes from
DImode to SImode in floating-point registers on 64-bit target.
* config/pa/pa.md (umulsidi3): Change nonimmediate_operand to
register_operand in xmpyu patterns.

Index: config/pa/pa.c
===
--- config/pa/pa.c  (revision 271383)
+++ config/pa/pa.c  (working copy)
@@ -10011,10 +10011,11 @@
   /* There is no way to load QImode or HImode values directly from memory
  to a FP register.  SImode loads to the FP registers are not zero
  extended.  On the 64-bit target, this conflicts with the definition
- of LOAD_EXTEND_OP.  Thus, we can't allow changing between modes with
- different sizes in the floating-point registers.  */
+ of LOAD_EXTEND_OP.  Thus, we reject all mode changes in the FP registers
+ except for DImode to SImode on the 64-bit target.  It is handled by
+ register renaming in pa_print_operand.  */
   if (MAYBE_FP_REG_CLASS_P (rclass))
-return false;
+return TARGET_64BIT && from == DImode && to == SImode;
 
   /* TARGET_HARD_REGNO_MODE_OK places modes with sizes larger than a word
  in specific sets of registers.  Thus, we cannot allow changing
Index: config/pa/pa.md
===
--- config/pa/pa.md (revision 271383)
+++ config/pa/pa.md (working copy)
@@ -5319,8 +5319,8 @@
 
 (define_insn "umulsidi3"
   [(set (match_operand:DI 0 "register_operand" "=f")
-   (mult:DI (zero_extend:DI (match_operand:SI 1 "nonimmediate_operand" 
"f"))
-(zero_extend:DI (match_operand:SI 2 "nonimmediate_operand" 
"f"]
+   (mult:DI (zero_extend:DI (match_operand:SI 1 "register_operand" "f"))
+(zero_extend:DI (match_operand:SI 2 "register_operand" "f"]
   "TARGET_PA_11 && ! TARGET_DISABLE_FPREGS && ! TARGET_SOFT_FLOAT"
   "xmpyu %1,%2,%0"
   [(set_attr "type" "fpmuldbl")
@@ -5328,7 +5328,7 @@
 
 (define_insn ""
   [(set (match_operand:DI 0 "register_operand" "=f")
-   (mult:DI (zero_extend:DI (match_operand:SI 1 "nonimmediate_operand" 
"f"))
+   (mult:DI (zero_extend:DI (match_operand:SI 1 "register_operand" "f"))
 (match_operand:DI 2 "uint32_operand" "f")))]
   "TARGET_PA_11 && ! TARGET_DISABLE_FPREGS && ! TARGET_SOFT_FLOAT && 
!TARGET_64BIT"
   "xmpyu %1,%R2,%0"
@@ -5337,7 +5337,7 @@
 
 (define_insn ""
   [(set (match_operand:DI 0 "register_operand" "=f")
-   (mult:DI (zero_extend:DI (match_operand:SI 1 "nonimmediate_operand" 
"f"))
+   (mult:DI (zero_extend:DI (match_operand:SI 1 "register_operand" "f"))
 (match_operand:DI 2 "uint32_operand" "f")))]
   "TARGET_PA_11 && ! TARGET_DISABLE_FPREGS && ! TARGET_SOFT_FLOAT && 
TARGET_64BIT"
   "xmpyu %1,%2R,%0"

[committed] Implement OpenMP 5.0 lastprivate(conditional:) for #pragma omp for

[Jakub Jelinek]

Hi!

The following patch implements lastprivate clause with conditional modifier
for #pragma omp for (when not combined with parallel).
Next week I'll try to address combined parallel for, sections, simd and for
simd.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2019-05-24  Jakub Jelinek  

* tree-core.h (enum omp_clause_code): Add OMP_CLAUSE__CONDTEMP_.
* tree.h (OMP_CLAUSE_DECL): Use OMP_CLAUSE__CONDTEMP_ instead of
OMP_CLAUSE__REDUCTEMP_.
* tree.c (omp_clause_num_ops, omp_clause_code_name): Add
OMP_CLAUSE__CONDTEMP_.
(walk_tree_1): Handle OMP_CLAUSE__CONDTEMP_.
* tree-pretty-print.c (dump_omp_clause): Likewise.
* tree-nested.c (convert_nonlocal_omp_clauses,
convert_local_omp_clauses): Likewise.
* gimplify.c (enum gimplify_omp_var_data): Use hexadecimal constants
instead of decimal.  Add GOVD_LASTPRIVATE_CONDITIONAL.
(gimplify_scan_omp_clauses): Don't reject lastprivate conditional
on OMP_FOR.
(gimplify_omp_for): Warn and disable conditional modifier from
lastprivate on loop iterators.
* omp-general.h (struct omp_for_data): Add lastprivate_conditional
member.
* omp-general.c (omp_extract_for_data): Initialize it.
* omp-low.c (struct omp_context): Add lastprivate_conditional_map
member.
(delete_omp_context): Delete it.
(lower_lastprivate_conditional_clauses): New function.
(lower_lastprivate_clauses): Add BODY_P and CSTMT_LIST arguments,
handle lastprivate conditional clauses.
(lower_reduction_clauses): Add CLIST argument, emit it into
the critical section if any.
(lower_omp_sections): Adjust lower_lastprivate_clauses and
lower_reduction_clauses callers.
(lower_omp_for_lastprivate): Add CLIST argument, pass it through
to lower_lastprivate_clauses.
(lower_omp_for): Call lower_lastprivate_conditional_clauses, adjust
lower_omp_for_lastprivate and lower_reduction_clauses callers, emit
clist into a critical section if not emitted there already by
lower_reduction_clauses.
(lower_omp_taskreg, lower_omp_teams): Adjust lower_reduction_clauses
callers.
(lower_omp_1): Handle GIMPLE_ASSIGNs storing into lastprivate
conditional variables.
* omp-expand.c (determine_parallel_type): Punt if OMP_CLAUSE__CONDTEMP_
clause is present.
(expand_omp_for_generic, expand_omp_for_static_nochunk,
expand_omp_for_static_chunk): Handle lastprivate conditional.
(expand_omp_for): Handle fd.lastprivate_conditional like
fd.have_reductemp.
gcc/testsuite/
* c-c++-common/gomp/lastprivate-conditional-2.c (foo): Don't expect
sorry for omp for.
* c-c++-common/gomp/lastprivate-conditional-3.c: New test.
libgomp/
* testsuite/libgomp.c-c++-common/lastprivate-conditional-1.c: New test.
* testsuite/libgomp.c-c++-common/lastprivate-conditional-2.c: New test.

--- gcc/tree-core.h.jj  2019-05-24 10:54:49.447682115 +0200
+++ gcc/tree-core.h 2019-05-24 12:23:22.535364602 +0200
@@ -343,6 +343,9 @@ enum omp_clause_code {
   /* Internal clause: temporary for task reductions.  */
   OMP_CLAUSE__REDUCTEMP_,
 
+  /* Internal clause: temporary for lastprivate(conditional:).  */
+  OMP_CLAUSE__CONDTEMP_,
+
   /* OpenACC/OpenMP clause: if (scalar-expression).  */
   OMP_CLAUSE_IF,
 
--- gcc/tree.h.jj   2019-05-24 10:54:49.781676629 +0200
+++ gcc/tree.h  2019-05-24 12:23:22.528364717 +0200
@@ -1439,7 +1439,7 @@ class auto_suppress_location_wrappers
 #define OMP_CLAUSE_DECL(NODE)  \
   OMP_CLAUSE_OPERAND (OMP_CLAUSE_RANGE_CHECK (OMP_CLAUSE_CHECK (NODE), \
  OMP_CLAUSE_PRIVATE,   \
- OMP_CLAUSE__REDUCTEMP_), 0)
+ OMP_CLAUSE__CONDTEMP_), 0)
 #define OMP_CLAUSE_HAS_LOCATION(NODE) \
   (LOCATION_LOCUS ((OMP_CLAUSE_CHECK (NODE))->omp_clause.locus)
\
   != UNKNOWN_LOCATION)
--- gcc/tree.c.jj   2019-05-24 10:54:49.734677400 +0200
+++ gcc/tree.c  2019-05-24 12:23:22.532364651 +0200
@@ -308,6 +308,7 @@ unsigned const char omp_clause_num_ops[]
   0, /* OMP_CLAUSE_SEQ  */
   1, /* OMP_CLAUSE__LOOPTEMP_  */
   1, /* OMP_CLAUSE__REDUCTEMP_  */
+  1, /* OMP_CLAUSE__CONDTEMP_  */
   1, /* OMP_CLAUSE_IF  */
   1, /* OMP_CLAUSE_NUM_THREADS  */
   1, /* OMP_CLAUSE_SCHEDULE  */
@@ -385,6 +386,7 @@ const char * const omp_clause_code_name[
   "seq",
   "_looptemp_",
   "_reductemp_",
+  "_condtemp_",
   "if",
   "num_threads",
   "schedule",
@@ -12304,6 +12306,7 @@ walk_tree_1 (tree *tp, walk_tree_fn func
case OMP_CLAUSE_IS_DEVICE_PTR:
case OMP_CLAUSE__LOOPTEMP_:
case OMP_CLAUSE__REDUCTEMP_:
+   case OMP_CLAUSE__CONDTEMP_:
case 

Re: [C++ Patch] PR 89875 ("[7/8/9/10 Regression] invalid typeof reference to a member of an incomplete struct accepted at function scope")

[Paolo Carlini]

Hi,

gently pinging this...

On 10/05/19 16:29, Paolo Carlini wrote:

Hi,

a while ago Martin noticed that an unintended consequence of an old 
tweak of mine - which avoided redundant error messages emitted from 
cp_parser_init_declarator - is that, in some cases, we started 
accepting ill-formed typeofs. Luckily, decltype isn't affected and 
that points to the real issue: by the time that place in 
cp_parser_init_declarator is reached, for a decltype version we 
already emitted a correct error message. Thus I think the right way to 
fix the problem is simply committing to tentative parse when, toward 
the end of cp_parser_sizeof_operand we know that we must be looking at 
a (possibly ill-formed) expression. Tested x86_64-linux.


    https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00501.html

Thanks, Paolo.

PS: To be honest, not knowing the exact rules, I would not consider this 
issue a P2 - in particular considering that typeof is legacy and is 
affected but all sorts of weird issues - but that's what it is ;)

Re: C++ PATCH for c++/90572 - wrong disambiguation in friend declaration

[Jason Merrill]

On 5/24/19 3:16 PM, Marek Polacek wrote:

Here we were parsing

   template  struct C {
 friend C(T::fn)(); // this
   };

wrongly in C++2a since my P0634 patch.  T::fn is actually a function
declaration, but cp_parser_constructor_declarator_p was thinking it's
a constructor.  That function actually has code to prevent the compiler
from thinking that

   S (f)(int);

is a constructor: it checks if after 'S' there's '(' followed by ')', '...',
or a type.  If parsing the type succeeds, it looks like a ctor.  In this
case it succeeded, because T::fn is a qualified name and we are parsing
a member-declaration, so CP_PARSER_FLAGS_TYPENAME_OPTIONAL was set.

We can either look further and say it's not a constructor if what comes
after "(T::fn)" is '('.  Or we can prevent cp_parser_type_specifier from
assuming a type if friend_p, because while constructors can be friends,
they need to use a qualified-id, and at this point we know that the name
isn't qualified, so it can't be a valid friend constructor.

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

2019-05-24  Marek Polacek  

PR c++/90572 - wrong disambiguation in friend declaration.
* parser.c (cp_parser_constructor_declarator_p): Don't allow missing
typename for friend declarations.


OK.

Jason

Re: Question on adding an option control to libcpp

[Qing Zhao]

Hi, David,

this is helpful.

thanks.

Qing
> On May 24, 2019, at 1:47 PM, David Malcolm  wrote:
> 
> On Fri, 2019-05-24 at 11:59 -0500, Qing Zhao wrote:
>> Hi, 
>> 
>> in order to fix PR90581: (provide an option to adjust the maximum
>> depth of nested #include)
>> 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 > rg/bugzilla/show_bug.cgi?id=90581>
>> 
>> we need to add a new option to preprocessor.  where should I put this
>> option?
>> 
>> I tried to add a new option into:
>> 
>> gcc/c-family/c.opt
>> 
>> [qinzhao@localhost c-family]$ git diff c.opt
>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>> index 046d489..4f237b6 100644
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -1598,6 +1598,10 @@ flocal-ivars
>> ObjC ObjC++ Var(flag_local_ivars) Init(1)
>> Allow access to instance variables as if they were local
>> declarations within instance method implementati
>> 
>> +finclude-nest-limit=
>> +C ObjC C++ ObjC++ Joined RejectNegative UInteger
>> Var(include_nest_limit) Init(200)
>> +Set the maximum number of depth of nested #include.
>> +
>> 
>> However, don’t know how to refer this new variable
>> “include_nest_limit” from libcpp.
>> 
> 
> You probably want to add a new field to cpp_options, and copy over the
> value from the GCC options to the new field; see e.g.
> c_common_handle_option where various cases write to fields of cpp_opts.
> 
> Hope this is helpful
> Dave
> 

C++ PATCH for c++/90572 - wrong disambiguation in friend declaration

[Marek Polacek]

Here we were parsing 

  template  struct C {
friend C(T::fn)(); // this
  };

wrongly in C++2a since my P0634 patch.  T::fn is actually a function
declaration, but cp_parser_constructor_declarator_p was thinking it's
a constructor.  That function actually has code to prevent the compiler
from thinking that

  S (f)(int);

is a constructor: it checks if after 'S' there's '(' followed by ')', '...',
or a type.  If parsing the type succeeds, it looks like a ctor.  In this
case it succeeded, because T::fn is a qualified name and we are parsing
a member-declaration, so CP_PARSER_FLAGS_TYPENAME_OPTIONAL was set.

We can either look further and say it's not a constructor if what comes
after "(T::fn)" is '('.  Or we can prevent cp_parser_type_specifier from
assuming a type if friend_p, because while constructors can be friends,
they need to use a qualified-id, and at this point we know that the name
isn't qualified, so it can't be a valid friend constructor.

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

2019-05-24  Marek Polacek  

PR c++/90572 - wrong disambiguation in friend declaration.
* parser.c (cp_parser_constructor_declarator_p): Don't allow missing
typename for friend declarations.

* g++.dg/cpp2a/typename16.C: New test.
* g++.dg/parse/friend13.C: New test.

diff --git gcc/cp/parser.c gcc/cp/parser.c
index 1440fdb0d18..08b4105c97f 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -27593,9 +27593,19 @@ cp_parser_constructor_declarator_p (cp_parser *parser, 
cp_parser_flags flags,
  parser->num_template_parameter_lists = 0;
 
  /* Look for the type-specifier.  It's not optional, but its typename
-might be.  */
+might be.  Unless this is a friend declaration; we don't want to
+treat
+
+  friend S (T::fn)(int);
+
+as a constructor, but with P0634, we might assume a type when
+looking for the type-specifier.  It is actually a function named
+`T::fn' that takes one parameter (of type `int') and returns a
+value of type `S'.  Constructors can be friends, but they must
+use a qualified name.  */
  cp_parser_type_specifier (parser,
-   (flags & ~CP_PARSER_FLAGS_OPTIONAL),
+   (friend_p ? CP_PARSER_FLAGS_NONE
+: (flags & ~CP_PARSER_FLAGS_OPTIONAL)),
/*decl_specs=*/NULL,
/*is_declarator=*/true,
/*declares_class_or_enum=*/NULL,
diff --git gcc/testsuite/g++.dg/cpp2a/typename16.C 
gcc/testsuite/g++.dg/cpp2a/typename16.C
new file mode 100644
index 000..7f4242a1dba
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/typename16.C
@@ -0,0 +1,11 @@
+// PR c++/90572
+// { dg-do compile { target c++2a } }
+
+struct X { X(int); };
+
+template struct S {
+  friend X::X(T::t);
+};
+
+struct W { using t = int; };
+S s;
diff --git gcc/testsuite/g++.dg/parse/friend13.C 
gcc/testsuite/g++.dg/parse/friend13.C
new file mode 100644
index 000..d716247a5da
--- /dev/null
+++ gcc/testsuite/g++.dg/parse/friend13.C
@@ -0,0 +1,16 @@
+// PR c++/90572
+
+template  struct C {
+  friend C(T::fn)();
+  friend C(T::fn)(int);
+  friend C(T::fn)(int, int);
+};
+
+struct X { };
+
+template
+struct B {
+  friend X(T::fn)();
+  friend X(T::fn)(int);
+  friend X(T::fn)(int, int);
+};

Re: Question on adding an option control to libcpp

[David Malcolm]

On Fri, 2019-05-24 at 11:59 -0500, Qing Zhao wrote:
> Hi, 
> 
> in order to fix PR90581: (provide an option to adjust the maximum
> depth of nested #include)
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581  rg/bugzilla/show_bug.cgi?id=90581>
> 
> we need to add a new option to preprocessor.  where should I put this
> option?
> 
> I tried to add a new option into:
> 
> gcc/c-family/c.opt
> 
> [qinzhao@localhost c-family]$ git diff c.opt
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index 046d489..4f237b6 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -1598,6 +1598,10 @@ flocal-ivars
>  ObjC ObjC++ Var(flag_local_ivars) Init(1)
>  Allow access to instance variables as if they were local
> declarations within instance method implementati
>  
> +finclude-nest-limit=
> +C ObjC C++ ObjC++ Joined RejectNegative UInteger
> Var(include_nest_limit) Init(200)
> +Set the maximum number of depth of nested #include.
> +
> 
> However, don’t know how to refer this new variable
> “include_nest_limit” from libcpp.
> 

You probably want to add a new field to cpp_options, and copy over the
value from the GCC options to the new field; see e.g.
c_common_handle_option where various cases write to fields of cpp_opts.

Hope this is helpful
Dave

Re: [PATCH] Commonize anon-name generation

[Iain Buclaw]

On Fri, 24 May 2019 at 16:34, Nathan Sidwell  wrote:
>
> Currently gcc/tree.c exports an anonymous name format string, and a
> predicate to detect identifiers of that form.  The C++ and D FEs use
> those functions to create and check anonymous names.
>
> That seems a little duplicative.  This patch changes tree.c to export an
> anonymous name generator, and uses a spare bit in IDENTIFIERs to mark
> them as anonymous, so no more strcmp to distinguish them.  Then replaces
> the bespoke handling in the two front ends to use the new interface.
>
> While my original goal was to make there be only one anon-identifier in
> the C++ FE (because modules kind of would prefer not to have names
> depend on source ordering), I didn't get to that goal, I think we still
> sometimes place them in symbol tables.  But this still seems a good thing.
>
> Are the common and D pieces ok?
>

Seems reasonable to me.  Don't have a strong opinion either on how it's done.

-- 
Iain

Question on adding an option control to libcpp

[Qing Zhao]

Hi, 

in order to fix PR90581: (provide an option to adjust the maximum depth of 
nested #include)

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


we need to add a new option to preprocessor.  where should I put this option?

I tried to add a new option into:

gcc/c-family/c.opt

[qinzhao@localhost c-family]$ git diff c.opt
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 046d489..4f237b6 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1598,6 +1598,10 @@ flocal-ivars
 ObjC ObjC++ Var(flag_local_ivars) Init(1)
 Allow access to instance variables as if they were local declarations within 
instance method implementati
 
+finclude-nest-limit=
+C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(include_nest_limit) 
Init(200)
+Set the maximum number of depth of nested #include.
+

However, don’t know how to refer this new variable “include_nest_limit” from 
libcpp.

thanks a lot for the help.

Qing

Re: [PATCH] aarch64: emit .variant_pcs for aarch64_vector_pcs symbol references

[Szabolcs Nagy]

On 24/05/2019 15:31, Richard Sandiford wrote:
> Szabolcs Nagy  writes:
>> +static void
>> +aarch64_asm_output_variant_pcs (FILE *stream, const tree decl, const char* 
>> name)
>> +{
>> +  if (TREE_CODE (decl) == FUNCTION_DECL
>> +  && TREE_PUBLIC (decl)
>> +  && lookup_attribute ("aarch64_vector_pcs",
>> +   TYPE_ATTRIBUTES (TREE_TYPE (decl
>> +{
>> +  fprintf (stream, "\t.variant_pcs\t");
>> +  assemble_name (stream, name);
>> +  fprintf (stream, "\n");
>> +}
>> +}
> 
> What do you think about leaving out the TREE_PUBLIC check?  The ABI
> doesn't require !TREE_PUBLIC functions to be marked, but it might be
> safer to do the same thing for all VPCS functions anyway (especially
> since, like you say below, we still mark some things that don't
> necessarily need to be marked).

yes, always emitting the directive seems simpler.

a use-case where it is preferable to only emit the
directive when necessary is when there is no asm
support, but we want to use local vector functions.

(e.g. static linking could work without asm support if
all vector functions are made hidden somehow and
emitting the directive is prevented for hidden symbols)

but that's not a very strong case.

i'll change this and address the other comments.

Re: [PATCH][GCC][AArch64] Make processing less fragile in config.gcc

[Kyrill Tkachov]

Hi Tamar,

On 5/21/19 6:00 PM, Tamar Christina wrote:

Hi All,

Due to config.gcc all the options need to be on one line because of 
the grep

lines which would select only the first line of the option.

This causes it not to select the right bits on options that are spread 
over
multiple lines when the --with-arch configure option is used.  The 
issue happens
silently and you just get a compiler with an incorrect set of default 
flags.


The current rules are quite rigid:

   1) No space between the AARCH64_OPT_EXTENSION and the opening (.
   2) No space between the opening ( and the extension name.
   3) No space after the extension name before the ,.
   4) Spaces are only allowed after a , and around |.

This patch makes this a lot less fragile by using the C pre-processor 
to flatten
the list and then provides much more flexible regex using group 
matching to

process the options instead of string replacement.  This removes all the
restrictions above and makes the code a bit more readable.

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Ok for trunk? and for eventual backport?

Thanks,
Tamar

gcc/ChangeLog:

2019-05-21  Tamar Christina  

    PR target/89517
    * config.gcc: Relax parsing of AARCH64_OPT_EXTENSION.
    * config/aarch64/aarch64-option-extensions.def: Add new comments
    and restore easier to read options.


LGTM FWIW, but I'm afraid you'll need to rebase it over the recent 
addition of sve2 family to the extensions.


Thanks,

Kyrill





--

Re: C++ PATCH to implement deferred parsing of noexcept-specifiers (c++/86476, c++/52869)

[Marek Polacek]

Ping.

On Fri, May 17, 2019 at 10:35:29AM -0400, Marek Polacek wrote:
> Ping.
> 
> On Fri, May 10, 2019 at 03:21:33PM -0400, Marek Polacek wrote:
> > Coming back to this.  I didn't think this was suitable for GCC 9.
> > 
> > On Mon, Jan 07, 2019 at 10:44:37AM -0500, Jason Merrill wrote:
> > > On 12/19/18 3:27 PM, Marek Polacek wrote:
> > > > Prompted by Jon's observation in 52869, I noticed that we don't treat
> > > > a noexcept-specifier as a complete-class context of a class 
> > > > ([class.mem]/6).
> > > > As with member function bodies, default arguments, and NSDMIs, names 
> > > > used in
> > > > a noexcept-specifier of a member-function can be declared later in the 
> > > > class
> > > > body, so we need to wait and parse them at the end of the class.
> > > > For that, I've made use of DEFAULT_ARG (now best to be renamed to 
> > > > UNPARSED_ARG).
> > > 
> > > Or DEFERRED_PARSE, yes.
> > 
> > I didn't change the name but I'm happy to do it as a follow up.
> > 
> > > > +  /* We can't compare unparsed noexcept-specifiers.  Save the old decl
> > > > + and check this again after we've parsed the noexcept-specifiers
> > > > + for real.  */
> > > > +  if (UNPARSED_NOEXCEPT_SPEC_P (new_exceptions))
> > > > +{
> > > > +  vec_safe_push (DEFARG_INSTANTIATIONS (TREE_PURPOSE 
> > > > (new_exceptions)),
> > > > +copy_decl (old_decl));
> > > > +  return;
> > > > +}
> > > 
> > > Why copy_decl?
> > 
> > This is so that we don't lose the diagnostic in noexcept46.C.  If I don't 
> > use
> > copy_decl then the tree is shared and subsequent changes to it make us not
> > detect discrepancies like noexcept(false) vs. noexcept(true) on the same 
> > decl.
> > 
> > > It seems wasteful to allocate a vec to hold this single decl; let's make 
> > > the
> > > last field of tree_default_arg a union instead.  And add a new macro for 
> > > the
> > > single decl case.
> > 
> > Done.  But that required also adding GTY markers *and* a new BOOL_BITFIELD 
> > for
> > the sake of GTY((desc)).
> > 
> > > I notice that default_arg currently uses tree_common for some reason, and 
> > > we
> > > ought to be able to save two words by switching to tree_base
> > 
> > Done.
> > 
> > > > @@ -1245,6 +1245,7 @@ nothrow_spec_p (const_tree spec)
> > > >   || TREE_VALUE (spec)
> > > >   || spec == noexcept_false_spec
> > > >   || TREE_PURPOSE (spec) == error_mark_node
> > > > + || TREE_CODE (TREE_PURPOSE (spec)) == DEFAULT_ARG
> > > 
> > > Maybe use UNPARSED_NOEXCEPT_SPEC_P here?
> >  
> > Done.
> > 
> > > > +/* Make sure that any member-function parameters are in scope.
> > > > +   For instance, a function's noexcept-specifier can use the function's
> > > > +   parameters:
> > > > +
> > > > +   struct S {
> > > > + void fn (int p) noexcept(noexcept(p));
> > > > +   };
> > > > +
> > > > +   so we need to make sure name lookup can find them.  This is used
> > > > +   when we delay parsing of the noexcept-specifier.  */
> > > > +
> > > > +static void
> > > > +maybe_begin_member_function_processing (tree decl)
> > > 
> > > This name is pretty misleading.  How about inject_parm_decls, to go with
> > > inject_this_parameter?
> > 
> > Done.
> > 
> > > > +/* Undo the effects of maybe_begin_member_function_processing.  */
> > > > +
> > > > +static void
> > > > +maybe_end_member_function_processing (void)
> > > 
> > > And then perhaps pop_injected_parms.
> > 
> > Done.
> > 
> > > > +/* Check throw specifier of OVERRIDER is at least as strict as
> > > > +   the one of BASEFN.  */
> > > > +
> > > > +bool
> > > > +maybe_check_throw_specifier (tree overrider, tree basefn)
> > > > +{
> > > > +  maybe_instantiate_noexcept (basefn);
> > > > +  maybe_instantiate_noexcept (overrider);
> > > > +  tree base_throw = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (basefn));
> > > > +  tree over_throw = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (overrider));
> > > > +
> > > > +  if (DECL_INVALID_OVERRIDER_P (overrider))
> > > > +return true;
> > > > +
> > > > +  /* Can't check this yet.  Pretend this is fine and let
> > > > + noexcept_override_late_checks check this later.  */
> > > > +  if (UNPARSED_NOEXCEPT_SPEC_P (base_throw)
> > > > +  || UNPARSED_NOEXCEPT_SPEC_P (over_throw))
> > > > +return true;
> > > > +
> > > > +  if (!comp_except_specs (base_throw, over_throw, ce_derived))
> > > > +{
> > > > +  auto_diagnostic_group d;
> > > > +  error ("looser throw specifier for %q+#F", overrider);
> > > 
> > > Since we're touching this diagnostic, let's correct it now to "exception
> > > specification".  And add "on overriding virtual function".
> > 
> > Ok, changed to the more up-to-date term.
> > 
> > Two further changes were required since my changes to detecting 'this' for
> > static member functions:
> > 1) use THIS_FORBIDDEN if needed when parsing the delayed noexcept,
> > 2) careful about friend member functions -- its DECL_CONTEXT is not the
> >   containing class, 

[PATCH V3] Remove empty loop with assumed finiteness (PR tree-optimization/89713)

[Feng Xue OS]

Doing aggressive loop removal at early CD-DCE might break OpenACC 
transformation. To the issue, this version 3 gave a somewhat simpler solution 
different from previous version 2. It uses a flag to postpone loop removal to 
late CD-DCE pass.

Feng
-

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 9f0f889..f18abdc 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2019-05-23  Feng Xue  
+
+   PR tree-optimization/89713
+   * doc/invoke.texi (-ffinite-loop): Document new option.
+   * common.opt (-ffinite-loop): New option.
+   * tree-ssa-dce.c (loop_has_true_exits): New function.
+   (find_obviously_necessary_stmts): Use flag to control
+   removal of a loop with assumed finiteness. 
+   * tree-ssa-loop.c (tree_ssa_loop_done): Update
+   flag_finite_loop.
+
 2019-05-22  David Malcolm  
 
PR c++/90462
diff --git a/gcc/common.opt b/gcc/common.opt
index d342c4f..e98a34d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1437,6 +1437,10 @@ ffinite-math-only
 Common Report Var(flag_finite_math_only) Optimization SetByCombined
 Assume no NaNs or infinities are generated.
 
+ffinite-loop
+Common Report Var(flag_finite_loop) Optimization
+Assume loops are finite if can not be analytically determined.
+
 ffixed-
 Common Joined RejectNegative Var(common_deferred_options) Defer
 -ffixed- Mark  as being unavailable to the compiler.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 6c89843..caa0852 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -412,6 +412,7 @@ Objective-C and Objective-C++ Dialects}.
 -fdevirtualize-at-ltrans  -fdse @gol
 -fearly-inlining  -fipa-sra  -fexpensive-optimizations  -ffat-lto-objects @gol
 -ffast-math  -ffinite-math-only  -ffloat-store  -fexcess-precision=@var{style} 
@gol
+-ffinite-loop @gol
 -fforward-propagate  -ffp-contract=@var{style}  -ffunction-sections @gol
 -fgcse  -fgcse-after-reload  -fgcse-las  -fgcse-lm  -fgraphite-identity @gol
 -fgcse-sm  -fhoist-adjacent-loads  -fif-conversion @gol
@@ -9501,6 +9502,20 @@ that may set @code{errno} but are otherwise free of side 
effects.  This flag is
 enabled by default at @option{-O2} and higher if @option{-Os} is not also
 specified.
 
+@item -ffinite-loop
+@opindex ffinite-loop
+@opindex fno-finite-loop
+Allow the compiler to assume that if finiteness of a loop can not be
+analytically determined, the loop must be finite. With the assumption, some
+aggressive transformation could be possible, such as removal of this kind
+of empty loop by dead code elimination (DCE).
+
+This option is not turned on by any @option{-O} option since it might result
+in incorrect behaviour for programs that contain seemly finite, but actually
+infinite loop.
+
+The default is @option{-fno-finite-loop}.
+
 @item -ftree-dominator-opts
 @opindex ftree-dominator-opts
 Perform a variety of simple scalar cleanups (constant/copy
diff --git a/gcc/testsuite/g++.dg/tree-ssa/empty-loop.C 
b/gcc/testsuite/g++.dg/tree-ssa/empty-loop.C
new file mode 100644
index 000..f6564a2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/empty-loop.C
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-cddce3 -ffinite-loop" } */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+using namespace std;
+
+int foo (vector , list , set , map 
)
+{
+  for (vector::iterator it = v.begin (); it != v.end (); ++it)
+it->length();
+
+  for (list::iterator it = l.begin (); it != l.end (); ++it)
+it->length();
+
+  for (map::iterator it = m.begin (); it != m.end (); ++it)
+it->first + it->second.length();
+
+  for (set::iterator it0 = s.begin (); it0 != s.end(); ++it0)
+for (vector::reverse_iterator it1 = v.rbegin(); it1 != v.rend(); 
++it1)
+  {
+it0->length();
+it1->length();
+  }  
+
+  return 0;
+}
+/* { dg-final { scan-tree-dump-not "if" "cddce3"} } */
+
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/dce-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/dce-2.c
new file mode 100644
index 000..d9b9fd2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/dce-2.c
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-cddce3 -ffinite-loop" } */
+
+typedef struct list {
+char pad[15];
+struct list *next;
+} list;
+
+int data;
+
+list *head, *tail;
+
+int __attribute__((pure)) pfn (int);
+
+int foo (unsigned u, int s)
+{
+  unsigned i;
+  list *p;
+  int j;
+
+  for (i = 0; i < u; i += 2)
+;
+
+  for (p = head; p; p = p->next)
+;
+
+  for (j = data; j & s; j = pfn (j + 3))
+;
+
+  for (p = head; p != tail; p = p->next)
+for (j = data + 1; j > s; j = pfn (j + 2))
+  ;
+
+  return 0;
+}
+/* { dg-final { scan-tree-dump-not "if" "cddce3"} } */
+
diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index 2478219..25f722f 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -357,6 +357,28 @@ mark_control_dependent_edges_necessary (basic_block bb, 
bool ignore_self)
 }
 
 
+/* Check whether a loop 

Re: [PATCH] PR c/86407 - Add option to ignore fndecl attributes on function pointers

[Alex Henrie]

On Fri, May 24, 2019 at 2:01 AM Richard Biener  wrote:
>
> I'm not sure we really need a new warning for this.

On Fri, May 24, 2019 at 9:23 AM Martin Sebor  wrote:
>
> I don't think GCC makes a formal distinction between function
> attributes that affect only function definitions vs those that
> affect its users, or both.  It might be a useful distinction
> to introduce, perhaps even for functions as well as variables,
> but as it is, users (as well as GCC developers) are on our own
> to figure it out.

Then is it preferable to simply silence Wattributes in this case?

On Fri, May 24, 2019 at 2:01 AM Richard Biener  wrote:
>
> > +int __attribute__((__ms_hook_prologue__)) func(); /* no warnings */
> > +
>
> But this is a declaration?

On Fri, May 24, 2019 at 9:23 AM Martin Sebor  wrote:
>
> My first question is: what is the meaning of "function definition
> attributes?"  Presumably those that affect only the definition of
> a function and not its callers or other users?

As far as I can tell, "fndecl" is a misnomer: these attributes are
more accurately called "function definition attributes", i.e.
attributes that affect the assembly code of the function but do not
affect its calling convention.

On Fri, May 24, 2019 at 9:23 AM Martin Sebor  wrote:
>
> Finally, with this as a prerequisite, if we decided that a warning
> like this would be useful, tests to verify that it works for all
> the definition attributes and not for the rest would need to be
> added (i.e., in addition to ms_hook_prologue).

Okay, I will add tests for the other function attributes that should
behave in the same way, commenting out the tests that will require
more work to pass.

The end goal is to include __ms_hook_prologue__ in the WINAPI macro on
Wine without causing spurious warnings. This will go a long way
towards making Wine compatible with current and future Windows
programs. Thank you for help.

-Alex

[PATCH] Fix std::midpoint(T*, T*) for reversed arguments

[Jonathan Wakely]

* include/std/numeric (midpoint(T*, T*)): Fix incorrect result.
* testsuite/26_numerics/midpoint/pointer.cc: Change "compile" test
to "run".

Tested x86_64-linux, committed to trunk. I'll backport to gcc-9-branch
too.


commit c8993a6a75753f9be84edaa692dc36e50dc9b30f
Author: Jonathan Wakely 
Date:   Fri May 24 14:03:51 2019 +0100

Fix std::midpoint(T*, T*) for reversed arguments

* include/std/numeric (midpoint(T*, T*)): Fix incorrect result.
* testsuite/26_numerics/midpoint/pointer.cc: Change "compile" test
to "run".

diff --git a/libstdc++-v3/include/std/numeric b/libstdc++-v3/include/std/numeric
index 4858ad1aea3..9dff247538a 100644
--- a/libstdc++-v3/include/std/numeric
+++ b/libstdc++-v3/include/std/numeric
@@ -195,7 +195,7 @@ template
 enable_if_t<__and_v, bool_constant>, _Tp*>
 midpoint(_Tp* __a, _Tp* __b) noexcept
 {
-  return __a > __b ? __b + (__a - __b) / 2 : __a + (__b - __a) / 2;
+  return __a  + (__b - __a) / 2;
 }
 #endif // C++20
 
diff --git a/libstdc++-v3/testsuite/26_numerics/midpoint/pointer.cc 
b/libstdc++-v3/testsuite/26_numerics/midpoint/pointer.cc
index bd586d28ba0..3d3aafc3ec8 100644
--- a/libstdc++-v3/testsuite/26_numerics/midpoint/pointer.cc
+++ b/libstdc++-v3/testsuite/26_numerics/midpoint/pointer.cc
@@ -16,7 +16,7 @@
 // .
 
 // { dg-options "-std=gnu++2a" }
-// { dg-do compile { target c++2a } }
+// { dg-do run { target c++2a } }
 
 #include 
 #include 

Re: [PATCH] Make any_cast compare typeinfo as well as function pointers

[Jonathan Wakely]

On 24/05/19 11:26 +0100, Jonathan Wakely wrote:

On 24/05/19 10:57 +0200, Christophe Lyon wrote:

Hi Jonathan,

On Thu, 23 May 2019 at 16:13, Jonathan Wakely  wrote:


It's possible for the function pointer comparison to fail even though
the type is correct, because the function could be defined multiple
times with different addresses when shared libraries are in use.

Retain the function pointer check for the common case where the check
succeeds, but compare typeinfo (if RTTI is enabled) if the first check
fails.

   * include/experimental/any (__any_caster): Use RTTI if comparing
   addresses fails, to support non-unique addresses in shared libraries.
   * include/std/any (__any_caster): Likewise.

Tested powerpc64le-linux, committed to trunk, backports to follow.




It seems OK on trunk, but on gcc-7/gcc-8 branches I see:
/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc:20:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/experimental/any:
In instantiation of '_ValueType
std::experimental::fundamentals_v1::any_cast(const
std::experimental::fundamentals_v1::any&) [with _ValueType = int&]':
/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc:28:
required from here
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/experimental/any:358:
error: binding reference of type 'int&' to 'const int' discards
qualifiers
compiler exited with status 1
FAIL: experimental/any/misc/any_cast_neg.cc  (test for errors, line 357)
FAIL: experimental/any/misc/any_cast_neg.cc (test for excess errors)

on arm/aarch64


I don't see how you can have that error when the test was changed to
match on any line:

https://gcc.gnu.org/viewcvs/gcc/branches/gcc-7-branch/libstdc%2B%2B-v3/testsuite/experimental/any/misc/any_cast_neg.cc?r1=271566=271565=271566
https://gcc.gnu.org/viewcvs/gcc/branches/gcc-8-branch/libstdc%2B%2B-v3/testsuite/experimental/any/misc/any_cast_neg.cc?r1=271562=271561=271562



As discussed on IRC, the failure was seen at r271565 and fixed at
r271566.

[committed, amdgcn] Wait for exit value to write before exiting.

[Andrew Stubbs]

This patch fixes a bug in which GCN5 devices often fail to return an 
exit value because it's not yet been written to memory when the program 
exits. The fix is simply to wait for it properly. GCN3 devices did not 
demonstrate the problem, but it was technically wrong there also. The 
bug was introduced when we stopped waiting for all writes to complete.


I've also taken the opportunity to adjust gcn-run such that a similar 
issue can't go unnoticed for so long, in future.


Andrew Stubbs
Mentor Graphics / CodeSourcery
GCN: Wait for exit value to write before exiting.

2019-05-24  Andrew Stubbs  

	gcc/
	* config/gcn/gcn-run.c (main): Set a non-zero return value if the
	kernel does not exit cleanly.
	* config/gcn/gcn.md (gcn_return): Insert s_waitcnt before s_dcache_wb.

diff --git a/gcc/config/gcn/gcn-run.c b/gcc/config/gcn/gcn-run.c
index 84718f42846..21852d78bc5 100644
--- a/gcc/config/gcn/gcn-run.c
+++ b/gcc/config/gcn/gcn-run.c
@@ -853,7 +853,10 @@ main (int argc, char *argv[])
 
   unsigned int upper = (return_value & ~0x) >> 16;
   if (upper == 0xcafe)
-printf ("Kernel exit value was never set\n");
+{
+  printf ("Kernel exit value was never set\n");
+  return_value = 0xff;
+}
   else if (upper == 0x)
 ; /* Set by exit.  */
   else if (upper == 0)
diff --git a/gcc/config/gcn/gcn.md b/gcc/config/gcn/gcn.md
index 2b805a73c56..1f06d0bd5cc 100644
--- a/gcc/config/gcn/gcn.md
+++ b/gcc/config/gcn/gcn.md
@@ -784,10 +784,10 @@
 if (cfun && cfun->machine && cfun->machine->normal_function)
   return "s_setpc_b64\ts[18:19]";
 else
-  return "s_dcache_wb\;s_endpgm";
+  return "s_waitcnt\tlgkmcnt(0)\;s_dcache_wb\;s_endpgm";
   }
   [(set_attr "type" "sop1")
-   (set_attr "length" "8")])
+   (set_attr "length" "12")])
 
 (define_expand "call"
   [(parallel [(call (match_operand 0 "")

Re: [PATCH] PR c/86407 - Add option to ignore fndecl attributes on function pointers

[Martin Sebor]

On 5/23/19 9:57 PM, Alex Henrie wrote:

---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86407#c6
---
  gcc/c-family/c.opt |  4 
  gcc/c/c-decl.c |  4 +++-
  gcc/config/i386/i386-options.c | 12 ++--
  gcc/testsuite/c-c++-common/pr86407-1.c | 23 +++
  gcc/testsuite/c-c++-common/pr86407-2.c | 25 +
  5 files changed, 65 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/c-c++-common/pr86407-1.c
  create mode 100644 gcc/testsuite/c-c++-common/pr86407-2.c

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 046d489f7eb..3b99c96e53d 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -776,6 +776,10 @@ Wsizeof-array-argument
  C ObjC C++ ObjC++ Var(warn_sizeof_array_argument) Warning Init(1)
  Warn when sizeof is applied on a parameter declared as an array.
  
+Wstrict-function-attributes

+C C++ Var(warn_strict_function_attributes) Init(1) Warning
+Warn when function definition attributes are applied to function pointers.


I thought I'd added my comments about the patch to the bug but
I guess I never saved it.

My first question is: what is the meaning of "function definition
attributes?"  Presumably those that affect only the definition of
a function and not its callers or other users?

I don't think GCC makes a formal distinction between function
attributes that affect only function definitions vs those that
affect its users, or both.  It might be a useful distinction
to introduce, perhaps even for functions as well as variables,
but as it is, users (as well as GCC developers) are on our own
to figure it out.

If such a distinction were to be introduced I think we then would
need to go through all attributes and decide which is which, make
sure it makes sense, and document it for each.  This might be
a useful exercise for other reasons as well: we should also
document whether an attribute attaches to the declaration or to
its type (this determines whether a pointer to a function can be
declared to have the same attribute as the function itself).

Finally, with this as a prerequisite, if we decided that a warning
like this would be useful, tests to verify that it works for all
the definition attributes and not for the rest would need to be
added (i.e., in addition to ms_hook_prologue).

Martin


+
  Wstringop-overflow
  C ObjC C++ LTO ObjC++ Warning Alias(Wstringop-overflow=, 2, 0)
  Warn about buffer overflow in string manipulation functions like memcpy
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index 181a8c2e9aa..427d573c8d3 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -6192,7 +6192,9 @@ grokdeclarator (const struct c_declarator *declarator,
  inner_decl = inner_decl->declarator;
if (inner_decl->kind == cdk_id)
  attr_flags |= (int) ATTR_FLAG_DECL_NEXT;
-   else if (inner_decl->kind == cdk_function)
+   else if (inner_decl->kind == cdk_function
+|| (inner_decl->kind == cdk_pointer
+&& TREE_CODE (type) == FUNCTION_TYPE))
  attr_flags |= (int) ATTR_FLAG_FUNCTION_NEXT;
else if (inner_decl->kind == cdk_array)
  attr_flags |= (int) ATTR_FLAG_ARRAY_NEXT;
diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
index 0f236626005..6b50f143b05 100644
--- a/gcc/config/i386/i386-options.c
+++ b/gcc/config/i386/i386-options.c
@@ -3489,8 +3489,16 @@ ix86_handle_fndecl_attribute (tree *node, tree name, 
tree args, int,
  {
if (TREE_CODE (*node) != FUNCTION_DECL)
  {
-  warning (OPT_Wattributes, "%qE attribute only applies to functions",
-   name);
+  if (FUNCTION_POINTER_TYPE_P (TREE_TYPE (*node)))
+   {
+ warning (OPT_Wstrict_function_attributes,
+  "%qE attribute only applies to function definitions", name);
+   }
+  else
+   {
+ warning (OPT_Wattributes,
+  "%qE attribute only applies to functions", name);
+   }
*no_add_attrs = true;
  }
  
diff --git a/gcc/testsuite/c-c++-common/pr86407-1.c b/gcc/testsuite/c-c++-common/pr86407-1.c

new file mode 100644
index 000..37993d8c051
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/pr86407-1.c
@@ -0,0 +1,23 @@
+/* PR c/86407 */
+/* Test a function attribute that is not a calling convention and does not
+   affect the function type. There should be no warnings when using the
+   attribute on a function declaration, function pointer, or function pointer
+   typedef, but there should be a warning when using the attribute on
+   non-function-pointer variables and typedefs. */
+
+/* { dg-options "-Wstrict-function-attributes -Wno-ignored-attributes" } */
+
+int __attribute__((__ms_hook_prologue__)) func(); /* no warnings */
+
+int (__attribute__((__ms_hook_prologue__)) *func_ptr)(); /* { dg-warning 
"'ms_hook_prologue' attribute only applies to function definitions" } */
+

Re: [PATCH] improve ifcvt optimization (PR rtl-optimization/89430)

[Kyrill Tkachov]

Hi Jiangning

On 3/15/19 4:46 AM, JiangNing OS wrote:
This patch is to fix a missing ifcvt opportunity in back-end. For the 
simple case below,


if (...)
    x = a;  /* x is memory */
/* no else */

We can generate conditional move and remove the branch as below if the 
target cost is acceptable.


r1 = x
r2 = a
cmp ...
csel r3, r1, r2, cond
x = r3

This could be safe if x is a stack variable, and there isn't any 
address taken in current function, so the store speculation can be 
avoided.


In practice, this optimization can improve a real application 
performance by %4 on aarch64.




Now that GCC 10 development is open, this should appropriate for 
considering.


I've cc'ed folks who are either listed maintainers in this area or have 
reviewed patches in this area in my recent memory.


Thanks,

Kyrill



Thanks,
-Jiangning

Re: [PATCH] A jump threading opportunity for condition branch

[Jiufu Guo]

Richard Biener  writes:

> On Thu, 23 May 2019, Jiufu Guo wrote:
>
>> Richard Biener  writes:
>> 
>> > On Thu, 23 May 2019, Jiufu Guo wrote:
>> >
>> >> Hi,
>> >> 
>> >> Richard Biener  writes:
>> >> 
>> >> > On Tue, 21 May 2019, Jiufu Guo wrote:
>> >> >
>> >> >> Hi,
>> >> >> 
>> >> >> This patch implements a new opportunity of jump threading for PR77820.
>> >> >> In this optimization, conditional jumps are merged with unconditional 
>> >> >> jump.
>> >> >> And then moving CMP result to GPR is eliminated.
>> >> >> 
>> >> >> It looks like below:
>> >> >> 
>> >> >>   
>> >> >>   p0 = a CMP b
>> >> >>   goto ;
>> >> >> 
>> >> >>   
>> >> >>   p1 = c CMP d
>> >> >>   goto ;
>> >> >> 
>> >> >>   
>> >> >>   # phi = PHI 
>> >> >>   if (phi != 0) goto ; else goto ;
>> >> >> 
>> >> >> Could be transformed to:
>> >> >> 
>> >> >>   
>> >> >>   p0 = a CMP b
>> >> >>   if (p0 != 0) goto ; else goto ;
>> >> >> 
>> >> >>   
>> >> >>   p1 = c CMP d
>> >> >>   if (p1 != 0) goto ; else goto ;
>> >> >> 
>> >> >> 
>> >> >> This optimization eliminates:
>> >> >> 1. saving CMP result: p0 = a CMP b.
>> >> >> 2. additional CMP on branch: if (phi != 0).
>> >> >> 3. converting CMP result if there is phi = (INT_CONV) p0 if there is.
>> >> >> 
>> >> >> Bootstrapped and tested on powerpc64le with no regressions(one case is 
>> >> >> improved)
>> >> >> and new testcases are added. Is this ok for trunk?
>> >> >> 
>> >> >> Thanks!
>> >> >> Jiufu Guo
>> >> >> 
>> >> ...
>> >> >> diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
>> >> >> index c3ea2d6..23000f6 100644
>> >> >> --- a/gcc/tree-ssa-threadedge.c
>> >> >> +++ b/gcc/tree-ssa-threadedge.c
>> >> >> @@ -1157,6 +1157,90 @@ thread_through_normal_block (edge e,
>> >> >>return 0;
>> >> >>  }
>> >> >>  
>> >> >> +/* Return true if PHI's INDEX-th incoming value is a CMP, and the CMP 
>> >> >> is
>> >> >> +   defined in the incoming basic block. Otherwise return false.  */
>> >> >> +static bool
>> >> >> +cmp_from_unconditional_block (gphi *phi, int index)
>> >> >> +{
>> >> >> +  tree value = gimple_phi_arg_def (phi, index);
>> >> >> +  if (!(TREE_CODE (value) == SSA_NAME && has_single_use (value)))
>> >> >> +return false;
>> >> >
>> >> > Not sure why we should reject a constant here but I guess we
>> >> > expect it to find a simplified condition anyways ;)
>> >> >
>> >> Const could be accepted here, like "# t_9 = PHI <5(3), t_17(4)>". I
>> >> found this case is already handled by other jump-threading code, like
>> >> 'ethread' pass.
>> >> 
>> >> >> +
>> >> >> +  gimple *def = SSA_NAME_DEF_STMT (value);
>> >> >> +
>> >> >> +  if (!is_gimple_assign (def))
>> >> >> +return false;
>> >> >> +
>> >> >> +  if (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def)))
>> >> >> +{
>> >> >> +  value = gimple_assign_rhs1 (def);
>> >> >> +  if (!(TREE_CODE (value) == SSA_NAME && has_single_use (value)))
>> >> >> +  return false;
>> >> >> +
>> >> >> +  def = SSA_NAME_DEF_STMT (value);
>> >> >> +
>> >> >> +  if (!is_gimple_assign (def))
>> >> >> +  return false;
>> >> >
>> >> > too much vertial space.
>> >> >
>> >> Thanks, I will refine it. 
>> >> >> +}
>> >> >> +
>> >> >> +  if (TREE_CODE_CLASS (gimple_assign_rhs_code (def)) != 
>> >> >> tcc_comparison)
>> >> >> +return false;
>> >> >> +
>> >> >> +  /* Check if phi's incoming value is defined in the incoming 
>> >> >> basic_block.  */
>> >> >> +  edge e = gimple_phi_arg_edge (phi, index);
>> >> >> +  if (def->bb != e->src)
>> >> >> +return false;
>> >> >
>> >> > why does this matter?
>> >> >
>> >> Through preparing pathes and duplicating block, this transform can also
>> >> help to combine a cmp in previous block and a gcond in current block.
>> >> "if (def->bb != e->src)" make sure the cmp is define in the incoming
>> >> block of the current; and then combining "cmp with gcond" is safe.  If
>> >> the cmp is defined far from the incoming block, it would be hard to
>> >> achieve the combining, and the transform may not needed.
>> >
>> > We're in SSA form so the "combining" doesn't really care where the
>> > definition comes from.
>> >
>> >> >> +
>> >> >> +  if (!single_succ_p (def->bb))
>> >> >> +return false;
>> >> >
>> >> > Or this?  The actual threading will ensure this will hold true.
>> >> >
>> >> Yes, other thread code check this and ensure it to be true, like
>> >> function thread_through_normal_block. Since this new function is invoked
>> >> outside thread_through_normal_block, so, checking single_succ_p is also
>> >> needed for this case.
>> >
>> > I mean threading will isolate the path making this trivially true.
>> > It's also no requirement for combining, in fact due to the single-use
>> > check the definition can be sinked across the edge already (if
>> > the edges dest didn't have multiple predecessors which this threading
>> > will fix as well).
>> >
>> I would relax these check and have a test.
>> 
>> And I refactor the code a little as below. Thanks for any comments!
>> 

Re: [PATCH] Commonize anon-name generation

[Jason Merrill]

On Fri, May 24, 2019 at 10:34 AM Nathan Sidwell  wrote:
>
> Currently gcc/tree.c exports an anonymous name format string, and a
> predicate to detect identifiers of that form.  The C++ and D FEs use
> those functions to create and check anonymous names.
>
> That seems a little duplicative.  This patch changes tree.c to export an
> anonymous name generator, and uses a spare bit in IDENTIFIERs to mark
> them as anonymous, so no more strcmp to distinguish them.  Then replaces
> the bespoke handling in the two front ends to use the new interface.
>
> While my original goal was to make there be only one anon-identifier in
> the C++ FE (because modules kind of would prefer not to have names
> depend on source ordering), I didn't get to that goal, I think we still
> sometimes place them in symbol tables.  But this still seems a good thing.
>
> Are the common and D pieces ok?
>
> Jason, lambda class names are similarly anonymous, and I have a patch
> for them too.  Would you prefer they just be from the same set of
> identifiers, with another C++-specific flag bit, or have a somewhat more
> distinct name, as they do now? (I.e. do you want to be able to
> distinguish lambdas when debugging just by looking at the string?)

I don't have a strong opinion.  It can be useful to recognize them
that way, but I don't imagine I'd miss it too much.

Jason

Re: [C++ PATCH] PR c++/86485 - -Wmaybe-unused with empty class ?:

[Jason Merrill]

On Fri, May 24, 2019 at 10:13 AM Jakub Jelinek  wrote:
> On Wed, May 22, 2019 at 05:59:56PM -0400, Jason Merrill wrote:
> > On Tue, May 7, 2019 at 4:43 PM Jason Merrill  wrote:
> > >
> > > * typeck.c (build_static_cast_1): Use cp_build_addr_expr.
> > >
> > > For GCC 9 I fixed this bug with a patch to gimplify_cond_expr, but this
> > > function was also doing the wrong thing.
> > >
> > > Using build_address does not push the ADDR_EXPR down into the arms of a
> > > COND_EXPR, which we need for proper handling of conversion of an lvalue ?:
> > > to another reference type.
> >
> > And that allows the gimplifier to assert that we should never see a
> > COND_EXPR of addressable type.
> >
> > Tested x86_64-pc-linux-gnu, applying to trunk.
>
> > commit c4f1e37204aaea7efb2aa7dc234d5c8ebeba1089
> > Author: Jason Merrill 
> > Date:   Mon Mar 4 14:09:57 2019 -0500
> >
> > * gimplify.c (gimplify_cond_expr): Don't check TREE_ADDRESSABLE.
> >
> > The front end shouldn't produce a GENERIC COND_EXPR of TREE_ADDRESSABLE
> > type.
>
> I think this broke a lot in the D testsuite:

Thanks, reverted.

Jason

[PATCH] Commonize anon-name generation

[Nathan Sidwell]

Currently gcc/tree.c exports an anonymous name format string, and a 
predicate to detect identifiers of that form.  The C++ and D FEs use 
those functions to create and check anonymous names.


That seems a little duplicative.  This patch changes tree.c to export an 
anonymous name generator, and uses a spare bit in IDENTIFIERs to mark 
them as anonymous, so no more strcmp to distinguish them.  Then replaces 
the bespoke handling in the two front ends to use the new interface.


While my original goal was to make there be only one anon-identifier in 
the C++ FE (because modules kind of would prefer not to have names 
depend on source ordering), I didn't get to that goal, I think we still 
sometimes place them in symbol tables.  But this still seems a good thing.


Are the common and D pieces ok?

Jason, lambda class names are similarly anonymous, and I have a patch 
for them too.  Would you prefer they just be from the same set of 
identifiers, with another C++-specific flag bit, or have a somewhat more 
distinct name, as they do now? (I.e. do you want to be able to 
distinguish lambdas when debugging just by looking at the string?)


nathan
--
Nathan Sidwell
2019-05-24  Nathan Sidwell  

	gcc/
	* tree.h (IDENTIFIER_ANON_P): New.
	(anon_aggrname_format, anon_aggname_p): Don't declare.
	(make_anon_name): Declare.
	* lto-streamer-out.c (DFS::DFS_write_tree_body): Use IDENTIFIER_ANON_P.
	(hash_tree): Likewise.
	* tree-streamer-out.c (write_ts_decl_minimal_tree): Likewise.
	* tree.c (anon_aggrname_p, anon_aggrname_format): Delete.
	(anon_cnt, make_anon_name): New.

 	gcc/cp/
	* cp-tree.h (make_anon_name): Drop declaration.
	(TYPE_UNNAMED_P): Use IDENTIFIER_ANON_P.
	* cp-lang.c (cxx_dwarf_name): Likewise.
	* class.c (find_flexarrays): Likewise.
	* decl.c (name_unnamed_type, xref_tag_1): Likewise.
	* error.c (dump_aggr_type): Likewise.
	* pt.c (push_template_decl_real): Likewise.
	* name-lookup.c (consider_binding_level): Likewise.
	(anon_cnt, make_anon_name): Delete.

	gcc/d/
	* types.cc (fixup_anonymous_offset): Use IDENTIFIER_ANON_P.
	(layout_aggregate_members): Use make_anon_name.

Index: gcc/cp/class.c
===
--- gcc/cp/class.c	(revision 271599)
+++ gcc/cp/class.c	(working copy)
@@ -6586,5 +6586,5 @@ find_flexarrays (tree t, flexmems_t *fme
 	  && DECL_IMPLICIT_TYPEDEF_P (fld)
 	  && CLASS_TYPE_P (TREE_TYPE (fld))
-	  && anon_aggrname_p (DECL_NAME (fld)))
+	  && IDENTIFIER_ANON_P (DECL_NAME (fld)))
 	{
 	  /* Check the nested unnamed type referenced via a typedef
Index: gcc/cp/cp-lang.c
===
--- gcc/cp/cp-lang.c	(revision 271599)
+++ gcc/cp/cp-lang.c	(working copy)
@@ -111,5 +111,5 @@ cxx_dwarf_name (tree t, int verbosity)
 
   if (DECL_NAME (t)
-  && (anon_aggrname_p (DECL_NAME (t)) || LAMBDA_TYPE_P (t)))
+  && (IDENTIFIER_ANON_P (DECL_NAME (t)) || LAMBDA_TYPE_P (t)))
 return NULL;
   if (verbosity >= 2)
Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h	(revision 271599)
+++ gcc/cp/cp-tree.h	(working copy)
@@ -1938,5 +1938,5 @@ enum languages { lang_c, lang_cplusplus
 /* Nonzero if NODE has no name for linkage purposes.  */
 #define TYPE_UNNAMED_P(NODE) \
-  (OVERLOAD_TYPE_P (NODE) && anon_aggrname_p (TYPE_LINKAGE_IDENTIFIER (NODE)))
+  (OVERLOAD_TYPE_P (NODE) && IDENTIFIER_ANON_P (TYPE_LINKAGE_IDENTIFIER (NODE)))
 
 /* The _DECL for this _TYPE.  */
@@ -6351,5 +6351,4 @@ extern tree strip_fnptr_conv			(tree);
 /* in name-lookup.c */
 extern void maybe_push_cleanup_level		(tree);
-extern tree make_anon_name			(void);
 extern tree maybe_push_decl			(tree);
 extern tree current_decl_namespace		(void);
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c	(revision 271599)
+++ gcc/cp/decl.c	(working copy)
@@ -10234,13 +10234,10 @@ name_unnamed_type (tree type, tree decl)
   /* Replace the anonymous name with the real name everywhere.  */
   for (tree t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
-{
-  if (anon_aggrname_p (TYPE_IDENTIFIER (t)))
-	/* We do not rename the debug info representing the
-	   unnamed tagged type because the standard says in
-	   [dcl.typedef] that the naming applies only for
-	   linkage purposes.  */
-	/*debug_hooks->set_name (t, decl);*/
-	TYPE_NAME (t) = decl;
-}
+if (IDENTIFIER_ANON_P (TYPE_IDENTIFIER (t)))
+  /* We do not rename the debug info representing the unnamed
+	 tagged type because the standard says in [dcl.typedef] that
+	 the naming applies only for linkage purposes.  */
+  /*debug_hooks->set_name (t, decl);*/
+  TYPE_NAME (t) = decl;
 
   if (TYPE_LANG_SPECIFIC (type))
@@ -14062,5 +14059,5 @@ xref_tag_1 (enum tag_types tag_code, tre
  make type node and push name.  Name lookup is not required.  */
   tree t = NULL_TREE;
-  if (scope != ts_lambda && !anon_aggrname_p (name))
+ 

Re: [PATCH] aarch64: emit .variant_pcs for aarch64_vector_pcs symbol references

[Richard Sandiford]

Szabolcs Nagy  writes:
> A dynamic linker with lazy binding support may need to handle variant
> PCS function symbols specially, so an ELF symbol table marking was
> introduced for such symbols.
>
> Global symbol references and definitions that follow the vector PCS are
> marked in the generated assembly and then the STO_AARCH64_VARIANT_PCS
> st_other flag is set on the symbol in the object file.
>
> For this to work, the assembler, the static linker and the dynamic
> linker has to be updated on a system.  Old assembler does not support
> the new .variant_pcs directive, so a toolchain with old binutils won't
> be able to compile code that references vector PCS symbols.
>
> For details about the ELF ABI and rationale see
> https://gcc.gnu.org/ml/gcc/2019-05/msg00185.html
>
> gcc/ChangeLog:
>
> 2019-05-22  Szabolcs Nagy  
>
>   * config/aarch64/aarch64-protos.h (aarch64_asm_output_alias): Declare.
>   (aarch64_asm_output_external): Declare.
>   * config/aarch64/aarch64.c (aarch64_asm_output_variant_pcs): New.
>   (aarch64_declare_function_name): Call aarch64_asm_output_variant_pcs.
>   (aarch64_asm_output_alias): New.
>   (aarch64_asm_output_external): New.
>   * config/aarch64/aarch64.h (ASM_OUTPUT_DEF_FROM_DECLS): Define.
>   (ASM_OUTPUT_EXTERNAL): Define.
>
> gcc/testsuite/ChangeLog:
>
> 2019-05-22  Szabolcs Nagy  
>
>   * gcc.target/aarch64/pcs_attribute-2.c: New test.
>   * gcc.target/aarch64/pcs_attribute.c: Require .variant_pcs support.
>   * gcc.target/aarch64/torture/simd-abi-1.c: Likewise.
>   * gcc.target/aarch64/torture/simd-abi-3.c: Likewise.
>   * gcc.target/aarch64/torture/simd-abi-4.c: Likewise.
>   * gcc.target/aarch64/torture/simd-abi-5.c: Likewise.
>   * gcc.target/aarch64/torture/simd-abi-6.c: Likewise.
>   * gcc.target/aarch64/torture/simd-abi-7.c: Likewise.
>   * lib/target-supports.exp (check_effective_target_aarch64_variant_pcs):
>   New.
>
> diff --git a/gcc/config/aarch64/aarch64-protos.h 
> b/gcc/config/aarch64/aarch64-protos.h
> index b6c0d0a8eb6..68f0b542202 100644
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++ b/gcc/config/aarch64/aarch64-protos.h
> @@ -427,6 +427,8 @@ bool aarch64_is_long_call_p (rtx);
>  bool aarch64_is_noplt_call_p (rtx);
>  bool aarch64_label_mentioned_p (rtx);
>  void aarch64_declare_function_name (FILE *, const char*, tree);
> +void aarch64_asm_output_alias (FILE *, const tree, const tree);
> +void aarch64_asm_output_external (FILE *, const tree, const char*);
>  bool aarch64_legitimate_pic_operand_p (rtx);
>  bool aarch64_mask_and_shift_for_ubfiz_p (scalar_int_mode, rtx, rtx);
>  bool aarch64_masks_and_shift_for_bfi_p (scalar_int_mode, unsigned 
> HOST_WIDE_INT,
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 83453d03095..189d958d817 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -15276,6 +15276,22 @@ aarch64_asm_preferred_eh_data_format (int code 
> ATTRIBUTE_UNUSED, int global)
> return (global ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | type;
>  }
>  
> +/* Output .variant_pcs for aarch64_vector_pcs function symbols.  */
> +
> +static void
> +aarch64_asm_output_variant_pcs (FILE *stream, const tree decl, const char* 
> name)
> +{
> +  if (TREE_CODE (decl) == FUNCTION_DECL
> +  && TREE_PUBLIC (decl)
> +  && lookup_attribute ("aarch64_vector_pcs",
> +TYPE_ATTRIBUTES (TREE_TYPE (decl
> +{
> +  fprintf (stream, "\t.variant_pcs\t");
> +  assemble_name (stream, name);
> +  fprintf (stream, "\n");
> +}
> +}

What do you think about leaving out the TREE_PUBLIC check?  The ABI
doesn't require !TREE_PUBLIC functions to be marked, but it might be
safer to do the same thing for all VPCS functions anyway (especially
since, like you say below, we still mark some things that don't
necessarily need to be marked).

IMO it'd be better to use aarch64_simd_decl_p instead of the attribute test.

> +/* Implement ASM_OUTPUT_EXTERNAL.  Output .variant_pcs for undefined
> +   function symbols references.  */

"symbol references"

> diff --git a/gcc/testsuite/gcc.target/aarch64/pcs_attribute-2.c 
> b/gcc/testsuite/gcc.target/aarch64/pcs_attribute-2.c
> new file mode 100644
> index 000..c808bd45d0f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/pcs_attribute-2.c
> @@ -0,0 +1,101 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target aarch64_variant_pcs } */
> +
> +/* Test that .variant_pcs is emitted for vector PCS symbol references.  */
> +
> +#define ATTR __attribute__ ((aarch64_vector_pcs))
> +
> +void f_undef_basepcs (void);
> +
> +void f_def_basepcs (void)
> +{
> +}
> +
> +ATTR void f_undef_vpcs (void);
> +
> +ATTR void f_def_vpcs (void)
> +{
> +}
> +
> +__attribute__ ((alias ("f_def_vpcs")))
> +ATTR void f_alias_vpcs (void);
> +
> +__attribute__ ((weak, alias ("f_def_vpcs")))
> +ATTR void f_weak_alias_vpcs (void);
> +
> +__attribute__ 

Re: *ping* Re: [PATCH] PR fortran/89100 Default widths for i, f and g format specifiers in format strings

[Steve Kargl]

On Fri, May 24, 2019 at 12:33:51PM +0200, Jakub Jelinek wrote:
> On Fri, May 24, 2019 at 11:28:34AM +0100, Mark Eggleston wrote:
> > > FAIL: gfortran.dg/fmt_f_default_field_width_3.f90   -O   (test for
> > > errors, line 33)
> > > PASS: gfortran.dg/fmt_f_default_field_width_3.f90   -O  (test for excess 
> > > errors)
> > > 
> > > that is, it seems there's no error message generated for line 33.
> > > 
> > > Christophe
> > > 
> > 
> > There is no error for line 33 because it isn't included in the compilation
> > because __GFC_REAL_16__ isn't defined. DejaGnu doesn't know this and the
> > dg-warning directive for this line is still processed.
> > 
> > I don't know enough about DejaGnu directives to determine whether this
> > situation can be handled. Does anybody know how to deal with a line that if
> > compiled a warning message output and if not compiled there is no output?
> > 
> > Is the easiest solution to omit the test code where kind=16?
> 
> You can do (pseudo patch, untested):
>  #ifdef __GFC_REAL_16__
>   real_16 = 4.18
> - write(buffer, fmt) ':',real_16,':' ! { dg-error "Positive width 
> required" }
> + write(buffer, fmt) ':',real_16,':' ! { dg-error "Positive width 
> required" "" { target fortran_real_16 } }
>  #endif
> 
> Effective target fortran_real_16 should be true whenever:
> real(kind=16) :: x
> x = cos (x)
> end
> compiles and links into an executable without diagnostics.
> 

Christophe, can you test Jakub's proposed fix?  If it passes,
I'll update the other testcases.

-- 
Steve

Re: [C++ PATCH] PR c++/86485 - -Wmaybe-unused with empty class ?:

[Jakub Jelinek]

On Wed, May 22, 2019 at 05:59:56PM -0400, Jason Merrill wrote:
> On Tue, May 7, 2019 at 4:43 PM Jason Merrill  wrote:
> >
> > * typeck.c (build_static_cast_1): Use cp_build_addr_expr.
> >
> > For GCC 9 I fixed this bug with a patch to gimplify_cond_expr, but this
> > function was also doing the wrong thing.
> >
> > Using build_address does not push the ADDR_EXPR down into the arms of a
> > COND_EXPR, which we need for proper handling of conversion of an lvalue ?:
> > to another reference type.
> 
> And that allows the gimplifier to assert that we should never see a
> COND_EXPR of addressable type.
> 
> Tested x86_64-pc-linux-gnu, applying to trunk.

> commit c4f1e37204aaea7efb2aa7dc234d5c8ebeba1089
> Author: Jason Merrill 
> Date:   Mon Mar 4 14:09:57 2019 -0500
> 
> * gimplify.c (gimplify_cond_expr): Don't check TREE_ADDRESSABLE.
> 
> The front end shouldn't produce a GENERIC COND_EXPR of TREE_ADDRESSABLE
> type.

I think this broke a lot in the D testsuite:
+FAIL: gdc.test/runnable/link15017.d   (internal compiler error)
+UNRESOLVED: gdc.test/runnable/link15017.d   compilation failed to produce 
executable
+FAIL: gdc.test/runnable/sdtor.d -O2   (internal compiler error)
+UNRESOLVED: gdc.test/runnable/sdtor.d -O2   compilation failed to produce 
executable
+FAIL: gdc.test/runnable/testaa.d   (internal compiler error)
+UNRESOLVED: gdc.test/runnable/testaa.d   compilation failed to produce 
executable
+FAIL: libphobos.druntime/rt/lifetime.d (test for excess errors)
+UNRESOLVED: libphobos.druntime/rt/lifetime.d compilation failed to produce 
executable
+FAIL: libphobos.druntime_shared/rt/lifetime.d (test for excess errors)
+UNRESOLVED: libphobos.druntime_shared/rt/lifetime.d compilation failed to 
produce executable
+FAIL: libphobos.phobos/std/uni.d (test for excess errors)
+UNRESOLVED: libphobos.phobos/std/uni.d compilation failed to produce executable
+FAIL: libphobos.phobos_shared/std/uni.d (test for excess errors)
+UNRESOLVED: libphobos.phobos_shared/std/uni.d compilation failed to produce 
executable
(the list is reduced, so that for each failing tests there aren't many
lines).

Iain, is that something that can be fixed on the D FE side?

> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -3990,10 +3990,12 @@ gimplify_cond_expr (tree *expr_p, gimple_seq *pre_p, 
> fallback_t fallback)
>tree result;
>  
>/* If either an rvalue is ok or we do not require an lvalue, create the
> -  temporary.  But we cannot do that if the type is addressable.  */
> +  temporary.  We cannot do that if the type is addressable, but
> +  that should have been avoided before we got here.  */
>if (((fallback & fb_rvalue) || !(fallback & fb_lvalue))
> -   && !TREE_ADDRESSABLE (type))
> +   && (flag_checking || !TREE_ADDRESSABLE (type)))
>   {
> +   gcc_assert (!TREE_ADDRESSABLE (type));
> if (gimplify_ctxp->allow_rhs_cond_expr
> /* If either branch has side effects or could trap, it can't be
>evaluated unconditionally.  */

Jakub

Re: [PATCH] rs6000: Call flow implementation for PC-relative addressing

[Bill Schmidt]

New test case ICEs, so consider this withdrawn.  Sorry again about this.

Bill

On 5/23/19 9:17 PM, Bill Schmidt wrote:
> Hm, I got ahead of myself on this one.  I haven't done the regstrap yet,
> so please hold off reviewing for now.
>
> Sorry for the noise.  I shouldn't post when I'm tired...
>
> Thanks,
> Bill
>
> On 5/23/19 9:11 PM, Bill Schmidt wrote:
>> Hi,
>>
>> This patch contains the changes to implement call flow for PC-relative 
>> addressing.  
>> It's an amalgam of several internal patches that Alan and I worked on, and 
>> as a 
>> result it's hard to tease apart individual pieces much further.  So I 
>> apologize 
>> that this patch is a little larger than the others.  Also, I've CC'd Alan so 
>> he 
>> can help answer questions about the patch, particularly the PLT bits I'm not 
>> very
>> familiar with.
>>
>> Following are descriptions of the individual patches that are combined here.
>>
>> (1) When a function uses PC-relative code generation, all direct calls 
>> (other than 
>> sibcalls) that the function makes to local or external callees should appear 
>> as
>> "bl sym@notoc" and should not be followed by a nop instruction.  @notoc 
>> indicates
>> that the assembler should annotate the call with R_PPC64_REL24_NOTOC, meaning
>> that the caller does not guarantee that r2 contains a valid TOC pointer.  
>> Thus
>> the linker should not try to replace a subsequent "nop" with a TOC restore
>> instruction.
>>
>> I've added a test case for the four cases handled here:  local calls 
>> with/without
>> a return value, and external cases with/without a return value.
>>
>> (2) If a caller preserves the TOC pointer and the callee does not, or vice 
>> versa,
>> then a sibcall will cause an inconsistency.  Don't allow that.
>>
>> (3) The linker needs a @notoc directive on sibcall targets when the caller 
>> does not
>> provide or preserve a TOC pointer.  This patch provides for that.
>>
>> In creating the new sibcall patterns, I did not duplicate the "c" 
>> alternatives
>> that allow for bctr or blr sibcalls.  I don't think there's a way to generate
>> those currently.  The bctr would be legitimate for PC-relative sibcalls if 
>> you
>> can prove that the target function is in the same binary, but we don't appear
>> to detect that possibility today.
>>
>> (4) This patch deletes all the extra insns added to handle pcrel calls,
>> instead opting to use existing insns but making their output
>> conditional on rs6000_pcrel_p(cfun).  There isn't a need to
>> differentiate between pcrel and non-pcrel calls at the point rtl is
>> created; rs6000_pcrel_p is valid right up to the final pass, as
>> evidenced by use of rs6000_pcrel_p to emit .localentry.
>> 
>> There is one case however where we do need new insns: The existing
>> nonlocal indirect call insns mention r2 in their rtl.  That isn't
>> correct for pcrel indirect calls, and may cause problems when/if r2
>> is allocated as any other volatile gpr in pcrel code.
>> 
>> The patch also fixes pcrel inline PLT calls (which are used for
>> -fno-plt and -mlongcall) to use a pcrel load from the PLT rather than
>> attempting (and failing) to use TOC-relative loads.  This requires
>> some changes in the way relocs are emitted.  For prefix insns we can't
>> write
>>.reloc .,R_PPC64_PLT_PCREL34_NOTOC,foo
>>pld 12,0(0),1
>> since the pld may require a padding nop.  Instead it's necessary to
>> put the .reloc after the instruction or use a label on the insn.  Like
>> this (which is what the patch does):
>>pld 12,0(0),1
>>.reloc .-8,R_PPC64_PLT_PCREL34_NOTOC,foo
>> or this:
>>.reloc 0f,R_PPC64_PLT_PCREL34_NOTOC,foo
>> 0: pld 12,0(0),1
>>
>> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
>> Is this okay for trunk?
>>
>> Thanks!
>> Bill
>>
>>
>> [gcc]
>>
>> 2019-05-23  Bill Schmidt  
>>  Alan Modra  
>>
>>  * config/rs6000/rs6000.c (rs6000_call_template_1): Handle pcrel
>>  calls here...
>>  (rs6000_indirect_call_template_1): ...and here.
>>  (rs6000_indirect_sibcall_template): Handle plt_pcrel34.  Rework
>>  tocsave, plt16_ha, plt16_lo, mtctr indirect calls.
>>  (rs6000_decl_ok_for_sibcall): New function.
>>  (rs6000_function_ok_for_sibcall): Refactor.
>>  (rs6000_longcall_ref): Use UNSPEC_PLT_PCREL when pcrel.
>>  (rs6000_call_aix): Don't emit toc restore rtl for indirect calls
>>  when pcrel.  Reorganize.
>>  (rs6000_sibcall_aix): Don't add r2 to function usage when pcrel.
>>  * rs6000.md (UNSPEC_PLT_PCREL): New unspec.
>>  (*pltseq_plt_pcrel): New insn.
>>  (*call_local_aix): Handle @notoc calls.
>>  (*call_value_local_aix): Likewise.
>>  (*call_nonlocal_aix): Adjust lengths for pcrel calls.
>>  (*call_value_nonlocal_aix): Likewise.
>>  (*call_indirect_pcrel): New insn.
>>  (*call_value_indirect_pcrel): Likewise.
>>
>>
>> 

Re: Teach same_types_for_tbaa to structurally compare arrays, pointers and vectors

[Jan Hubicka]

> I don't think it works like this, peeling arrays/vectors from
> types individually instead of in lock-step?
> 
> I think for better testing coverage you want to force
> TYPE_STRUCTURAL_EQUALITY on all types here - this shouldn't
> make things invalid but otherwise these code-paths are not
> tested very well.

Here is coverage of the function compiling tramp3d with -flto.
All the paths through are relatively frequent.
Most of time we call function for case where type1 and type2 have same
main variants.  Out of 1.5m remaining cases approx 30k are
pointers/arrays and go the structural walk which in 17k cases goes to
mismatched pointer types.

2k cases are considered equivalent because of canonical check and
126k cases we disprove equivalence.

-:  780:/* Return 1 if TYPE1 and TYPE2 are to be considered equivalent 
for the
-:  781:   purpose of TBAA.  Return 0 if they are distinct and -1 if we 
cannot
-:  782:   decide.  */
-:  783:
-:  784:static inline int
   669818:  785:same_type_for_tbaa (tree type1, tree type2)
-:  786:{
   669818:  787:  type1 = TYPE_MAIN_VARIANT (type1);
   669818:  788:  type2 = TYPE_MAIN_VARIANT (type2);
-:  789:
-:  790:  /* If same_type_for_tbaa returns true we make an assumption 
that pointers to
-:  791: TYPE1 and TYPE2 can either point to same copy of the type 
or completely
-:  792: different.
-:  793:
-:  794: This is not necessarily true for arrays where overlap can 
be partial
-:  795: as in gcc.dg/torture/alias-2.c.  So we can only prove that 
arrays are
-:  796: disjoint becuase they are derived from different types but 
we can not
-:  797: prove they are same.
-:  798:
-:  799: On the other hand for pointers we can always consider them 
to be same
-:  800: unless we can prove that pointed-to types are different.
-:  801:
-:  802: So normally return values are
-:  803:   0  if types are known to be different
-:  804:   1  if types are same and there is no partial overlap
-:  805:   -1 otherwise.
-:  806:
-:  807: However if comparing two pointers return values are
-:  808:   0  if pointed to types are known to be different
-:  809:   1  otherwise (because partial overlaps do not happen).
-:  810:
-:  811: If comparing array or vector to other type return values 
are
-:  812:   0  if types array/vector are derived from are known to 
be different
-:  813:   -1 otherwise (to watch for partial overlaps).  */
-:  814:
   669818:  815:  bool in_ptr = false;
   669818:  816:  bool in_array = false;
-:  817:
   669818:  818:  if (type1 == type2)
   515089:  819:return 1;
-:  820:
-:  821:  /* Do structural comparsion for types that have no canonical 
types in LTO.  */
   162119:  822:  while (TYPE_STRUCTURAL_EQUALITY_P (type1)
   162119:  823: || TYPE_STRUCTURAL_EQUALITY_P (type2))
-:  824:{
-:  825:  /* Pointer types are same if they point to same types.  */
30761:  826:  if (POINTER_TYPE_P (type1) && POINTER_TYPE_P (type2))
-:  827:{
 4662:  828:  type1 = TYPE_MAIN_VARIANT (TREE_TYPE (type1));
 4662:  829:  type2 = TYPE_MAIN_VARIANT (TREE_TYPE (type2));
 4662:  830:  if (!in_array)
 4662:  831:in_ptr = true;
-:  832:}
-:  833:  /* Peel out arrays and vector to compare inner types.  */
52198:  834:  else if ((TREE_CODE (type1) == ARRAY_TYPE
23728:  835:|| TREE_CODE (type1) == VECTOR_TYPE)
49827:  836:   && TYPE_STRUCTURAL_EQUALITY_P (type1))
-:  837:{
 2371:  838:  type1 = TYPE_MAIN_VARIANT (TREE_TYPE (type1));
 2371:  839:  if (!in_ptr)
 2371:  840:in_array = true;
-:  841:}
47456:  842:  else if ((TREE_CODE (type2) == ARRAY_TYPE
21042:  843:|| TREE_CODE (type2) == VECTOR_TYPE)
44770:  844:   && TYPE_STRUCTURAL_EQUALITY_P (type2))
-:  845:{
 2686:  846:  type2 = TYPE_MAIN_VARIANT (TREE_TYPE (type2));
 2686:  847:  if (!in_ptr)
 2686:  848:in_array = true;
-:  849:}
-:  850:  else
-:  851:{
21042:  852:  if (POINTER_TYPE_P (type1) != POINTER_TYPE_P (type2))
17208:  853:return 0;
3834*:  854:  return in_ptr ? 1 : -1;
-:  855:}
-:  856:
 9719:  857:  if (type1 == type2)
 2329:  858:return in_array ? -1 : 1;
-:  859:}
-:  860:
-:  861:  /* Compare the canonical types.  */
   131358:  862:  if (TYPE_CANONICAL (type1) == 

Re: [Patch] [aarch64] Change two function declaration types

[Richard Sandiford]

Matthew Malcomson  writes:
> Commit r271514 missed changing the type of two functions in
> aarch64-protos.h.  The function definitions had been updated to use
> uint64_t while the function declarations had been missed.
> They were missed since I only tested the patch on aarch64 where
> `unsigned long` is the same as `uint64_t`.
>
> This patch updates these declarations in aarch64-protos.h.
>
> Tested by building an aarch64 cross-compiler on arm-none-linux-gnu (so
> that `unsigned long` and `uint64_t` are different and would give error
> messages), and bootstrapping on aarch64-none-linux-gnu.
> Also manually tested command line options to see that
> -march=armv8-a+typo prints out the expected flags while using the new
> feature flags does not complain about missing flags.
>
> gcc/ChangeLog:
>
> 2019-05-24  Matthew Malcomson  
>
>   PR target/90588
>   * common/config/aarch64/aarch64-common.c
>   (aarch64_rewrite_selected_cpu): Change local temporary variable
>   type from unsigned long to uint64_t.
>   * config/aarch64/aarch64-protos.h (aarch64_parse_extension,
>   aarch64_get_extension_string_for_isa_flags): Change declaration to
>   match new definition by replacing unsigned long with uint64_t.

OK, thanks.

Richard

FWIW, this would also have been OK under the "obviously correct" rule.

Re: [PATCH,RFC 0/3] Support for CTF in GCC

[Jakub Jelinek]

On Fri, May 24, 2019 at 03:24:34PM +0200, Jakub Jelinek wrote:
> On Tue, May 21, 2019 at 03:44:47PM -0700, Indu Bhagat wrote:
> > Yes and No :) And that is indeed one of the motivation of the project - to
> > allow CTF generation where it's most suited aka the toolchain.
> > 
> > There do exist utilties for generation of CTF from DWARF. For example, one 
> > of
> > them is the dwarf2ctf in the DTrace Linux distribution. dwarf2ctf works 
> > offline
> > to transform DWARF generated by the compiler into CTF.
> 
> So, if there is a conversion utility, why don't we just change gcc so that
> if some new option is passed on the gcc driver link line, then that
> post-processing utility will be invoked too?

It could be even written as a linker plugin.

Jakub

Re: [PATCH,RFC 0/3] Support for CTF in GCC

[Jakub Jelinek]

On Tue, May 21, 2019 at 03:44:47PM -0700, Indu Bhagat wrote:
> Yes and No :) And that is indeed one of the motivation of the project - to
> allow CTF generation where it's most suited aka the toolchain.
> 
> There do exist utilties for generation of CTF from DWARF. For example, one of
> them is the dwarf2ctf in the DTrace Linux distribution. dwarf2ctf works 
> offline
> to transform DWARF generated by the compiler into CTF.

So, if there is a conversion utility, why don't we just change gcc so that
if some new option is passed on the gcc driver link line, then that
post-processing utility will be invoked too?

> A dependency of an external conversion utility for "post-processing" DWARF
> offline poses several problems:
> 
> 1. Deployment problems: the converter should be distributed and integrated in
>the build system of the program.  This, on occasions, can be intrusive.  
> For
>example, in terms of dependencies: the dwarf2ctf converter depends on
>libdwarf from elfutils suite, glib2 (used for the GHashTable), zlib (used 
> to
>compress the CTF information) and libctf (which both reads and writes the
>CTF data).

I don't see this as a problem.

> 2. Performance problems: the conversion from DWARF to CTF can take a long 
> time,
>especially in big programs such as the Linux kernel.

So optimize it?  Linux kernel certainly doesn't have extra large debug
information, compared to other projects.

> 3. Maintainability problems: the converter should be maintained in order to
>reflect potential changes in the DWARF generated by the compiler.

If you integrate the support into GCC, then it will need to be maintained
there as well, I bet it will be more work than on the conversion utility.

Jakub

Re: Teach same_types_for_tbaa to structurally compare arrays, pointers and vectors

[Jan Hubicka]

> > so about 5 times increase of alias_components_refs_p disambiguations.
> 
> Note the number of queries also changes so it's "somewhat" comparing
> apples and oranges (possibly the alias walk doesn't have to give up
> and thus we walk more and do more queries).

Yep, I know. If you disambiguate you may increase number of queries
overall because oracles walks further or decrease because tings get
optimized out.

It is however relatively useful to check if patch is doing something :)

> > +  /* If same_type_for_tbaa returns true we make an assumption that 
> > pointers to
> > + TYPE1 and TYPE2 can either point to same copy of the type or 
> > completely
> > + different.
> > +
> > + This is not necessarily true for arrays where overlap can be partial
> > + as in gcc.dg/torture/alias-2.c.  So we can only prove that arrays are
> > + disjoint becuase they are derived from different types but we can not
> > + prove they are same.
> > +
> > + On the other hand for pointers we can always consider them to be same
> > + unless we can prove that pointed-to types are different.
> 
> What about different address-spaces and/or pointer sizes?
> 
> > + So normally return values are
> > +   0  if types are known to be different
> > +   1  if types are same and there is no partial overlap
> > +   -1 otherwise.
> > +
> > + However if comparing two pointers return values are
> > +   0  if pointed to types are known to be different
> > +   1  otherwise (because partial overlaps do not happen).
> 
> Doesn't this apply to all non-composite types?  (the "partial overlaps
> do not happen"?)

I think we should have TYPE_CANONICAL defined on those so the comparsion
should follow the usual way.
> 
> > + If comparing array or vector to other type return values are
> > +   0  if types array/vector are derived from are known to be different
> > +   -1 otherwise (to watch for partial overlaps).  */
> > +
> > +  bool in_ptr = false;
> > +  bool in_array = false;
> > +
> > +  if (type1 == type2)
> > +return 1;
> > +
> > +  /* Do structural comparsion for types that have no canonical types in 
> > LTO.  */
> > +  while (TYPE_STRUCTURAL_EQUALITY_P (type1)
> > +|| TYPE_STRUCTURAL_EQUALITY_P (type2))
> > +{
> > +  /* Pointer types are same if they point to same types.  */
> > +  if (POINTER_TYPE_P (type1) && POINTER_TYPE_P (type2))
> > +   {
> > + type1 = TYPE_MAIN_VARIANT (TREE_TYPE (type1));
> > + type2 = TYPE_MAIN_VARIANT (TREE_TYPE (type2));
> > + if (!in_array)
> > +   in_ptr = true;
> 
> Don't you run into unrelated types when visiting pointed-to types
> here?  Why would we care for the pointed-to type anwyways?

What do you mean by unrelated type here?
> 
> That is, the loop should just handle composite types
> and after it compare non-composite types with
> types_compatible_p for example?  Maybe even do that change
> independently.

It would probably give more 1s and less 0s which would, in turn, make
aliasing_component_refs to apply range check (which will return 1)
instead of concluding that access paths are disjoint.

Why do you think this is better than looking up the pointed-to type
and comparing that one?
> 
> > +   }
> > +  /* Peel out arrays and vector to compare inner types.  */
> > +  else if ((TREE_CODE (type1) == ARRAY_TYPE
> > +   || TREE_CODE (type1) == VECTOR_TYPE)
> > +  && TYPE_STRUCTURAL_EQUALITY_P (type1))
> > +   {
> > + type1 = TYPE_MAIN_VARIANT (TREE_TYPE (type1));
> > + if (!in_ptr)
> > +   in_array = true;
> > +   }
> > +  else if ((TREE_CODE (type2) == ARRAY_TYPE
> > +   || TREE_CODE (type2) == VECTOR_TYPE)
> > +  && TYPE_STRUCTURAL_EQUALITY_P (type2))
> > +   {
> > + type2 = TYPE_MAIN_VARIANT (TREE_TYPE (type2));
> > + if (!in_ptr)
> > +   in_array = true;
> > +   }
> 
> I don't think it works like this, peeling arrays/vectors from
> types individually instead of in lock-step?

The intention here is behave similarly to get_alias_set and handle
declare arrays/vectors to be the same as the type they are derived from
+ dissabling the assumption about non-existence of partial overlaps.
> 
> I think for better testing coverage you want to force
> TYPE_STRUCTURAL_EQUALITY on all types here - this shouldn't
> make things invalid but otherwise these code-paths are not
> tested very well.

I played around with this on non-LTO builds bypasing the
TYPE_STRUCTURAL_EQUALITY check. For pointers it agreed with
the TYPE_CANONICAL check, for arrays I run into problems that
same_types_for_tbaa returns 1 because it first check TYPE_CANONICAL for
equality and ARRAY_TYPEs later. There is some code later to special case
this but not very systematic. Such as:

  /* But avoid treating arrays as "objects", instead assume they
 can overlap by an exact multiple of their element size.  */
 && TREE_CODE (TREE_TYPE 

Re: [PATCH,RFC 0/3] Support for CTF in GCC

[Michael Matz]

Hello,

On Thu, 23 May 2019, Indu Bhagat wrote:

> > OK.  So I wonder how difficult it is to emit CTF by walking dwarf2outs own
> > data structures?  That is, in my view CTF should be emitted by
> > dwarf2out_early_finish ()  (which is also the point LTO type/decl debug
> > is generated from).  It would be nice to avoid extra bookkeeping data
> > structures
> > for CTF since those of DWARF should include all necessary information
> > already.
> 
> CTF format has some characteristics which make it necessary to "pre-process"
> the generated CTF data before asm'ing out into a section. E.g. few cases of
> why "pre-processing" CTF is required before asm'ing out :
>  1. CTF types do need to be emitted in "some" order :
> CTF types can have references to other CTF types. This consequently
> implies
> that the referenced type must appear BEFORE the referring type.
>  2. CTF preamble holds offsets to the various subsections - function info,
> variables, data types and CTF string table. To calculate the offsets, the
> compiler needs to know the size in bytes of these sub-sections.  CTF
> representation for some types like structures, functions, enums have
> variable length of bytes trailing them (depending on the defintion of the
> type).
>  3. CTF variable entries need to be placed in the order of the names.
> 
> Because of some of these "features" of the CTF format, the compiler does 
> need to do a transition from runtime CTF generated data --> CTF binary 
> data format for a clean and readable code.

Sure, but this whole process could still be triggered from within 
dwarf2out_early_finish, by walking the DWARF tree (instead of getting fed 
types and decls via hooks) and generating the appropriate CTF data 
structures.  (It's just a possibility, it might end up uglier that using 
GCC trees)

Imagine a world where debug hooks wouldn't exist (which is where we would 
like to end up in a far away future), how would you then add CTF debug 
info to the compiler (assuming it already emits DWARF)?  You would hook 
yourself either into the DWARF routines that currently are fed the 
entities or you would hook yourself into somewhere late in the pipeline 
where the DWARF debug info is complete and you would generate CTF from 
that.

> So, I think the needs are different enough to vouch for an implementation
> segregated from dwarf* codebase.

Of course.  We are merely discussing of where the triggering of processing 
starts: debug hooks, or something like:

dwarf2out_early_finish() {
  ...
  if (ctf)
ctf_emit();
}

(and then in addition if the current DWARF info would be the source of CTF 
info, or if it'd be whatever the compiler gives you as trees)

The thing is, with debug hooks you'd have to invent a scheme of stacking 
hooks on top of each other (because we want to generate DWARF and CTF from 
the same compilation).  That seems like a wasted effort when our wish is 
for the hooks to go away alltogether.


Ciao,
Michael.

Re: [PATCH] LWG 2996 add rvalue overloads for shared_ptr aliasing and casting

[Jonathan Wakely]

On 24/05/19 11:39 +0100, Jonathan Wakely wrote:

On 24/05/19 11:02 +0200, Christophe Lyon wrote:

Hi Jonathan,

On Thu, 23 May 2019 at 23:40, Jonathan Wakely  wrote:


   * doc/xml/manual/intro.xml: Document LWG DR 2996 change.
   * doc/html/*: Regenerate.
   * include/bits/shared_ptr.h (shared_ptr(shared_ptr&&, T*)): Add
   rvalue aliasing constructor.
   (static_pointer_cast, const_pointer, dynamic_pointer_cast)
   (reinterpret_pointer_cast): Add overloads taking rvalues.
   * include/bits/shared_ptr_base.h (__shared_ptr(__shared_ptr&&, T*)):
   Add rvalue aliasing constructor.
   * testsuite/20_util/shared_ptr/casts/1.cc: Change "compile" test to
   "run" and check return values as well as types.
   * testsuite/20_util/shared_ptr/casts/reinterpret.cc: Likewise.
   * testsuite/20_util/shared_ptr/casts/rval.cc: New test.
   * testsuite/20_util/shared_ptr/cons/alias-rval.cc: New test.
   * testsuite/20_util/shared_ptr/cons/alias.cc: Remove unused return
   values.

Tested powerpc64le-linux, committed to trunk.



As you may have noticed, the new test alias-rval.cc fails on arm and
aarch64, and other targets according to gcc-testresults@


Yes, for some reason that test didn't run on the machine I tested on
... not sure why. Fix coming shortly ...


Looks like I only half-finished writing that test, and then it didn't
get run. Here's a correct test, committed to trunk (and definitely
tested this time, on three systems).


commit bd804ab00d8854f7b32969c31126356aed461cfe
Author: Jonathan Wakely 
Date:   Fri May 24 13:42:21 2019 +0100

Fix broken shared_ptr test

* testsuite/20_util/shared_ptr/cons/alias-rval.cc: Fix test.
* testsuite/20_util/shared_ptr/cons/alias.cc: Remove unused function.

diff --git a/libstdc++-v3/testsuite/20_util/shared_ptr/cons/alias-rval.cc b/libstdc++-v3/testsuite/20_util/shared_ptr/cons/alias-rval.cc
index 205587cde66..f0b0d9cf9ff 100644
--- a/libstdc++-v3/testsuite/20_util/shared_ptr/cons/alias-rval.cc
+++ b/libstdc++-v3/testsuite/20_util/shared_ptr/cons/alias-rval.cc
@@ -37,8 +37,6 @@ struct B : A
   A a;
 };
 
-void deletefunc(A* p) { delete p; }
-
 // 20.6.6.2.1 shared_ptr constructors [util.smartptr.shared.const]
 
 // Aliasing constructors
@@ -63,29 +61,33 @@ test01()
 void
 test02()
 {
-  std::shared_ptr a(new A);
+  A* ptr = new A;
+  ptr->i = 100;
+  std::shared_ptr a(ptr);
   std::shared_ptr i1(std::move(a), >i);
   VERIFY( i1.use_count() == 1 );
-  VERIFY( i1 != nullptr );
+  VERIFY( *i1 == 100 );
   VERIFY( a.use_count() == 0 );
   VERIFY( a == nullptr );
 
   std::shared_ptr i2(i1);
   VERIFY( i2.use_count() == 2 );
-  VERIFY( i2.get() == >i );
+  VERIFY( i2.get() == >i );
 }
 
 void
 test03()
 {
   std::shared_ptr b1(new B);
+  b1->i = 100;
+  b1->a.i = 200;
   std::shared_ptr b2(b1);
   std::shared_ptr a1(std::move(b1), b1.get());
-  std::shared_ptr a2(b2, >a);
+  std::shared_ptr a2(std::move(b2), >a);
+  VERIFY( a1.use_count() == 2 );
   VERIFY( a2.use_count() == 2 );
-  VERIFY( a1 != nullptr );
-  VERIFY( a2 != nullptr );
-  VERIFY( a1 != a2 );
+  VERIFY( a1->i == 100 );
+  VERIFY( a2->i == 200 );
   VERIFY( b1.use_count() == 0 );
   VERIFY( b2.use_count() == 0 );
   VERIFY( b1 == nullptr );
diff --git a/libstdc++-v3/testsuite/20_util/shared_ptr/cons/alias.cc b/libstdc++-v3/testsuite/20_util/shared_ptr/cons/alias.cc
index 134a05894a2..8dbb7af638c 100644
--- a/libstdc++-v3/testsuite/20_util/shared_ptr/cons/alias.cc
+++ b/libstdc++-v3/testsuite/20_util/shared_ptr/cons/alias.cc
@@ -36,8 +36,6 @@ struct B : A
   A a;
 };
 
-void deletefunc(A* p) { delete p; }
-
 // 20.6.6.2.1 shared_ptr constructors [util.smartptr.shared.const]
 
 // Aliasing constructors

Re: Teach same_types_for_tbaa to structurally compare arrays, pointers and vectors

[Richard Biener]

On Fri, 24 May 2019, Jan Hubicka wrote:

> Hi,
> this patch implements basic structura compare so same_type_for_tbaa does
> not return -1 for all arrays, vectors and pointers with LTO.
> The current TBAA stats for tramp3d are:
> 
> Alias oracle query stats:
>   refs_may_alias_p: 3016393 disambiguations, 3316783 queries
>   ref_maybe_used_by_call_p: 7112 disambiguations, 3041993 queries
>   call_may_clobber_ref_p: 817 disambiguations, 817 queries
>   aliasing_component_ref_p: 652 disambiguations, 19720 queries
>   TBAA oracle: 1420658 disambiguations 2918622 queries
>552186 are in alias set 0
>569271 queries asked about the same object
>0 queries asked about the same alias set
>0 access volatile
>260166 are dependent in the DAG
>116341 are aritificially in conflict with void *
> 
> compared to:
> Alias oracle query stats:
>   refs_may_alias_p: 3013166 disambiguations, 3313523 queries
>   ref_maybe_used_by_call_p: 7112 disambiguations, 3038766 queries
>   call_may_clobber_ref_p: 817 disambiguations, 817 queries
>   aliasing_component_ref_p: 124 disambiguations, 12414 queries
>   TBAA oracle: 1417999 disambiguations 2914624 queries
>552182 are in alias set 0
>569275 queries asked about the same object
>0 queries asked about the same alias set
>0 access volatile
>258909 are dependent in the DAG
>116259 are aritificially in conflict with void *
> 
> so about 5 times increase of alias_components_refs_p disambiguations.

Note the number of queries also changes so it's "somewhat" comparing
apples and oranges (possibly the alias walk doesn't have to give up
and thus we walk more and do more queries).

> 
> The basic idea is simple - pointers are same if points-to types are same
> and similarly for arrays/vector.
> 
> I have noticed that a lot of -1s come from comparing void pointers to non-void
> because void is structural type we consider incomparable with everyting.
> I think for pointers it is OK to return either 0 or 1 and never care about
> undecided cases that matters only in the middle of paths.
> For this I track if we compare pointers and return this.
> 
> For arrays situation is slightly different - we can only disprove array
> equivalence but we do not want to return 1 because we support partial overlaps
> on them. The logic about arrays is bit sloppy: some users of
> types_same_for_tbaa_p explicitly disallow them while others doesn't and there
> are cases where the function returns 1 w/o LTO. We can also handle matches 
> when
> array is not the outer type of whole reference which is a common case.
> I plan to clean it up incrementally.
> 
> lto-bootstrapped/regtested x86_64-linux, OK?
> 
> Honza
> 
>   * tree-ssa-alias.c (same_type_for_tbaa): Handle structural comparison
>   of pointers, arrays and vectors.
> Index: tree-ssa-alias.c
> ===
> --- tree-ssa-alias.c  (revision 271292)
> +++ tree-ssa-alias.c  (working copy)
> @@ -745,21 +767,87 @@ same_type_for_tbaa (tree type1, tree typ
>type1 = TYPE_MAIN_VARIANT (type1);
>type2 = TYPE_MAIN_VARIANT (type2);
>  
> -  /* If we would have to do structural comparison bail out.  */
> -  if (TYPE_STRUCTURAL_EQUALITY_P (type1)
> -  || TYPE_STRUCTURAL_EQUALITY_P (type2))
> -return -1;
> +  /* If same_type_for_tbaa returns true we make an assumption that pointers 
> to
> + TYPE1 and TYPE2 can either point to same copy of the type or completely
> + different.
> +
> + This is not necessarily true for arrays where overlap can be partial
> + as in gcc.dg/torture/alias-2.c.  So we can only prove that arrays are
> + disjoint becuase they are derived from different types but we can not
> + prove they are same.
> +
> + On the other hand for pointers we can always consider them to be same
> + unless we can prove that pointed-to types are different.

What about different address-spaces and/or pointer sizes?

> + So normally return values are
> +   0  if types are known to be different
> +   1  if types are same and there is no partial overlap
> +   -1 otherwise.
> +
> + However if comparing two pointers return values are
> +   0  if pointed to types are known to be different
> +   1  otherwise (because partial overlaps do not happen).

Doesn't this apply to all non-composite types?  (the "partial overlaps
do not happen"?)

> + If comparing array or vector to other type return values are
> +   0  if types array/vector are derived from are known to be different
> +   -1 otherwise (to watch for partial overlaps).  */
> +
> +  bool in_ptr = false;
> +  bool in_array = false;
> +
> +  if (type1 == type2)
> +return 1;
> +
> +  /* Do structural comparsion for types that have no canonical types in LTO. 
>  */
> +  while 

[PATCH] PR c/17896 Check for missplaced bitwise op

[Rafael Tsuha]

This patch adds a function to warn when there's a bitwise operation
between a boolean and any other type. This kind of operation is
probably a programmer mistake that may lead to unexpected behavior
because possibily the logical operation was intended.
The test was adapted from PR c/17896.

gcc/c-family/ChangeLog
2019-05-24  Rafael Tsuha 

* c-warn.c (warn_logical_operator): Check for missplaced bitwise op.

gcc/testsuite/ChangeLog
2019-05-24  Rafael Tsuha 

PR c/17896
* gcc.dg/boolean-bitwise.c: New test.
Index: gcc/c-family/c-warn.c
===
--- gcc/c-family/c-warn.c	(revision 268782)
+++ gcc/c-family/c-warn.c	(working copy)
@@ -167,10 +167,10 @@
 }
 
 /* Warn about uses of logical || / && operator in a context where it
-   is likely that the bitwise equivalent was intended by the
-   programmer.  We have seen an expression in which CODE is a binary
-   operator used to combine expressions OP_LEFT and OP_RIGHT, which before folding
-   had CODE_LEFT and CODE_RIGHT, into an expression of type TYPE.  */
+   is likely that the bitwise equivalent was intended by the programmer or vice
+   versa.  We have seen an expression in which CODE is a binary operator used to
+   combine expressions OP_LEFT and OP_RIGHT, which before folding had CODE_LEFT
+   and CODE_RIGHT, into an expression of type TYPE.  */
 
 void
 warn_logical_operator (location_t location, enum tree_code code, tree type,
@@ -178,6 +178,7 @@
 		   enum tree_code ARG_UNUSED (code_right), tree op_right)
 {
   int or_op = (code == TRUTH_ORIF_EXPR || code == TRUTH_OR_EXPR);
+  int and_op = (code == TRUTH_ANDIF_EXPR || code == TRUTH_AND_EXPR);
   int in0_p, in1_p, in_p;
   tree low0, low1, low, high0, high1, high, lhs, rhs, tem;
   bool strict_overflow_p = false;
@@ -188,7 +189,9 @@
   if (code != TRUTH_ANDIF_EXPR
   && code != TRUTH_AND_EXPR
   && code != TRUTH_ORIF_EXPR
-  && code != TRUTH_OR_EXPR)
+  && code != TRUTH_OR_EXPR
+  && code != BIT_AND_EXPR
+  && code != BIT_IOR_EXPR)
 return;
 
   /* We don't want to warn if either operand comes from a macro
@@ -219,7 +222,7 @@
 	  if (or_op)
 	warning_at (location, OPT_Wlogical_op, "logical %"
 			" applied to non-boolean constant");
-	  else
+	  else if (and_op)
 	warning_at (location, OPT_Wlogical_op, "logical %"
 			" applied to non-boolean constant");
 	  TREE_NO_WARNING (op_left) = true;
@@ -227,6 +230,26 @@
 	}
 }
 
+  /* Warn if &/| are being used in a context where it is
+ likely that the logical equivalent was intended by the
+ programmer. That is, an expression such as op_1 & op_2
+ where op_n should not be any boolean expression. */
+  if ( TREE_CODE (TREE_TYPE (op_right)) == BOOLEAN_TYPE
+  || TREE_CODE (TREE_TYPE (op_left)) == BOOLEAN_TYPE 
+	  || COMPARISON_CLASS_P ((op_left))
+	  || COMPARISON_CLASS_P ((op_right)))
+{
+  tree folded_op_right = fold_for_warn (op_right);
+	  if (code == BIT_IOR_EXPR)
+	warning_at (location, OPT_Wlogical_op, "bitwise %"
+			" applied to boolean type");
+	  else if (code == BIT_AND_EXPR)
+	warning_at (location, OPT_Wlogical_op, "bitwise %"
+			" applied to boolean type");
+	  TREE_NO_WARNING (op_left) = true;
+	  return;
+	}
+
   /* We do not warn for constants because they are typical of macro
  expansions that test for features.  */
   if (CONSTANT_CLASS_P (fold_for_warn (op_left))
Index: gcc/testsuite/gcc.dg/boolean-bitwise.c
===
--- gcc/testsuite/gcc.dg/boolean-bitwise.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/boolean-bitwise.c	(working copy)
@@ -0,0 +1,28 @@
+/* Test operation of -Wparentheses.  booleans joined by & or | */
+
+/* { dg-do compile } */
+/* { dg-options "-Wlogical-op" } */
+
+int foo (int);
+
+int
+bar (int a, int b, int c)
+{
+  foo (a == b & b == c); /* { dg-warning "boolean" "correct warning" } */
+  foo (a == b & (b == c));   /* { dg-warning "boolean" "correct warning" } */
+  foo ((a == b) & b == c);   /* { dg-warning "boolean" "correct warning" } */
+  foo (++a == b & b == c);   /* { dg-warning "boolean" "correct warning" } */
+  foo ((a == b) & (b == c)); /* { dg-warning "boolean" "correct warning" } */
+  foo (a == b && b == c);
+  foo (a & b);
+
+  foo (a == b | b == c); /* { dg-warning "boolean" "correct warning" } */
+  foo (a == b | (b == c));   /* { dg-warning "boolean" "correct warning" } */
+  foo ((a == b) | b == c);   /* { dg-warning "boolean" "correct warning" } */
+  foo (++a == b | b == c);   /* { dg-warning "boolean" "correct warning" } */
+  foo ((a == b) | (b == c)); /* { dg-warning "boolean" "correct warning" } */
+  foo (a == b || b == c);
+  foo (a | b);
+
+  return 0;
+}

Re: [PATCH] A jump threading opportunity for condition branch

[Richard Biener]

On Thu, 23 May 2019, Jiufu Guo wrote:

> Richard Biener  writes:
> 
> > On Thu, 23 May 2019, Jiufu Guo wrote:
> >
> >> Hi,
> >> 
> >> Richard Biener  writes:
> >> 
> >> > On Tue, 21 May 2019, Jiufu Guo wrote:
> >> >
> >> >> Hi,
> >> >> 
> >> >> This patch implements a new opportunity of jump threading for PR77820.
> >> >> In this optimization, conditional jumps are merged with unconditional 
> >> >> jump.
> >> >> And then moving CMP result to GPR is eliminated.
> >> >> 
> >> >> It looks like below:
> >> >> 
> >> >>   
> >> >>   p0 = a CMP b
> >> >>   goto ;
> >> >> 
> >> >>   
> >> >>   p1 = c CMP d
> >> >>   goto ;
> >> >> 
> >> >>   
> >> >>   # phi = PHI 
> >> >>   if (phi != 0) goto ; else goto ;
> >> >> 
> >> >> Could be transformed to:
> >> >> 
> >> >>   
> >> >>   p0 = a CMP b
> >> >>   if (p0 != 0) goto ; else goto ;
> >> >> 
> >> >>   
> >> >>   p1 = c CMP d
> >> >>   if (p1 != 0) goto ; else goto ;
> >> >> 
> >> >> 
> >> >> This optimization eliminates:
> >> >> 1. saving CMP result: p0 = a CMP b.
> >> >> 2. additional CMP on branch: if (phi != 0).
> >> >> 3. converting CMP result if there is phi = (INT_CONV) p0 if there is.
> >> >> 
> >> >> Bootstrapped and tested on powerpc64le with no regressions(one case is 
> >> >> improved)
> >> >> and new testcases are added. Is this ok for trunk?
> >> >> 
> >> >> Thanks!
> >> >> Jiufu Guo
> >> >> 
> >> ...
> >> >> diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
> >> >> index c3ea2d6..23000f6 100644
> >> >> --- a/gcc/tree-ssa-threadedge.c
> >> >> +++ b/gcc/tree-ssa-threadedge.c
> >> >> @@ -1157,6 +1157,90 @@ thread_through_normal_block (edge e,
> >> >>return 0;
> >> >>  }
> >> >>  
> >> >> +/* Return true if PHI's INDEX-th incoming value is a CMP, and the CMP 
> >> >> is
> >> >> +   defined in the incoming basic block. Otherwise return false.  */
> >> >> +static bool
> >> >> +cmp_from_unconditional_block (gphi *phi, int index)
> >> >> +{
> >> >> +  tree value = gimple_phi_arg_def (phi, index);
> >> >> +  if (!(TREE_CODE (value) == SSA_NAME && has_single_use (value)))
> >> >> +return false;
> >> >
> >> > Not sure why we should reject a constant here but I guess we
> >> > expect it to find a simplified condition anyways ;)
> >> >
> >> Const could be accepted here, like "# t_9 = PHI <5(3), t_17(4)>". I
> >> found this case is already handled by other jump-threading code, like
> >> 'ethread' pass.
> >> 
> >> >> +
> >> >> +  gimple *def = SSA_NAME_DEF_STMT (value);
> >> >> +
> >> >> +  if (!is_gimple_assign (def))
> >> >> +return false;
> >> >> +
> >> >> +  if (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def)))
> >> >> +{
> >> >> +  value = gimple_assign_rhs1 (def);
> >> >> +  if (!(TREE_CODE (value) == SSA_NAME && has_single_use (value)))
> >> >> +   return false;
> >> >> +
> >> >> +  def = SSA_NAME_DEF_STMT (value);
> >> >> +
> >> >> +  if (!is_gimple_assign (def))
> >> >> +   return false;
> >> >
> >> > too much vertial space.
> >> >
> >> Thanks, I will refine it. 
> >> >> +}
> >> >> +
> >> >> +  if (TREE_CODE_CLASS (gimple_assign_rhs_code (def)) != tcc_comparison)
> >> >> +return false;
> >> >> +
> >> >> +  /* Check if phi's incoming value is defined in the incoming 
> >> >> basic_block.  */
> >> >> +  edge e = gimple_phi_arg_edge (phi, index);
> >> >> +  if (def->bb != e->src)
> >> >> +return false;
> >> >
> >> > why does this matter?
> >> >
> >> Through preparing pathes and duplicating block, this transform can also
> >> help to combine a cmp in previous block and a gcond in current block.
> >> "if (def->bb != e->src)" make sure the cmp is define in the incoming
> >> block of the current; and then combining "cmp with gcond" is safe.  If
> >> the cmp is defined far from the incoming block, it would be hard to
> >> achieve the combining, and the transform may not needed.
> >
> > We're in SSA form so the "combining" doesn't really care where the
> > definition comes from.
> >
> >> >> +
> >> >> +  if (!single_succ_p (def->bb))
> >> >> +return false;
> >> >
> >> > Or this?  The actual threading will ensure this will hold true.
> >> >
> >> Yes, other thread code check this and ensure it to be true, like
> >> function thread_through_normal_block. Since this new function is invoked
> >> outside thread_through_normal_block, so, checking single_succ_p is also
> >> needed for this case.
> >
> > I mean threading will isolate the path making this trivially true.
> > It's also no requirement for combining, in fact due to the single-use
> > check the definition can be sinked across the edge already (if
> > the edges dest didn't have multiple predecessors which this threading
> > will fix as well).
> >
> I would relax these check and have a test.
> 
> And I refactor the code a little as below. Thanks for any comments!
> 
> bool
> edge_forwards_cmp_to_conditional_jump_through_empty_bb_p (edge e)
> {
>   basic_block bb = e->dest;
> 
>   /* See if there is only one stmt which is gcond.  */
>   

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Florian Weimer]

* Segher Boessenkool:

> On Thu, May 23, 2019 at 10:33:28PM +, Joseph Myers wrote:
>> On Tue, 21 May 2019, Segher Boessenkool wrote:
>> 
>> > > I think having author names and email addresses is a basic requirement 
>> > > of 
>> > > any reasonable repository conversion
>> > 
>> > Yes, and they should be the same as they were in the original repository.
>> 
>> That's what the "changelogs" feature in reposurgeon does, when the commit 
>> that made the change also added a ChangeLog entry.
>> 
>> In the case where the commit didn't add a ChangeLog entry, a name and 
>> email address from an author map is the best we can practically do (and I 
>
> IMO the best we can do is use what we already have: what CVS or SVN used
> as the committer identity.  *That* info is *correct* at least.
>
> In many cases we can glance someone's real name from the changelog, sure.
> People looking up things can trivially do that, and with much better
> accuracy than any script can.  In some other cases you cannot, no matter
> how hard you try.

Looking at the git fsck sources, I think you have to fake an email address:

if (*p == '<')
return report(options, obj, FSCK_MSG_MISSING_NAME_BEFORE_EMAIL, 
"invalid author/committer line - missing space before email");
p += strcspn(p, "<>\n");
if (*p == '>')
return report(options, obj, FSCK_MSG_BAD_NAME, "invalid 
author/committer line - bad name");
if (*p != '<')
return report(options, obj, FSCK_MSG_MISSING_EMAIL, "invalid 
author/committer line - missing email");
if (p[-1] != ' ')
return report(options, obj, 
FSCK_MSG_MISSING_SPACE_BEFORE_EMAIL, "invalid author/committer line - missing 
space before email");
p++;
p += strcspn(p, "<>\n");
if (*p != '>')
return report(options, obj, FSCK_MSG_BAD_EMAIL, "invalid 
author/committer line - bad email");
p++;

But something like “fw ” would probably be acceptable.

Thanks,
Florian

Re: [PATCH] libbacktrace: split test_elf into 32 and 64 bits version

[Ian Lance Taylor]

On Fri, May 24, 2019 at 7:37 AM Tom de Vries  wrote:
>
> On 24-05-19 13:10, CHIGOT, CLEMENT wrote:
> > Description:
> >   * This patch splits libbacktrace's test_elf into two new tests: 
> > test_elf_32 and test_elf_64.
> >
> > Tests:
> >   * AIX 7.2: Configure/Build: SUCCESS
> >
> > Changelog:
> >   * Makefile.am (BUILDTESTS): Remove test_elf, add test_elf_32 and 
> > test_elf_64.
> >   * Makefile.in: Regenerate.
>
> Hi,
>
> the patch looks ok to me (but I'm not an approver).
>
> I've tested it, and it passes for me on x86_64-linux.
>
> [ Perhaps for a next submission you could read through
> https://gcc.gnu.org/contribute.html#patches on how to properly format a
> ChangeLog entry. ]
>
> I've reformatted the patch as attached below.
>
> Ian, ok for trunk?

Yes.  Thanks.  Committed.

Ian

Re: [PATCH] libbacktrace: split test_elf into 32 and 64 bits version

[Tom de Vries]

On 24-05-19 13:10, CHIGOT, CLEMENT wrote:
> Description: 
>   * This patch splits libbacktrace's test_elf into two new tests: test_elf_32 
> and test_elf_64. 
>
> Tests: 
>   * AIX 7.2: Configure/Build: SUCCESS
>  
> Changelog: 
>   * Makefile.am (BUILDTESTS): Remove test_elf, add test_elf_32 and 
> test_elf_64.
>   * Makefile.in: Regenerate. 

Hi,

the patch looks ok to me (but I'm not an approver).

I've tested it, and it passes for me on x86_64-linux.

[ Perhaps for a next submission you could read through
https://gcc.gnu.org/contribute.html#patches on how to properly format a
ChangeLog entry. ]

I've reformatted the patch as attached below.

Ian, ok for trunk?

Thanks,
- Tom
[libbacktrace] Replace test_elf with test_elf_{32,64}

This patch splits libbacktrace's test_elf into two new tests: test_elf_32 and
test_elf_64.

Tested on AIX 7.2.

2019-04-24  Clement Chigot  

	* Makefile.am (BUILDTESTS): Remove test_elf, add test_elf_32 and
	test_elf_64.
	* Makefile.in: Regenerate.

---
 libbacktrace/Makefile.am | 20 +++--
 libbacktrace/Makefile.in | 74 ++--
 2 files changed, 69 insertions(+), 25 deletions(-)

diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index 7e183c7ca89..e989d8e9f6c 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -130,6 +130,15 @@ elf_for_test.c: elf.c
 endif HAVE_OBJCOPY_DEBUGLINK
 endif HAVE_ELF
 
+elf_%.c: elf.c
+	SEARCH='#error "Unknown BACKTRACE_ELF_SIZE"'; \
+	REPLACE='#undef BACKTRACE_ELF_SIZE\
+	#define BACKTRACE_ELF_SIZE'; \
+	$(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
+		$< \
+		> $@.tmp
+	mv $@.tmp $@
+
 xcoff_%.c: xcoff.c
 	SEARCH='#error "Unknown BACKTRACE_XCOFF_SIZE"'; \
 	REPLACE='#undef BACKTRACE_XCOFF_SIZE\
@@ -139,10 +148,15 @@ xcoff_%.c: xcoff.c
 		> $@.tmp
 	mv $@.tmp $@
 
-test_elf_SOURCES = test_format.c testlib.c
-test_elf_LDADD = libbacktrace_noformat.la elf.lo
+test_elf_32_SOURCES = test_format.c testlib.c
+test_elf_32_LDADD = libbacktrace_noformat.la elf_32.lo
+
+BUILDTESTS += test_elf_32
+
+test_elf_64_SOURCES = test_format.c testlib.c
+test_elf_64_LDADD = libbacktrace_noformat.la elf_64.lo
 
-BUILDTESTS += test_elf
+BUILDTESTS += test_elf_64
 
 test_xcoff_32_SOURCES = test_format.c testlib.c
 test_xcoff_32_LDADD = libbacktrace_noformat.la xcoff_32.lo
diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in
index ba8de4fa5c2..4ade8e9efcf 100644
--- a/libbacktrace/Makefile.in
+++ b/libbacktrace/Makefile.in
@@ -126,9 +126,9 @@ TESTS = $(am__append_4) $(am__append_6) $(am__append_8) \
 	$(am__append_11) $(am__append_12) $(am__append_18) \
 	$(am__EXEEXT_11)
 @HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_1 = libbacktrace_elf_for_test.la
-@NATIVE_TRUE@am__append_2 = test_elf test_xcoff_32 test_xcoff_64 \
-@NATIVE_TRUE@	test_pecoff test_unknown unittest unittest_alloc \
-@NATIVE_TRUE@	btest
+@NATIVE_TRUE@am__append_2 = test_elf_32 test_elf_64 test_xcoff_32 \
+@NATIVE_TRUE@	test_xcoff_64 test_pecoff test_unknown unittest \
+@NATIVE_TRUE@	unittest_alloc btest
 @NATIVE_TRUE@am__append_3 = allocfail
 @NATIVE_TRUE@am__append_4 = allocfail.sh
 @HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_5 = b2test
@@ -206,10 +206,11 @@ libbacktrace_noformat_la_OBJECTS =  \
 @NATIVE_TRUE@am__EXEEXT_1 = allocfail$(EXEEXT)
 @HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__EXEEXT_2 = b2test$(EXEEXT)
 @HAVE_DWZ_TRUE@@HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__EXEEXT_3 = b3test$(EXEEXT)
-@NATIVE_TRUE@am__EXEEXT_4 = test_elf$(EXEEXT) test_xcoff_32$(EXEEXT) \
-@NATIVE_TRUE@	test_xcoff_64$(EXEEXT) test_pecoff$(EXEEXT) \
-@NATIVE_TRUE@	test_unknown$(EXEEXT) unittest$(EXEEXT) \
-@NATIVE_TRUE@	unittest_alloc$(EXEEXT) btest$(EXEEXT)
+@NATIVE_TRUE@am__EXEEXT_4 = test_elf_32$(EXEEXT) test_elf_64$(EXEEXT) \
+@NATIVE_TRUE@	test_xcoff_32$(EXEEXT) test_xcoff_64$(EXEEXT) \
+@NATIVE_TRUE@	test_pecoff$(EXEEXT) test_unknown$(EXEEXT) \
+@NATIVE_TRUE@	unittest$(EXEEXT) unittest_alloc$(EXEEXT) \
+@NATIVE_TRUE@	btest$(EXEEXT)
 @HAVE_ELF_TRUE@@NATIVE_TRUE@am__EXEEXT_5 = btest_lto$(EXEEXT)
 @NATIVE_TRUE@am__EXEEXT_6 = btest_alloc$(EXEEXT) stest$(EXEEXT) \
 @NATIVE_TRUE@	stest_alloc$(EXEEXT)
@@ -320,10 +321,16 @@ stest_OBJECTS = $(am_stest_OBJECTS)
 @NATIVE_TRUE@am_stest_alloc_OBJECTS = $(am__objects_8)
 stest_alloc_OBJECTS = $(am_stest_alloc_OBJECTS)
 @NATIVE_TRUE@stest_alloc_DEPENDENCIES = libbacktrace_alloc.la
-@NATIVE_TRUE@am_test_elf_OBJECTS = test_format.$(OBJEXT) \
+@NATIVE_TRUE@am_test_elf_32_OBJECTS = test_format.$(OBJEXT) \
 @NATIVE_TRUE@	testlib.$(OBJEXT)
-test_elf_OBJECTS = $(am_test_elf_OBJECTS)
-@NATIVE_TRUE@test_elf_DEPENDENCIES = libbacktrace_noformat.la elf.lo
+test_elf_32_OBJECTS = $(am_test_elf_32_OBJECTS)
+@NATIVE_TRUE@test_elf_32_DEPENDENCIES = libbacktrace_noformat.la \
+@NATIVE_TRUE@	elf_32.lo
+@NATIVE_TRUE@am_test_elf_64_OBJECTS = test_format.$(OBJEXT) \
+@NATIVE_TRUE@	testlib.$(OBJEXT)
+test_elf_64_OBJECTS = 

Re: Fix alias oracle stats

[Jan Hubicka]

> Hi honza,
> 
> On 20 May 2019 11:38:14 CEST, Richard Biener  wrote:
> >On Mon, 20 May 2019, Jan Hubicka wrote:
> >
> >> Hi,
> >> at the moment the alias stats outputs mostly 0 for res_may_alias_p
> >> (which is supposed to be main entry point to the alias oracle).
> >> I think this is because of code refactoring where we added more
> >variants
> >> of this function and we want to do stats around the main worker.
> >> 
> >> Bootstrapped/regtested x86_64-linux, OK?
> >
> >OK.
> 
> >> @@ -1569,15 +1650,9 @@ bool
> >>  refs_may_alias_p (tree ref1, tree ref2, bool tbaa_p)
> >>  {
> >>ao_ref r1, r2;
> >> -  bool res;
> >>ao_ref_init (, ref1);
> >>ao_ref_init (, ref2);
> >> -  res = refs_may_alias_p_1 (, , tbaa_p);
> >> -  if (res)
> >> -++alias_stats.refs_may_alias_p_may_alias;
> >> -  else
> >> -++alias_stats.refs_may_alias_p_no_alias;
> >> -  return res;
> >> +  return; refs_may_alias_p_1 (, , tbaa_p);
> >>  }
> 
> Maybe remove the dead call to refs_may_alias_p_1() after the return though, 
> please.

This is OK in trunk. I wonder how that got into the email :)
Thanks for noticing though.

Honza
> 
> TIA

Teach same_types_for_tbaa to structurally compare arrays, pointers and vectors

[Jan Hubicka]

Hi,
this patch implements basic structura compare so same_type_for_tbaa does
not return -1 for all arrays, vectors and pointers with LTO.
The current TBAA stats for tramp3d are:

Alias oracle query stats:
  refs_may_alias_p: 3016393 disambiguations, 3316783 queries
  ref_maybe_used_by_call_p: 7112 disambiguations, 3041993 queries
  call_may_clobber_ref_p: 817 disambiguations, 817 queries
  aliasing_component_ref_p: 652 disambiguations, 19720 queries
  TBAA oracle: 1420658 disambiguations 2918622 queries
   552186 are in alias set 0
   569271 queries asked about the same object
   0 queries asked about the same alias set
   0 access volatile
   260166 are dependent in the DAG
   116341 are aritificially in conflict with void *

compared to:
Alias oracle query stats:
  refs_may_alias_p: 3013166 disambiguations, 3313523 queries
  ref_maybe_used_by_call_p: 7112 disambiguations, 3038766 queries
  call_may_clobber_ref_p: 817 disambiguations, 817 queries
  aliasing_component_ref_p: 124 disambiguations, 12414 queries
  TBAA oracle: 1417999 disambiguations 2914624 queries
   552182 are in alias set 0
   569275 queries asked about the same object
   0 queries asked about the same alias set
   0 access volatile
   258909 are dependent in the DAG
   116259 are aritificially in conflict with void *

so about 5 times increase of alias_components_refs_p disambiguations.


The basic idea is simple - pointers are same if points-to types are same
and similarly for arrays/vector.

I have noticed that a lot of -1s come from comparing void pointers to non-void
because void is structural type we consider incomparable with everyting.
I think for pointers it is OK to return either 0 or 1 and never care about
undecided cases that matters only in the middle of paths.
For this I track if we compare pointers and return this.

For arrays situation is slightly different - we can only disprove array
equivalence but we do not want to return 1 because we support partial overlaps
on them. The logic about arrays is bit sloppy: some users of
types_same_for_tbaa_p explicitly disallow them while others doesn't and there
are cases where the function returns 1 w/o LTO. We can also handle matches when
array is not the outer type of whole reference which is a common case.
I plan to clean it up incrementally.

lto-bootstrapped/regtested x86_64-linux, OK?

Honza

* tree-ssa-alias.c (same_type_for_tbaa): Handle structural comparison
of pointers, arrays and vectors.
Index: tree-ssa-alias.c
===
--- tree-ssa-alias.c(revision 271292)
+++ tree-ssa-alias.c(working copy)
@@ -745,21 +767,87 @@ same_type_for_tbaa (tree type1, tree typ
   type1 = TYPE_MAIN_VARIANT (type1);
   type2 = TYPE_MAIN_VARIANT (type2);
 
-  /* If we would have to do structural comparison bail out.  */
-  if (TYPE_STRUCTURAL_EQUALITY_P (type1)
-  || TYPE_STRUCTURAL_EQUALITY_P (type2))
-return -1;
+  /* If same_type_for_tbaa returns true we make an assumption that pointers to
+ TYPE1 and TYPE2 can either point to same copy of the type or completely
+ different.
+
+ This is not necessarily true for arrays where overlap can be partial
+ as in gcc.dg/torture/alias-2.c.  So we can only prove that arrays are
+ disjoint becuase they are derived from different types but we can not
+ prove they are same.
+
+ On the other hand for pointers we can always consider them to be same
+ unless we can prove that pointed-to types are different.
+
+ So normally return values are
+   0  if types are known to be different
+   1  if types are same and there is no partial overlap
+   -1 otherwise.
+
+ However if comparing two pointers return values are
+   0  if pointed to types are known to be different
+   1  otherwise (because partial overlaps do not happen).
+
+ If comparing array or vector to other type return values are
+   0  if types array/vector are derived from are known to be different
+   -1 otherwise (to watch for partial overlaps).  */
+
+  bool in_ptr = false;
+  bool in_array = false;
+
+  if (type1 == type2)
+return 1;
+
+  /* Do structural comparsion for types that have no canonical types in LTO.  
*/
+  while (TYPE_STRUCTURAL_EQUALITY_P (type1)
+|| TYPE_STRUCTURAL_EQUALITY_P (type2))
+{
+  /* Pointer types are same if they point to same types.  */
+  if (POINTER_TYPE_P (type1) && POINTER_TYPE_P (type2))
+   {
+ type1 = TYPE_MAIN_VARIANT (TREE_TYPE (type1));
+ type2 = TYPE_MAIN_VARIANT (TREE_TYPE (type2));
+ if (!in_array)
+   in_ptr = true;
+   }
+  /* Peel out arrays and vector to compare inner types.  */
+  else if ((TREE_CODE (type1) == ARRAY_TYPE
+   || TREE_CODE (type1) == VECTOR_TYPE)
+   

[committed, amdgcn] Fix stack initialization bug

[Andrew Stubbs]

This patch fixes a 64-bit arithmetic bug in which the wrong instruction 
was used for the lo-part resulting in an incorrect calculation for the 
hi-part (signed vs. unsigned add). This causes a Memory Access Fault 
whenever the launcher happens to choose a problematic address for the 
stack allocation.


This problem never occurred on GCN3 because the launcher always chose 
addresses in the 32-bit range. It seems to happen more frequently on 
GCN5 devices since a recent ROCm update.


--
Andrew Stubbs
Mentor Graphics / CodeSourcery
Fix 64-bit addition in prologue.

2019-05-24  Andrew Stubbs  

	gcc/
	* config/gcn/gcn.c (gcn_expand_prologue): Use gen_addsi3_scalar_carry
	for lo-part.

diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
index 47630c6edb4..71f4b4ce35a 100644
--- a/gcc/config/gcn/gcn.c
+++ b/gcc/config/gcn/gcn.c
@@ -2824,9 +2824,9 @@ gcn_expand_prologue ()
   emit_move_insn (fp_lo, gen_rtx_REG (SImode, 0));
   emit_insn (gen_andsi3_scc (fp_hi, gen_rtx_REG (SImode, 1),
  gen_int_mode (0x, SImode)));
-  emit_insn (gen_addsi3_scc (fp_lo, fp_lo, wave_offset));
-  emit_insn (gen_addcsi3_scalar_zero (fp_hi, fp_hi,
-	  gen_rtx_REG (BImode, SCC_REG)));
+  rtx scc = gen_rtx_REG (BImode, SCC_REG);
+  emit_insn (gen_addsi3_scalar_carry (fp_lo, fp_lo, wave_offset, scc));
+  emit_insn (gen_addcsi3_scalar_zero (fp_hi, fp_hi, scc));
 
   if (sp_adjust > 0)
 	emit_insn (gen_adddi3_scc (sp, fp, gen_int_mode (sp_adjust, DImode)));

[PATCH] libbacktrace: split test_elf into 32 and 64 bits version

[CHIGOT, CLEMENT]

Description: 
  * This patch splits libbacktrace's test_elf into two new tests: test_elf_32 
and test_elf_64. 
   
Tests: 
  * AIX 7.2: Configure/Build: SUCCESS
 
Changelog: 
  * Makefile.am (BUILDTESTS): Remove test_elf, add test_elf_32 and test_elf_64.
  * Makefile.in: Regenerate. 



Index: libbacktrace/Makefile.am
===
--- a/libbacktrace/Makefile.am	(revision 271281)
+++ b/libbacktrace/Makefile.am	(working copy)
@@ -130,6 +130,15 @@ elf_for_test.c: elf.c
 endif HAVE_OBJCOPY_DEBUGLINK
 endif HAVE_ELF
 
+elf_%.c: elf.c
+	SEARCH='#error "Unknown BACKTRACE_ELF_SIZE"'; \
+	REPLACE='#undef BACKTRACE_ELF_SIZE\
+	#define BACKTRACE_ELF_SIZE'; \
+	$(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
+		$< \
+		> $@.tmp
+	mv $@.tmp $@
+
 xcoff_%.c: xcoff.c
 	SEARCH='#error "Unknown BACKTRACE_XCOFF_SIZE"'; \
 	REPLACE='#undef BACKTRACE_XCOFF_SIZE\
@@ -139,11 +148,16 @@ xcoff_%.c: xcoff.c
 		> $@.tmp
 	mv $@.tmp $@
 
-test_elf_SOURCES = test_format.c testlib.c
-test_elf_LDADD = libbacktrace_noformat.la elf.lo
+test_elf_32_SOURCES = test_format.c testlib.c
+test_elf_32_LDADD = libbacktrace_noformat.la elf_32.lo
 
-BUILDTESTS += test_elf
+BUILDTESTS += test_elf_32
 
+test_elf_64_SOURCES = test_format.c testlib.c
+test_elf_64_LDADD = libbacktrace_noformat.la elf_64.lo
+
+BUILDTESTS += test_elf_64
+
 test_xcoff_32_SOURCES = test_format.c testlib.c
 test_xcoff_32_LDADD = libbacktrace_noformat.la xcoff_32.lo
 
Index: libbacktrace/Makefile.in
===
--- a/libbacktrace/Makefile.in	(revision 271281)
+++ b/libbacktrace/Makefile.in	(working copy)
@@ -126,9 +126,9 @@ TESTS = $(am__append_4) $(am__append_6) $(am__appe
 	$(am__append_11) $(am__append_12) $(am__append_18) \
 	$(am__EXEEXT_11)
 @HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_1 = libbacktrace_elf_for_test.la
-@NATIVE_TRUE@am__append_2 = test_elf test_xcoff_32 test_xcoff_64 \
-@NATIVE_TRUE@	test_pecoff test_unknown unittest unittest_alloc \
-@NATIVE_TRUE@	btest
+@NATIVE_TRUE@am__append_2 = test_elf_32 test_elf_64 test_xcoff_32 \
+@NATIVE_TRUE@	test_xcoff_64 test_pecoff test_unknown unittest \
+@NATIVE_TRUE@	unittest_alloc btest
 @NATIVE_TRUE@am__append_3 = allocfail
 @NATIVE_TRUE@am__append_4 = allocfail.sh
 @HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_5 = b2test
@@ -206,10 +206,11 @@ libbacktrace_noformat_la_OBJECTS =  \
 @NATIVE_TRUE@am__EXEEXT_1 = allocfail$(EXEEXT)
 @HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__EXEEXT_2 = b2test$(EXEEXT)
 @HAVE_DWZ_TRUE@@HAVE_ELF_TRUE@@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__EXEEXT_3 = b3test$(EXEEXT)
-@NATIVE_TRUE@am__EXEEXT_4 = test_elf$(EXEEXT) test_xcoff_32$(EXEEXT) \
-@NATIVE_TRUE@	test_xcoff_64$(EXEEXT) test_pecoff$(EXEEXT) \
-@NATIVE_TRUE@	test_unknown$(EXEEXT) unittest$(EXEEXT) \
-@NATIVE_TRUE@	unittest_alloc$(EXEEXT) btest$(EXEEXT)
+@NATIVE_TRUE@am__EXEEXT_4 = test_elf_32$(EXEEXT) test_elf_64$(EXEEXT) \
+@NATIVE_TRUE@	test_xcoff_32$(EXEEXT) test_xcoff_64$(EXEEXT) \
+@NATIVE_TRUE@	test_pecoff$(EXEEXT) test_unknown$(EXEEXT) \
+@NATIVE_TRUE@	unittest$(EXEEXT) unittest_alloc$(EXEEXT) \
+@NATIVE_TRUE@	btest$(EXEEXT)
 @HAVE_ELF_TRUE@@NATIVE_TRUE@am__EXEEXT_5 = btest_lto$(EXEEXT)
 @NATIVE_TRUE@am__EXEEXT_6 = btest_alloc$(EXEEXT) stest$(EXEEXT) \
 @NATIVE_TRUE@	stest_alloc$(EXEEXT)
@@ -320,10 +321,16 @@ stest_OBJECTS = $(am_stest_OBJECTS)
 @NATIVE_TRUE@am_stest_alloc_OBJECTS = $(am__objects_8)
 stest_alloc_OBJECTS = $(am_stest_alloc_OBJECTS)
 @NATIVE_TRUE@stest_alloc_DEPENDENCIES = libbacktrace_alloc.la
-@NATIVE_TRUE@am_test_elf_OBJECTS = test_format.$(OBJEXT) \
+@NATIVE_TRUE@am_test_elf_32_OBJECTS = test_format.$(OBJEXT) \
 @NATIVE_TRUE@	testlib.$(OBJEXT)
-test_elf_OBJECTS = $(am_test_elf_OBJECTS)
-@NATIVE_TRUE@test_elf_DEPENDENCIES = libbacktrace_noformat.la elf.lo
+test_elf_32_OBJECTS = $(am_test_elf_32_OBJECTS)
+@NATIVE_TRUE@test_elf_32_DEPENDENCIES = libbacktrace_noformat.la \
+@NATIVE_TRUE@	elf_32.lo
+@NATIVE_TRUE@am_test_elf_64_OBJECTS = test_format.$(OBJEXT) \
+@NATIVE_TRUE@	testlib.$(OBJEXT)
+test_elf_64_OBJECTS = $(am_test_elf_64_OBJECTS)
+@NATIVE_TRUE@test_elf_64_DEPENDENCIES = libbacktrace_noformat.la \
+@NATIVE_TRUE@	elf_64.lo
 @NATIVE_TRUE@am_test_pecoff_OBJECTS = test_format.$(OBJEXT) \
 @NATIVE_TRUE@	testlib.$(OBJEXT)
 test_pecoff_OBJECTS = $(am_test_pecoff_OBJECTS)
@@ -436,10 +443,11 @@ SOURCES = $(libbacktrace_la_SOURCES) $(EXTRA_libba
 	$(ctesta_alloc_SOURCES) $(ctestg_SOURCES) \
 	$(ctestg_alloc_SOURCES) $(edtest_SOURCES) \
 	$(edtest_alloc_SOURCES) $(stest_SOURCES) \
-	$(stest_alloc_SOURCES) $(test_elf_SOURCES) \
-	$(test_pecoff_SOURCES) $(test_unknown_SOURCES) \
-	$(test_xcoff_32_SOURCES) $(test_xcoff_64_SOURCES) \
-	$(ttest_SOURCES) $(ttest_alloc_SOURCES) $(unittest_SOURCES) \
+	$(stest_alloc_SOURCES) $(test_elf_32_SOURCES) \
+	$(test_elf_64_SOURCES) $(test_pecoff_SOURCES) \
+	$(test_unknown_SOURCES) $(test_xcoff_32_SOURCES) \
+	

Re: [PATCH] LWG 2996 add rvalue overloads for shared_ptr aliasing and casting

[Jonathan Wakely]

On 24/05/19 11:02 +0200, Christophe Lyon wrote:

Hi Jonathan,

On Thu, 23 May 2019 at 23:40, Jonathan Wakely  wrote:


* doc/xml/manual/intro.xml: Document LWG DR 2996 change.
* doc/html/*: Regenerate.
* include/bits/shared_ptr.h (shared_ptr(shared_ptr&&, T*)): Add
rvalue aliasing constructor.
(static_pointer_cast, const_pointer, dynamic_pointer_cast)
(reinterpret_pointer_cast): Add overloads taking rvalues.
* include/bits/shared_ptr_base.h (__shared_ptr(__shared_ptr&&, T*)):
Add rvalue aliasing constructor.
* testsuite/20_util/shared_ptr/casts/1.cc: Change "compile" test to
"run" and check return values as well as types.
* testsuite/20_util/shared_ptr/casts/reinterpret.cc: Likewise.
* testsuite/20_util/shared_ptr/casts/rval.cc: New test.
* testsuite/20_util/shared_ptr/cons/alias-rval.cc: New test.
* testsuite/20_util/shared_ptr/cons/alias.cc: Remove unused return
values.

Tested powerpc64le-linux, committed to trunk.



As you may have noticed, the new test alias-rval.cc fails on arm and
aarch64, and other targets according to gcc-testresults@


Yes, for some reason that test didn't run on the machine I tested on
... not sure why. Fix coming shortly ...

Re: [Patch] [aarch64] Change two function declaration types

[Richard Earnshaw (lists)]

On 24/05/2019 11:28, Matthew Malcomson wrote:
> Commit r271514 missed changing the type of two functions in
> aarch64-protos.h.  The function definitions had been updated to use
> uint64_t while the function declarations had been missed.
> They were missed since I only tested the patch on aarch64 where
> `unsigned long` is the same as `uint64_t`.
> 
> This patch updates these declarations in aarch64-protos.h.
> 
> Tested by building an aarch64 cross-compiler on arm-none-linux-gnu (so
> that `unsigned long` and `uint64_t` are different and would give error
> messages), and bootstrapping on aarch64-none-linux-gnu.
> Also manually tested command line options to see that
> -march=armv8-a+typo prints out the expected flags while using the new
> feature flags does not complain about missing flags.
> 
> gcc/ChangeLog:
> 
> 2019-05-24  Matthew Malcomson  
> 
>   PR target/90588
>   * common/config/aarch64/aarch64-common.c
>   (aarch64_rewrite_selected_cpu): Change local temporary variable
>   type from unsigned long to uint64_t.
>   * config/aarch64/aarch64-protos.h (aarch64_parse_extension,
>   aarch64_get_extension_string_for_isa_flags): Change declaration to
>   match new definition by replacing unsigned long with uint64_t.
> 
> 

OK.

R.

> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/common/config/aarch64/aarch64-common.c 
> b/gcc/common/config/aarch64/aarch64-common.c
> index 
> f9051056589861ce0ffe1bae4fa04cf44d34b9a2..07c032539513eec8c9e7f800c35454d81d627301
>  100644
> --- a/gcc/common/config/aarch64/aarch64-common.c
> +++ b/gcc/common/config/aarch64/aarch64-common.c
> @@ -541,7 +541,7 @@ aarch64_rewrite_selected_cpu (const char *name)
>|| a_to_an->arch == aarch64_no_arch)
>  fatal_error (input_location, "unknown value %qs for %<-mcpu%>", name);
>  
> -  unsigned long extensions = p_to_a->flags;
> +  uint64_t extensions = p_to_a->flags;
>aarch64_parse_extension (extension_str.c_str (), , NULL);
>  
>std::string outstr = a_to_an->arch_name
> diff --git a/gcc/config/aarch64/aarch64-protos.h 
> b/gcc/config/aarch64/aarch64-protos.h
> index 
> b6c0d0a8eb6c1bbc6d0524fbf98686fa9ef9613d..a0723266f22454ce3d4d57830573acdebc96489c
>  100644
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++ b/gcc/config/aarch64/aarch64-protos.h
> @@ -624,11 +624,10 @@ bool aarch64_handle_option (struct gcc_options *, 
> struct gcc_options *,
>const struct cl_decoded_option *, location_t);
>  const char *aarch64_rewrite_selected_cpu (const char *name);
>  enum aarch64_parse_opt_result aarch64_parse_extension (const char *,
> -unsigned long *,
> +uint64_t *,
>  std::string *);
>  void aarch64_get_all_extension_candidates (auto_vec 
> *candidates);
> -std::string aarch64_get_extension_string_for_isa_flags (unsigned long,
> - unsigned long);
> +std::string aarch64_get_extension_string_for_isa_flags (uint64_t, uint64_t);
>  
>  /* Defined in aarch64-d.c  */
>  extern void aarch64_d_target_versions (void);
> 
> 
> prototype-fix.patch
> 
> diff --git a/gcc/common/config/aarch64/aarch64-common.c 
> b/gcc/common/config/aarch64/aarch64-common.c
> index 
> f9051056589861ce0ffe1bae4fa04cf44d34b9a2..07c032539513eec8c9e7f800c35454d81d627301
>  100644
> --- a/gcc/common/config/aarch64/aarch64-common.c
> +++ b/gcc/common/config/aarch64/aarch64-common.c
> @@ -541,7 +541,7 @@ aarch64_rewrite_selected_cpu (const char *name)
>|| a_to_an->arch == aarch64_no_arch)
>  fatal_error (input_location, "unknown value %qs for %<-mcpu%>", name);
>  
> -  unsigned long extensions = p_to_a->flags;
> +  uint64_t extensions = p_to_a->flags;
>aarch64_parse_extension (extension_str.c_str (), , NULL);
>  
>std::string outstr = a_to_an->arch_name
> diff --git a/gcc/config/aarch64/aarch64-protos.h 
> b/gcc/config/aarch64/aarch64-protos.h
> index 
> b6c0d0a8eb6c1bbc6d0524fbf98686fa9ef9613d..a0723266f22454ce3d4d57830573acdebc96489c
>  100644
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++ b/gcc/config/aarch64/aarch64-protos.h
> @@ -624,11 +624,10 @@ bool aarch64_handle_option (struct gcc_options *, 
> struct gcc_options *,
>const struct cl_decoded_option *, location_t);
>  const char *aarch64_rewrite_selected_cpu (const char *name);
>  enum aarch64_parse_opt_result aarch64_parse_extension (const char *,
> -unsigned long *,
> +uint64_t *,
>  std::string *);
>  void aarch64_get_all_extension_candidates (auto_vec 
> *candidates);
> -std::string aarch64_get_extension_string_for_isa_flags (unsigned long,
> - 

Re: *ping* Re: [PATCH] PR fortran/89100 Default widths for i, f and g format specifiers in format strings

[Jakub Jelinek]

On Fri, May 24, 2019 at 11:28:34AM +0100, Mark Eggleston wrote:
> > FAIL: gfortran.dg/fmt_f_default_field_width_3.f90   -O   (test for
> > errors, line 33)
> > PASS: gfortran.dg/fmt_f_default_field_width_3.f90   -O  (test for excess 
> > errors)
> > 
> > that is, it seems there's no error message generated for line 33.
> > 
> > Christophe
> > 
> 
> There is no error for line 33 because it isn't included in the compilation
> because __GFC_REAL_16__ isn't defined. DejaGnu doesn't know this and the
> dg-warning directive for this line is still processed.
> 
> I don't know enough about DejaGnu directives to determine whether this
> situation can be handled. Does anybody know how to deal with a line that if
> compiled a warning message output and if not compiled there is no output?
> 
> Is the easiest solution to omit the test code where kind=16?

You can do (pseudo patch, untested):
 #ifdef __GFC_REAL_16__
  real_16 = 4.18
- write(buffer, fmt) ':',real_16,':' ! { dg-error "Positive width required" 
}
+ write(buffer, fmt) ':',real_16,':' ! { dg-error "Positive width required" 
"" { target fortran_real_16 } }
 #endif

Effective target fortran_real_16 should be true whenever:
real(kind=16) :: x
x = cos (x)
end
compiles and links into an executable without diagnostics.

Jakub

Re: *ping* Re: [PATCH] PR fortran/89100 Default widths for i, f and g format specifiers in format strings

[Mark Eggleston]

On 24/05/2019 10:06, Christophe Lyon wrote:

On Thu, 23 May 2019 at 19:21, Steve Kargl
 wrote:

On Thu, May 23, 2019 at 05:26:53PM +0200, Christophe Lyon wrote:

On Thu, 23 May 2019 at 15:54, Mark Eggleston
 wrote:

The logs contain:
/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_1.f90:15:11:
Error: Kind 16 not supported for type REAL at (1)

Christophe

Apologies, I'd forgotten that kind=16 is not always defined. The
attached patch modifies the test cases to take this into account. I
currently have no means of verifying this.

Please confirm that this patch solves the problem.


I confirm this patch does fix the problem, thanks


Patch committed as r271573.


Hi,

Sorry, I didn't check all the testcases you changed, and this commit
introduces a new failure on arm:
/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:23:23:
Error: Nonnegative width required in format string at (1)
/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:26:23:
Error: Nonnegative width required in format string at (1)
/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:29:23:
Error: Nonnegative width required in format string at (1)
compiler exited with status 1
PASS: gfortran.dg/fmt_f_default_field_width_3.f90   -O   (test for
errors, line 23)
PASS: gfortran.dg/fmt_f_default_field_width_3.f90   -O   (test for
errors, line 26)
PASS: gfortran.dg/fmt_f_default_field_width_3.f90   -O   (test for
errors, line 29)
FAIL: gfortran.dg/fmt_f_default_field_width_3.f90   -O   (test for
errors, line 33)
PASS: gfortran.dg/fmt_f_default_field_width_3.f90   -O  (test for excess errors)

that is, it seems there's no error message generated for line 33.

Christophe



There is no error for line 33 because it isn't included in the 
compilation because __GFC_REAL_16__ isn't defined. DejaGnu doesn't know 
this and the dg-warning directive for this line is still processed.


I don't know enough about DejaGnu directives to determine whether this 
situation can be handled. Does anybody know how to deal with a line that 
if compiled a warning message output and if not compiled there is no output?


Is the easiest solution to omit the test code where kind=16?

Mark


--
Steve


--
https://www.codethink.co.uk/privacy.html

[Patch] [aarch64] Change two function declaration types

[Matthew Malcomson]

Commit r271514 missed changing the type of two functions in
aarch64-protos.h.  The function definitions had been updated to use
uint64_t while the function declarations had been missed.
They were missed since I only tested the patch on aarch64 where
`unsigned long` is the same as `uint64_t`.

This patch updates these declarations in aarch64-protos.h.

Tested by building an aarch64 cross-compiler on arm-none-linux-gnu (so
that `unsigned long` and `uint64_t` are different and would give error
messages), and bootstrapping on aarch64-none-linux-gnu.
Also manually tested command line options to see that
-march=armv8-a+typo prints out the expected flags while using the new
feature flags does not complain about missing flags.

gcc/ChangeLog:

2019-05-24  Matthew Malcomson  

PR target/90588
* common/config/aarch64/aarch64-common.c
(aarch64_rewrite_selected_cpu): Change local temporary variable
type from unsigned long to uint64_t.
* config/aarch64/aarch64-protos.h (aarch64_parse_extension,
aarch64_get_extension_string_for_isa_flags): Change declaration to
match new definition by replacing unsigned long with uint64_t.



### Attachment also inlined for ease of reply###


diff --git a/gcc/common/config/aarch64/aarch64-common.c 
b/gcc/common/config/aarch64/aarch64-common.c
index 
f9051056589861ce0ffe1bae4fa04cf44d34b9a2..07c032539513eec8c9e7f800c35454d81d627301
 100644
--- a/gcc/common/config/aarch64/aarch64-common.c
+++ b/gcc/common/config/aarch64/aarch64-common.c
@@ -541,7 +541,7 @@ aarch64_rewrite_selected_cpu (const char *name)
   || a_to_an->arch == aarch64_no_arch)
 fatal_error (input_location, "unknown value %qs for %<-mcpu%>", name);
 
-  unsigned long extensions = p_to_a->flags;
+  uint64_t extensions = p_to_a->flags;
   aarch64_parse_extension (extension_str.c_str (), , NULL);
 
   std::string outstr = a_to_an->arch_name
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 
b6c0d0a8eb6c1bbc6d0524fbf98686fa9ef9613d..a0723266f22454ce3d4d57830573acdebc96489c
 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -624,11 +624,10 @@ bool aarch64_handle_option (struct gcc_options *, struct 
gcc_options *,
 const struct cl_decoded_option *, location_t);
 const char *aarch64_rewrite_selected_cpu (const char *name);
 enum aarch64_parse_opt_result aarch64_parse_extension (const char *,
-  unsigned long *,
+  uint64_t *,
   std::string *);
 void aarch64_get_all_extension_candidates (auto_vec *candidates);
-std::string aarch64_get_extension_string_for_isa_flags (unsigned long,
-   unsigned long);
+std::string aarch64_get_extension_string_for_isa_flags (uint64_t, uint64_t);
 
 /* Defined in aarch64-d.c  */
 extern void aarch64_d_target_versions (void);

diff --git a/gcc/common/config/aarch64/aarch64-common.c 
b/gcc/common/config/aarch64/aarch64-common.c
index 
f9051056589861ce0ffe1bae4fa04cf44d34b9a2..07c032539513eec8c9e7f800c35454d81d627301
 100644
--- a/gcc/common/config/aarch64/aarch64-common.c
+++ b/gcc/common/config/aarch64/aarch64-common.c
@@ -541,7 +541,7 @@ aarch64_rewrite_selected_cpu (const char *name)
   || a_to_an->arch == aarch64_no_arch)
 fatal_error (input_location, "unknown value %qs for %<-mcpu%>", name);
 
-  unsigned long extensions = p_to_a->flags;
+  uint64_t extensions = p_to_a->flags;
   aarch64_parse_extension (extension_str.c_str (), , NULL);
 
   std::string outstr = a_to_an->arch_name
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 
b6c0d0a8eb6c1bbc6d0524fbf98686fa9ef9613d..a0723266f22454ce3d4d57830573acdebc96489c
 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -624,11 +624,10 @@ bool aarch64_handle_option (struct gcc_options *, struct 
gcc_options *,
 const struct cl_decoded_option *, location_t);
 const char *aarch64_rewrite_selected_cpu (const char *name);
 enum aarch64_parse_opt_result aarch64_parse_extension (const char *,
-  unsigned long *,
+  uint64_t *,
   std::string *);
 void aarch64_get_all_extension_candidates (auto_vec *candidates);
-std::string aarch64_get_extension_string_for_isa_flags (unsigned long,
-   unsigned long);
+std::string aarch64_get_extension_string_for_isa_flags (uint64_t, uint64_t);
 
 /* Defined in aarch64-d.c  */
 extern void aarch64_d_target_versions (void);

Re: [PATCH] Make any_cast compare typeinfo as well as function pointers

[Jonathan Wakely]

On 24/05/19 10:57 +0200, Christophe Lyon wrote:

Hi Jonathan,

On Thu, 23 May 2019 at 16:13, Jonathan Wakely  wrote:


It's possible for the function pointer comparison to fail even though
the type is correct, because the function could be defined multiple
times with different addresses when shared libraries are in use.

Retain the function pointer check for the common case where the check
succeeds, but compare typeinfo (if RTTI is enabled) if the first check
fails.

* include/experimental/any (__any_caster): Use RTTI if comparing
addresses fails, to support non-unique addresses in shared libraries.
* include/std/any (__any_caster): Likewise.

Tested powerpc64le-linux, committed to trunk, backports to follow.




It seems OK on trunk, but on gcc-7/gcc-8 branches I see:
/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc:20:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/experimental/any:
In instantiation of '_ValueType
std::experimental::fundamentals_v1::any_cast(const
std::experimental::fundamentals_v1::any&) [with _ValueType = int&]':
/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc:28:
required from here
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/experimental/any:358:
error: binding reference of type 'int&' to 'const int' discards
qualifiers
compiler exited with status 1
FAIL: experimental/any/misc/any_cast_neg.cc  (test for errors, line 357)
FAIL: experimental/any/misc/any_cast_neg.cc (test for excess errors)

on arm/aarch64


I don't see how you can have that error when the test was changed to
match on any line:

https://gcc.gnu.org/viewcvs/gcc/branches/gcc-7-branch/libstdc%2B%2B-v3/testsuite/experimental/any/misc/any_cast_neg.cc?r1=271566=271565=271566
https://gcc.gnu.org/viewcvs/gcc/branches/gcc-8-branch/libstdc%2B%2B-v3/testsuite/experimental/any/misc/any_cast_neg.cc?r1=271562=271561=271562

Re: Patch ping (Re: [PATCH][PR90106] Builtin call transformation changes in cdce pass)

[Richard Biener]

On Fri, 24 May 2019, Jakub Jelinek wrote:

> On Fri, May 17, 2019 at 12:04:16AM +0200, Jakub Jelinek wrote:
> > On Thu, May 16, 2019 at 11:39:38PM +0200, Jakub Jelinek wrote:
> > > One possibility is to add -fdump-tree-optimized and scan for
> > > /* { dg-final { scan-tree-dump "pow \\(\[^\n\r]*\\); \\\[tail call\\\]" 
> > > "optimized" } } */
> > > resp.
> > > /* { dg-final { scan-tree-dump "log \\(\[^\n\r]*\\); \\\[tail call\\\]" 
> > > "optimized" } } */
> > 
> > Here it is in patch form.
> > 
> > That said, I'm not convinced your patch does what you wanted, because
> > comparing a month old trunk with today's trunk generates the same assembly
> > except for .ident, generates as many [tail call] lines in *.optimized dump
> > as before, emits the same number of jmp\tpow and jmp\tlog instructions as
> > before (one in a separate routine).
> > 
> > But at least the tests aren't UNSUPPORTED anymore.
> > 
> > 2019-05-16  Jakub Jelinek  
> > 
> > PR tree-optimization/90106
> > * gcc.dg/cdce1.c: Don't scan-assembler, instead -fdump-tree-optimized
> > and scan-tree-dump for tail call.
> > * gcc.dg/cdce2.c: Likewise.
> 
> I'd like to ping this patch.  A new cdce3.c testcase has been added in the
> mean time, so the above "That said," paragraph is resolved through that.

OK

> > --- gcc/testsuite/gcc.dg/cdce1.c.jj 2019-05-16 11:28:22.750177582 +0200
> > +++ gcc/testsuite/gcc.dg/cdce1.c2019-05-16 23:50:23.618450891 +0200
> > @@ -1,9 +1,9 @@
> > -/* { dg-do  run  } */
> > -/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details  -lm" } */
> > +/* { dg-do run } */
> > +/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details 
> > -fdump-tree-optimized -lm" } */
> >  /* { dg-require-effective-target int32plus } */
> > -/* { dg-final { scan-tree-dump  "cdce1.c:17: .* function call is 
> > shrink-wrapped into error conditions\."  "cdce" } } */
> > -/* { dg-final { scan-assembler "jmp pow" } } */
> >  /* { dg-require-effective-target large_double } */
> > +/* { dg-final { scan-tree-dump "cdce1.c:17: .* function call is 
> > shrink-wrapped into error conditions\." "cdce" } } */
> > +/* { dg-final { scan-tree-dump "pow \\(\[^\n\r]*\\); \\\[tail call\\\]" 
> > "optimized" } } */
> >  
> >  #include 
> >  #include 
> > --- gcc/testsuite/gcc.dg/cdce2.c.jj 2019-05-16 11:28:22.781177075 +0200
> > +++ gcc/testsuite/gcc.dg/cdce2.c2019-05-16 23:50:58.505880845 +0200
> > @@ -1,8 +1,8 @@
> > -/* { dg-do  run  } */
> > +/* { dg-do run } */
> >  /* { dg-skip-if "doubles are floats" { "avr-*-*" } } */
> > -/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details  -lm" } */
> > -/* { dg-final { scan-tree-dump  "cdce2.c:16: .* function call is 
> > shrink-wrapped into error conditions\." "cdce" } } */
> > -/* { dg-final { scan-assembler "jmp log" } } */
> > +/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details 
> > -fdump-tree-optimized -lm" } */
> > +/* { dg-final { scan-tree-dump "cdce2.c:16: .* function call is 
> > shrink-wrapped into error conditions\." "cdce" } } */
> > +/* { dg-final { scan-tree-dump "log \\(\[^\n\r]*\\); \\\[tail call\\\]" 
> > "optimized" } } */
> >   
> >  #include 
> >  #include 
> > 
> 
>   Jakub
> 

-- 
Richard Biener 
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany;
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)

Patch ping (Re: [PATCH][PR90106] Builtin call transformation changes in cdce pass)

[Jakub Jelinek]

On Fri, May 17, 2019 at 12:04:16AM +0200, Jakub Jelinek wrote:
> On Thu, May 16, 2019 at 11:39:38PM +0200, Jakub Jelinek wrote:
> > One possibility is to add -fdump-tree-optimized and scan for
> > /* { dg-final { scan-tree-dump "pow \\(\[^\n\r]*\\); \\\[tail call\\\]" 
> > "optimized" } } */
> > resp.
> > /* { dg-final { scan-tree-dump "log \\(\[^\n\r]*\\); \\\[tail call\\\]" 
> > "optimized" } } */
> 
> Here it is in patch form.
> 
> That said, I'm not convinced your patch does what you wanted, because
> comparing a month old trunk with today's trunk generates the same assembly
> except for .ident, generates as many [tail call] lines in *.optimized dump
> as before, emits the same number of jmp\tpow and jmp\tlog instructions as
> before (one in a separate routine).
> 
> But at least the tests aren't UNSUPPORTED anymore.
> 
> 2019-05-16  Jakub Jelinek  
> 
>   PR tree-optimization/90106
>   * gcc.dg/cdce1.c: Don't scan-assembler, instead -fdump-tree-optimized
>   and scan-tree-dump for tail call.
>   * gcc.dg/cdce2.c: Likewise.

I'd like to ping this patch.  A new cdce3.c testcase has been added in the
mean time, so the above "That said," paragraph is resolved through that.

> --- gcc/testsuite/gcc.dg/cdce1.c.jj   2019-05-16 11:28:22.750177582 +0200
> +++ gcc/testsuite/gcc.dg/cdce1.c  2019-05-16 23:50:23.618450891 +0200
> @@ -1,9 +1,9 @@
> -/* { dg-do  run  } */
> -/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details  -lm" } */
> +/* { dg-do run } */
> +/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details 
> -fdump-tree-optimized -lm" } */
>  /* { dg-require-effective-target int32plus } */
> -/* { dg-final { scan-tree-dump  "cdce1.c:17: .* function call is 
> shrink-wrapped into error conditions\."  "cdce" } } */
> -/* { dg-final { scan-assembler "jmp pow" } } */
>  /* { dg-require-effective-target large_double } */
> +/* { dg-final { scan-tree-dump "cdce1.c:17: .* function call is 
> shrink-wrapped into error conditions\." "cdce" } } */
> +/* { dg-final { scan-tree-dump "pow \\(\[^\n\r]*\\); \\\[tail call\\\]" 
> "optimized" } } */
>  
>  #include 
>  #include 
> --- gcc/testsuite/gcc.dg/cdce2.c.jj   2019-05-16 11:28:22.781177075 +0200
> +++ gcc/testsuite/gcc.dg/cdce2.c  2019-05-16 23:50:58.505880845 +0200
> @@ -1,8 +1,8 @@
> -/* { dg-do  run  } */
> +/* { dg-do run } */
>  /* { dg-skip-if "doubles are floats" { "avr-*-*" } } */
> -/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details  -lm" } */
> -/* { dg-final { scan-tree-dump  "cdce2.c:16: .* function call is 
> shrink-wrapped into error conditions\." "cdce" } } */
> -/* { dg-final { scan-assembler "jmp log" } } */
> +/* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details 
> -fdump-tree-optimized -lm" } */
> +/* { dg-final { scan-tree-dump "cdce2.c:16: .* function call is 
> shrink-wrapped into error conditions\." "cdce" } } */
> +/* { dg-final { scan-tree-dump "log \\(\[^\n\r]*\\); \\\[tail call\\\]" 
> "optimized" } } */
>   
>  #include 
>  #include 
> 

Jakub

Re: libbacktrace tests for AIX

[Tom de Vries]

[ Add CC gcc-patches ]

On 23-05-19 15:22, CHIGOT, CLEMENT wrote:
> Hi Ian, Tom, 
> 
> I've some problems with gccgo and libbacktrace so I've tried to run
> libbacktrace tests on AIX, to see if everything looks good. 
> However, I can't build them... 
> 
> Looking at the code, test_elf is trying to compile elf.c which won't
> work because BACKTRACE_ELF_SIZE is defined to unused. Therefore, I've
> got this error:
>     ../../../../gcc-9.1.0/libbacktrace/elf.c:144:2: error: #error
> "Unknown BACKTRACE_ELF_SIZE"
>     144 | #error "Unknown BACKTRACE_ELF_SIZE"
>         |  ^
>  
> On a elf system (I've tried on Fedora), test_xcoff is separated into two
> different tests: *test_xcoff_32 and test_xcoff_64*. These tests will
> build xcoff_32.c and xcoff_64.c replacing BACKTRACE_XCOFF_SIZE by the
> correct value. 
> 
> I was wondering if it's possible to do something similar for test_elf ? 

Hi,

I think so, yes.

> I've tried locally on AIX and it seems to work. I haven't tried on
> Fedora yet, but I don't see any reason why it would fail. 
> 
> If you agree with that, I'll submit a patch (to you by the way?). 
> 

Fine by me. Please send to both Ian and me, as well as
gcc-patches@gcc.gnu.org.

Thanks,
- Tom

Re: [PATCH] Handle loop fields in IPA ICF (PR ipa/90555).

[Richard Biener]

On Fri, May 24, 2019 at 10:08 AM Jakub Jelinek  wrote:
>
> On Fri, May 24, 2019 at 09:48:03AM +0200, Martin Liška wrote:
> > gcc/ChangeLog:
> >
> > 2019-05-23  Martin Liska  
> >
> >   PR ipa/90555
> >   * ipa-icf-gimple.c (func_checker::compare_loops): New function.
> >   * ipa-icf-gimple.h (func_checker::compare_loops): Likewise.
> >   * ipa-icf.c (sem_function::equals_private): Use compare_loops.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2019-05-23  Martin Liska  
> >
> >   PR ipa/90555
> >   * gcc.dg/ipa/pr90555.c: New test.
>
> > @@ -605,6 +606,45 @@ func_checker::compare_variable_decl (tree t1, tree t2)
> >return return_with_debug (ret);
> >  }
> >
> > +/* Compare significant loop information.  */
> > +bool
> > +func_checker::compare_loops (void)
> > +{
> > +  struct loop *loop;
> > +
> > +  auto_vec  loops1;
> > +  auto_vec  loops2;
> > +
> > +  FOR_EACH_LOOP_FN (DECL_STRUCT_FUNCTION (m_source_func_decl), loop, 0)
> > +loops1.safe_push (loop);
> > +
> > +  FOR_EACH_LOOP_FN (DECL_STRUCT_FUNCTION (m_target_func_decl), loop, 0)
> > +loops2.safe_push (loop);
> > +
> > +  gcc_assert (loops1.length () == loops2.length ());
> > +
> > +  for (unsigned i = 0; i < loops1.length (); i++)
>
> I wonder how likely/unlikely it is that the loops will be ordered the same
> by the iterators.  If they are the same always, then perhaps it would be
> better to avoid the temporary vectors, and just do one FOR_EACH_LOOP_FN
> with another manual loop_iterator use in sync with that.
> If it isn't guaranteed they are ordered the same, then I think we need to
> match the loops by the corresponding loop header and perhaps also verify
> loop latch and other basic blocks in the loop?

In fact I wouldn't even compare loops this way but compare loop
paris when I run across two equal basic-blocks that are loop
headers (bb->loop_father == bb->loop_father->header).

> > +{
> > +  struct loop *l1 = loops1[i];
> > +  struct loop *l2 = loops2[i];
> > +  if (l1->simdlen != l2->simdlen)
> > + return return_false_with_msg ("simdlen");
> > +  if (l1->safelen != l2->safelen)
> > + return return_false_with_msg ("safelen");
> > +  if (l1->can_be_parallel != l2->can_be_parallel)
> > + return return_false_with_msg ("can_be_parallel");
> > +  if (l1->dont_vectorize != l2->dont_vectorize)
> > + return return_false_with_msg ("dont_vectorize");
> > +  if (l1->force_vectorize != l2->force_vectorize)
> > + return return_false_with_msg ("force_vectorize");
> > +  if (l1->unroll != l2->unroll)
> > + return return_false_with_msg ("unroll");
> > +  if (!compare_variable_decl (l1->simduid, l2->simduid))
> > + return return_false_with_msg ("simduid");
>
> The above looks reasonable if we are guaranteed we are talking about a loop
> corresponding between the two functions.
>
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/ipa/pr90555.c
> > @@ -0,0 +1,67 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-fopenmp-simd -O2 -mavx512f -fdump-ipa-icf" } */
> > +/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
>
> Please don't use two dg-do compile directives, drop the first line,
> move the third line to first one.
>
> Jakub

Re: [PATCH] Add LABEL_REF_P to rtl.h

[Richard Biener]

On Thu, May 23, 2019 at 10:59 PM Bill Schmidt  wrote:
>
> Hi,
>
> This patch just adds a convenience macro to be used in subsequent patches.
>
> Bootstrapped successfully on powerpc64le-unknown-linux-gnu.  Okay for trunk?

OK.

> Thanks,
> Bill
>
>
> 2019-05-23  Michael Meissner  
>
> * rtl.h (LABEL_REF_P): New #define.
>
>
> Index: gcc/rtl.h
> ===
> --- gcc/rtl.h   (revision 271579)
> +++ gcc/rtl.h   (working copy)
> @@ -1052,6 +1052,10 @@ is_a_helper ::test (rtx_insn *insn)
>  #define CONSTANT_P(X)   \
>(GET_RTX_CLASS (GET_CODE (X)) == RTX_CONST_OBJ)
>
> +/* 1 if X is a LABEL_REF.  */
> +#define LABEL_REF_P(X)  \
> +  (GET_CODE (X) == LABEL_REF)
> +
>  /* 1 if X can be used to represent an object.  */
>  #define OBJECT_P(X)\
>((GET_RTX_CLASS (GET_CODE (X)) & RTX_OBJ_MASK) == RTX_OBJ_RESULT)
>

Re: [PATCH,RFC 0/3] Support for CTF in GCC

[Richard Biener]

On Thu, May 23, 2019 at 10:31 PM Indu Bhagat  wrote:
>
>
>
> On 05/22/2019 02:04 AM, Richard Biener wrote:
>
> The CTF debug information is kept in a CTF container distinct from the 
> frontend
> structures.  HashMaps are used to avoid generation of duplicate CTF and to
> book-keep the generated CTF.
>
> OK.  So I wonder how difficult it is to emit CTF by walking dwarf2outs own
> data structures?  That is, in my view CTF should be emitted by
> dwarf2out_early_finish ()  (which is also the point LTO type/decl debug
> is generated from).  It would be nice to avoid extra bookkeeping data 
> structures
> for CTF since those of DWARF should include all necessary information already.
>
> CTF format has some characteristics which make it necessary to "pre-process"
> the generated CTF data before asm'ing out into a section. E.g. few cases of 
> why
> "pre-processing" CTF is required before asm'ing out :
>  1. CTF types do need to be emitted in "some" order :
> CTF types can have references to other CTF types. This consequently 
> implies
> that the referenced type must appear BEFORE the referring type.
>  2. CTF preamble holds offsets to the various subsections - function info,
> variables, data types and CTF string table. To calculate the offsets, the
> compiler needs to know the size in bytes of these sub-sections.  CTF
> representation for some types like structures, functions, enums have
> variable length of bytes trailing them (depending on the defintion of the
> type).
>  3. CTF variable entries need to be placed in the order of the names.
>
> Because of some of these "features" of the CTF format, the compiler does need
> to do a transition from runtime CTF generated data --> CTF binary data format
> for a clean and readable code.
>
> So, I think the needs are different enough to vouch for an implementation
> segregated from dwarf* codebase.
>
>
> Btw, do I read the CTF document posted to the binutils list (but not
> cross-referenced
> here :/) correctly in that you only want CTF debug for objects defined
> in the file and
> type information for the types refered to from that?  At
>
> Yes. CTF is emitted for types at file-scope and global-scope only.  Types, 
> vars
> at function-scope should be skipped.
>
> dwarf2out_early_finish time
> it isn't fully known which symbols will end up being emitted (and with
> LTO you only
> would know at link time).
>
> In nutshell, I am processing all decl at early_global_decl () time except
> TYPE_DECL (Similar to DWARF, based on the thinking that if they are required
> they will be reached at via other DECL).
> In addition, I process all decl at type_decl () time except function-scope,
> no-name decl, builtins.
>
> Currently, it does look like CTF for possibly to-be-omitted symbols will be
> generated... I assume even DWARF needs to handle this case. Can you point me 
> to
> how DWARF does this ?

It emits the debug information.  DWARF outputs a representation of the source,
not only emitted objects.  We prune some "unused" bits if the user prefers us
to do that but we do not omit information on types or decls that are used in
the source but later eventually optimized away.

> It seems to me that linker support to garbage collect
> unused entries would be the way to go forward (probably easy for the
> declarations
> but not so for the types)?
>
> Hmm, garbage collecting unused types in linker - Let me get back to you on
> this. It does not look easy. Decl should be doable though.

For example DWARF has something like type units that can be refered
to via hashes.  GCC can output those into separate sections and I can
envision outputting separate debug (CTF) sections for each declaration.
The linker could then merge sections for declarations that survived
and pick up all referenced type sections.  Restrictions on ordering
for CTF may make this a bit difficult though, essentially forcing a
separate intermediate "unlinked" format and the linker regenerating
the final one.  OTOH CTF probably simply concatenates data from
different CUs?

Richard.

[PATCH V2] Remove empty loop with assumed finiteness (PR tree-optimization/89713)

[Feng Xue OS]

This version is based on the proposal of Richard. And fix a bug on OpenACC loop 
when this opt is turned on.
Also add some test cases

Feng
-

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 9f0f889..d1c1e3a 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,16 @@
+2019-05-23  Feng Xue  
+
+ PR tree-optimization/89713
+ * doc/invoke.texi (-ffinite-loop): Document new option.
+ * common.opt (-ffinite-loop): New option.
+ * tree-ssa-dce.c (loop_has_true_exits): New function.
+ (mark_stmt_if_obviously_necessary): Mark IFN_GOACC_LOOP
+ calls as neccessary.
+ (find_obviously_necessary_stmts): Use flag to control
+ removal of a loop with assumed finiteness.
+ (eliminate_unnecessary_stmts): Do not delete dead result
+ of IFN_GOACC_LOOP calls.
+
 2019-05-22  David Malcolm  

  PR c++/90462
diff --git a/gcc/common.opt b/gcc/common.opt
index d342c4f..e98a34d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1437,6 +1437,10 @@ ffinite-math-only
 Common Report Var(flag_finite_math_only) Optimization SetByCombined
 Assume no NaNs or infinities are generated.

+ffinite-loop
+Common Report Var(flag_finite_loop) Optimization
+Assume loops are finite if can not be analytically determined.
+
 ffixed-
 Common Joined RejectNegative Var(common_deferred_options) Defer
 -ffixed- Mark  as being unavailable to the compiler.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 6c89843..caa0852 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -412,6 +412,7 @@ Objective-C and Objective-C++ Dialects}.
 -fdevirtualize-at-ltrans  -fdse @gol
 -fearly-inlining  -fipa-sra  -fexpensive-optimizations  -ffat-lto-objects @gol
 -ffast-math  -ffinite-math-only  -ffloat-store  -fexcess-precision=@var{style} 
@gol
+-ffinite-loop @gol
 -fforward-propagate  -ffp-contract=@var{style}  -ffunction-sections @gol
 -fgcse  -fgcse-after-reload  -fgcse-las  -fgcse-lm  -fgraphite-identity @gol
 -fgcse-sm  -fhoist-adjacent-loads  -fif-conversion @gol
@@ -9501,6 +9502,20 @@ that may set @code{errno} but are otherwise free of side 
effects.  This flag is
 enabled by default at @option{-O2} and higher if @option{-Os} is not also
 specified.

+@item -ffinite-loop
+@opindex ffinite-loop
+@opindex fno-finite-loop
+Allow the compiler to assume that if finiteness of a loop can not be
+analytically determined, the loop must be finite. With the assumption, some
+aggressive transformation could be possible, such as removal of this kind
+of empty loop by dead code elimination (DCE).
+
+This option is not turned on by any @option{-O} option since it might result
+in incorrect behaviour for programs that contain seemly finite, but actually
+infinite loop.
+
+The default is @option{-fno-finite-loop}.
+
 @item -ftree-dominator-opts
 @opindex ftree-dominator-opts
 Perform a variety of simple scalar cleanups (constant/copy
diff --git a/gcc/testsuite/g++.dg/tree-ssa/empty-loop.C 
b/gcc/testsuite/g++.dg/tree-ssa/empty-loop.C
new file mode 100644
index 000..e374155
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/empty-loop.C
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-cddce2 -ffinite-loop" } */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+using namespace std;
+
+int foo (vector , list , set , map 
)
+{
+  for (vector::iterator it = v.begin (); it != v.end (); ++it)
+it->length();
+
+  for (list::iterator it = l.begin (); it != l.end (); ++it)
+it->length();
+
+  for (map::iterator it = m.begin (); it != m.end (); ++it)
+it->first + it->second.length();
+
+  for (set::iterator it0 = s.begin (); it0 != s.end(); ++it0)
+for (vector::reverse_iterator it1 = v.rbegin(); it1 != v.rend(); 
++it1)
+  {
+it0->length();
+it1->length();
+  }
+
+  return 0;
+}
+/* { dg-final { scan-tree-dump-not "if" "cddce2"} } */
+
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/dce-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/dce-2.c
new file mode 100644
index 000..ffca49c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/dce-2.c
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-cddce1 -ffinite-loop" } */
+
+typedef struct list {
+char pad[15];
+struct list *next;
+} list;
+
+int data;
+
+list *head, *tail;
+
+int __attribute__((pure)) pfn (int);
+
+int foo (unsigned u, int s)
+{
+  unsigned i;
+  list *p;
+  int j;
+
+  for (i = 0; i < u; i += 2)
+;
+
+  for (p = head; p; p = p->next)
+;
+
+  for (j = data; j & s; j = pfn (j + 3))
+;
+
+  for (p = head; p != tail; p = p->next)
+for (j = data + 1; j > s; j = pfn (j + 2))
+  ;
+
+  return 0;
+}
+/* { dg-final { scan-tree-dump-not "if" "cddce1"} } */
+
diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index 2478219..bb143a3 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -245,6 +245,18 @@ mark_stmt_if_obviously_necessary (gimple *stmt, bool 
aggressive)
  mark_stmt_necessary (stmt, true);
  return;
}
+/* IFN_GOACC_LOOP calls are neccessary in that they 

Re: *ping* Re: [PATCH] PR fortran/89100 Default widths for i, f and g format specifiers in format strings

[Christophe Lyon]

On Thu, 23 May 2019 at 19:21, Steve Kargl
 wrote:
>
> On Thu, May 23, 2019 at 05:26:53PM +0200, Christophe Lyon wrote:
> > On Thu, 23 May 2019 at 15:54, Mark Eggleston
> >  wrote:
> > > >
> > > > The logs contain:
> > > > /gcc/testsuite/gfortran.dg/fmt_f_default_field_width_1.f90:15:11:
> > > > Error: Kind 16 not supported for type REAL at (1)
> > > >
> > > > Christophe
> > >
> > > Apologies, I'd forgotten that kind=16 is not always defined. The
> > > attached patch modifies the test cases to take this into account. I
> > > currently have no means of verifying this.
> > >
> > > Please confirm that this patch solves the problem.
> > >
> >
> > I confirm this patch does fix the problem, thanks
> >
>
> Patch committed as r271573.
>

Hi,

Sorry, I didn't check all the testcases you changed, and this commit
introduces a new failure on arm:
/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:23:23:
Error: Nonnegative width required in format string at (1)
/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:26:23:
Error: Nonnegative width required in format string at (1)
/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:29:23:
Error: Nonnegative width required in format string at (1)
compiler exited with status 1
PASS: gfortran.dg/fmt_f_default_field_width_3.f90   -O   (test for
errors, line 23)
PASS: gfortran.dg/fmt_f_default_field_width_3.f90   -O   (test for
errors, line 26)
PASS: gfortran.dg/fmt_f_default_field_width_3.f90   -O   (test for
errors, line 29)
FAIL: gfortran.dg/fmt_f_default_field_width_3.f90   -O   (test for
errors, line 33)
PASS: gfortran.dg/fmt_f_default_field_width_3.f90   -O  (test for excess errors)

that is, it seems there's no error message generated for line 33.

Christophe

> --
> Steve

[committed] Fix libgomp hsa plugin build on x32 (PR libgomp/90585)

[Jakub Jelinek]

Hi!

The hsa plugin assumes that %lu can be used for uint64_t, which is not
always the case.
Other spots in libgomp use inttypes.h only conditionally and have fallbacks
with casts to unsigned long and using %lu, this patch does the same.
Furthermore, libgomp configury prepares gstdint.h which includes stdint.h
if available, but fills the types in otherwise; libgomp.h already includes
that, this patch includes it in this plugin too (and in nvptx plugin as
well).  Plus some header cleanups, libgomp.h already includes config.h and
gstdint.h.

Tested on x86_64-linux with hsa plugin enabled, including forcefully
undefining HAVE_INTTYPES_H, committed to trunk.

2019-05-24  Jakub Jelinek  

PR libgomp/90585
* plugin/plugin-hsa.c: Include gstdint.h.  Include inttypes.h only if
HAVE_INTTYPES_H is defined.
(print_uint64_t): New typedef.
(PRIu64): Define if HAVE_INTTYPES_H is not defined.
(print_kernel_dispatch, run_kernel): Use PRIu64 macro instead of
"lu", cast uint64_t HSA_DEBUG and fprintf arguments to print_uint64_t.
(release_kernel_dispatch): Likewise.  Cast shadow->debug to uintptr_t
before casting to void *.
* plugin/plugin-nvptx.c: Include gstdint.h instead of stdint.h.
* oacc-mem.c: Don't include config.h nor stdint.h.
* target.c: Don't include config.h.
* oacc-cuda.c: Likewise.
* oacc-host.c: Don't include stdint.h.

--- libgomp/plugin/plugin-hsa.c.jj  2019-01-02 00:11:51.903434368 +0100
+++ libgomp/plugin/plugin-hsa.c 2019-05-24 10:42:11.436041458 +0200
@@ -28,11 +28,14 @@
.  */
 
 #include "config.h"
+#include "gstdint.h"
 #include 
 #include 
 #include 
 #include 
+#ifdef HAVE_INTTYPES_H
 #include 
+#endif
 #include 
 #include 
 #include 
@@ -41,6 +44,13 @@
 #include "gomp-constants.h"
 #include "secure_getenv.h"
 
+#ifdef HAVE_INTTYPES_H
+typedef uint64_t print_uint64_t;
+#else
+#define PRIu64 "lu"
+typedef unsigned long print_uint64_t; 
+#endif
+
 /* As an HSA runtime is dlopened, following structure defines function
pointers utilized by the HSA plug-in.  */
 
@@ -1154,8 +1164,9 @@ create_single_kernel_dispatch (struct ke
 static void
 release_kernel_dispatch (struct GOMP_hsa_kernel_dispatch *shadow)
 {
-  HSA_DEBUG ("Released kernel dispatch: %p has value: %lu (%p)\n", shadow,
-shadow->debug, (void *) shadow->debug);
+  HSA_DEBUG ("Released kernel dispatch: %p has value: %" PRIu64 " (%p)\n",
+shadow, (print_uint64_t) shadow->debug,
+(void *) (uintptr_t) shadow->debug);
 
   hsa_fns.hsa_memory_free_fn (shadow->kernarg_address);
 
@@ -1276,9 +1287,9 @@ print_kernel_dispatch (struct GOMP_hsa_k
   indent_stream (stderr, indent);
   fprintf (stderr, "kernarg_address: %p\n", dispatch->kernarg_address);
   indent_stream (stderr, indent);
-  fprintf (stderr, "object: %lu\n", dispatch->object);
+  fprintf (stderr, "object: %" PRIu64 "\n", (print_uint64_t) dispatch->object);
   indent_stream (stderr, indent);
-  fprintf (stderr, "signal: %lu\n", dispatch->signal);
+  fprintf (stderr, "signal: %" PRIu64 "\n", (print_uint64_t) dispatch->signal);
   indent_stream (stderr, indent);
   fprintf (stderr, "private_segment_size: %u\n",
   dispatch->private_segment_size);
@@ -1286,8 +1297,8 @@ print_kernel_dispatch (struct GOMP_hsa_k
   fprintf (stderr, "group_segment_size: %u\n",
   dispatch->group_segment_size);
   indent_stream (stderr, indent);
-  fprintf (stderr, "children dispatches: %lu\n",
-  dispatch->kernel_dispatch_count);
+  fprintf (stderr, "children dispatches: %" PRIu64 "\n",
+  (print_uint64_t) dispatch->kernel_dispatch_count);
   indent_stream (stderr, indent);
   fprintf (stderr, "omp_num_threads: %u\n",
   dispatch->omp_num_threads);
@@ -1594,8 +1605,8 @@ run_kernel (struct kernel_info *kernel,
hsa_signal_t child_s;
child_s.handle = shadow->children_dispatches[i]->signal;
 
-   HSA_DEBUG ("Waiting for children completion signal: %lu\n",
-  shadow->children_dispatches[i]->signal);
+   HSA_DEBUG ("Waiting for children completion signal: %" PRIu64 "\n",
+  (print_uint64_t) shadow->children_dispatches[i]->signal);
hsa_fns.hsa_signal_load_acquire_fn (child_s);
   }
 
--- libgomp/plugin/plugin-nvptx.c.jj2019-05-20 21:59:18.816737553 +0200
+++ libgomp/plugin/plugin-nvptx.c   2019-05-24 10:40:31.521668336 +0200
@@ -34,6 +34,7 @@
 #define _GNU_SOURCE
 #include "openacc.h"
 #include "config.h"
+#include "gstdint.h"
 #include "libgomp-plugin.h"
 #include "oacc-plugin.h"
 #include "gomp-constants.h"
@@ -42,7 +43,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
--- libgomp/oacc-mem.c.jj   2019-05-20 21:59:18.831737310 +0200
+++ libgomp/oacc-mem.c  2019-05-24 10:44:11.544085774 +0200
@@ -27,11 +27,9 @@
.  */
 
 #include "openacc.h"
-#include 

Re: [PATCH] LWG 2996 add rvalue overloads for shared_ptr aliasing and casting

[Christophe Lyon]

Hi Jonathan,

On Thu, 23 May 2019 at 23:40, Jonathan Wakely  wrote:
>
> * doc/xml/manual/intro.xml: Document LWG DR 2996 change.
> * doc/html/*: Regenerate.
> * include/bits/shared_ptr.h (shared_ptr(shared_ptr&&, T*)): Add
> rvalue aliasing constructor.
> (static_pointer_cast, const_pointer, dynamic_pointer_cast)
> (reinterpret_pointer_cast): Add overloads taking rvalues.
> * include/bits/shared_ptr_base.h (__shared_ptr(__shared_ptr&&, T*)):
> Add rvalue aliasing constructor.
> * testsuite/20_util/shared_ptr/casts/1.cc: Change "compile" test to
> "run" and check return values as well as types.
> * testsuite/20_util/shared_ptr/casts/reinterpret.cc: Likewise.
> * testsuite/20_util/shared_ptr/casts/rval.cc: New test.
> * testsuite/20_util/shared_ptr/cons/alias-rval.cc: New test.
> * testsuite/20_util/shared_ptr/cons/alias.cc: Remove unused return
> values.
>
> Tested powerpc64le-linux, committed to trunk.
>

As you may have noticed, the new test alias-rval.cc fails on arm and
aarch64, and other targets according to gcc-testresults@

Christophe

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Thu, May 23, 2019 at 10:33:28PM +, Joseph Myers wrote:
> On Tue, 21 May 2019, Segher Boessenkool wrote:
> 
> > > I think having author names and email addresses is a basic requirement of 
> > > any reasonable repository conversion
> > 
> > Yes, and they should be the same as they were in the original repository.
> 
> That's what the "changelogs" feature in reposurgeon does, when the commit 
> that made the change also added a ChangeLog entry.
> 
> In the case where the commit didn't add a ChangeLog entry, a name and 
> email address from an author map is the best we can practically do (and I 

IMO the best we can do is use what we already have: what CVS or SVN used
as the committer identity.  *That* info is *correct* at least.

In many cases we can glance someone's real name from the changelog, sure.
People looking up things can trivially do that, and with much better
accuracy than any script can.  In some other cases you cannot, no matter
how hard you try.

> think it's much better than having something that never was a valid name 
> and email address for author or committer at all).

The fields in Git are just called "Author" and "Commit".  Not "real name"
or "email address" or anything like that.  It is just text.  Git does not
require anything specific about what you put here.


Segher

Re: [PATCH] Make any_cast compare typeinfo as well as function pointers

[Christophe Lyon]

Hi Jonathan,

On Thu, 23 May 2019 at 16:13, Jonathan Wakely  wrote:
>
> It's possible for the function pointer comparison to fail even though
> the type is correct, because the function could be defined multiple
> times with different addresses when shared libraries are in use.
>
> Retain the function pointer check for the common case where the check
> succeeds, but compare typeinfo (if RTTI is enabled) if the first check
> fails.
>
> * include/experimental/any (__any_caster): Use RTTI if comparing
> addresses fails, to support non-unique addresses in shared libraries.
> * include/std/any (__any_caster): Likewise.
>
> Tested powerpc64le-linux, committed to trunk, backports to follow.
>
>

It seems OK on trunk, but on gcc-7/gcc-8 branches I see:
/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc:20:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/experimental/any:
In instantiation of '_ValueType
std::experimental::fundamentals_v1::any_cast(const
std::experimental::fundamentals_v1::any&) [with _ValueType = int&]':
/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc:28:
required from here
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/experimental/any:358:
error: binding reference of type 'int&' to 'const int' discards
qualifiers
compiler exited with status 1
FAIL: experimental/any/misc/any_cast_neg.cc  (test for errors, line 357)
FAIL: experimental/any/misc/any_cast_neg.cc (test for excess errors)

on arm/aarch64

Christophe

[PATCH] Fix PR90607

[Richard Biener]

I failed to notice gcc.dg/pr53265.c FAIL after the loop distribution
change.  The following amends the testcase with the new expected
diagnostic and adjusts loop distribution to assign a more sensible
location to generated library calls.

Bootstrap / regtest in progress on x86_64-unknwon-linux-gnu.

Richard.

2019-05-24  Richard Biener  

PR testsuite/90607
* tree-loop-distribution.c (struct partition): Add location
member.
(partition_alloc): Initialize all fields.
(generate_memset_builtin): Use the location recorded in the
partition for the generated call.
(generate_memcpy_builtin): Likewise.
(classify_partition): Record the location of a single store
as location for the partition.

* gcc.dg/pr53265.c: Amend for new expected diagnostic.

Index: gcc/tree-loop-distribution.c
===
--- gcc/tree-loop-distribution.c(revision 271594)
+++ gcc/tree-loop-distribution.c(working copy)
@@ -636,6 +636,7 @@ struct partition
   bitmap stmts;
   /* True if the partition defines variable which is used outside of loop.  */
   bool reduction_p;
+  location_t loc;
   enum partition_kind kind;
   enum partition_type type;
   /* Data references in the partition.  */
@@ -653,7 +654,9 @@ partition_alloc (void)
   partition *partition = XCNEW (struct partition);
   partition->stmts = BITMAP_ALLOC (NULL);
   partition->reduction_p = false;
+  partition->loc = UNKNOWN_LOCATION;
   partition->kind = PKIND_NORMAL;
+  partition->type = PTYPE_PARALLEL;
   partition->datarefs = BITMAP_ALLOC (NULL);
   return partition;
 }
@@ -1028,6 +1031,7 @@ generate_memset_builtin (struct loop *lo
 
   fn = build_fold_addr_expr (builtin_decl_implicit (BUILT_IN_MEMSET));
   fn_call = gimple_build_call (fn, 3, mem, val, nb_bytes);
+  gimple_set_location (fn_call, partition->loc);
   gsi_insert_after (, fn_call, GSI_CONTINUE_LINKING);
   fold_stmt ();
 
@@ -1072,6 +1076,7 @@ generate_memcpy_builtin (struct loop *lo
  false, GSI_CONTINUE_LINKING);
   fn = build_fold_addr_expr (builtin_decl_implicit (kind));
   fn_call = gimple_build_call (fn, 3, dest, src, nb_bytes);
+  gimple_set_location (fn_call, partition->loc);
   gsi_insert_after (, fn_call, GSI_CONTINUE_LINKING);
   fold_stmt ();
 
@@ -1706,6 +1711,8 @@ classify_partition (loop_p loop, struct
   if (!find_single_drs (loop, rdg, partition, _st, _ld))
 return;
 
+  partition->loc = gimple_location (DR_STMT (single_st));
+
   /* Classify the builtin kind.  */
   if (single_ld == NULL)
 classify_builtin_st (loop, partition, single_st);
Index: gcc/testsuite/gcc.dg/pr53265.c
===
--- gcc/testsuite/gcc.dg/pr53265.c  (revision 271594)
+++ gcc/testsuite/gcc.dg/pr53265.c  (working copy)
@@ -38,7 +38,8 @@ fn3 (void)
   for (i = 0; i < (int) (sizeof (a) / sizeof (a[0])); i++) /* { dg-message 
"note: within this loop" } */
 {
   c[i + 8] = b[i]; /* { dg-warning "8 invokes undefined behavior" } */
-  a[i + 8] = b[i + 8];
+   /* { dg-warning "out of the bounds" "" { target *-*-* } .-1 } */
+  a[i + 8] = b[i + 8]; /* { dg-warning "out of the bounds" } */
 }
   bar (a);
   bar (c);

Re: [PATCH} rs6000: Enable PC-relative by default and test

[Segher Boessenkool]

Hi,

On Thu, May 23, 2019 at 04:15:26PM -0500, Bill Schmidt wrote:
> This is a short patch that enables PC-relative support by default, and 
> provides a
> test case to ensure that the correct .localentry name,1 directive is produced 
> iff
> PC-relative support is enabled.

> 2019-05-23  Bill Schmidt  
> 
>   * gcc.target/powerpc/pcrel-detect-1.c: New file.

That's a very strange file name for what it tests, then.  Improve it?

> diff --git a/gcc/testsuite/gcc.target/powerpc/pcrel-detect-1.c 
> b/gcc/testsuite/gcc.target/powerpc/pcrel-detect-1.c
> new file mode 100644
> index 000..8e0e9053dc7
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pcrel-detect-1.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile { target { powerpc*-*-* } } } */

Just

/* { dg-do compile } */

is enough.

> +/* { dg-require-effective-target powerpc_elfv2 } */
> +/* { dg-options "-O3 -mdejagnu-cpu=future" } */

Please use -O2 if there is not specific reason for -O3.

Okay with those things fixed somehow.  Thanks,


Segher

[C++ PATCH] Fix decltype on a trivial dtor with -flifetime-dse (PR c++/90598)

[Jakub Jelinek]

Hi!

The following testcase is rejected, because we determine B as void &
rather than the expected void when -flifetime-dse.

I'd say the main problem is premature folding, that we lower the trivial
destructor already at parsing time, rather than cp_fold, I'd say that goes
against the intentions of the late folding.

That said, these patch attempts to address this differently (in a way that
would also be backportable).

With -fno-lifetime-dse, when the test passes, the trivial destructor is
folded into (void)  and lvalue_kind returns clk_none for that, so
finish_decltype_type returns just void for it.

With -flifetime-dse, the trivial destructor is folded into a void mode
MODIFY_EXPR instance = {CLOBBER} and lvalue_kind returns clk_ordinary in
that case, so finish_decltype_type then applies the rules and makes void &
out of it.

The first patch fixes this by forcibly wrapping the MODIFY_EXPR into a void
type NOP_EXPR, so that lvalue_kind still considers it clk_none.

The second patch fixes that by special casing void type MODIFY_EXPR, I
believe if we have void type MODIFY_EXPR, then it can't be an lvalue.

Another option would be to tweak finish_decltype_type to special case
VOID_TYPE_P and never try to create a reference for it (which is not valid
in C++).

Both patches successfully bootstrapped/regtested on x86_64-linux and
i686-linux.

2019-05-24  Jakub Jelinek  

PR c++/90598
* call.c (build_trivial_dtor_call): Wrap MODIFY_EXPR for
-flifetime-dse into void_type_node NOP_EXPR.

* g++.dg/cpp0x/pr90598.C: New test.

--- gcc/cp/call.c.jj2019-05-23 12:57:16.658493722 +0200
+++ gcc/cp/call.c   2019-05-23 18:37:09.570874611 +0200
@@ -7995,8 +7995,8 @@ build_trivial_dtor_call (tree instance)
 
   /* A trivial destructor should still clobber the object.  */
   tree clobber = build_clobber (TREE_TYPE (instance));
-  return build2 (MODIFY_EXPR, void_type_node,
-instance, clobber);
+  return build1 (NOP_EXPR, void_type_node,
+build2 (MODIFY_EXPR, void_type_node, instance, clobber));
 }
 
 /* Subroutine of the various build_*_call functions.  Overload resolution
--- gcc/testsuite/g++.dg/cpp0x/pr90598.C.jj 2019-05-23 18:39:37.034464509 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/pr90598.C2019-05-23 18:39:05.471980348 
+0200
@@ -0,0 +1,8 @@
+// PR c++/90598
+// { dg-do compile { target c++11 } }
+
+struct A {};
+using B = decltype(A ().~A ());
+template  struct C;
+template <> struct C {};
+C t;

Jakub
2019-05-24  Jakub Jelinek  

PR c++/90598
* tree.c (lvalue_kind): Return clk_none for MODIFY_EXPR with
VOID_TYPE_P.

* g++.dg/cpp0x/pr90598.C: New test.

--- gcc/cp/tree.c.jj2019-05-20 21:59:19.886720194 +0200
+++ gcc/cp/tree.c   2019-05-23 23:37:42.335181291 +0200
@@ -245,6 +245,10 @@ lvalue_kind (const_tree ref)
   return clk_ordinary;
 
 case MODIFY_EXPR:
+  if (TREE_TYPE (ref) && VOID_TYPE_P (TREE_TYPE (ref)))
+   return clk_none;
+  return clk_ordinary;
+
 case TYPEID_EXPR:
   return clk_ordinary;
 
--- gcc/testsuite/g++.dg/cpp0x/pr90598.C.jj 2019-05-23 18:39:37.034464509 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/pr90598.C2019-05-23 18:39:05.471980348 
+0200
@@ -0,0 +1,8 @@
+// PR c++/90598
+// { dg-do compile { target c++11 } }
+
+struct A {};
+using B = decltype(A ().~A ());
+template  struct C;
+template <> struct C {};
+C t;

Re: [PATCH] Handle loop fields in IPA ICF (PR ipa/90555).

[Jakub Jelinek]

On Fri, May 24, 2019 at 09:48:03AM +0200, Martin Liška wrote:
> gcc/ChangeLog:
> 
> 2019-05-23  Martin Liska  
> 
>   PR ipa/90555
>   * ipa-icf-gimple.c (func_checker::compare_loops): New function.
>   * ipa-icf-gimple.h (func_checker::compare_loops): Likewise.
>   * ipa-icf.c (sem_function::equals_private): Use compare_loops.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-05-23  Martin Liska  
> 
>   PR ipa/90555
>   * gcc.dg/ipa/pr90555.c: New test.

> @@ -605,6 +606,45 @@ func_checker::compare_variable_decl (tree t1, tree t2)
>return return_with_debug (ret);
>  }
>  
> +/* Compare significant loop information.  */
> +bool
> +func_checker::compare_loops (void)
> +{
> +  struct loop *loop;
> +
> +  auto_vec  loops1;
> +  auto_vec  loops2;
> +
> +  FOR_EACH_LOOP_FN (DECL_STRUCT_FUNCTION (m_source_func_decl), loop, 0)
> +loops1.safe_push (loop);
> +
> +  FOR_EACH_LOOP_FN (DECL_STRUCT_FUNCTION (m_target_func_decl), loop, 0)
> +loops2.safe_push (loop);
> +
> +  gcc_assert (loops1.length () == loops2.length ());
> +
> +  for (unsigned i = 0; i < loops1.length (); i++)

I wonder how likely/unlikely it is that the loops will be ordered the same
by the iterators.  If they are the same always, then perhaps it would be
better to avoid the temporary vectors, and just do one FOR_EACH_LOOP_FN
with another manual loop_iterator use in sync with that.
If it isn't guaranteed they are ordered the same, then I think we need to
match the loops by the corresponding loop header and perhaps also verify
loop latch and other basic blocks in the loop?

> +{
> +  struct loop *l1 = loops1[i];
> +  struct loop *l2 = loops2[i];
> +  if (l1->simdlen != l2->simdlen)
> + return return_false_with_msg ("simdlen");
> +  if (l1->safelen != l2->safelen)
> + return return_false_with_msg ("safelen");
> +  if (l1->can_be_parallel != l2->can_be_parallel)
> + return return_false_with_msg ("can_be_parallel");
> +  if (l1->dont_vectorize != l2->dont_vectorize)
> + return return_false_with_msg ("dont_vectorize");
> +  if (l1->force_vectorize != l2->force_vectorize)
> + return return_false_with_msg ("force_vectorize");
> +  if (l1->unroll != l2->unroll)
> + return return_false_with_msg ("unroll");
> +  if (!compare_variable_decl (l1->simduid, l2->simduid))
> + return return_false_with_msg ("simduid");

The above looks reasonable if we are guaranteed we are talking about a loop
corresponding between the two functions.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/ipa/pr90555.c
> @@ -0,0 +1,67 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fopenmp-simd -O2 -mavx512f -fdump-ipa-icf" } */
> +/* { dg-do compile { target i?86-*-* x86_64-*-* } } */

Please don't use two dg-do compile directives, drop the first line,
move the third line to first one.

Jakub

Re: [PATCH] PR c/86407 - Add option to ignore fndecl attributes on function pointers

[Richard Biener]

On Thu, 23 May 2019, Alex Henrie wrote:

> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86407#c6
> ---
>  gcc/c-family/c.opt |  4 
>  gcc/c/c-decl.c |  4 +++-
>  gcc/config/i386/i386-options.c | 12 ++--
>  gcc/testsuite/c-c++-common/pr86407-1.c | 23 +++
>  gcc/testsuite/c-c++-common/pr86407-2.c | 25 +
>  5 files changed, 65 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/pr86407-1.c
>  create mode 100644 gcc/testsuite/c-c++-common/pr86407-2.c
> 
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index 046d489f7eb..3b99c96e53d 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -776,6 +776,10 @@ Wsizeof-array-argument
>  C ObjC C++ ObjC++ Var(warn_sizeof_array_argument) Warning Init(1)
>  Warn when sizeof is applied on a parameter declared as an array.
>  
> +Wstrict-function-attributes
> +C C++ Var(warn_strict_function_attributes) Init(1) Warning
> +Warn when function definition attributes are applied to function pointers.
> +
>  Wstringop-overflow
>  C ObjC C++ LTO ObjC++ Warning Alias(Wstringop-overflow=, 2, 0)
>  Warn about buffer overflow in string manipulation functions like memcpy
> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> index 181a8c2e9aa..427d573c8d3 100644
> --- a/gcc/c/c-decl.c
> +++ b/gcc/c/c-decl.c
> @@ -6192,7 +6192,9 @@ grokdeclarator (const struct c_declarator *declarator,
> inner_decl = inner_decl->declarator;
>   if (inner_decl->kind == cdk_id)
> attr_flags |= (int) ATTR_FLAG_DECL_NEXT;
> - else if (inner_decl->kind == cdk_function)
> + else if (inner_decl->kind == cdk_function
> +  || (inner_decl->kind == cdk_pointer
> +  && TREE_CODE (type) == FUNCTION_TYPE))
> attr_flags |= (int) ATTR_FLAG_FUNCTION_NEXT;
>   else if (inner_decl->kind == cdk_array)
> attr_flags |= (int) ATTR_FLAG_ARRAY_NEXT;
> diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
> index 0f236626005..6b50f143b05 100644
> --- a/gcc/config/i386/i386-options.c
> +++ b/gcc/config/i386/i386-options.c
> @@ -3489,8 +3489,16 @@ ix86_handle_fndecl_attribute (tree *node, tree name, 
> tree args, int,
>  {
>if (TREE_CODE (*node) != FUNCTION_DECL)
>  {
> -  warning (OPT_Wattributes, "%qE attribute only applies to functions",
> -   name);
> +  if (FUNCTION_POINTER_TYPE_P (TREE_TYPE (*node)))
> + {
> +   warning (OPT_Wstrict_function_attributes,
> +"%qE attribute only applies to function definitions", name);
> + }
> +  else
> + {
> +   warning (OPT_Wattributes,
> +"%qE attribute only applies to functions", name);
> + }

I'm not sure we really need a new warning for this.

>*no_add_attrs = true;
>  }
>  
> diff --git a/gcc/testsuite/c-c++-common/pr86407-1.c 
> b/gcc/testsuite/c-c++-common/pr86407-1.c
> new file mode 100644
> index 000..37993d8c051
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/pr86407-1.c
> @@ -0,0 +1,23 @@
> +/* PR c/86407 */
> +/* Test a function attribute that is not a calling convention and does not
> +   affect the function type. There should be no warnings when using the
> +   attribute on a function declaration, function pointer, or function pointer
> +   typedef, but there should be a warning when using the attribute on
> +   non-function-pointer variables and typedefs. */
> +
> +/* { dg-options "-Wstrict-function-attributes -Wno-ignored-attributes" } */
> +
> +int __attribute__((__ms_hook_prologue__)) func(); /* no warnings */
> +

But this is a declaration?

> +int (__attribute__((__ms_hook_prologue__)) *func_ptr)(); /* { dg-warning 
> "'ms_hook_prologue' attribute only applies to function definitions" } */
> +
> +typedef int (__attribute__((__ms_hook_prologue__)) *FUNC_PTR)(); /* { 
> dg-warning "'ms_hook_prologue' attribute only applies to function 
> definitions" } */
> +
> +int __attribute__((__ms_hook_prologue__)) *var_ptr; /* { dg-warning 
> "'ms_hook_prologue' attribute only applies to functions" } */
> +
> +typedef int __attribute__((__ms_hook_prologue__)) *VAR_PTR; /* { dg-warning 
> "'ms_hook_prologue' attribute only applies to functions" } */
> +
> +int main(int argc, char **argv)
> +{
> +return 0;
> +}
> diff --git a/gcc/testsuite/c-c++-common/pr86407-2.c 
> b/gcc/testsuite/c-c++-common/pr86407-2.c
> new file mode 100644
> index 000..6840b0180dd
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/pr86407-2.c
> @@ -0,0 +1,25 @@
> +/* PR c/86407 */
> +/* Test a function attribute that is not a calling convention and does not
> +   affect the function type. A function pointer without the attribute may 
> point
> +   to a function with the attribute and vice-versa. */
> +
> +/* { dg-options "-Wno-strict-function-attributes -Wno-ignored-attributes" } 
> */
> +
> +int 

Re: [PATCH] Move VEC_PERM_EXPR folding to match.pd

[Richard Biener]

On Fri, 24 May 2019, Bernhard Reutner-Fischer wrote:

> On 20 May 2019 12:31:46 CEST, Richard Biener  wrote:
> 
> >
> >So the following is what I have applied.
> 
> Typo in the guard?
> 
> s/GCC_VEC_PERN_INDICES_H/GCC_VEC_PERM_INDICES_H/
> 
> ?

Yeah, but copied that from vec-perm-indices.h ... (otherwise
it wouldn't work obviously)

Richard.

> I.e. not pern but perm, with an 'M'
> thanks,
> 
> >Bootstrapped / tested on x86_64-unknown-linux-gnu.
> >
> >Richard.
> >
> >2019-05-20  Richard Biener  
> >
> > * gimple-match-head.c: Include vec-perm-indices.h.
> > * generic-match-head.c: Likewise.
> > * fold-const.h (fold_vec_perm): Declare when vec-perm-indices.h
> > is included.
> 
> 
> >Index: gcc/fold-const.h
> >===
> >--- gcc/fold-const.h (revision 271320)
> >+++ gcc/fold-const.h (working copy)
> >@@ -100,6 +100,9 @@ extern tree fold_bit_and_mask (tree, tre
> >tree, enum tree_code, tree, tree,
> >tree, enum tree_code, tree, tree, tree *);
> > extern tree fold_read_from_constant_string (tree);
> >+#if GCC_VEC_PERN_INDICES_H
> >+extern tree fold_vec_perm (tree, tree, tree, const vec_perm_indices
> >&);
> >+#endif
> 
> 

-- 
Richard Biener 
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany;
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)

Re: Add GCC support to ENQCMD.

[Uros Bizjak]

On Fri, May 24, 2019 at 9:43 AM Uros Bizjak  wrote:
>
> On Fri, May 24, 2019 at 7:16 AM Hongtao Liu  wrote:
> >
> > Hi Uros and all:
> >   This patch is about to enable support for ENQCMD(Enqueue Command)
> > which will be in Willow Cove.
> >   There are two instructions for ENQCMD: ENQCMD and ENQCMDS. More
> > details please refer to
> > https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
> >
> >   Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
> >
> > gcc/ChangeLog
> > 2019-01-23  Xuepeng Guo  
> >
> > * common/config/i386/i386-common.c
> > (OPTION_MASK_ISA_ENQCMD_SET,
> > OPTION_MASK_ISA_ENQCMD_UNSET): New macros.
> > (ix86_handle_option): Handle -menqcmd.
> > * config.gcc (enqcmdintrin.h): New header file.
> > * config/i386/cpuid.h (bit_ENQCMD): New bit.
> > * config/i386/driver-i386.c (host_detect_local_cpu): Handle
> > -menqcmd.
> > * config/i386/i386-builtin-types.def ((INT, PVOID, PCVOID)): New
> > function type.
> > * config/i386/i386-builtin.def (__builtin_ia32_enqcmd,
> > __builtin_ia32_enqcmds): New builtins.
> > * config/i386/i386-c.c (__ENQCMD__): New macro.
> > * config/i386/i386-option.c (ix86_target_string): Add
> > -menqcmd.
> > (ix86_valid_target_attribute_inner_p): Likewise.
> > * config/i386/i386-expand.c
> > (ix86_expand_builtin): Expand IX86_BUILTIN_ENQCMD and
> > IX86_BUILTIN_ENQCMDS.
> > * config/i386/i386.h (TARGET_ENQCMD): New.
> > * config/i386/i386.md (UNSPECV_ENQCMD, UNSPECV_ENQCMDS): New.
> > (@enqcmd_): New insn pattern.
> > (movdir64b_): Parameterize to enable share expansion code
> > with ENQCMD in function ix86_expand_builtin.
> > * config/i386/i386.opt: Add -menqcmd.
> > * config/i386/immintrin.h: Include enqcmdintrin.h.
> > * config/i386/enqcmdintrin.h: New intrinsic file.
> > * doc/invoke.texi: Add -menqcmd.
> >
> > gcc/testsuite/ChangeLog
> >
> > 2019-01-23  Xuepeng Guo  
> >
> > * gcc.target/i386/enqcmd.c: New test.
> > * gcc.target/i386/enqcmds.c: Likewise.
> > * g++.dg/other/i386-2.C: Add -menqcmd.
> > * g++.dg/other/i386-3.C: Likewise.
> > * gcc.target/i386/sse-12.c: Likewise.
> > * gcc.target/i386/sse-13.c: Likewise.
> > * gcc.target/i386/sse-14.c: Likewise.
> > * gcc.target/i386/sse-23.c: Likewise.
>
> OK for mainline with a small fix below.
>
> Thanks,
> Uros.
>
> @@ -20321,7 +20325,7 @@
>"movdiri\t{%1, %0|%0, %1}"
>[(set_attr "type" "other")])
>
> -(define_insn "movdir64b_"
> +(define_insn "@movdir64b"
>[(unspec_volatile:XI [(match_operand:P 0 "register_operand" "r")
>   (match_operand:XI 1 "memory_operand")]
> UNSPECV_MOVDIR64B)]
>
> No need to remove the underscore in the above name.

+  emit_insn (gen_movdir64b (GET_MODE (op0), op0, op1));

You can just use Pmode instead of GET_MODE here ...

+  if (fcode == IX86_BUILTIN_ENQCMD)
+pat = gen_enqcmd (UNSPECV_ENQCMD, GET_MODE (op0), op0, op1);

... here ...

+  else
+pat = gen_enqcmd (UNSPECV_ENQCMDS, GET_MODE (op0), op0, op1);

... and here.

[PATCH] Handle loop fields in IPA ICF (PR ipa/90555).

[Martin Liška]

Hi.

The patch is about more fine comparison of loop fields that
are mentioned in the PR.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2019-05-23  Martin Liska  

PR ipa/90555
* ipa-icf-gimple.c (func_checker::compare_loops): New function.
* ipa-icf-gimple.h (func_checker::compare_loops): Likewise.
* ipa-icf.c (sem_function::equals_private): Use compare_loops.

gcc/testsuite/ChangeLog:

2019-05-23  Martin Liska  

PR ipa/90555
* gcc.dg/ipa/pr90555.c: New test.
---
 gcc/ipa-icf-gimple.c   | 40 ++
 gcc/ipa-icf-gimple.h   |  3 ++
 gcc/ipa-icf.c  |  3 ++
 gcc/testsuite/gcc.dg/ipa/pr90555.c | 67 ++
 4 files changed, 113 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr90555.c


diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c
index 25284936bc3..4d4e4c7c350 100644
--- a/gcc/ipa-icf-gimple.c
+++ b/gcc/ipa-icf-gimple.c
@@ -37,6 +37,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "ipa-utils.h"
 #include "tree-eh.h"
 #include "builtins.h"
+#include "cfgloop.h"
 
 #include "ipa-icf-gimple.h"
 
@@ -605,6 +606,45 @@ func_checker::compare_variable_decl (tree t1, tree t2)
   return return_with_debug (ret);
 }
 
+/* Compare significant loop information.  */
+bool
+func_checker::compare_loops (void)
+{
+  struct loop *loop;
+
+  auto_vec  loops1;
+  auto_vec  loops2;
+
+  FOR_EACH_LOOP_FN (DECL_STRUCT_FUNCTION (m_source_func_decl), loop, 0)
+loops1.safe_push (loop);
+
+  FOR_EACH_LOOP_FN (DECL_STRUCT_FUNCTION (m_target_func_decl), loop, 0)
+loops2.safe_push (loop);
+
+  gcc_assert (loops1.length () == loops2.length ());
+
+  for (unsigned i = 0; i < loops1.length (); i++)
+{
+  struct loop *l1 = loops1[i];
+  struct loop *l2 = loops2[i];
+  if (l1->simdlen != l2->simdlen)
+	return return_false_with_msg ("simdlen");
+  if (l1->safelen != l2->safelen)
+	return return_false_with_msg ("safelen");
+  if (l1->can_be_parallel != l2->can_be_parallel)
+	return return_false_with_msg ("can_be_parallel");
+  if (l1->dont_vectorize != l2->dont_vectorize)
+	return return_false_with_msg ("dont_vectorize");
+  if (l1->force_vectorize != l2->force_vectorize)
+	return return_false_with_msg ("force_vectorize");
+  if (l1->unroll != l2->unroll)
+	return return_false_with_msg ("unroll");
+  if (!compare_variable_decl (l1->simduid, l2->simduid))
+	return return_false_with_msg ("simduid");
+}
+
+  return true;
+}
 
 /* Function visits all gimple labels and creates corresponding
mapping between basic blocks and labels.  */
diff --git a/gcc/ipa-icf-gimple.h b/gcc/ipa-icf-gimple.h
index 0035db32e66..0fb0744d912 100644
--- a/gcc/ipa-icf-gimple.h
+++ b/gcc/ipa-icf-gimple.h
@@ -226,6 +226,9 @@ public:
   /* Verifies that trees T1 and T2 do correspond.  */
   bool compare_variable_decl (tree t1, tree t2);
 
+  /* Compare significant loop information.  */
+  bool compare_loops (void);
+
   /* Return true if types are compatible for polymorphic call analysis.
  COMPARE_PTR indicates if polymorphic type comparsion should be
  done for pointers, too.  */
diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index 074181491da..ba5121f2198 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -926,6 +926,9 @@ sem_function::equals_private (sem_item *item)
 if (!compare_phi_node (bb_sorted[i]->bb, m_compared_func->bb_sorted[i]->bb))
   return return_false_with_msg ("PHI node comparison returns false");
 
+  if (!m_checker->compare_loops ())
+return return_false_with_msg ("loops are different");
+
   return result;
 }
 
diff --git a/gcc/testsuite/gcc.dg/ipa/pr90555.c b/gcc/testsuite/gcc.dg/ipa/pr90555.c
new file mode 100644
index 000..a9c751cd63c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr90555.c
@@ -0,0 +1,67 @@
+/* { dg-do compile } */
+/* { dg-options "-fopenmp-simd -O2 -mavx512f -fdump-ipa-icf" } */
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+
+#define N 1024
+int a[N];
+
+void
+test_simdlen1 (void)
+{
+  int i;
+  #pragma omp simd simdlen (4)
+  for (i = 0; i < N; ++i)
+a[i] = a[i] + 1;
+}
+
+void
+test_simdlen2 (void)
+{
+  int i;
+  #pragma omp simd simdlen (8)
+  for (i = 0; i < N; ++i)
+a[i] = a[i] + 1;
+}
+
+void
+test_safelen1 (void)
+{
+  int i;
+  #pragma omp simd safelen (4)
+  for (i = 0; i < N; ++i)
+a[i] = a[i] + 1;
+}
+
+void
+test_safelen2 (void)
+{
+  int i;
+  #pragma omp simd safelen (8)
+  for (i = 0; i < N; ++i)
+a[i] = a[i] + 1;
+}
+
+int d[1024];
+
+int
+test_simduid1 (int j, int b)
+{
+  int l, c = 0;
+#pragma omp simd reduction(+: c)
+  for (l = 0; l < b; ++l)
+c += d[j + l];
+  return c;
+}
+
+int
+test_simduid2 (int j, int b)
+{
+  int l, c2 = 0;
+#pragma omp simd reduction(+: c2)
+  for (l = 0; l < b; ++l)
+c2 += d[j + l];
+  return c2;
+}
+
+/* { dg-final { 

[PATCH, x86, testsuite] Two tests that need to be native TLS?

[Iain Sandoe]

Hi Uros,

The following two tests fail on Darwin, which is an emulated TLS target.
ISTM that the tests really required native support, so that the right fix
is to require that. (I can skip them for Darwin, if this isn’t the right 
solution).

OK?

thanks
Iain

gcc/testsuite/

* gcc.target/i386/pr86257.c: Require native TLS support.
* gcc.target/i386/stack-prot-sym.c: Likewise.

diff --git a/gcc/testsuite/gcc.target/i386/pr86257.c 
b/gcc/testsuite/gcc.target/i386/pr86257.c
index 07fbba9..bc758c2 100644
--- a/gcc/testsuite/gcc.target/i386/pr86257.c
+++ b/gcc/testsuite/gcc.target/i386/pr86257.c
@@ -1,6 +1,6 @@
 /* { dg-require-effective-target lp64 } */
 /* { dg-require-effective-target fpic } */
-/* { dg-require-effective-target tls } */
+/* { dg-require-effective-target tls_native } */
 /* { dg-options "-g -fPIC -mtls-dialect=gnu" } */
 
 __thread int i;
diff --git a/gcc/testsuite/gcc.target/i386/stack-prot-sym.c 
b/gcc/testsuite/gcc.target/i386/stack-prot-sym.c
index 7f63424..dcd7cbd 100644
--- a/gcc/testsuite/gcc.target/i386/stack-prot-sym.c
+++ b/gcc/testsuite/gcc.target/i386/stack-prot-sym.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target tls_native } */
 /* { dg-options "-O2 -fstack-protector-all -mstack-protector-guard=tls 
-mstack-protector-guard-reg=gs -mstack-protector-guard-symbol=my_guard" } */
 
 void f(void) { }

Re: Add GCC support to ENQCMD.

[Uros Bizjak]

On Fri, May 24, 2019 at 7:16 AM Hongtao Liu  wrote:
>
> Hi Uros and all:
>   This patch is about to enable support for ENQCMD(Enqueue Command)
> which will be in Willow Cove.
>   There are two instructions for ENQCMD: ENQCMD and ENQCMDS. More
> details please refer to
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
>
>   Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
>
> gcc/ChangeLog
> 2019-01-23  Xuepeng Guo  
>
> * common/config/i386/i386-common.c
> (OPTION_MASK_ISA_ENQCMD_SET,
> OPTION_MASK_ISA_ENQCMD_UNSET): New macros.
> (ix86_handle_option): Handle -menqcmd.
> * config.gcc (enqcmdintrin.h): New header file.
> * config/i386/cpuid.h (bit_ENQCMD): New bit.
> * config/i386/driver-i386.c (host_detect_local_cpu): Handle
> -menqcmd.
> * config/i386/i386-builtin-types.def ((INT, PVOID, PCVOID)): New
> function type.
> * config/i386/i386-builtin.def (__builtin_ia32_enqcmd,
> __builtin_ia32_enqcmds): New builtins.
> * config/i386/i386-c.c (__ENQCMD__): New macro.
> * config/i386/i386-option.c (ix86_target_string): Add
> -menqcmd.
> (ix86_valid_target_attribute_inner_p): Likewise.
> * config/i386/i386-expand.c
> (ix86_expand_builtin): Expand IX86_BUILTIN_ENQCMD and
> IX86_BUILTIN_ENQCMDS.
> * config/i386/i386.h (TARGET_ENQCMD): New.
> * config/i386/i386.md (UNSPECV_ENQCMD, UNSPECV_ENQCMDS): New.
> (@enqcmd_): New insn pattern.
> (movdir64b_): Parameterize to enable share expansion code
> with ENQCMD in function ix86_expand_builtin.
> * config/i386/i386.opt: Add -menqcmd.
> * config/i386/immintrin.h: Include enqcmdintrin.h.
> * config/i386/enqcmdintrin.h: New intrinsic file.
> * doc/invoke.texi: Add -menqcmd.
>
> gcc/testsuite/ChangeLog
>
> 2019-01-23  Xuepeng Guo  
>
> * gcc.target/i386/enqcmd.c: New test.
> * gcc.target/i386/enqcmds.c: Likewise.
> * g++.dg/other/i386-2.C: Add -menqcmd.
> * g++.dg/other/i386-3.C: Likewise.
> * gcc.target/i386/sse-12.c: Likewise.
> * gcc.target/i386/sse-13.c: Likewise.
> * gcc.target/i386/sse-14.c: Likewise.
> * gcc.target/i386/sse-23.c: Likewise.

OK for mainline with a small fix below.

Thanks,
Uros.

@@ -20321,7 +20325,7 @@
   "movdiri\t{%1, %0|%0, %1}"
   [(set_attr "type" "other")])

-(define_insn "movdir64b_"
+(define_insn "@movdir64b"
   [(unspec_volatile:XI [(match_operand:P 0 "register_operand" "r")
  (match_operand:XI 1 "memory_operand")]
UNSPECV_MOVDIR64B)]

No need to remove the underscore in the above name.

Re: GCC 9 backports

[Martin Liška]

Hi.

I'm sending one more patch that I've tested.

Martin
>From 279c24c2af259c8f3e7668056fcb707bc3c03ad2 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 23 May 2019 10:12:01 +
Subject: [PATCH] Backport r271548

gcc/ChangeLog:

2019-05-23  Martin Liska  

	PR sanitizer/90570
	* gimplify.c (gimplify_target_expr): Skip TREE_STATIC target
	expression similarly to gimplify_decl_expr.

gcc/testsuite/ChangeLog:

2019-05-23  Martin Liska  

	PR sanitizer/90570
	* g++.dg/asan/pr90570.C: New test.
---
 gcc/gimplify.c  |  1 +
 gcc/testsuite/g++.dg/asan/pr90570.C | 18 ++
 2 files changed, 19 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/asan/pr90570.C

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index e59f38261c3..72f1cc38ff7 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -6662,6 +6662,7 @@ gimplify_target_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p)
 	}
 	  if (asan_poisoned_variables
 	  && DECL_ALIGN (temp) <= MAX_SUPPORTED_STACK_ALIGNMENT
+	  && !TREE_STATIC (temp)
 	  && dbg_cnt (asan_use_after_scope)
 	  && !gimplify_omp_ctxp)
 	{
diff --git a/gcc/testsuite/g++.dg/asan/pr90570.C b/gcc/testsuite/g++.dg/asan/pr90570.C
new file mode 100644
index 000..c2366905516
--- /dev/null
+++ b/gcc/testsuite/g++.dg/asan/pr90570.C
@@ -0,0 +1,18 @@
+/* PR sanitizer/90570 */
+/* { dg-do run } */
+
+#include 
+
+struct stru
+{
+  std::vector v{1,2,3,4};
+  int i{5};
+};
+
+int main()
+{
+  stru s1;
+  stru s2;
+
+  return 0;
+}
-- 
2.21.0

Re: GCC 8 backports

[Martin Liška]

Hi.

I'm sending one more patch that I've tested.

Martin
>From 3a0412967ede61515ce59230580558f5531e63f6 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 23 May 2019 10:12:01 +
Subject: [PATCH] Backport r271548

gcc/ChangeLog:

2019-05-23  Martin Liska  

	PR sanitizer/90570
	* gimplify.c (gimplify_target_expr): Skip TREE_STATIC target
	expression similarly to gimplify_decl_expr.

gcc/testsuite/ChangeLog:

2019-05-23  Martin Liska  

	PR sanitizer/90570
	* g++.dg/asan/pr90570.C: New test.
---
 gcc/gimplify.c  |  1 +
 gcc/testsuite/g++.dg/asan/pr90570.C | 18 ++
 2 files changed, 19 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/asan/pr90570.C

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index bdb15a8fd14..2971293a720 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -6653,6 +6653,7 @@ gimplify_target_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p)
 	}
 	  if (asan_poisoned_variables
 	  && DECL_ALIGN (temp) <= MAX_SUPPORTED_STACK_ALIGNMENT
+	  && !TREE_STATIC (temp)
 	  && dbg_cnt (asan_use_after_scope)
 	  && !gimplify_omp_ctxp)
 	{
diff --git a/gcc/testsuite/g++.dg/asan/pr90570.C b/gcc/testsuite/g++.dg/asan/pr90570.C
new file mode 100644
index 000..c2366905516
--- /dev/null
+++ b/gcc/testsuite/g++.dg/asan/pr90570.C
@@ -0,0 +1,18 @@
+/* PR sanitizer/90570 */
+/* { dg-do run } */
+
+#include 
+
+struct stru
+{
+  std::vector v{1,2,3,4};
+  int i{5};
+};
+
+int main()
+{
+  stru s1;
+  stru s2;
+
+  return 0;
+}
-- 
2.21.0

[PATCH, Darwin, x86, testsuite] Make match strings more specific.

[Iain Sandoe]

Some of the i386.exp tests fail on Darwin (and at least one passes
incorrectly on Linux) because their scan-asm match strings are too
general.  In some cases the strings also match instances in the .file
and size directives or in comment output.  This patch makes the match
strings more specific.

tested on x86_64-darwin and x86_64-linux 
(--target_board=unix\{-m32,-m64\}\{,-fpic\})
Note that it is expected for one fewer test passes on m32 Linux, since
the m64 test for ptwrite2.c had been erroneously passing there and that
is now corrected.

Applied as obvious to mainline,
Iain

2019-05-24  Iain Sandoe  

* gcc.target/i386/pconfig-1.c: Scan for the string in the generated
code, not in comments or miscellaneous directives. Adjust expected
count.
* gcc.target/i386/pr18041-1.c: Likewise.
* gcc.target/i386/pr18041-2.c: Likewise.
* gcc.target/i386/wbinvd-1.c: Likewise.
* gcc.target/i386/wbnoinvd-1.c: Likewise.
* gcc.target/i386/pr66819-3.c: Specifically, check that there is no
call to "bar".
* gcc.target/i386/pr66819-4.c: Likewise.
* gcc.target/i386/pr82662.c
* gcc.target/i386/ptwrite2.c: Make the checks look for the specific
destination register, don't try the m32 test on m64 targets.

diff --git a/gcc/testsuite/gcc.target/i386/pconfig-1.c 
b/gcc/testsuite/gcc.target/i386/pconfig-1.c
index a3fc4f411f..40b4c0c127 100644
--- a/gcc/testsuite/gcc.target/i386/pconfig-1.c
+++ b/gcc/testsuite/gcc.target/i386/pconfig-1.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -mpconfig" } */
-/* { dg-final { scan-assembler-times "pconfig" 5 } } */
+/* { dg-final { scan-assembler-times {\tpconfig} 2 } } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.target/i386/pr18041-1.c 
b/gcc/testsuite/gcc.target/i386/pr18041-1.c
index 24da41a02e..dafe5a82d3 100644
--- a/gcc/testsuite/gcc.target/i386/pr18041-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr18041-1.c
@@ -9,5 +9,5 @@ foo (struct B *b)
 b->bit0 = b->bit0 | b->bit1;
 }
 
-/* { dg-final { scan-assembler-times "and" 1 } } */
-/* { dg-final { scan-assembler-times "or" 1 } } */
+/* { dg-final { scan-assembler-times {\tand[l|q]} 1 } } */
+/* { dg-final { scan-assembler-times {\tor[l|q]} 1 } } */
diff --git a/gcc/testsuite/gcc.target/i386/pr18041-2.c 
b/gcc/testsuite/gcc.target/i386/pr18041-2.c
index 00ebd2ae36..1d7748bccc 100644
--- a/gcc/testsuite/gcc.target/i386/pr18041-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr18041-2.c
@@ -10,5 +10,5 @@ bar  (struct B *b, int x)
 }
 
 /* This fails to combine in 32bit mode but not for x32.  */
-/* { dg-final { scan-assembler-times "and" 1 { xfail { { ! x32 } && ilp32 } } 
} } */
-/* { dg-final { scan-assembler-times "or" 1 { xfail { { ! x32 } && ilp32 } } } 
} */
+/* { dg-final { scan-assembler-times {\tand[lq]} 1 { xfail { { ! x32 } && 
ilp32 } } } } */
+/* { dg-final { scan-assembler-times {\tor} 1 { xfail { { ! x32 } && ilp32 } } 
} } */
diff --git a/gcc/testsuite/gcc.target/i386/pr66819-3.c 
b/gcc/testsuite/gcc.target/i386/pr66819-3.c
index 3bc5a3471e..76e3726b38 100644
--- a/gcc/testsuite/gcc.target/i386/pr66819-3.c
+++ b/gcc/testsuite/gcc.target/i386/pr66819-3.c
@@ -1,6 +1,6 @@
 /* { dg-do compile { target ia32 } } */
 /* { dg-options "-O2 -mregparm=3" } */
-/* { dg-final { scan-assembler-not "call" } } */
+/* { dg-final { scan-assembler-not {call[ \t]+_?bar} } } */
 
 void (*bar)(int, int);
 
diff --git a/gcc/testsuite/gcc.target/i386/pr66819-4.c 
b/gcc/testsuite/gcc.target/i386/pr66819-4.c
index 18b2ccf812..143360d0de 100644
--- a/gcc/testsuite/gcc.target/i386/pr66819-4.c
+++ b/gcc/testsuite/gcc.target/i386/pr66819-4.c
@@ -1,6 +1,6 @@
 /* { dg-do compile { target ia32 } } */
 /* { dg-options "-O2 -mregparm=3" } */
-/* { dg-final { scan-assembler-not "call" } } */
+/* { dg-final { scan-assembler-not {call[ \t]+_?bar} } } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.target/i386/pr82662.c 
b/gcc/testsuite/gcc.target/i386/pr82662.c
index 8a9332b5c5..ec08edc982 100644
--- a/gcc/testsuite/gcc.target/i386/pr82662.c
+++ b/gcc/testsuite/gcc.target/i386/pr82662.c
@@ -23,4 +23,4 @@ int f9 (S x, S y) { return x >= y; }
 int f10 (S x, S y) { return x < y; }
 int f11 (S x, S y) { return x <= y; }
 
-/* { dg-final { scan-assembler-times {\mset} 12 } } */
+/* { dg-final { scan-assembler-times {\tset} 12 } } */
diff --git a/gcc/testsuite/gcc.target/i386/ptwrite2.c 
b/gcc/testsuite/gcc.target/i386/ptwrite2.c
index bd144fc077..be6b23eb83 100644
--- a/gcc/testsuite/gcc.target/i386/ptwrite2.c
+++ b/gcc/testsuite/gcc.target/i386/ptwrite2.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -mptwrite " } */
-/* { dg-final { scan-assembler "ptwrite\[^\n\r\]+r" } } */
-/* { dg-final { scan-assembler "ptwrite\[^\n\r\]+e" } } */
+/* { dg-final { scan-assembler {ptwrite[^\n\r]+%eax} } } */
+/* { dg-final { scan-assembler {ptwrite[^\n\r]+%rax} { target lp64 } } } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.target/i386/wbinvd-1.c 

Re: [PATCH, Darwin, x86, testsuite] Disable tests that cannot pass for Darwin.

[Iain Sandoe]

> On 24 May 2019, at 08:29, Iain Sandoe  wrote:
> 
> A few of the i386.exp target tests cannot pass on Darwin
> because either the port doesn't support a feature, or the
> ABI demands sufficiently different codegen that matching
> the output with scan-asms would require a different test.
> 
> Disabling those tests here.
> 
> tested on x86_64-darwin and x86_64-linux 
> (--target_board=unix\{-m32,-m64\}\{,-fpic\})
> Applied to mainline,
> Iain
> 
> 2019-05-24  Iain Sandoe  
> 
>   * gcc.target/i386/falign-functions-2.c: Skip for Darwin.
>   * gcc.target/i386/pr70738-7.c: Likewise.
>   * gcc.target/i386/pr24414.c: Likewise.
> 

ENOPATCH:

diff --git a/gcc/testsuite/gcc.target/i386/falign-functions-2.c 
b/gcc/testsuite/gcc.target/i386/falign-functions-2.c
index 26d505e3be..2672c87262 100644
--- a/gcc/testsuite/gcc.target/i386/falign-functions-2.c
+++ b/gcc/testsuite/gcc.target/i386/falign-functions-2.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -falign-functions=64:8" } */
+/* { dg-skip-if "SUBALIGN_LOG not set for Darwin" { *-*-darwin* } } */
 
 void
 a (void)
diff --git a/gcc/testsuite/gcc.target/i386/pr24414.c 
b/gcc/testsuite/gcc.target/i386/pr24414.c
index bd12f0c849..0acaa001a5 100644
--- a/gcc/testsuite/gcc.target/i386/pr24414.c
+++ b/gcc/testsuite/gcc.target/i386/pr24414.c
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-options "-O2" } */
+/* { dg-skip-if "asm insert mismatches ABI for Darwin" { *-*-darwin* } } */
 int test;
 
 int
diff --git a/gcc/testsuite/gcc.target/i386/pr70738-7.c 
b/gcc/testsuite/gcc.target/i386/pr70738-7.c
index 2e5b49f619..ee9dfbfb35 100644
--- a/gcc/testsuite/gcc.target/i386/pr70738-7.c
+++ b/gcc/testsuite/gcc.target/i386/pr70738-7.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target ia32 } } */
+/* { dg-do compile { target { ia32 && { ! *-*-darwin* } } } } */
 /* { dg-options "-msse2 -mgeneral-regs-only" } */
 
 extern float a, b, c;
-- 
2.17.1

[PATCH, Darwin, x86, testsuite] Adjust test labels for Darwin.

[Iain Sandoe]

A couple of the i386.exp tests fail because the label spelling used
is different between ELF and Mach-O targets. Adjusted here.

tested on x86_64-darwin and x86_64-linux 
(--target_board=unix\{-m32,-m64\}\{,-fpic\})
Applied as obvious to mainline,
Iain

2019-05-24  Iain Sandoe  

* gcc.target/i386/pr67985-2.c: Adjust label checks for
Darwin.
* gcc.target/i386/pr77881.c: Likewise.

diff --git a/gcc/testsuite/gcc.target/i386/pr67985-2.c 
b/gcc/testsuite/gcc.target/i386/pr67985-2.c
index 9c7a25ad17..a45815af66 100644
--- a/gcc/testsuite/gcc.target/i386/pr67985-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr67985-2.c
@@ -10,4 +10,4 @@ foo (float x, float y)
 
 /* { dg-final { scan-assembler-not "mulss" } } */
 /* { dg-final { scan-assembler-not "movl\[ \t\].*, %eax" } } */
-/* { dg-final { scan-assembler "call\[ \t\]__mulsf3" } } */
+/* { dg-final { scan-assembler "call\[ \t\]_?__mulsf3" } } */
diff --git a/gcc/testsuite/gcc.target/i386/pr77881.c 
b/gcc/testsuite/gcc.target/i386/pr77881.c
index 80d143f2bc..6803341568 100644
--- a/gcc/testsuite/gcc.target/i386/pr77881.c
+++ b/gcc/testsuite/gcc.target/i386/pr77881.c
@@ -8,5 +8,5 @@ foo (long long int a, long long int a2, int b)
 if (a < 0 || b)
   baz ();
 }
-/* { dg-final { scan-assembler "js\[ \t\]\.L" } } */
-/* { dg-final { scan-assembler "jne\[ \t\]\.L" } } */
+/* { dg-final { scan-assembler "js\[ \t\]\.?L" } } */
+/* { dg-final { scan-assembler "jne\[ \t\]\.?L" } } */
-- 
2.17.1

[PATCH, Darwin, x86, testsuite] Disable tests that cannot pass for Darwin.

[Iain Sandoe]

A few of the i386.exp target tests cannot pass on Darwin
because either the port doesn't support a feature, or the
ABI demands sufficiently different codegen that matching
the output with scan-asms would require a different test.

Disabling those tests here.

tested on x86_64-darwin and x86_64-linux 
(--target_board=unix\{-m32,-m64\}\{,-fpic\})
Applied to mainline,
Iain

2019-05-24  Iain Sandoe  

* gcc.target/i386/falign-functions-2.c: Skip for Darwin.
* gcc.target/i386/pr70738-7.c: Likewise.
* gcc.target/i386/pr24414.c: Likewise.

Re: Fixed: "required ftruncate or chsize support not present" in gfortran testsuite

[Hans-Peter Nilsson]

> From: Janne Blomqvist 
> Date: Thu, 23 May 2019 23:43:23 +0300

> On Thu, May 23, 2019 at 5:21 AM Hans-Peter Nilsson
>  wrote:
> >
> > There was a regression for gfortran.dg/fmt_en.f90 for cris-elf
> > that on inspection was due to it having acquired a truncation
> > call through the runtime.  I updated that and the new tests that
> > had "Fortran runtime error: required ftruncate or chsize support
> > not present" messages in gfortran.log, ran past cris-elf and
> > committed as obvious.

> Do you know which commit caused this? Was it something recent? Based
> on a quick look, at least for fmt_en this shouldn't happen..

For fmt_en.f90, it was quite long ago, in 2015, and luckily just
two commits since the previous run.  It's either r223857 or
r223858, but it can't be r223857, being on a branch elsewhere
than trunk.  I'm not completely sure how r223858 could have
changed matters either, but I have a theory: While fmt_en.f90
*was* touched by that commit, it was about changing how dump
files etc was cleaned up in the test-suite.  The test outputs to
a file "fmt_en.res" and is run multiple times for various
optimization options.  I guess that before that commit, that
file was wiped out by the test-machinery between iterations and
afterwards, there's a fmt_en.res from a previous run, and the
fortran runtime library "empties" an existing output-file by
truncating it.  ...Right, the first (-O0) iteration succeeded.
I thought that was because gfortran arranged to output things
differently depending on optimization options!  So, that
"should/should not happen" depends on whether the test should
cover handling an existing fmt_en.res.

I guess it should, so all tests outputting to a file are
affected, as long as libgfortran empties files by ftruncate or
chsize.

The other tests have failed since their introduction.

> Since this seems to happen semi-regularly, would it be possible to do
> something at the dejagnu level, e.g. to fail a test that uses
> ftruncate/chsize even though it's not marked with target fd_truncate.

Sorry, I don't know, I don't understand what's suggested.  But,
it's not that the semi-regular frequency is disturbingly high
(cycle-time half a year to 11 years).

> Hard to see how that could be verified without running testcases under
> strace or something like that.

brgds, H-P

Re: [PATCH] Allow fusion of stack_protect_test_ with adjacent conditional jump (PR target/90568)

[Uros Bizjak]

On Thu, May 23, 2019 at 11:36 PM Jakub Jelinek  wrote:
>
> Hi!
>
> On Thu, May 23, 2019 at 12:40:51AM +0200, Jakub Jelinek wrote:
> > Incrementally, we should consider handling e.g. *subsi_2{,_zext} and similar
> > patterns and also this stack_protect_test_[sd]i in ix86_macro_fusion_pair_p,
> > not sure if unconditionally, or only when tuning for skylake+ / generic.
>
> Actually, *subsi_2 etc. is already supported, the following patch adds macro
> fusion support for the stack_protect_test_?i.
> Additionally, it fixes a compile time inefficiency, while recog_memoized
> and extract_constrain_insn_cached do caching, get_attr_type uses those two
> plus often calls various predicates which are not cached, so calling
> get_attr_type 4-7 times in a row on the same instruction isn't a very good
> idea.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2019-05-23  Jakub Jelinek  
>
> PR target/90568
> * config/i386/x86-tune-sched.c (ix86_macro_funsion_pair_p): Call
> gen_attr_type just once instead of 4-7 times.  Formatting fixes.
> Handle stack_protect_test_ codegen similarly to corresponding
> sub instruction.

OK.

Thanks,
Uros.

>
> --- gcc/config/i386/x86-tune-sched.c.jj 2019-01-01 12:37:31.608737849 +0100
> +++ gcc/config/i386/x86-tune-sched.c2019-05-23 12:28:29.826740473 +0200
> @@ -525,6 +525,7 @@ ix86_macro_fusion_pair_p (rtx_insn *cond
>enum rtx_code ccode;
>rtx compare_set = NULL_RTX, test_if, cond;
>rtx alu_set = NULL_RTX, addr = NULL_RTX;
> +  enum attr_type condgen_type;
>
>if (!any_condjump_p (condjmp))
>  return false;
> @@ -538,15 +539,26 @@ ix86_macro_fusion_pair_p (rtx_insn *cond
>|| !modified_in_p (cc_reg_1, condgen))
>  return false;
>
> -  if (get_attr_type (condgen) != TYPE_TEST
> -  && get_attr_type (condgen) != TYPE_ICMP
> -  && get_attr_type (condgen) != TYPE_INCDEC
> -  && get_attr_type (condgen) != TYPE_ALU)
> +  condgen_type = get_attr_type (condgen);
> +  if (condgen_type == TYPE_MULTI
> +  && (INSN_CODE (condgen) == CODE_FOR_stack_protect_test_di
> + || INSN_CODE (condgen) == CODE_FOR_stack_protect_test_si)
> +  && TARGET_FUSE_ALU_AND_BRANCH)
> +{
> +  /* stack_protect_test_ ends with a sub, which subtracts
> +a non-rip special memory operand from a GPR.  */
> +  src = NULL_RTX;
> +  alu_set = XVECEXP (PATTERN (condgen), 0, 1);
> +  goto handle_stack_protect_test;
> +}
> +  else if (condgen_type != TYPE_TEST
> +  && condgen_type != TYPE_ICMP
> +  && condgen_type != TYPE_INCDEC
> +  && condgen_type != TYPE_ALU)
>  return false;
>
>compare_set = single_set (condgen);
> -  if (compare_set == NULL_RTX
> -  && !TARGET_FUSE_ALU_AND_BRANCH)
> +  if (compare_set == NULL_RTX && !TARGET_FUSE_ALU_AND_BRANCH)
>  return false;
>
>if (compare_set == NULL_RTX)
> @@ -571,10 +583,8 @@ ix86_macro_fusion_pair_p (rtx_insn *cond
>
>/* Macro-fusion for cmp/test MEM-IMM + conditional jmp is not
>   supported.  */
> -  if ((MEM_P (XEXP (src, 0))
> -   && CONST_INT_P (XEXP (src, 1)))
> -  || (MEM_P (XEXP (src, 1))
> - && CONST_INT_P (XEXP (src, 0
> +  if ((MEM_P (XEXP (src, 0)) && CONST_INT_P (XEXP (src, 1)))
> +  || (MEM_P (XEXP (src, 1)) && CONST_INT_P (XEXP (src, 0
>  return false;
>
>/* No fusion for RIP-relative address.  */
> @@ -583,29 +593,27 @@ ix86_macro_fusion_pair_p (rtx_insn *cond
>else if (MEM_P (XEXP (src, 1)))
>  addr = XEXP (XEXP (src, 1), 0);
>
> -  if (addr) {
> -ix86_address parts;
> -int ok = ix86_decompose_address (addr, );
> -gcc_assert (ok);
> -
> -if (ix86_rip_relative_addr_p ())
> -  return false;
> -  }
> +  if (addr)
> +{
> +  ix86_address parts;
> +  int ok = ix86_decompose_address (addr, );
> +  gcc_assert (ok);
> +
> +  if (ix86_rip_relative_addr_p ())
> +   return false;
> +}
>
> + handle_stack_protect_test:
>test_if = SET_SRC (pc_set (condjmp));
>cond = XEXP (test_if, 0);
>ccode = GET_CODE (cond);
>/* Check whether conditional jump use Sign or Overflow Flags.  */
>if (!TARGET_FUSE_CMP_AND_BRANCH_SOFLAGS
> -  && (ccode == GE
> -  || ccode == GT
> - || ccode == LE
> - || ccode == LT))
> +  && (ccode == GE || ccode == GT || ccode == LE || ccode == LT))
>  return false;
>
>/* Return true for TYPE_TEST and TYPE_ICMP.  */
> -  if (get_attr_type (condgen) == TYPE_TEST
> -  || get_attr_type (condgen) == TYPE_ICMP)
> +  if (condgen_type == TYPE_TEST || condgen_type == TYPE_ICMP)
>  return true;
>
>/* The following is the case that macro-fusion for alu + jmp.  */
> @@ -619,11 +627,8 @@ ix86_macro_fusion_pair_p (rtx_insn *cond
>
>/* Macro-fusion for inc/dec + unsigned conditional jump is not
>   supported.  */
> -  if (get_attr_type (condgen) == TYPE_INCDEC
> -  && (ccode == GEU
> - || ccode ==