Re: [09/nn] Add a fixed_size_mode_pod class

[Trevor Saunders]

On Wed, Nov 01, 2017 at 10:30:29AM -0600, Jeff Law wrote:
> On 10/31/2017 08:47 PM, Trevor Saunders wrote:
> > On Tue, Oct 31, 2017 at 11:38:48AM -0600, Jeff Law wrote:
> > > On 10/31/2017 11:22 AM, Eric Botcazou wrote:
> > > > > I don't see a reason not to other than a pretty small amount of work
> > > > > each time we make a release.
> > > > 
> > > > I'm not sure it would be so small an amount of work, especially on 
> > > > non-Linux
> > > > platforms, so this would IMO divert our resources for little benefit.
> > > Having done this for years on HPUX, yes, it takes more time than one
> > > could imagine.  THen I went to work for a company that did this for
> > > hpux, solaris, aix, irix and others and well, it was very painful.
> > 
> > I'm sure its a project one can spend arbitrary amounts of time on if one
> > wishes or is payed to do so.  That said I'm considering the scope here
> > limitted to running configure / make  / make install with the defaults
> > and taring up the result.  I'll admitt I've only done that on linux
> > where it was easy, but people do keep AIX and Solaris building and they
> > really are supposed to be buildable in a release.  However at some point
> > it can be less work to do this than to beat C++98 into doing what is
> > desired.
> It sounds so easy, but it does get more complex than just build and tar the
> result up.  How (for example) do you handle DSOs that may or may not be on
> the system where the bits get installed.  Do you embed them or tell the user
> to go get them?That's just one example of a gotcha, there's many.
> 
> It's really not something I'd suggest we pursue all that deeply.  Been
> there, done that wouldn't want to do it again.
> 
> > > > > Thirdly making it easier to work on the compiler and understand it 
> > > > > makes
> > > > > things easier for those possible contributors, so if being able to use
> > > > > C++11 advances that goalthings could be better over all for possible
> > > > > contributors with different system compilers.
> > > > 
> > > > I don't buy this at all.  You don't need bleeding edge C++ features to 
> > > > build a
> > > > compiler and people don't work on compilers to use bleeding edge C++.  
> > > > Using a
> > > > narrow and sensible set of C++ features was one of the conditions under 
> > > > which
> > > > the switch to C++ as implementation language was accepted at the time.
> > > Agreed that we need to stick with a sensible set of features.  But the
> > > sensible set isn't necessarily fixed forever.
> > 
> > Also as a counter example what brought this thread up is Richard wanting
> > to use something from C++11.  So in that particular case it probably
> > would make something better.
> In my particular case I could use certain C++11 features to make the code
> cleaner/easier to prove right -- particularly rvalue references and move
> semantics.  I've got an object with a chunk of allocated memory.  I want to
> move ownership of the memory to another object.
> 
> C++11 handles this cleanly and gracefully and in doing so makes it very hard
> to get it wrong.

You may want to look at how the unique_ptr shim deals with that, though
maybe you don't want to copy the ifdef hackery to actually use rval refs
when possible.

Trev

> 
> However, I don't think  my case, in and of itself, is enough to push us into
> the C++11 world.  Nor am I convinced that the aggregate of these things is
> enough to push us into the C++11 world.  But I do think we'll be there at
> some point.
> 
> jeff

[PATCH] PR fortran/82796 -- common entity in equivalence in pure routine

[Steve Kargl]

The attached patch fixes a regression where gfortran was
issuing an error for an entity in a common block within
a module when it appears in equivalence, and the entity
*is not* use associated in a pure subprogram.  OK to 
commit?


2017-11-01  Steven G. Kargl  

PR fortran/82796
* resolve.c (resolve_equivalence): An entity in a common block within
a module cannot appear in an equivalence statement if the entity is
with a pure procedure.

2017-11-01  Steven G. Kargl  

PR fortran/82796
* gfortran.dg/equiv_pure.f90: New test.

-- 
Steve
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 254241)
+++ gcc/fortran/resolve.c	(working copy)
@@ -15936,9 +15936,22 @@ resolve_equivalence (gfc_equiv *eq)
 	  && sym->ns->proc_name->attr.pure
 	  && sym->attr.in_common)
 	{
-	  gfc_error ("Common block member %qs at %L cannot be an EQUIVALENCE "
-		 "object in the pure procedure %qs",
-		 sym->name, >where, sym->ns->proc_name->name);
+	  /* Need to check for symbols that may have entered the pure
+	 procedure via a USE statement.  */
+	  bool saw_sym = false;
+	  if (sym->ns->use_stmts)
+	{
+	  gfc_use_rename *r;
+	  for (r = sym->ns->use_stmts->rename; r; r = r->next)
+		if (strcmp(r->use_name, sym->name) == 0) saw_sym = true; 
+	}
+	  else
+	saw_sym = true;
+
+	  if (saw_sym)
+	gfc_error ("COMMON block member %qs at %L cannot be an "
+		   "EQUIVALENCE object in the pure procedure %qs",
+		   sym->name, >where, sym->ns->proc_name->name);
 	  break;
 	}
 
Index: gcc/testsuite/gfortran.dg/equiv_pure.f90
===
--- gcc/testsuite/gfortran.dg/equiv_pure.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/equiv_pure.f90	(working copy)
@@ -0,0 +1,50 @@
+! { dg-do compile }
+module eq
+   implicit none
+   integer :: n1, n2
+   integer, dimension(2) :: a
+   equivalence (a(1), n1)
+   equivalence (a(2), n2)
+   common /a/ a
+end module eq
+
+module m
+   use eq
+   implicit none
+   type, public :: t
+ integer :: i
+   end type t
+end module m
+
+module p
+   implicit none
+   contains
+   pure integer function d(h)
+ use m
+ implicit none
+ integer, intent(in) :: h
+ d = h
+   end function
+end module p
+
+module q
+   implicit none
+   contains
+   pure integer function d(h)
+ use m, only : t
+ implicit none
+ integer, intent(in) :: h
+ d = h
+   end function
+end module q
+
+module r
+   implicit none
+   contains
+   pure integer function d(h)
+ use m, only : a  ! { dg-error "cannot be an EQUIVALENCE object" }
+ implicit none
+ integer, intent(in) :: h
+ d = h
+   end function
+end module r

[PATCH] PR auto keyword variable lost its attributes/80986

[林作健]

The following patch aims to removing the attribute only tf_waring flag is on.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d1c846ecf44..8ff46498fd6 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -7410,7 +7410,10 @@ canonicalize_type_argument (tree arg,
tsubst_flags_t complain)
   if (!arg || arg == error_mark_node || arg == TYPE_CANONICAL (arg))
 return arg;
   bool removed_attributes = false;
-  tree canon = strip_typedefs (arg, _attributes);
+  bool *premove_attributes = NULL;
+  if (complain & tf_warning)
+premove_attributes = _attributes;
+  tree canon = strip_typedefs (arg, premove_attributes);
   if (removed_attributes
   && (complain & tf_warning))
 warning (OPT_Wignored_attributes,

Re: [PATCH] RISC-V: Document the medlow and medany code models

[Palmer Dabbelt]

On Wed, 01 Nov 2017 15:07:59 PDT (-0700), jos...@codesourcery.com wrote:
> On Wed, 1 Nov 2017, Palmer Dabbelt wrote:
>
>> On Wed, 01 Nov 2017 14:59:43 PDT (-0700), jos...@codesourcery.com wrote:
>> > On Tue, 31 Oct 2017, Palmer Dabbelt wrote:
>> >
>> >> +between absolute addresses -2 GiB and +2 GiB. Programs can be statically 
>> >> or
>> >
>> > That should be @minus{}2 GiB, to get a minus sign instead of a hyphen.
>>
>> Oops, I already committed it.  How does this look?
>>
>>  * doc/invoke.texi (RISC-V Options): Use "@minus{}2 GB", not "-2 GB".
>
> That looks OK.

Committed.  Thanks!

Re: [PATCH, AArch64] Disable reg offset in quad-word store for Falkor.

[Kugan Vivekanandarajah]

Hi,

On 1 November 2017 at 03:12, Jim Wilson  wrote:
> On Tue, 2017-10-31 at 14:35 +1100, Kugan Vivekanandarajah wrote:
>> Ping ?
>>
>> I see that Jim has clarified the comments from Andrew.
>
> Andrew also suggested that we add a testcase to the testsuite.  I
> didn't do that.  I did put a testcase to reproduce in the bug report.
>  See
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82533
> It should be a relatively simple matter of taking that testcase,
> compiling to assembly with -mcpu=falkor, then doing a pattern search
> for a str q [r+r] instruction, and fail if it is present.
>
> Jim
>

Here is the testcase. Is the original patch OK with the testcase attached.

Thanks,
Kugan
diff --git a/gcc/testsuite/gcc.target/aarch64/pr82533.c 
b/gcc/testsuite/gcc.target/aarch64/pr82533.c
new file mode 100644
index 000..fa28ffa
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr82533.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-mcpu=falkor -O2 -ftree-vectorize" } */
+
+void
+copy (int N, double *c, double *a)
+{
+  for (int i = 0; i < N; ++i)
+c[i] = a[i];
+}
+
+/* { dg-final { scan-assembler-not "str\tq\[0-9\]+, \\\[x\[0-9\]+, 
x\[0-9\]+\\\]" } } */
gcc/testsuite/ChangeLog:

2017-11-02  Kugan Vivekanandarajah  

	* gcc.target/aarch64/pr82533.c: New test.

Re: [PATCH] enhance -Warray-bounds to detect out-of-bounds offsets (PR 82455)

[Martin Sebor]

I of course don't want to break anything.  I didn't see any fallout
in my testing and I normally test all the front ends, including Ada,
but let me check to make sure I tested it this time (I had made some
temporary changes to my build script and may have disabled it.)  Let
me double check it after I get back from my trip.

No worries.  Hopefully by the time you're back I'll have something
publishable on the ripping apart tree-vrp front and we can prototype the
effectiveness of doing this kind of stuff outside tree-vrp.c


I re-did my build and re-ran all the tests and found no regressions
in the Ada tests.


We should also revisit Aldy's work from last year which started the
whole effort around fixing how we deal with out out of bounds index
testing.   He had a version which ran outside tree-vrp.c but used the
same basic structure and queried range data for the index.  I've got a
copy here we can poke at.


Sure, I'd be interested in looking at it when I'm done with this
work.

Martin

Re: [PATCH] RISC-V: Document the medlow and medany code models

[Joseph Myers]

On Wed, 1 Nov 2017, Palmer Dabbelt wrote:

> On Wed, 01 Nov 2017 14:59:43 PDT (-0700), jos...@codesourcery.com wrote:
> > On Tue, 31 Oct 2017, Palmer Dabbelt wrote:
> >
> >> +between absolute addresses -2 GiB and +2 GiB. Programs can be statically 
> >> or
> >
> > That should be @minus{}2 GiB, to get a minus sign instead of a hyphen.
> 
> Oops, I already committed it.  How does this look?
> 
>   * doc/invoke.texi (RISC-V Options): Use "@minus{}2 GB", not "-2 GB".

That looks OK.

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

Re: [PATCH] RISC-V: Document the medlow and medany code models

[Palmer Dabbelt]

On Wed, 01 Nov 2017 14:59:43 PDT (-0700), jos...@codesourcery.com wrote:
> On Tue, 31 Oct 2017, Palmer Dabbelt wrote:
>
>> +between absolute addresses -2 GiB and +2 GiB. Programs can be statically or
>
> That should be @minus{}2 GiB, to get a minus sign instead of a hyphen.

Oops, I already committed it.  How does this look?

* doc/invoke.texi (RISC-V Options): Use "@minus{}2 GB", not "-2 GB".

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8903afaeeffc..fc5c4f975a2b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -21769,8 +21769,8 @@ Do not generate unaligned memory accesses.
 @opindex mcmodel=medlow
 Generate code for the medium-low code model. The program and its statically
 defined symbols must lie within a single 2 GiB address range and must lie
-between absolute addresses -2 GiB and +2 GiB. Programs can be statically or
-dynamically linked. This is the default code model.
+between absolute addresses @minus{}2 GiB and +2 GiB. Programs can be
+statically or dynamically linked. This is the default code model.

 @item -mcmodel=medany
 @opindex mcmodel=medany

Re: [PATCH] RISC-V: Document the medlow and medany code models

[Joseph Myers]

On Tue, 31 Oct 2017, Palmer Dabbelt wrote:

> +between absolute addresses -2 GiB and +2 GiB. Programs can be statically or

That should be @minus{}2 GiB, to get a minus sign instead of a hyphen.

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

Re: [PATCH, rs6000] Add Power 9 support for vec_first builtins

[Segher Boessenkool]

Hi Carl,

On Tue, Oct 31, 2017 at 08:46:09AM -0700, Carl Love wrote:
> gcc/ChangeLog:

See Jakub's comments (thanks!)

> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -14286,6 +14286,34 @@ swap_selector_for_mode (machine_mode mode)
>return force_reg (V16QImode, gen_rtx_CONST_VECTOR (V16QImode, gen_rtvec_v 
> (16, perm)));
>  }
>  
> +/* Return bytes in type */

Dot space space.

> +int
> +bytes_in_mode (machine_mode mode)
> +{

But what do you need this for?  This is GET_MODE_SIZE (GET_MODE_INNER (mode))
(or similar).

> +;; Return first position of match between vectors
> +(define_expand "first_match_index_"
> +  [(match_operand:SI 0 "register_operand")
> +   (unspec: SI [(match_operand:VSX_EXTRACT_I 1 "register_operand")

No space in :SI please.

> +   (match_operand:VSX_EXTRACT_I 2 "register_operand")]

This should indent to the same level as the previous match_operand.

> +  UNSPEC_VSX_FIRST_MATCH_INDEX)]

(define_expand "first_match_index_"
  [(match_operand:SI 0 "register_operand")
   (unspec:SI [(match_operand:VSX_EXTRACT_I 1 "register_operand")
   (match_operand:VSX_EXTRACT_I 2 "register_operand")]
  UNSPEC_VSX_FIRST_MATCH_INDEX)]

> +  emit_insn (gen_vcmpnez (cmp_result, operands[1],
> +operands[2]));

Indent with tabs for each each spaces; the "o" should align with the "c".

> +  sh = bytes_in_mode(mode)/2;

Spaces around binary operators please, and before the opening paren of
parameter lists.

> +  /* Vector with zeros in elements that correspond to zeros in operands.  */
> +  emit_insn (gen_xor3 (zero, zero, zero));

I think we have a helper for this?  One that avoids xor if it can.


Segher

Re: [PATCH][compare-elim] Fix PR rtl-optimization/82597

[Eric Botcazou]

> Oops, I thought I've removed it, but apparently I haven't; thanks for
> catching it.  Here is an updated patch I'll bootstrap/regtest soon.
> 
> 2017-11-01  Jakub Jelinek  
> 
>   PR rtl-optimization/82778
>   PR rtl-optimization/82597
>   * compare-elim.c (struct comparison): Add in_a_setter field.
>   (find_comparison_dom_walker::before_dom_children): Remove killed
>   bitmap and df_simulate_find_defs call, instead walk the defs.
>   Compute last_setter and initialize in_a_setter.  Merge definitions
>   with first initialization for a few variables.
>   (try_validate_parallel): Use insn_invalid_p instead of
>   recog_memoized.  Return insn rather than just the pattern.
>   (try_merge_compare): Fix up comment.  Don't uselessly test if
>   in_a is a REG_P.  Use cmp->in_a_setter instead of walking UD
>   chains.
>   (execute_compare_elim_after_reload): Remove df_chain_add_problem
>   call.
> 
>   * g++.dg/opt/pr82778.C: New test.
> 
> 2017-10-31  Michael Collison  
> 
>   PR rtl-optimization/82597
>   * gcc.dg/pr82597.c: New test.

This is OK if it successfully passes testing, thanks.

-- 
Eric Botcazou

Re: [C++ Patch] PR 80955 (Macros expanded in definition of user-defined literals)

[Mukesh Kapoor]

On 11/1/2017 1:02 PM, Jason Merrill wrote:

On Tue, Oct 31, 2017 at 12:17 PM, Mukesh Kapoor
 wrote:

On 10/25/2017 6:44 PM, Mukesh Kapoor wrote:

On 10/25/2017 4:20 AM, Nathan Sidwell wrote:

On 10/25/2017 12:03 AM, Mukesh Kapoor wrote:


Thanks for pointing this out. Checking in the front end will be
difficult because the front end gets tokens after macro expansion. I think
the difficulty of fixing this bug comes because of the requirement to
maintain backward compatibility with the option -Wliteral-suffix for
-std=c++11.


IIUC the warning's intent is to catch cases of:
printf ("some format"PRIx64 ..., ...);
where there's no space between the string literals and the PRIx64 macro.
I suspect it's very common for there to be a following string-literal, so
perhaps the preprocessor could detect:

NON-FN-MACRO

and warn on that sequence?


Yes, this can be done easily and this is also the usage mentioned in the
man page. I made this change in the compiler, bootstrapped it and ran the
tests. The following two tests fail after the fix:

g++.dg/cpp0x/Wliteral-suffix.C
g++.dg/cpp0x/warn_cxx0x4.C

Both tests have code similar to the following (from Wliteral-suffix.C):

#define BAR "bar"
#define PLUS_ONE + 1

   char c = '3'PLUS_ONE;   // { dg-warning "invalid suffix on literal" }
   char s[] = "foo"BAR;// { dg-warning "invalid suffix on literal" }

Other compilers don't accept this code. Maybe I should just modify these
tests to have error messages instead of warnings and submit my revised fix?


Actually, according to the man page for -Wliteral-suffix, only macro names
that don't start with an underscore should be considered when issuing a
warning:

-Wliteral-suffix (C++ and Objective-C++ only)
Warn when a string or character literal is followed by a
ud-suffix
which does not begin with an underscore...

So the fix is simply to check if the macro name in is_macro() starts with an
underscore. The function is_macro() is called only at three places. At two
places it's used to check for the warning related to -Wliteral-suffix and
the check for underscore should be made for these two cases; at one place it
is used to check for the warning related to -Wc++11-compat and there is no
need to check for underscore for this case.

The fix is simply to pass a bool flag as an additional argument to
is_macro() to decide whether the macro name starts with an underscore or
not. I have tested the attached patch on x86_64-linux. Thanks.

Rather than add a mysterious parameter to is_macro, how about checking
*cur != '_' before we call it?


This is a good suggestion. I have attached the revised patch. Thanks.

Mukesh

/libcpp
2017-10-31  Mukesh Kapoor   

PR c++/80955
* lex.c (lex_string): When checking for a valid macro for the
warning related to -Wliteral-suffix (CPP_W_LITERAL_SUFFIX),
check that the macro name does not start with an underscore
before calling is_macro().

/testsuite
2017-10-31  Mukesh Kapoor   

PR c++/80955
* g++.dg/cpp0x/udlit-macros.C: New.

Index: gcc/testsuite/g++.dg/cpp0x/udlit-macros.C
===
--- gcc/testsuite/g++.dg/cpp0x/udlit-macros.C   (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/udlit-macros.C   (working copy)
@@ -0,0 +1,31 @@
+// PR c++/80955
+// { dg-do compile { target c++11 } }
+
+#define __STDC_FORMAT_MACROS
+#include 
+#include 
+#include 
+
+using size_t = decltype(sizeof(0));
+#define _zero
+#define _ID _xx
+int operator""_zero(const char*, size_t) { return 0; }
+int operator""_ID(const char*, size_t) { return 0; }
+
+int main()
+{
+  int64_t i64 = 123;
+  char buf[100];
+  sprintf(buf, "%"PRId64"abc", i64);  // { dg-warning "invalid suffix on 
literal" }
+  return strcmp(buf, "123abc")
++ ""_zero
++ "bob"_zero
++ R"#(raw
+  string)#"_zero
++ "xx"_ID
++ ""_ID
++ R"AA(another
+   raw
+   string)AA"_ID;
+}
+
Index: libcpp/lex.c
===
--- libcpp/lex.c(revision 254048)
+++ libcpp/lex.c(working copy)
@@ -1871,8 +1871,9 @@
   /* If a string format macro, say from inttypes.h, is placed touching
 a string literal it could be parsed as a C++11 user-defined string
 literal thus breaking the program.
-Try to identify macros with is_macro. A warning is issued. */
-  if (is_macro (pfile, cur))
+Try to identify macros with is_macro. A warning is issued.
+The macro name should not start with '_' for this warning. */
+  if ((*cur != '_') && is_macro (pfile, cur))
{
  /* Raise a warning, but do not consume subsequent tokens.  */
  if (CPP_OPTION (pfile, warn_literal_suffix) && !pfile->state.skipping)
@@ -2001,8 +2002,9 @@
   /* If a string format 

Re: [C++ PATCH] overloaded operator fns [8/N]

[Jason Merrill]

On Wed, Nov 1, 2017 at 2:29 PM, Nathan Sidwell  wrote:
> This is the last of the overloaded operator reworking.  Now we can cheaply
> go from identifier->overload info, there's no need to specially mark
> identifiers as new or delete operators themselves.  Thus we can reorder the
> cp_identifier_kind enumeration and leave space in it for udlit operators.
>
> This patch does that renumbering, and reserves a value for udlit operators.
> Those are currently detected by string compare, which isn't the most
> satisfactory way to do it.  But it's a change for another day.

> -&& IDENTIFIER_NEWDEL_OP_P (unqualified_id)))
> +&& IDENTIFIER_OVL_OP_P (unqualified_id)
> +&& (IDENTIFIER_OVL_OP_FLAGS (unqualified_id) & OVL_OP_FLAG_ALLOC)))

Why not keep the name IDENTIFIER_NEWDEL_OP_P, which expands to this?

Jason

Re: [C++ Patch] PR 80955 (Macros expanded in definition of user-defined literals)

[Jason Merrill]

On Tue, Oct 31, 2017 at 12:17 PM, Mukesh Kapoor
 wrote:
> On 10/25/2017 6:44 PM, Mukesh Kapoor wrote:
>>
>> On 10/25/2017 4:20 AM, Nathan Sidwell wrote:
>>>
>>> On 10/25/2017 12:03 AM, Mukesh Kapoor wrote:
>>>
 Thanks for pointing this out. Checking in the front end will be
 difficult because the front end gets tokens after macro expansion. I think
 the difficulty of fixing this bug comes because of the requirement to
 maintain backward compatibility with the option -Wliteral-suffix for
 -std=c++11.
>>>
>>>
>>> IIUC the warning's intent is to catch cases of:
>>> printf ("some format"PRIx64 ..., ...);
>>> where there's no space between the string literals and the PRIx64 macro.
>>> I suspect it's very common for there to be a following string-literal, so
>>> perhaps the preprocessor could detect:
>>>
>>> NON-FN-MACRO
>>>
>>> and warn on that sequence?
>>
>>
>> Yes, this can be done easily and this is also the usage mentioned in the
>> man page. I made this change in the compiler, bootstrapped it and ran the
>> tests. The following two tests fail after the fix:
>>
>> g++.dg/cpp0x/Wliteral-suffix.C
>> g++.dg/cpp0x/warn_cxx0x4.C
>>
>> Both tests have code similar to the following (from Wliteral-suffix.C):
>>
>> #define BAR "bar"
>> #define PLUS_ONE + 1
>>
>>   char c = '3'PLUS_ONE;   // { dg-warning "invalid suffix on literal" }
>>   char s[] = "foo"BAR;// { dg-warning "invalid suffix on literal" }
>>
>> Other compilers don't accept this code. Maybe I should just modify these
>> tests to have error messages instead of warnings and submit my revised fix?
>
>
> Actually, according to the man page for -Wliteral-suffix, only macro names
> that don't start with an underscore should be considered when issuing a
> warning:
>
>-Wliteral-suffix (C++ and Objective-C++ only)
>Warn when a string or character literal is followed by a
> ud-suffix
>which does not begin with an underscore...
>
> So the fix is simply to check if the macro name in is_macro() starts with an
> underscore. The function is_macro() is called only at three places. At two
> places it's used to check for the warning related to -Wliteral-suffix and
> the check for underscore should be made for these two cases; at one place it
> is used to check for the warning related to -Wc++11-compat and there is no
> need to check for underscore for this case.
>
> The fix is simply to pass a bool flag as an additional argument to
> is_macro() to decide whether the macro name starts with an underscore or
> not. I have tested the attached patch on x86_64-linux. Thanks.

Rather than add a mysterious parameter to is_macro, how about checking
*cur != '_' before we call it?

Jason

Re: [PATCH], Add rounding built-ins to the _Float and _FloatX built-in functions

[Michael Meissner]

On Wed, Nov 01, 2017 at 01:31:57PM -0500, Segher Boessenkool wrote:
> Hi Mike,
> 
> On Fri, Oct 27, 2017 at 06:39:21PM -0400, Michael Meissner wrote:
> > The power9 (running PowerPC ISA 3.0) has a round to integer instruction
> > (XSRQPI) that does various flavors of round an IEEE 128-bit floating point 
> > to
> > integeral values.  This patch adds the support to the machine independent
> > portion of the compiler, and adds the necessary support for ceilf128,
> > roundf128, truncf128, and roundf128 to the PowerPC backend when you use
> > -mcpu=power9.
> > 
> > I have done bootstrap builds on both x86-64 and a little endian power8 
> > system.
> > Can I install these patches to the trunk?
> 
> Do you really need to duplicate everything?  Other than that the generic
> parts look fine to me (but someone else will have to approve it).
> 
> The rs6000 parts are okay for trunk.

Yes, right now you have to do the duplication.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH 4/9] [SFN] introduce statement frontier notes, still disabled

[Jason Merrill]

On Wed, Nov 1, 2017 at 3:13 PM, Alexandre Oliva  wrote:
> Hi, Jason,
>
> Apologies for the delay in responding; somehow I missed your reply when
> it arrived (probably because I had a cold back then :-), and only saw it
> today.
>
> On Oct 24, 2017, Jason Merrill  wrote:
>
>> On Sat, Sep 30, 2017 at 5:08 AM, Alexandre Oliva  wrote:
>>> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
>>> index a89ee49..f9209ac 100644
>>> --- a/gcc/cp/constexpr.c
>>> +++ b/gcc/cp/constexpr.c
>>> @@ -306,6 +306,9 @@ build_data_member_initialization (tree t, 
>>> vec **vec)
>>> tree_stmt_iterator i;
>>> for (i = tsi_start (t); !tsi_end_p (i); tsi_next ())
>>> {
>>> + if (TREE_CODE (tsi_stmt (i)) == DEBUG_BEGIN_STMT)
>>> +   /* ??? Can we retain this information somehow?  */
>
>> There's no need; the result of this function isn't used for codegen
>> any more, just checking.
>
>> Why do you need a special case for this?  The existing code should
>> have the same effect.
>
> More than anything, it was to add the comment about retaining the begin
> stmt markers.
>
> Something in me wishes that, in spite of resolving the entire function
> call to a constant expression, we could still express in debug info that
> "we went through these statements", and maybe even single-step through
> them towards the final result.

Sure, but my point is that this function is not involved in evaluating
the call, so there would be no reason for a change here.  Most likely
you'd want something in cxx_eval_store_expression.

>>> @@ -586,6 +590,9 @@ build_constexpr_constructor_member_initializers (tree 
>>> type, tree body)
>>> tree_stmt_iterator i;
>>> for (i = tsi_start (body); !tsi_end_p (i); tsi_next ())
>>> {
>>> + if (TREE_CODE (tsi_stmt (i)) == DEBUG_BEGIN_STMT)
>>> +   /* ??? Can we retain this information somehow?  */
>
>> Likewise.

>>> @@ -3783,6 +3791,8 @@ cxx_eval_statement_list (const constexpr_ctx *ctx, 
>>> tree t,
>>> for (i = tsi_start (t); !tsi_end_p (i); tsi_next ())
>>> {
>>> tree stmt = tsi_stmt (i);
>>> +  if (TREE_CODE (stmt) == DEBUG_BEGIN_STMT)
>>> +   continue;
>
>> Maybe instead of handling this here, add it to the sequence of codes
>> that are returned unchanged in cxx_eval_constant_expression, after
>> PREDICT_EXPR?
>
> That would likely work, but there's a slight risk of codegen changes
> then, if a debug begin stmt happens to be present (for some reason I
> can't imagine) after the statement expression whose result we're
> supposed to use and return: we'd then overwrite the expression value we
> should use with the debug begin stmt.  Defensively, it seemed best to
> avoid that risk, even though in theory it shouldn't ever occur.

> There's another case that's more material, that also involves a debug
> begin stmt at the end of a statement list: that of an empty statement
> list.  It's not expected that cxx_eval_statement_list returns a debug
> begin stmt marker, but that's what it would do with the proposed change.
> Then we'd have to handle that up the call chain.  Maybe it doesn't
> matter, maybe it's no big deal, but by just skipping it there we can
> just not worry about it elsewhere.

I'm skeptical about adding defensive special cases everywhere to deal
with seemingly impossible situations.  If I'm not sure something's
actually impossible, I prefer to add an assert so things break more
loudly.

Jason

Re: [PATCH] fix fdump-lang-raw ICE

[Jakub Jelinek]

On Wed, Nov 01, 2017 at 03:24:56PM -0400, Nathan Sidwell wrote:
> Thomas Koenig noticed -fdump-lang-raw gives an immediate ICE.  I broke it
> with the DECL_ASSEMBLER_NAME changes last month.  Fixed thusly, applied as
> obvious.

Shouldn't there be a testcase with that option?

> 2017-11-01  Nathan Sidwell  
> 
>   * tree-dump.c (dequeue_and_dump): Use HAS_DECL_ASSEMBLER_NAME_P.
> 
> Index: tree-dump.c
> ===
> --- tree-dump.c   (revision 254314)
> +++ tree-dump.c   (working copy)
> @@ -337,7 +337,8 @@ dequeue_and_dump (dump_info_p di)
>/* All declarations have names.  */
>if (DECL_NAME (t))
>   dump_child ("name", DECL_NAME (t));
> -  if (DECL_ASSEMBLER_NAME_SET_P (t)
> +  if (HAS_DECL_ASSEMBLER_NAME_P (t)
> +   && DECL_ASSEMBLER_NAME_SET_P (t)
> && DECL_ASSEMBLER_NAME (t) != DECL_NAME (t))
>   dump_child ("mngl", DECL_ASSEMBLER_NAME (t));
>if (DECL_ABSTRACT_ORIGIN (t))


Jakub

[PATCH] fix fdump-lang-raw ICE

[Nathan Sidwell]

Thomas Koenig noticed -fdump-lang-raw gives an immediate ICE.  I broke 
it with the DECL_ASSEMBLER_NAME changes last month.  Fixed thusly, 
applied as obvious.


nathan
--
Nathan Sidwell
2017-11-01  Nathan Sidwell  

* tree-dump.c (dequeue_and_dump): Use HAS_DECL_ASSEMBLER_NAME_P.

Index: tree-dump.c
===
--- tree-dump.c (revision 254314)
+++ tree-dump.c (working copy)
@@ -337,7 +337,8 @@ dequeue_and_dump (dump_info_p di)
   /* All declarations have names.  */
   if (DECL_NAME (t))
dump_child ("name", DECL_NAME (t));
-  if (DECL_ASSEMBLER_NAME_SET_P (t)
+  if (HAS_DECL_ASSEMBLER_NAME_P (t)
+ && DECL_ASSEMBLER_NAME_SET_P (t)
  && DECL_ASSEMBLER_NAME (t) != DECL_NAME (t))
dump_child ("mngl", DECL_ASSEMBLER_NAME (t));
   if (DECL_ABSTRACT_ORIGIN (t))

Re: [PATCH,RFC] collect2 LTO for AIX

[Jim Wilson]

On 10/31/2017 12:11 PM, David Edelsohn wrote:

With your recent removal of SDB and -gcoff support, I would appreciate
your advice about my patch to incrementally add some preliminary LTO
support for AIX to collect2.c:


OK.  I can take a look.  I started a new job this week, so I'm a bit 
disorganized until I get my new work environment sorted out.


Jim

Re: [PATCH,RFC] collect2 LTO for AIX

[Jim Wilson]

On 10/30/2017 12:13 PM, Jeff Law wrote:

On 10/13/2017 12:04 PM, David Edelsohn wrote:

This patch adds the basic LTO scanning pass to the COFF support in
collect2.  I don't believe that this change should affect other COFF
targets adversely (do they even use collect2?), but I wanted to give
people an opportunity to comment.

I honestly can't remember what the COFF targets do anymore :-)  Didn't
we delete them all a while back?  I see that the generic COFF targets
died back in gcc-4.4.


We still have PE-COFF for Windows and XCOFF for AIX.  The SVR3 Unix 
COFF, embedded COFF, and ECOFF (MIPS/Alpha) support is gone.  Hopefully 
Microsoft and IBM will see the light someday and switch to ELF.


Jim

Re: [PATCH 4/9] [SFN] introduce statement frontier notes, still disabled

[Alexandre Oliva]

Hi, Jason,

Apologies for the delay in responding; somehow I missed your reply when
it arrived (probably because I had a cold back then :-), and only saw it
today.

On Oct 24, 2017, Jason Merrill  wrote:

> On Sat, Sep 30, 2017 at 5:08 AM, Alexandre Oliva  wrote:
>> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
>> index a89ee49..f9209ac 100644
>> --- a/gcc/cp/constexpr.c
>> +++ b/gcc/cp/constexpr.c
>> @@ -306,6 +306,9 @@ build_data_member_initialization (tree t, 
>> vec **vec)
>> tree_stmt_iterator i;
>> for (i = tsi_start (t); !tsi_end_p (i); tsi_next ())
>> {
>> + if (TREE_CODE (tsi_stmt (i)) == DEBUG_BEGIN_STMT)
>> +   /* ??? Can we retain this information somehow?  */

> There's no need; the result of this function isn't used for codegen
> any more, just checking.

> Why do you need a special case for this?  The existing code should
> have the same effect.

More than anything, it was to add the comment about retaining the begin
stmt markers.

Something in me wishes that, in spite of resolving the entire function
call to a constant expression, we could still express in debug info that
"we went through these statements", and maybe even single-step through
them towards the final result.

But if we all agree we don't want to do that, I'll be glad to drop the
???/FIXME markers to that effect.

>> @@ -586,6 +590,9 @@ build_constexpr_constructor_member_initializers (tree 
>> type, tree body)
>> tree_stmt_iterator i;
>> for (i = tsi_start (body); !tsi_end_p (i); tsi_next ())
>> {
>> + if (TREE_CODE (tsi_stmt (i)) == DEBUG_BEGIN_STMT)
>> +   /* ??? Can we retain this information somehow?  */

> Likewise.

>> @@ -3783,6 +3791,8 @@ cxx_eval_statement_list (const constexpr_ctx *ctx, 
>> tree t,
>> for (i = tsi_start (t); !tsi_end_p (i); tsi_next ())
>> {
>> tree stmt = tsi_stmt (i);
>> +  if (TREE_CODE (stmt) == DEBUG_BEGIN_STMT)
>> +   continue;

> Maybe instead of handling this here, add it to the sequence of codes
> that are returned unchanged in cxx_eval_constant_expression, after
> PREDICT_EXPR?

That would likely work, but there's a slight risk of codegen changes
then, if a debug begin stmt happens to be present (for some reason I
can't imagine) after the statement expression whose result we're
supposed to use and return: we'd then overwrite the expression value we
should use with the debug begin stmt.  Defensively, it seemed best to
avoid that risk, even though in theory it shouldn't ever occur.

There's another case that's more material, that also involves a debug
begin stmt at the end of a statement list: that of an empty statement
list.  It's not expected that cxx_eval_statement_list returns a debug
begin stmt marker, but that's what it would do with the proposed change.
Then we'd have to handle that up the call chain.  Maybe it doesn't
matter, maybe it's no big deal, but by just skipping it there we can
just not worry about it elsewhere.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [PATCH 9/9] [IEPM] Introduce inline entry point markers

[Alexandre Oliva]

On Oct 31, 2017, Jeff Law  wrote:

>> @@ -5691,6 +5691,15 @@ expand_gimple_basic_block (basic_block bb, bool 
>> disable_tail_calls)
>> goto delink_debug_stmt;
>> else if (gimple_debug_begin_stmt_p (stmt))
>> val = gen_rtx_DEBUG_MARKER (VOIDmode);
>> +  else if (gimple_debug_inline_entry_p (stmt))
>> +{
>> +  tree block = gimple_block (stmt);
>> +
>> +  if (block)
>> +val = gen_rtx_DEBUG_MARKER (BLKmode);
>> +  else
>> +goto delink_debug_stmt;
>> +}
>> else
>> gcc_unreachable ();
> So again, I haven't looked at prior patches.  It seems to me like we're
> abusing the mode of the debug marker rtx here.

It is still abuse if it's documented in INSN_DEBUG_MARKER_KIND and
rtl.texi?  :-)

We need some way to tell the (currently) two kinds of markers apart.  I
didn't want yet another rtl code that would have to be added to cases
all over; the distinction between markers matters at only very few
points in the compiler.  I considered adding an operand to the debug
marker, to reference a const_int that could tell them apart with room
for growth to other kinds of markers, or using any of the flag bits, but
the mode was the most visibly unused mandatory rtl field in debug
markers, so I went for it.

Changing that would make for a very localized patch, touching only this
creation point, the macro that tells the kinds apart, and the
documentation, so if you'd rather have something else, I'll be glad to
comply.



>> +/* Check whether BLOCK, a lexical block, is nested within OUTER, or is
>> +   OUTER itself.  */
>> +static bool
>> +block_within_block_p (tree block, tree outer)
>> +{
>> +  if (block == outer)
>> +return true;
>> +
>> +  /* Quickly check that OUTER is up BLOCK's supercontext chain.  */
>> +  for (tree context = BLOCK_SUPERCONTEXT (block);
>> +   context != outer;
>> +   context = BLOCK_SUPERCONTEXT (context))
>> +if (!context || TREE_CODE (context) != BLOCK)
>> +  return false;
>> +
>> +  /* Now check that each block is actually referenced by its
>> + parent.  */
> So this seemed reasonable up to here.  Based on the name and function
> comment, I'd think at this point you'd be able to return true.  We found
> OUTER in BLOCK's supercontext chain.

The part you quoted looks at only at child-to-parent links; the other
part looks at parent-to-children links, to make sure they match.  The
function is a consistency check, used only in a checking assert.  It's
intended to check both links, that the parent is reachable by the child,
and that the child is reachable by the parent.  At some point, I had
blocks that had been disconnected and discarded from the lexical block
tree, but that remained pointed-to by markers; they still pointed to
their parents, but their parents no longer pointed to them.

> But you've got another blob of code.  So it seems like you're check more
> than what the name/function comment imply.

I guess I should expand the comments ;-)

Will do...

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [PATCH], Add rounding built-ins to the _Float and _FloatX built-in functions

[Segher Boessenkool]

Hi Mike,

On Fri, Oct 27, 2017 at 06:39:21PM -0400, Michael Meissner wrote:
> The power9 (running PowerPC ISA 3.0) has a round to integer instruction
> (XSRQPI) that does various flavors of round an IEEE 128-bit floating point to
> integeral values.  This patch adds the support to the machine independent
> portion of the compiler, and adds the necessary support for ceilf128,
> roundf128, truncf128, and roundf128 to the PowerPC backend when you use
> -mcpu=power9.
> 
> I have done bootstrap builds on both x86-64 and a little endian power8 system.
> Can I install these patches to the trunk?

Do you really need to duplicate everything?  Other than that the generic
parts look fine to me (but someone else will have to approve it).

The rs6000 parts are okay for trunk.

Thanks,


Segher


> 2017-10-27  Michael Meissner  
> 
>   * builtins.def: (_Float and _FloatX BUILT_IN_CEIL): Add
>   _Float and _FloatX variants for rounding built-in
>   functions.
>   (_Float and _FloatX BUILT_IN_FLOOR): Likewise.
>   (_Float and _FloatX BUILT_IN_NEARBYINT): Likewise.
>   (_Float and _FloatX BUILT_IN_RINT): Likewise.
>   (_Float and _FloatX BUILT_IN_ROUND): Likewise.
>   (_Float and _FloatX BUILT_IN_TRUNC): Likewise.
>   * builtins.c (mathfn_built_in_2): Likewise.
>   * internal-fn.def (CEIL): Likewise.
>   (FLOOR): Likewise.
>   (NEARBYINT): Likewise.
>   (RINT): Likewise.
>   (ROUND): Likewise.
>   (TRUNC): Likewise.
>   * fold-const.c (tree_call_nonnegative_warnv_p): Likewise.
>   (integer_valued_real_call_p): Likewise.
>   * fold-const-call.c (fold_const_call_ss): Likewise.
>   * config/rs6000/rs6000.md (floor2): Add support for IEEE
>   128-bit round to integer instructions.
>   (ceil2): Likewise.
>   (btrunc2): Likewise.
>   (round2): Likewise.
> 
> [gcc/c]
> 2017-10-27  Michael Meissner  
> 
>   * c-decl.c (header_for_builtin_fn): Add integer rounding _Float
>   and _FloatX built-in functions.
> 
> [gcc/testsuite]
> 2017-10-27  Michael Meissner  
> 
>   * gcc.target/powerpc/float128-hw2.c: Add tests for ceilf128,
>   floorf128, truncf128, and roundf128.

[C++ PATCH] overloaded operator fns [8/N]

[Nathan Sidwell]

This is the last of the overloaded operator reworking.  Now we can 
cheaply go from identifier->overload info, there's no need to specially 
mark identifiers as new or delete operators themselves.  Thus we can 
reorder the cp_identifier_kind enumeration and leave space in it for 
udlit operators.


This patch does that renumbering, and reserves a value for udlit 
operators.  Those are currently detected by string compare, which isn't 
the most satisfactory way to do it.  But it's a change for another day.


nathan

--
Nathan Sidwell
2017-11-01  Nathan Sidwell  

	* cp-tree.h (enum cp_identifier_kind): Delete cik_newdel_op.
	Renumber and reserve udlit value.
	(IDENTIFIER_NEWDEL_OP): Delete.
	(IDENTIFIER_OVL_OP): New.
	(IDENTIFIER_ASSIGN_OP): Adjust.
	(IDENTIFIER_CONV_OP): Adjust.
	(IDENTIFIER_OVL_OP_INFO): Adjust.
	(IDENTIFIER_OVL_OP_FLAGS): New.
	* decl.c (grokdeclarator): Use IDENTIFIER_OVL_OP_FLAGS.
	* lex.c (get_identifier_kind_name): Adjust.
	(init_operators): Don't special case new/delete ops.
	* mangle.c (write_unqualified_id): Use IDENTIFIER_OVL_OP.
	* pt.c (push_template_decl_real): Use IDENTIFIER_OVL_OP_FLAGS.
	* typeck.c (check_return_expr): Likewise.

Index: cp-tree.h
===
--- cp-tree.h	(revision 254314)
+++ cp-tree.h	(working copy)
@@ -996,9 +996,9 @@ enum cp_identifier_kind {
   cik_dtor = 3,		/* Destructor (in-chg, deleting, complete or
 			   base).  */
   cik_simple_op = 4,	/* Non-assignment operator name.  */
-  cik_newdel_op = 5,	/* New or delete operator name.  */
-  cik_assign_op = 6,	/* An assignment operator name.  */
-  cik_conv_op = 7,	/* Conversion operator name.  */
+  cik_assign_op = 5,	/* An assignment operator name.  */
+  cik_conv_op = 6,	/* Conversion operator name.  */
+  cik_reserved_for_udlit = 7,	/* Not yet in use  */
   cik_max
 };
 
@@ -1053,24 +1053,22 @@ enum cp_identifier_kind {
 #define IDENTIFIER_ANY_OP_P(NODE)		\
   (IDENTIFIER_KIND_BIT_2 (NODE))
 
-/* True if this identifier is for new or delete operator.  Value 5.  */
-#define IDENTIFIER_NEWDEL_OP_P(NODE)		\
-  (IDENTIFIER_KIND_BIT_2 (NODE)			\
-   & (!IDENTIFIER_KIND_BIT_1 (NODE))		\
-   & IDENTIFIER_KIND_BIT_0 (NODE))
+/* True if this identifier is for an overloaded operator. Values 4, 5.  */
+#define IDENTIFIER_OVL_OP_P(NODE)		\
+  (IDENTIFIER_ANY_OP_P (NODE)			\
+   & (!IDENTIFIER_KIND_BIT_1 (NODE)))
 
-/* True if this identifier is for any assignment. Values 6.  */
+/* True if this identifier is for any assignment. Values 5.  */
 #define IDENTIFIER_ASSIGN_OP_P(NODE)		\
-  (IDENTIFIER_KIND_BIT_2 (NODE)			\
-   & IDENTIFIER_KIND_BIT_1 (NODE)		\
-   & (!IDENTIFIER_KIND_BIT_0 (NODE)))
+  (IDENTIFIER_OVL_OP_P (NODE)			\
+   & IDENTIFIER_KIND_BIT_0 (NODE))
 
 /* True if this identifier is the name of a type-conversion
operator.  Value 7.  */
 #define IDENTIFIER_CONV_OP_P(NODE)		\
-  (IDENTIFIER_KIND_BIT_2 (NODE)			\
+  (IDENTIFIER_ANY_OP_P (NODE)			\
& IDENTIFIER_KIND_BIT_1 (NODE)		\
-   & IDENTIFIER_KIND_BIT_0 (NODE))
+   & (!IDENTIFIER_KIND_BIT_0 (NODE)))
 
 /* Access a C++-specific index for identifier NODE.
Used to optimize operator mappings etc.  */
@@ -5529,9 +5527,11 @@ extern GTY(()) unsigned char ovl_op_alte
 #define OVL_OP_INFO(IS_ASS_P, TREE_CODE)			\
   (_op_info[(IS_ASS_P) != 0][ovl_op_mapping[(TREE_CODE)]])
 /* Overloaded operator info for an identifier for which
-   IDENTIFIER_ANY_OP_P is true.  */
+   IDENTIFIER_OVL_OP_P is true.  */
 #define IDENTIFIER_OVL_OP_INFO(NODE) \
-  (_op_info[IDENTIFIER_ASSIGN_OP_P (NODE)][IDENTIFIER_CP_INDEX (NODE)])
+  (_op_info[IDENTIFIER_KIND_BIT_0 (NODE)][IDENTIFIER_CP_INDEX (NODE)])
+#define IDENTIFIER_OVL_OP_FLAGS(NODE) \
+  (IDENTIFIER_OVL_OP_INFO (NODE)->flags)
 
 /* A type-qualifier, or bitmask therefore, using the TYPE_QUAL
constants.  */
Index: decl.c
===
--- decl.c	(revision 254314)
+++ decl.c	(working copy)
@@ -11744,7 +11744,8 @@ grokdeclarator (const cp_declarator *dec
 
   if (ctype && TREE_CODE (type) == FUNCTION_TYPE && staticp < 2
   && !(identifier_p (unqualified_id)
-	   && IDENTIFIER_NEWDEL_OP_P (unqualified_id)))
+	   && IDENTIFIER_OVL_OP_P (unqualified_id)
+	   && (IDENTIFIER_OVL_OP_FLAGS (unqualified_id) & OVL_OP_FLAG_ALLOC)))
 {
   cp_cv_quals real_quals = memfn_quals;
   if (cxx_dialect < cxx14 && constexpr_p
@@ -11857,7 +11858,9 @@ grokdeclarator (const cp_declarator *dec
 
 		if (virtualp
 		&& identifier_p (unqualified_id)
-		&& IDENTIFIER_NEWDEL_OP_P (unqualified_id))
+		&& IDENTIFIER_OVL_OP_P (unqualified_id)
+		&& (IDENTIFIER_OVL_OP_FLAGS (unqualified_id)
+			& OVL_OP_FLAG_ALLOC))
 		  {
 		error ("%qD cannot be declared %, since it "
 			   "is always static", unqualified_id);
Index: lex.c
===
--- lex.c	(revision 254314)
+++ lex.c	(working copy)
@@ -100,7 +100,8 @@ 

[Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

[Paul Richard Thomas]

Dear All,

This patch is adequately described by the comment in the second chunk
applied to resolve.c.

Note, however, that the 'unconditionally' is promptly undermined by
the subsequent conditions. I will change the adjective appropriately.
In writing this, I have just realised that access=private need not
have a vtable generated unless it is required for a class within the
module. I will make it so a regtest once more.

Some of the increases in counts in the tree dumps look alarming. They
are however just a reflection of the number of derived types in some
of the tests and are due to the auxiliary vtable functions.

Bootstrapped and regtested on FC23/x86_64 - OK for trunk and then 7- branch?

Paul

2017-11-01  Paul Thomas  

PR fortran/81447
PR fortran/82783
* resolve.c (resolve_component): There is no need to resolve
the components of a use associated vtype.
(resolve_fl_derived): Unconditionally generate a vtable for any
module derived type, as long as the standard is F2003 or later
and it is not a vtype or a PDT template.

2017-11-01  Paul Thomas  

PR fortran/81447
* gfortran.dg/class_65.f90: New test.
* gfortran.dg/alloc_comp_basics_1.f90: Increase builtin_free
count from 18 to 21.
* gfortran.dg/allocatable_scalar_9.f90: Increase builtin_free
count from 32 to 54.
* gfortran.dg/auto_dealloc_1.f90: Increase builtin_free
count from 4 to 10.
* gfortran.dg/coarray_lib_realloc_1.f90: Increase builtin_free
count from 3 to 6. Likewise _gfortran_caf_deregister from 2 to
3, builtin_malloc from 1 to 4 and builtin_memcpy|= MEM from
2 to 5.
* gfortran.dg/finalize_28.f90: Increase builtin_free
count from 3 to 6.
* gfortran.dg/move_alloc_15.f90: Increase builtin_free and
builtin_malloc counts from 11 to 14.
* gfortran.dg/typebound_proc_27.f03: Increase builtin_free
count from 7 to 10. Likewise builtin_malloc from 12 to 15.
Index: gcc/fortran/match.c
===
*** gcc/fortran/match.c (revision 254300)
--- gcc/fortran/match.c (working copy)
*** gfc_match_allocate (void)
*** 4010,4019 
  
  /* TODO understand why this error does not appear but, instead,
 the derived type is caught as a variable in primary.c.  */
! if (gfc_spec_list_type (type_param_spec_list, NULL) != SPEC_EXPLICIT)
{
  gfc_error ("The type parameter spec list in the type-spec at "
!"%L cannot contain ASSUMED or DEFERRED parameters",
 _locus);
  goto cleanup;
}
--- 4010,4019 
  
  /* TODO understand why this error does not appear but, instead,
 the derived type is caught as a variable in primary.c.  */
! if (gfc_spec_list_type (type_param_spec_list, NULL) == SPEC_DEFERRED)
{
  gfc_error ("The type parameter spec list in the type-spec at "
!"%L cannot contain DEFERRED parameters",
 _locus);
  goto cleanup;
}
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 254300)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_component (gfc_component *c, gfc
*** 13496,13501 
--- 13496,13504 
if (c->attr.artificial)
  return true;
  
+   if (sym->attr.vtype && sym->attr.use_assoc)
+ return true;
+ 
/* F2008, C442.  */
if ((!sym->attr.is_class || c != sym->components)
&& c->attr.codimension
*** resolve_fl_derived (gfc_symbol *sym)
*** 14075,14080 
--- 14078,14096 
if (!resolve_typebound_procedures (sym))
  return false;
  
+   /* Generate module vtables unconditionally. If this is not done
+  class declarations in external procedures wind up with their
+  own version and so SELECT TYPE fails because the vptrs do not
+  have the same address.  */
+   if (gfc_option.allow_std & GFC_STD_F2003
+   && sym->ns->proc_name
+   && sym->ns->proc_name->attr.flavor == FL_MODULE
+   && !(sym->attr.use_assoc || sym->attr.vtype || sym->attr.pdt_template))
+ {
+   gfc_symbol *vtab = gfc_find_derived_vtab (sym);
+   gfc_set_sym_referenced (vtab);
+ }
+ 
return true;
  }
  
Index: gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90
===
*** gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90   (revision 254300)
--- gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90   (working copy)
*** contains
*** 141,144 
  end subroutine check_alloc2
  
  end program alloc
! ! { dg-final { scan-tree-dump-times "builtin_free" 18 "original" } }
--- 141,144 
  end subroutine check_alloc2
  
  end program alloc
! ! { dg-final { 

Re: [PATCH 6/9] [LVU] Allow final_start_function to skip initial insns

[Alexandre Oliva]

On Oct 31, 2017, Jeff Law  wrote:

> On 09/30/2017 03:08 AM, Alexandre Oliva wrote:
>> This API change will enable final_start_function() to "consume"
>> initial insns, and choose the first insn to be passed to final().
>> 
>> Many ports call final_start_function() and final() when creating
>> thunks and whatnot, so they needed adjusting.
> So I haven't really followed the discussion until now.  What's driving
> the need to have some insns "consumed" and have more control over what
> tthe first insn passed to final will be?

We want to build debug notes that bind arguments into the initial view
in a function.  That initial view (first .loc note) is emitted in
final_start_function.  So we don't want to process the initial debug
bind insns in final_start_function, and not process them again in final.

In response to richi's objections, I reverted the API exposed by final.c
so that we process the loc notes in final_start_function, and just skip
them in final, so that no changes are required to the various backends,
at a very slight performance penalty as the leading debug insns will be
looked at twice instead of just once, when final is so used by the
backends.

As for uses within final.c, those benefit from an API change internal to
that file, that allows the leading debug insns to be processed just
once.  Here are the relevant snippets from the updated patchset (yet to
be posted):


+/* We want to emit param bindings (before the first begin_stmt) in the
+   initial view, if we are emitting views.  To that end, we may
+   consume initial notes in the function, processing them in
+   final_start_function, before signaling the beginning of the
+   prologue, rather than in final.
+
+   We don't test whether the DECLs are PARM_DECLs: the assumption is
+   that there will be a NOTE_INSN_BEGIN_STMT marker before any
+   non-parameter NOTE_INSN_VAR_LOCATION.  It's ok if the marker is not
+   there, we'll just have more variable locations bound in the initial
+   view, which is consistent with their being bound without any code
+   that would give them a value.  */
+
+static inline bool
+in_initial_view_p (rtx_insn *insn)
+{
+  return !DECL_IGNORED_P (current_function_decl)
+&& debug_variable_location_views
+&& insn && GET_CODE (insn) == NOTE
+&& NOTE_KIND (insn) == NOTE_INSN_VAR_LOCATION;
+}
+
 /* Output assembler code for the start of a function,
and initialize some of the variables in this file
for the new function.  The label for the function and associated
@@ -1757,12 +1819,15 @@ get_some_local_dynamic_name ()
 
FIRST is the first insn of the rtl for the function being compiled.
FILE is the file to write assembler code to.
+   SEEN should be initially set to zero, and it may be updated to
+   indicate we have references to the next location view, that would
+   require us to emit it at the current PC.
OPTIMIZE_P is nonzero if we should eliminate redundant
  test and compare insns.  */
 
-void
-final_start_function (rtx_insn *first, FILE *file,
- int optimize_p ATTRIBUTE_UNUSED)
+static void
+final_start_function_1 (rtx_insn **firstp, FILE *file, int *seen,
+   int optimize_p ATTRIBUTE_UNUSED)
 {
   block_depth = 0;
 
@@ -1780,8 +1845,21 @@ final_start_function (rtx_insn *first, FILE *file,
   if (flag_sanitize & SANITIZE_ADDRESS)
 asan_function_start ();
 
+  rtx_insn *first = *firstp;
+  if (in_initial_view_p (first))
+{
+  do
+   {
+ final_scan_insn (first, file, 0, 0, seen);
+ first = NEXT_INSN (first);
+   }
+  while (in_initial_view_p (first));
+  *firstp = first;
+}
+
   if (!DECL_IGNORED_P (current_function_decl))
@@ -1856,6 +1934,17 @@ final_start_function (rtx_insn *first, FILE *file,
 profile_after_prologue (file);
 }
 
+/* This is an exported final_start_function_1, callable without SEEN.  */
+
+void
+final_start_function (rtx_insn *first, FILE *file,
+ int optimize_p ATTRIBUTE_UNUSED)
+{
+  int seen = 0;
+  final_start_function_1 (, file, , optimize_p);
+  gcc_assert (seen == 0);
+}
+
 static void
 profile_after_prologue (FILE *file ATTRIBUTE_UNUSED)
 {
@@ -1987,11 +2076,10 @@ dump_basic_block_info (FILE *file, rtx_insn *insn, 
basic_block *start_to_bb,
 /* Output assembler code for some insns: all or part of a function.
For description of args, see `final_start_function', above.  */
 
-void
-final (rtx_insn *first, FILE *file, int optimize_p)
+static void
+final_1 (rtx_insn *first, FILE *file, int seen, int optimize_p)
 {
   rtx_insn *insn, *next;
-  int seen = 0;
 
   /* Used for -dA dump.  */
   basic_block *start_to_bb = NULL;
@@ -2074,6 +2164,23 @@ final (rtx_insn *first, FILE *file, int optimize_p)
delete_insn (insn);
 }
 }
+
+/* This is an exported final_1, callable without SEEN.  */
+
+void
+final (rtx_insn *first, FILE *file, int optimize_p)
+{
+  /* Those that use the internal final_start_function_1/final_1 API

Re: Fix pretty printers for versioned namespace

[François Dumont]

On 30/10/2017 19:15, Jonathan Wakely wrote:



@@ -1227,7 +1227,12 @@ class Printer(object):
   def add_version(self, base, name, function):
   self.add(base + name, function)
   if _versioned_namespace:
-    self.add(base + _versioned_namespace + name, function)
+    vbase = re.sub('^std::', 'std::%s' % 
_versioned_namespace, base)

+    if vbase != base:
+    self.add(vbase + name, function)
+    vbase = re.sub('^__gnu_cxx::', '__gnu_cxx::%s' % 
_versioned_namespace, base)

+    if vbase != base:
+    self.add(vbase + name, function)


Only one re.sub is needed:

vbase = re.sub('^(std|__gnu_cxx)::', r'\1::%s' % 
_versioned_namespace, base)


Or using \g<0> to refer to the whole match:

vbase = re.sub('^(std|__gnu_cxx)::', r'\g<0>%s' % 
_versioned_namespace, base)



OK for trunk with that change, assuming it works. Thanks.

It worked, attached patch applied.

François

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index b7b2a0f..2b54065 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -973,8 +973,8 @@ class StdExpAnyPrinter(SingleObjContainerPrinter):
 "Print a std::any or std::experimental::any"
 
 def __init__ (self, typename, val):
-self.typename = re.sub('^std::experimental::fundamentals_v\d::', 'std::experimental::', typename, 1)
-self.typename = strip_versioned_namespace(self.typename)
+self.typename = strip_versioned_namespace(typename)
+self.typename = re.sub('^std::experimental::fundamentals_v\d::', 'std::experimental::', self.typename, 1)
 self.val = val
 self.contained_type = None
 contained_value = None
@@ -1021,8 +1021,8 @@ class StdExpOptionalPrinter(SingleObjContainerPrinter):
 
 def __init__ (self, typename, val):
 valtype = self._recognize (val.type.template_argument(0))
-self.typename = re.sub('^std::(experimental::|)(fundamentals_v\d::|)(.*)', r'std::\1\3<%s>' % valtype, typename, 1)
-self.typename = strip_versioned_namespace(self.typename)
+self.typename = strip_versioned_namespace(typename)
+self.typename = re.sub('^std::(experimental::|)(fundamentals_v\d::|)(.*)', r'std::\1\3<%s>' % valtype, self.typename, 1)
 if not self.typename.startswith('std::experimental'):
 val = val['_M_payload']
 self.val = val
@@ -1043,8 +1043,8 @@ class StdVariantPrinter(SingleObjContainerPrinter):
 
 def __init__(self, typename, val):
 alternatives = self._template_args(val)
-self.typename = "%s<%s>" % (typename, ', '.join([self._recognize(alt) for alt in alternatives]))
-self.typename = strip_versioned_namespace(self.typename)
+self.typename = strip_versioned_namespace(typename)
+self.typename = "%s<%s>" % (self.typename, ', '.join([self._recognize(alt) for alt in alternatives]))
 self.index = val['_M_index']
 if self.index >= len(alternatives):
 self.contained_type = None
@@ -1227,7 +1227,8 @@ class Printer(object):
 def add_version(self, base, name, function):
 self.add(base + name, function)
 if _versioned_namespace:
-self.add(base + _versioned_namespace + name, function)
+vbase = re.sub('^(std|__gnu_cxx)::', r'\g<0>%s' % _versioned_namespace, base)
+self.add(vbase + name, function)
 
 # Add a name using _GLIBCXX_BEGIN_NAMESPACE_CONTAINER.
 def add_container(self, base, name, function):
@@ -1507,7 +1508,7 @@ def build_libstdcxx_dictionary ():
 # In order from:
 # http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01847.html
 libstdcxx_printer.add_version('std::', 'basic_string', StdStringPrinter)
-libstdcxx_printer.add_version('std::', '__cxx11::basic_string', StdStringPrinter)
+libstdcxx_printer.add_version('std::__cxx11::', 'basic_string', StdStringPrinter)
 libstdcxx_printer.add_container('std::', 'bitset', StdBitsetPrinter)
 libstdcxx_printer.add_container('std::', 'deque', StdDequePrinter)
 libstdcxx_printer.add_container('std::', 'list', StdListPrinter)
@@ -1555,15 +1556,15 @@ def build_libstdcxx_dictionary ():
 libstdcxx_printer.add_container('std::', 'forward_list',
 StdForwardListPrinter)
 
-libstdcxx_printer.add_version('std::', 'tr1::shared_ptr', SharedPointerPrinter)
-libstdcxx_printer.add_version('std::', 'tr1::weak_ptr', SharedPointerPrinter)
-libstdcxx_printer.add_version('std::', 'tr1::unordered_map',
+libstdcxx_printer.add_version('std::tr1::', 'shared_ptr', SharedPointerPrinter)
+libstdcxx_printer.add_version('std::tr1::', 'weak_ptr', SharedPointerPrinter)
+libstdcxx_printer.add_version('std::tr1::', 'unordered_map',
   Tr1UnorderedMapPrinter)
-libstdcxx_printer.add_version('std::', 

Re: [PATCH] RISC-V: Document the medlow and medany code models

[Palmer Dabbelt]

Committed.

On Tue, 31 Oct 2017 23:37:04 PDT (-0700), Andrew Waterman wrote:
> Thanks for caring enough about our patches to even notice the grammar :)
>
> On Tue, Oct 31, 2017 at 11:09 PM, Sandra Loosemore
>  wrote:
>> On 10/31/2017 10:27 PM, Andrew Waterman wrote:
>>>
>>> I have to disagree.  It's standard to not hyphenate an
>>> adverb-adjective compound, since they tend not to be ambiguous.  But
>>> if the standard in the GCC documentation is to hyphenate, I will not
>>> stand in the way!
>>
>>
>> Heh, you got me on this one -- it's one of those weird special cases, the
>> "adverb ending in -ly plus participle" case listed here:
>>
>> http://www.chicagomanualofstyle.org/16/images/ch07_tab01.pdf
>>
>> So the patch is OK as-is, but maybe I need a few new brain cells.  :-P
>>
>> -Sandra
>>

Re: [PATCH, rs6000 V3] Add Power 8 support to vec_revb

[Segher Boessenkool]

Hi Carl,

On Fri, Oct 27, 2017 at 09:49:04AM -0700, Carl Love wrote:
> > > +;; Swap all bytes in each element of vector
> > > +(define_expand "revb_"
> > > +  [(set (match_operand:VEC_A 0 "vsx_register_operand")
> > > + (bswap:VEC_A (match_operand:VEC_A 1 "vsx_register_operand")))]
> > > +  "TARGET_P9_VECTOR"
> > > +{
> > > +  rtx sel;
> > 
> > So a special case here:
> > 
> >   if (mode == V16QImode)
> > {
> >   emit_move_insn (operands[0], operands[1]);
> >   DONE;
> > }
> 
> Even if I put in the above special case, I still have issues with the
> .  The updated code for the expand with the special case above is

[ snip ]

> The issue is the if (mode == V16QImode) does not prevent the code
> in the else statement from getting expanded for . I agree it will
> prevent the generation of the instruction but the code is still expanded
> and compiled.  I get the error message:
> 
> /home/carll/GCC/gcc-revb/gcc/config/rs6000/vsx.md:4727:62: error:
> ‘gen_p9_xxbrb_v16qi’ was not declared in this scope
>emit_insn (gen_p9_xxbr_ (operands[0], operands[1]));
> 
> Because  for mode v16qi still gets expanded to "b" not "q".
> 
> There is no definition for "gen_p9_xxbrb_v16qi" since xxbrb is not
> vaild.  Short of using a different expander for  I don't see how to
> not get the expansion.  Sorry if I am missing something obvious here.

I think you'll need another iterator, like VEC_A but without the V16QI
(possibly not the float modes either?)


Segher

Re: [PATCH][AArch64] Define MALLOC_ABI_ALIGNMENT

[James Greenhalgh]

On Tue, Oct 31, 2017 at 05:07:54PM +, Wilco Dijkstra wrote:
> The AArch64 backend currently doesn't set MALLOC_ABI_ALIGNMENT, so
> add this to enable alignment optimizations on malloc pointers.
> 
> OK for commit?

As far as I understand it, because we have 128-bit types, a malloc of
anything greater than 16 bytes would require 16-byte alignment. So, assuming
this macro isn't required to desribe possibly unaligned smaller allocations
(for example 1 byte allocations), this is OK.

Reviewed-By: James Greenhalgh 

Thanks,
James

> 
> 2017-10-31  Wilco Dijkstra  
> 
>   * config/aarch64/aarch64.h (MALLOC_ABI_ALIGNMENT): New define.
> --
> diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
> index 
> 8e7093f0476fa7fed3ba6d6cb008743106d1ff58..159dde7c7134d4d0e5378951d1d8a1d6dab48ba2
>  100644
> --- a/gcc/config/aarch64/aarch64.h
> +++ b/gcc/config/aarch64/aarch64.h
> @@ -111,6 +111,9 @@
>  
>  #define STRUCTURE_SIZE_BOUNDARY  8
>  
> +/* Heap alignment.  */
> +#define MALLOC_ABI_ALIGNMENT  BIGGEST_ALIGNMENT
> +
>  /* Defined by the ABI */
>  #define WCHAR_TYPE "unsigned int"
>  #define WCHAR_TYPE_SIZE  32

[PATCH] PR libstdc++/82777 fix path normalization for dot-dot

[Jonathan Wakely]

This fixes a bug in the implementation of the normalization algo. I
messed up a case with adjacent ../.. elements, because it's written to
work in a single pass, rather than applying each of the rules in turn,
creating loads of temporaries and reallocations.

PR libstdc++/82777
* src/filesystem/std-path.cc (path::lexically_normal): Remove dot-dot
elements correctly.
* testsuite/27_io/filesystem/path/generation/normal.cc: Add testcase.
* testsuite/util/testsuite_fs.h (compare_paths): Improve exception
text.

Tested powerpc64le-linux, committed to trunk.

commit a7c908d1b56118b3a6bd844c7511fc0d9377
Author: Jonathan Wakely 
Date:   Wed Nov 1 16:07:56 2017 +

PR libstdc++/82777 fix path normalization for dot-dot

PR libstdc++/82777
* src/filesystem/std-path.cc (path::lexically_normal): Remove 
dot-dot
elements correctly.
* testsuite/27_io/filesystem/path/generation/normal.cc: Add 
testcase.
* testsuite/util/testsuite_fs.h (compare_paths): Improve exception
text.

diff --git a/libstdc++-v3/src/filesystem/std-path.cc 
b/libstdc++-v3/src/filesystem/std-path.cc
index 1e2a8fad584..330aee72b13 100644
--- a/libstdc++-v3/src/filesystem/std-path.cc
+++ b/libstdc++-v3/src/filesystem/std-path.cc
@@ -388,10 +388,35 @@ path::lexically_normal() const
 #endif
   if (is_dotdot(p))
{
- if (ret.has_filename() && !is_dotdot(ret.filename()))
-   ret.remove_filename();
- else if (ret.has_filename() || !ret.has_root_directory())
-   ret /= p;
+ if (ret.has_filename())
+   {
+ // remove a non-dot-dot filename immediately followed by /..
+ if (!is_dotdot(ret.filename()))
+   ret.remove_filename();
+ else
+   ret /= p;
+   }
+ else if (!ret.has_relative_path())
+   {
+ if (!ret.is_absolute())
+   ret /= p;
+   }
+ else
+   {
+ // Got a path with a relative path (i.e. at least one non-root
+ // element) and no filename at the end (i.e. empty last element),
+ // so must have a trailing slash. See what is before it.
+ auto elem = std::prev(ret.end(), 2);
+ if (elem->has_filename() && !is_dotdot(*elem))
+   {
+ // Remove the filename before the trailing slash
+ // (equiv. to ret = ret.parent_path().remove_filename())
+ ret._M_pathname.erase(elem._M_cur->_M_pos);
+ ret._M_cmpts.erase(elem._M_cur, ret._M_cmpts.end());
+   }
+ else // ???
+   ret /= p;
+   }
}
   else if (is_dot(p))
ret /= path();
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/generation/normal.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/generation/normal.cc
index 789ce186f82..df3b7154ab3 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/generation/normal.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/generation/normal.cc
@@ -46,6 +46,10 @@ test02()
   compare_paths( path().lexically_normal(), "" );
 
   compare_paths( path("/..").lexically_normal(), "/" );
+
+  // PR libstdc++/82777
+  compare_paths( path("./a/b/c/../.././b/c").lexically_normal(), "a/b/c" );
+  compare_paths( path("/a/b/c/../.././b/c").lexically_normal(), "/a/b/c" );
 }
 
 void
diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
b/libstdc++-v3/testsuite/util/testsuite_fs.h
index 47f56090b47..c18dae28fcc 100644
--- a/libstdc++-v3/testsuite/util/testsuite_fs.h
+++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
@@ -40,7 +40,7 @@ namespace __gnu_test
 {
 #define PATH_CHK(p1, p2, fn) \
 if ( p1.fn() != p2.fn() ) \
-  throw test_fs::filesystem_error( #fn, p1, p2, \
+  throw test_fs::filesystem_error("comparing '" #fn "' failed", p1, p2, \
  std::make_error_code(std::errc::invalid_argument) )
 
   void

Re: [PATCH] Use Pcrt1.o%s/gPcrt1.o%s for -static-pie

[H.J. Lu]

On Wed, Nov 1, 2017 at 9:32 AM, Rich Felker  wrote:
> On Sun, Oct 15, 2017 at 06:16:57AM -0700, H.J. Lu wrote:
>> crt1.o is used to create dynamic and non-PIE static executables.  Static
>> PIE needs to link with Pcrt1.o, instead of crt1.o, to relocate static PIE
>> at run-time.  When -pg is used with -static-pie, gPcrt1.o should be used.
>>
>> Tested on x86-64.  OK for master?
>
> Is there a reason you didn't follow the existing naming practice here?
> Openbsd and musl libc have both had static pie for a long time now and
> have used rcrt1.o as the name.

I wasn't aware of rcrt1.o and there is no reference to rcrt1.o in GCC at all.
Does the FSF GCC support static PIE for musl libc? If not, is there a GCC
bug for it?

BTW, I don't mind replacing Pcrt1.o/gPcrt1.o with rcrt1.o/grcrt1.o.


-- 
H.J.

[PATCH] combine: Fix bug in giving up placing REG_DEAD notes (PR82683)

[Segher Boessenkool]

When we have a REG_DEAD note for a reg that is set in the new I2, we
drop the note on the floor (we cannot find whether to place it on I2
or on I3).  But the code I added to do this has a bug and does not
always actually drop it.  This patch fixes it.

But that on its own is too pessimistic, it turns out, and we generate
worse code.  One case where we do know where to place the note is if
it came from I3 (it should go to I3 again).  Doing this fixes all of
the regressions.

Tested on an aarch64 cross-compiler with the PR82683 test; tested on
powerpc64-linux {-m32,-m64}.  Committing to trunk, will backport later.


Segher


2017-11-01  Segher Boessenkool  

PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

---
 gcc/combine.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/gcc/combine.c b/gcc/combine.c
index 4fba2c1..5782013 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -14388,6 +14388,17 @@ distribute_notes (rtx notes, rtx_insn *from_insn, 
rtx_insn *i3, rtx_insn *i2,
  && CALL_P (from_insn)
  && find_reg_fusage (from_insn, USE, XEXP (note, 0)))
place = from_insn;
+ else if (i2 && reg_set_p (XEXP (note, 0), PATTERN (i2)))
+   {
+ /* If the new I2 sets the same register that is marked
+dead in the note, we do not in general know where to
+put the note.  One important case we _can_ handle is
+when the note comes from I3.  */
+ if (from_insn == i3)
+   place = i3;
+ else
+   break;
+   }
  else if (reg_referenced_p (XEXP (note, 0), PATTERN (i3)))
place = i3;
  else if (i2 != 0 && next_nonnote_nondebug_insn (i2) == i3
@@ -14401,11 +14412,6 @@ distribute_notes (rtx notes, rtx_insn *from_insn, 
rtx_insn *i3, rtx_insn *i2,
   || rtx_equal_p (XEXP (note, 0), elim_i0))
break;
  tem_insn = i3;
- /* If the new I2 sets the same register that is marked dead
-in the note, we do not know where to put the note.
-Give up.  */
- if (i2 != 0 && reg_set_p (XEXP (note, 0), PATTERN (i2)))
-   break;
}
 
  if (place == 0)
-- 
1.8.3.1

Re: [PATCH] Use Pcrt1.o%s/gPcrt1.o%s for -static-pie

[Rich Felker]

On Sun, Oct 15, 2017 at 06:16:57AM -0700, H.J. Lu wrote:
> crt1.o is used to create dynamic and non-PIE static executables.  Static
> PIE needs to link with Pcrt1.o, instead of crt1.o, to relocate static PIE
> at run-time.  When -pg is used with -static-pie, gPcrt1.o should be used.
> 
> Tested on x86-64.  OK for master?

Is there a reason you didn't follow the existing naming practice here?
Openbsd and musl libc have both had static pie for a long time now and
have used rcrt1.o as the name.

Rich


> ---
>   * config/gnu-user.h (GNU_USER_TARGET_STARTFILE_SPEC): Use
>   Pcrt1.o%s/gPcrt1.o%s for -static-pie.
> ---
>  gcc/config/gnu-user.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h
> index a967b69a350..c1cfdc3da90 100644
> --- a/gcc/config/gnu-user.h
> +++ b/gcc/config/gnu-user.h
> @@ -51,9 +51,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
> If not, see
>  #if defined HAVE_LD_PIE
>  #define GNU_USER_TARGET_STARTFILE_SPEC \
>"%{shared:; \
> - pg|p|profile:gcrt1.o%s; \
> + pg|p|profile:%{static-pie:gPcrt1.o%s;:gcrt1.o%s}; \
>   static:crt1.o%s; \
> - static-pie|" PIE_SPEC ":Scrt1.o%s; \
> + static-pie:Pcrt1.o%s; \
> + " PIE_SPEC ":Scrt1.o%s; \
>   :crt1.o%s} \
> crti.o%s \
> %{static:crtbeginT.o%s; \
> -- 
> 2.13.5

Re: [09/nn] Add a fixed_size_mode_pod class

[Jeff Law]

On 10/31/2017 08:47 PM, Trevor Saunders wrote:

On Tue, Oct 31, 2017 at 11:38:48AM -0600, Jeff Law wrote:

On 10/31/2017 11:22 AM, Eric Botcazou wrote:

I don't see a reason not to other than a pretty small amount of work
each time we make a release.


I'm not sure it would be so small an amount of work, especially on non-Linux
platforms, so this would IMO divert our resources for little benefit.

Having done this for years on HPUX, yes, it takes more time than one
could imagine.  THen I went to work for a company that did this for
hpux, solaris, aix, irix and others and well, it was very painful.


I'm sure its a project one can spend arbitrary amounts of time on if one
wishes or is payed to do so.  That said I'm considering the scope here
limitted to running configure / make  / make install with the defaults
and taring up the result.  I'll admitt I've only done that on linux
where it was easy, but people do keep AIX and Solaris building and they
really are supposed to be buildable in a release.  However at some point
it can be less work to do this than to beat C++98 into doing what is
desired.
It sounds so easy, but it does get more complex than just build and tar 
the result up.  How (for example) do you handle DSOs that may or may not 
be on the system where the bits get installed.  Do you embed them or 
tell the user to go get them?That's just one example of a gotcha, 
there's many.


It's really not something I'd suggest we pursue all that deeply.  Been 
there, done that wouldn't want to do it again.



Thirdly making it easier to work on the compiler and understand it makes
things easier for those possible contributors, so if being able to use
C++11 advances that goalthings could be better over all for possible
contributors with different system compilers.


I don't buy this at all.  You don't need bleeding edge C++ features to build a
compiler and people don't work on compilers to use bleeding edge C++.  Using a
narrow and sensible set of C++ features was one of the conditions under which
the switch to C++ as implementation language was accepted at the time.

Agreed that we need to stick with a sensible set of features.  But the
sensible set isn't necessarily fixed forever.


Also as a counter example what brought this thread up is Richard wanting
to use something from C++11.  So in that particular case it probably
would make something better.
In my particular case I could use certain C++11 features to make the 
code cleaner/easier to prove right -- particularly rvalue references and 
move semantics.  I've got an object with a chunk of allocated memory.  I 
want to move ownership of the memory to another object.


C++11 handles this cleanly and gracefully and in doing so makes it very 
hard to get it wrong.


However, I don't think  my case, in and of itself, is enough to push us 
into the C++11 world.  Nor am I convinced that the aggregate of these 
things is enough to push us into the C++11 world.  But I do think we'll 
be there at some point.


jeff

Re: [C++ PATCH] overloaded operator fns [6/N]

[Nathan Sidwell]

This patch shrinks the lang_fn_decl's operator_code field from 16 to 6 
bits, by storing the compressed operator code instead of the tree_code.


I rename DECL_OVERLOADED_OPERATOR_CODE to 
DECL_OVERLOADED_OPERATOR_CODE_RAW, to remind that it's not a tree_code. 
DECL_OVERLOADED_OPERATOR_CODE_IS remains with checking a literal tree 
code.  It uses preprocessor concatenation to directly map the tree_code 
name to the compressed operator enumeration.  So no runtime indirection!


nathan

--
Nathan Sidwell
2017-11-01  Nathan Sidwell  

	gcc/cp/
	* cp-tree.h (assign_op_identifier, call_op_identifier): Use
	compressed code.
	(struct lang_decl_fn): Use compressed operator code.
	(DECL_OVERLOADED_OPERATOR_CODE): Replace with ...
	(DECL_OVERLOADED_OPERATOR_CODE_RAW): ... this.
	(DECL_OVERLOADED_OPERATOR_CODE_IS): Use it.
	* decl.c (duplicate_decls): Use DECL_OVERLOADED_OPERATOR_CODE_RAW.
	(build_library_fn): Likewise.
	(grok_op_properties): Likewise.
	* mangle.c (write_unqualified_name): Likewise.
	* method.c (implicitly_declare_fn): Likewise.
	* typeck.c (check_return_expr): Use DECL_OVERLOADED_OPERATOR_IS.

	libcc1/
	* libcp1plugin.cc (plugin_build_decl): Use
	DECL_OVERLOADED_OPERATOR_CODE_RAW.

Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h	(revision 254311)
+++ gcc/cp/cp-tree.h	(working copy)
@@ -246,8 +246,8 @@ extern GTY(()) tree cp_global_trees[CPTI
 #define deleting_dtor_identifier	cp_global_trees[CPTI_DELETING_DTOR_IDENTIFIER]
 
 #define ovl_op_identifier(ISASS, CODE)  (OVL_OP_INFO(ISASS, CODE)->identifier)
-#define assign_op_identifier (ovl_op_identifier (true, NOP_EXPR))
-#define call_op_identifier (ovl_op_identifier (false, CALL_EXPR))
+#define assign_op_identifier (ovl_op_info[true][OVL_OP_NOP_EXPR].identifier)
+#define call_op_identifier (ovl_op_info[false][OVL_OP_CALL_EXPR].identifier)
 /* The name used for conversion operators -- but note that actual
conversion functions use special identifiers outside the identifier
table.  */
@@ -2479,26 +2479,24 @@ struct GTY(()) lang_decl_min {
 struct GTY(()) lang_decl_fn {
   struct lang_decl_min min;
 
-  /* In an overloaded operator, this is the value of
- DECL_OVERLOADED_OPERATOR_P.
- FIXME: We should really do better in compressing this.  */
-  ENUM_BITFIELD (tree_code) operator_code : 16;
-
+  /* In a overloaded operator, this is the compressed operator code.  */
+  unsigned ovl_op_code : 6;
   unsigned global_ctor_p : 1;
   unsigned global_dtor_p : 1;
+
   unsigned static_function : 1;
   unsigned pure_virtual : 1;
   unsigned defaulted_p : 1;
   unsigned has_in_charge_parm_p : 1;
   unsigned has_vtt_parm_p : 1;
   unsigned pending_inline_p : 1;
-
   unsigned nonconverting : 1;
   unsigned thunk_p : 1;
+
   unsigned this_thunk_p : 1;
   unsigned hidden_friend_p : 1;
   unsigned omp_declare_reduction_p : 1;
-  /* 3 spare bits.  */
+  unsigned spare : 13;
 
   /* 32-bits padding on 64-bit host.  */
 
@@ -2814,14 +2812,14 @@ struct GTY(()) lang_decl {
   IDENTIFIER_ASSIGN_OP_P (DECL_NAME (NODE))
 
 /* NODE is a function_decl for an overloaded operator.  Return its
-   operator code.   */
-#define DECL_OVERLOADED_OPERATOR_CODE(NODE)			\
-  (LANG_DECL_FN_CHECK (NODE)->operator_code)
+   compressed (raw) operator code.  Note that this is not a TREE_CODE.  */
+#define DECL_OVERLOADED_OPERATOR_CODE_RAW(NODE)		\
+  (LANG_DECL_FN_CHECK (NODE)->ovl_op_code)
 
 /* DECL is an overloaded operator.  Test whether it is for TREE_CODE
(a literal constant).  */
 #define DECL_OVERLOADED_OPERATOR_IS(DECL, CODE)			\
-  (DECL_OVERLOADED_OPERATOR_CODE (DECL) == CODE)
+  (DECL_OVERLOADED_OPERATOR_CODE_RAW (DECL) == OVL_OP_##CODE)
 
 /* For FUNCTION_DECLs: nonzero means that this function is a
constructor or a destructor with an extra in-charge parameter to
@@ -5526,7 +5524,8 @@ extern GTY(()) unsigned char ovl_op_mapp
 extern GTY(()) unsigned char ovl_op_alternate[OVL_OP_MAX];
 
 /* Given an ass_op_p boolean and a tree code, return a pointer to its
-   overloaded operator info.  */
+   overloaded operator info.  Tree codes for non-overloaded operators
+   map to the error-operator.  */
 #define OVL_OP_INFO(IS_ASS_P, TREE_CODE)			\
   (_op_info[(IS_ASS_P) != 0][ovl_op_mapping[(TREE_CODE)]])
 /* Overloaded operator info for an identifier for which
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c	(revision 254311)
+++ gcc/cp/decl.c	(working copy)
@@ -1920,8 +1920,8 @@ next_arg:;
   DECL_OVERRIDE_P (newdecl) |= DECL_OVERRIDE_P (olddecl);
   DECL_THIS_STATIC (newdecl) |= DECL_THIS_STATIC (olddecl);
   if (DECL_OVERLOADED_OPERATOR_P (olddecl))
-	DECL_OVERLOADED_OPERATOR_CODE (newdecl)
-	  = DECL_OVERLOADED_OPERATOR_CODE (olddecl);
+	DECL_OVERLOADED_OPERATOR_CODE_RAW (newdecl)
+	  = DECL_OVERLOADED_OPERATOR_CODE_RAW (olddecl);
   new_defines_function = DECL_INITIAL (newdecl) != NULL_TREE;
 
   /* 

[C++ PATCH] overloaded operator fns [6/N]

[Nathan Sidwell]

This patch adds a new enum for the overloaded operators, we only 
enumerate the codes we need, and thus can shrink the ovl_op_info array. 
We do need to create a mapping array to go from tree_code to ovl_op_code.


More significantly is the use of the base.u.bits.address_space field, 
which is otherwise unused in an identifier.  We can use this as an 
arbitrary 8-bit index.  Which indeed this patch does for the overloaded 
operators.  This means grok_op_properties and mangling can directly 
index the operator information, rather than search for them.  We also 
simplify the ambi-ary operators by detecting these cases during 
initialization and constructing an alternate array.


nathan

--
Nathan Sidwell
2017-11-01  Nathan Sidwell  

	* cp-tree.h (IDENTIFIER_CP_INDEX): Define.
	(enum ovl_op_flags): Add OVL_OP_FLAG_AMBIARY.
	(enum ovl_op_code): New.
	(struct ovl_op_info): Add ovl_op_code field.
	(ovl_op_info): Size by OVL_OP_MAX.
	(ovl_op_mapping, ovl_op_alternate): Declare.
	(OVL_OP_INFO): Adjust for mapping array.
	(IDENTIFIER_OVL_OP_INFO): New.
	* decl.c (ambi_op_p, unary_op_p): Delete.
	(grok_op_properties): Use IDENTIFIER_OVL_OP_INFO and
	ovl_op_alternate.
	* lex.c (ovl_op_info): Adjust and static initialize.
	(ovl_op_mappings, ovl_op_alternate): Define.
	(init_operators): Iterate over ovl_op_info array and init mappings
	& alternate arrays.
	* mangle.c (write_unqualified_id): Use IDENTIFIER_OVL_OP_INFO.
	* operators.def (DEF_OPERATOR): Remove KIND parm.
	(DEF_SIMPLE_OPERATOR): Delete.
	(OPERATOR_TRANSITION): Expand if defined.

Index: cp-tree.h
===
--- cp-tree.h	(revision 254279)
+++ cp-tree.h	(working copy)
@@ -1072,6 +1072,11 @@ enum cp_identifier_kind {
& IDENTIFIER_KIND_BIT_1 (NODE)		\
& IDENTIFIER_KIND_BIT_0 (NODE))
 
+/* Access a C++-specific index for identifier NODE.
+   Used to optimize operator mappings etc.  */
+#define IDENTIFIER_CP_INDEX(NODE)		\
+  (IDENTIFIER_NODE_CHECK(NODE)->base.u.bits.address_space)
+
 /* In a RECORD_TYPE or UNION_TYPE, nonzero if any component is read-only.  */
 #define C_TYPE_FIELDS_READONLY(TYPE) \
   (LANG_TYPE_CLASS_CHECK (TYPE)->fields_readonly)
@@ -5477,12 +5482,25 @@ extern void init_reswords (void);
 /* Various flags for the overloaded operator information.  */
 enum ovl_op_flags
   {
-OVL_OP_FLAG_NONE = 0,
-OVL_OP_FLAG_UNARY = 1,
-OVL_OP_FLAG_BINARY = 2,
-OVL_OP_FLAG_ALLOC = 4,  	/* operator new or delete  */
-OVL_OP_FLAG_DELETE = 1,	/* operator delete  */
-OVL_OP_FLAG_VEC = 2		/* vector new or delete  */
+OVL_OP_FLAG_NONE = 0,	/* Don't care.  */
+OVL_OP_FLAG_UNARY = 1,	/* Is unary.  */
+OVL_OP_FLAG_BINARY = 2,	/* Is binary.  */
+OVL_OP_FLAG_AMBIARY = 3,	/* May be unary or binary.  */
+OVL_OP_FLAG_ALLOC = 4,  	/* operator new or delete.  */
+OVL_OP_FLAG_DELETE = 1,	/* operator delete.  */
+OVL_OP_FLAG_VEC = 2		/* vector new or delete.  */
+  };
+
+/* Compressed operator codes.  Order is determined by operators.def
+   and does not match that of tree_codes.  */
+enum ovl_op_code
+  {
+OVL_OP_ERROR_MARK,
+OVL_OP_NOP_EXPR,
+#define DEF_OPERATOR(NAME, CODE, MANGLING, FLAGS) OVL_OP_##CODE,
+#define DEF_ASSN_OPERATOR(NAME, CODE, MANGLING) /* NOTHING */
+#include "operators.def"
+OVL_OP_MAX
   };
 
 struct GTY(()) ovl_op_info_t {
@@ -5492,19 +5510,29 @@ struct GTY(()) ovl_op_info_t {
   const char *name;
   /* The mangled name of the operator.  */
   const char *mangled_name;
-  /* The tree code.  */
+  /* The (regular) tree code.  */
   enum tree_code tree_code : 16;
+  /* The (compressed) operator code.  */
+  enum ovl_op_code ovl_op_code : 8;
   /* The ovl_op_flags of the operator */
   unsigned flags : 8;
 };
 
-/* Overloaded operator info indexed by ass_op_p & tree_code.  */
-extern GTY(()) ovl_op_info_t ovl_op_info[2][MAX_TREE_CODES];
+/* Overloaded operator info indexed by ass_op_p & ovl_op_code.  */
+extern GTY(()) ovl_op_info_t ovl_op_info[2][OVL_OP_MAX];
+/* Mapping from tree_codes to ovl_op_codes.  */
+extern GTY(()) unsigned char ovl_op_mapping[MAX_TREE_CODES];
+/* Mapping for ambi-ary operators from the binary to the unary.  */
+extern GTY(()) unsigned char ovl_op_alternate[OVL_OP_MAX];
 
 /* Given an ass_op_p boolean and a tree code, return a pointer to its
overloaded operator info.  */
 #define OVL_OP_INFO(IS_ASS_P, TREE_CODE)			\
-  (_op_info[(IS_ASS_P) != 0][(TREE_CODE)])
+  (_op_info[(IS_ASS_P) != 0][ovl_op_mapping[(TREE_CODE)]])
+/* Overloaded operator info for an identifier for which
+   IDENTIFIER_ANY_OP_P is true.  */
+#define IDENTIFIER_OVL_OP_INFO(NODE) \
+  (_op_info[IDENTIFIER_ASSIGN_OP_P (NODE)][IDENTIFIER_CP_INDEX (NODE)])
 
 /* A type-qualifier, or bitmask therefore, using the TYPE_QUAL
constants.  */
Index: decl.c
===
--- decl.c	(revision 254279)
+++ decl.c	(working copy)
@@ -65,8 +65,6 @@ static const char 

Re: [PATCH][compare-elim] Fix PR rtl-optimization/82597

[Jakub Jelinek]

On Wed, Nov 01, 2017 at 02:49:45PM +0100, Eric Botcazou wrote:
> > At least, the only spot that used to mention df_link in compare-elim.c was:
> >   struct df_link *ref_chain;
> >   ref_chain = DF_REF_CHAIN (use);
> >   if (!ref_chain || !ref_chain->ref
> > 
> >   || !DF_REF_INSN_INFO (ref_chain->ref) || ref_chain->next != NULL)
> > 
> > return false;
> > 
> >   rtx_insn *def_insn = DF_REF_INSN (ref_chain->ref);
> > and
> >   df_chain_add_problem (DF_UD_CHAIN + DF_DU_CHAIN);
> > that ensured it is computed, but the former is replaced with the patch by
> >   rtx_insn *def_insn = cmp->in_a_setter;
> > which is computed during the bb walking using the last_setter array
> > and the latter is dropped.
> 
> Then why does the patch not remove the df_chain_add_problem call itself?

Oops, I thought I've removed it, but apparently I haven't; thanks for
catching it.  Here is an updated patch I'll bootstrap/regtest soon.

2017-11-01  Jakub Jelinek  

PR rtl-optimization/82778
PR rtl-optimization/82597
* compare-elim.c (struct comparison): Add in_a_setter field.
(find_comparison_dom_walker::before_dom_children): Remove killed
bitmap and df_simulate_find_defs call, instead walk the defs.
Compute last_setter and initialize in_a_setter.  Merge definitions
with first initialization for a few variables.
(try_validate_parallel): Use insn_invalid_p instead of
recog_memoized.  Return insn rather than just the pattern.
(try_merge_compare): Fix up comment.  Don't uselessly test if
in_a is a REG_P.  Use cmp->in_a_setter instead of walking UD
chains.
(execute_compare_elim_after_reload): Remove df_chain_add_problem
call.

* g++.dg/opt/pr82778.C: New test.

2017-10-31  Michael Collison  

PR rtl-optimization/82597
* gcc.dg/pr82597.c: New test.

--- gcc/compare-elim.c.jj   2017-10-31 20:01:31.431670403 +0100
+++ gcc/compare-elim.c  2017-11-01 14:51:42.482884881 +0100
@@ -97,6 +97,9 @@ struct comparison
   /* The insn prior to the comparison insn that clobbers the flags.  */
   rtx_insn *prev_clobber;
 
+  /* The insn prior to the comparison insn that sets in_a REG.  */
+  rtx_insn *in_a_setter;
+
   /* The two values being compared.  These will be either REGs or
  constants.  */
   rtx in_a, in_b;
@@ -309,26 +312,22 @@ can_eliminate_compare (rtx compare, rtx
 edge
 find_comparison_dom_walker::before_dom_children (basic_block bb)
 {
-  struct comparison *last_cmp;
-  rtx_insn *insn, *next, *last_clobber;
-  bool last_cmp_valid;
+  rtx_insn *insn, *next;
   bool need_purge = false;
-  bitmap killed;
-
-  killed = BITMAP_ALLOC (NULL);
+  rtx_insn *last_setter[FIRST_PSEUDO_REGISTER];
 
   /* The last comparison that was made.  Will be reset to NULL
  once the flags are clobbered.  */
-  last_cmp = NULL;
+  struct comparison *last_cmp = NULL;
 
   /* True iff the last comparison has not been clobbered, nor
  have its inputs.  Used to eliminate duplicate compares.  */
-  last_cmp_valid = false;
+  bool last_cmp_valid = false;
 
   /* The last insn that clobbered the flags, if that insn is of
  a form that may be valid for eliminating a following compare.
  To be reset to NULL once the flags are set otherwise.  */
-  last_clobber = NULL;
+  rtx_insn *last_clobber = NULL;
 
   /* Propagate the last live comparison throughout the extended basic block. */
   if (single_pred_p (bb))
@@ -338,6 +337,7 @@ find_comparison_dom_walker::before_dom_c
last_cmp_valid = last_cmp->inputs_valid;
 }
 
+  memset (last_setter, 0, sizeof (last_setter));
   for (insn = BB_HEAD (bb); insn; insn = next)
 {
   rtx src;
@@ -346,10 +346,6 @@ find_comparison_dom_walker::before_dom_c
   if (!NONDEBUG_INSN_P (insn))
continue;
 
-  /* Compute the set of registers modified by this instruction.  */
-  bitmap_clear (killed);
-  df_simulate_find_defs (insn, killed);
-
   src = conforming_compare (insn);
   if (src)
{
@@ -373,6 +369,13 @@ find_comparison_dom_walker::before_dom_c
  last_cmp->in_b = XEXP (src, 1);
  last_cmp->eh_note = eh_note;
  last_cmp->orig_mode = GET_MODE (src);
+ if (last_cmp->in_b == const0_rtx
+ && last_setter[REGNO (last_cmp->in_a)])
+   {
+ rtx set = single_set (last_setter[REGNO (last_cmp->in_a)]);
+ if (set && rtx_equal_p (SET_DEST (set), last_cmp->in_a))
+   last_cmp->in_a_setter = last_setter[REGNO (last_cmp->in_a)];
+   }
  all_compares.safe_push (last_cmp);
 
  /* It's unusual, but be prepared for comparison patterns that
@@ -388,28 +391,36 @@ find_comparison_dom_walker::before_dom_c
find_flags_uses_in_insn (last_cmp, insn);
 
  /* Notice if this instruction kills the flags register.  */
- if (bitmap_bit_p (killed, targetm.flags_regnum))
-  

Re: [PATCH][compare-elim] Fix PR rtl-optimization/82597

[Eric Botcazou]

> At least, the only spot that used to mention df_link in compare-elim.c was:
>   struct df_link *ref_chain;
>   ref_chain = DF_REF_CHAIN (use);
>   if (!ref_chain || !ref_chain->ref
> 
>   || !DF_REF_INSN_INFO (ref_chain->ref) || ref_chain->next != NULL)
> 
> return false;
> 
>   rtx_insn *def_insn = DF_REF_INSN (ref_chain->ref);
> and
>   df_chain_add_problem (DF_UD_CHAIN + DF_DU_CHAIN);
> that ensured it is computed, but the former is replaced with the patch by
>   rtx_insn *def_insn = cmp->in_a_setter;
> which is computed during the bb walking using the last_setter array
> and the latter is dropped.

Then why does the patch not remove the df_chain_add_problem call itself?

-- 
Eric Botcazou

Re: [PATCH][compare-elim] Fix PR rtl-optimization/82597

[Jakub Jelinek]

On Wed, Nov 01, 2017 at 02:32:02PM +0100, Eric Botcazou wrote:
> > 2017-10-31  Jakub Jelinek  
> > 
> > PR rtl-optimization/82778
> > PR rtl-optimization/82597
> > * compare-elim.c (struct comparison): Add in_a_setter field.
> > (find_comparison_dom_walker::before_dom_children): Remove killed
> > bitmap and df_simulate_find_defs call, instead walk the defs.
> > Compute last_setter and initialize in_a_setter.  Merge definitions
> > with first initialization for a few variables.
> > (try_validate_parallel): Use insn_invalid_p instead of
> > recog_memoized.  Return insn rather than just the pattern.
> > (try_merge_compare): Fix up comment.  Don't uselessly test if
> > in_a is a REG_P.  Use cmp->in_a_setter instead of walking UD
> > chains.
> > 
> > * g++.dg/opt/pr82778.C: New test.
> > 
> > 2017-10-31  Michael Collison  
> > 
> > PR rtl-optimization/82597
> > * gcc.dg/pr82597.c: New test.
> 
> That's a clear progress, but the patch doesn't fully get rid of use-def and 
> def-use chains, does it?

I believe it does fully get rid of use-def and def-use chains in
compare-elim.c.  The DU and UD chains are still in ree.c and haifa-sched.c
and UD chains only in dce.c, loop-invariant.c, loop-iv.c and web.c.

At least, the only spot that used to mention df_link in compare-elim.c was:
  struct df_link *ref_chain;
  ref_chain = DF_REF_CHAIN (use);
  if (!ref_chain || !ref_chain->ref
  || !DF_REF_INSN_INFO (ref_chain->ref) || ref_chain->next != NULL)
return false;

  rtx_insn *def_insn = DF_REF_INSN (ref_chain->ref);
and
  df_chain_add_problem (DF_UD_CHAIN + DF_DU_CHAIN);
that ensured it is computed, but the former is replaced with the patch by
  rtx_insn *def_insn = cmp->in_a_setter;
which is computed during the bb walking using the last_setter array
and the latter is dropped.

Jakub

Re: [PATCH][compare-elim] Fix PR rtl-optimization/82597

[Eric Botcazou]

> Here is an untested patch (only tried the cmpelim_mult_uses_1.c testcase in
> aarch64 cross) that does that.  I don't have aarch64 boxes around for easy
> trunk testing, can bootstrap/regtest it on x86_64-linux/i686-linux and
> maybe powerpc64le-linux though.
> 
> If the memset (last_setter, 0, sizeof (last_setter)); for each bb is a
> problem (maybe for ia64/mmix/mips which have huge numbers of hard
> registers), one possibility would be to put the array into
> find_comparison_dom_walker class, clear it only in the constructor and have
> next to it an auto_vec into which we'd push the REGNOs we've set
> last_setter to non-NULL where previously they were NULL, then instead of
> clearing the whole vector we'd just pop all the REGNOs from the vector and
> clear just those.
> One extra advantage would be that we could also cheaply clear the
> last_setter entries when seeing some following flags setter, user,
> call/jump/asm_input (stuff that can_merge_compare_into_arith verifies).
> 
> 2017-10-31  Jakub Jelinek  
> 
>   PR rtl-optimization/82778
>   PR rtl-optimization/82597
>   * compare-elim.c (struct comparison): Add in_a_setter field.
>   (find_comparison_dom_walker::before_dom_children): Remove killed
>   bitmap and df_simulate_find_defs call, instead walk the defs.
>   Compute last_setter and initialize in_a_setter.  Merge definitions
>   with first initialization for a few variables.
>   (try_validate_parallel): Use insn_invalid_p instead of
>   recog_memoized.  Return insn rather than just the pattern.
>   (try_merge_compare): Fix up comment.  Don't uselessly test if
>   in_a is a REG_P.  Use cmp->in_a_setter instead of walking UD
>   chains.
> 
>   * g++.dg/opt/pr82778.C: New test.
> 
> 2017-10-31  Michael Collison  
> 
>   PR rtl-optimization/82597
>   * gcc.dg/pr82597.c: New test.

That's a clear progress, but the patch doesn't fully get rid of use-def and 
def-use chains, does it?

-- 
Eric Botcazou

PING*2 Fwd: [patch] implement generic debug() for vectors and hash sets

[Aldy Hernandez]

-- Forwarded message --
From: Aldy Hernandez 
Date: Mon, Oct 16, 2017 at 9:52 AM
Subject: [patch] implement generic debug() for vectors and hash sets
To: gcc-patches 


We have a generic mechanism for dumping types from the debugger with:

(gdb) call debug(some_type)

However, even though most types are implemented, we have no canonical
way of dumping vectors or hash sets.

The attached patch fixes this oversight.  With it you can call
debug(vec<>) and debug(hash_set<>) with the following types: rtx,
tree, basic_block, edge, rtx_insn.  More can be added simply by adding
a debug_slim(your_type) overload and calling:

  DEFINE_DEBUG_VEC (your_type)
  DEFINE_DEBUG_HASH_SET (your_type)

Here is an example of how things look with this patch:

vec of edges:
[0] =  10)>

vec of bbs:
[0] = 
[1] = 

vec of trees:
[0] =  
[1] =  
[2] =  

vec of rtx:
[0] = (reg:SI 87)
[1] = (reg:SI 87)

hash of bbs:



OK for mainline?
gcc/

	* vec.h (debug_helper): New function.
	(DEFINE_DEBUG_VEC): New macro.
	* hash-set.h (debug_helper): New function.
	(DEFINE_DEBUG_HASH_SET): New macro.
	* cfg.c (debug_slim (edge)): New function.
	Call DEFINE_DEBUG_VEC for edges.
	Call DEFINE_DEBUG_HASH_SET for edges.
	* cfghooks.c (debug_slim (basic_block)): New function.
	Call DEFINE_DEBUG_VEC for basic blocks.
	Call DEFINE_DEBUG_HASH_SET for basic blocks.
	* print-tree.c (debug_slim): New function to handle trees.
	Call DEFINE_DEBUG_VEC for trees.
	Call DEFINE_DEBUG_HASH_SET for trees.
	(debug (vec) &): Remove.
	(debug () *): Remove.
	* print-rtl.c (debug_slim): New function to handle const_rtx.
	Call DEFINE_DEBUG_VEC for rtx_def.
	Call DEFINE_DEBUG_VEC for rtx_insn.
	Call DEFINE_DEBUG_HASH_SET for rtx_def.
	Call DEFINE_DEBUG_HASH_SET for rtx_insn.
	* sel-sched-dump.c (debug (vec &): Remove.
	(debug (vec *ptr): Remove.
	(debug_insn_vector): Remove.
	* stor-layout.c (debug_rli): Call debug() instead of debug_vec_tree.

diff --git a/gcc/cfg.c b/gcc/cfg.c
index 01e68aeda51..4d02fb56cbf 100644
--- a/gcc/cfg.c
+++ b/gcc/cfg.c
@@ -573,6 +573,16 @@ debug (edge_def *ptr)
   else
 fprintf (stderr, "\n");
 }
+
+static void
+debug_slim (edge e)
+{
+  fprintf (stderr, " %d)>", (void *) e,
+	   e->src->index, e->dest->index);
+}
+
+DEFINE_DEBUG_VEC (edge)
+DEFINE_DEBUG_HASH_SET (edge)
 
 /* Simple routines to easily allocate AUX fields of basic blocks.  */
 
diff --git a/gcc/cfghooks.c b/gcc/cfghooks.c
index 258a5eabf8d..73b196feec7 100644
--- a/gcc/cfghooks.c
+++ b/gcc/cfghooks.c
@@ -304,6 +304,14 @@ debug (basic_block_def *ptr)
 fprintf (stderr, "\n");
 }
 
+static void
+debug_slim (basic_block ptr)
+{
+  fprintf (stderr, "", (void *) ptr, ptr->index);
+}
+
+DEFINE_DEBUG_VEC (basic_block_def *)
+DEFINE_DEBUG_HASH_SET (basic_block_def *)
 
 /* Dumps basic block BB to pretty-printer PP, for use as a label of
a DOT graph record-node.  The implementation of this hook is
diff --git a/gcc/hash-set.h b/gcc/hash-set.h
index d2247d39571..58f7750243a 100644
--- a/gcc/hash-set.h
+++ b/gcc/hash-set.h
@@ -123,6 +123,44 @@ private:
   hash_table m_table;
 };
 
+/* Generic hash_set debug helper.
+
+   This needs to be instantiated for each hash_set used throughout
+   the compiler like this:
+
+DEFINE_DEBUG_HASH_SET (TYPE)
+
+   The reason we have a debug_helper() is because GDB can't
+   disambiguate a plain call to debug(some_hash), and it must be called
+   like debug(some_hash).  */
+template
+void
+debug_helper (hash_set )
+{
+  for (typename hash_set::iterator it = ref.begin ();
+   it != ref.end (); ++it)
+{
+  debug_slim (*it);
+  fputc ('\n', stderr);
+}
+}
+
+#define DEFINE_DEBUG_HASH_SET(T) \
+  template static void debug_helper (hash_set &);	\
+  DEBUG_FUNCTION void	\
+  debug (hash_set )\
+  {			\
+debug_helper  (ref);\
+  }			\
+  DEBUG_FUNCTION void	\
+  debug (hash_set *ptr)\
+  {			\
+if (ptr)		\
+  debug (*ptr);	\
+else		\
+  fprintf (stderr, "\n");			\
+  }
+
 /* ggc marking routines.  */
 
 template
diff --git a/gcc/print-rtl.c b/gcc/print-rtl.c
index 28d99862cad..5fe23801ab2 100644
--- a/gcc/print-rtl.c
+++ b/gcc/print-rtl.c
@@ -967,6 +967,23 @@ debug (const rtx_def *ptr)
 fprintf (stderr, "\n");
 }
 
+/* Like debug_rtx but with no newline, as debug_helper will add one.
+
+   Note: No debug_slim(rtx_insn *) variant implemented, as this
+   function can serve for both rtx and rtx_insn.  */
+
+static void
+debug_slim (const_rtx x)
+{
+  rtx_writer w (stderr, 0, false, false, NULL);
+  w.print_rtx (x);
+}
+
+DEFINE_DEBUG_VEC (rtx_def *)
+DEFINE_DEBUG_VEC (rtx_insn *)
+DEFINE_DEBUG_HASH_SET (rtx_def *)
+DEFINE_DEBUG_HASH_SET (rtx_insn *)
+
 /* Count of rtx's to print with debug_rtx_list.
This global exists because gdb user defined commands have no arguments.  */
 
diff --git a/gcc/print-tree.c b/gcc/print-tree.c
index d534c76ee49..3a0f85d4038 100644
--- 

Generalize -(-X) a little

[Marc Glisse]

Hello,

just a little tweak to that transformation. There is some overlap between 
the 2 versions, but it seemed easier to handle the NOP case (including the 
case without convert and the vector case) separately from the 
narrowing / sign-extending scalar integer case.


At some point it would be good to have fold_negate_expr call 
generic_simplify so we could remove some transformations from 
fold-const.c.


Bootstrap+regtest on powerpc64le-unknown-linux-gnu.

2017-11-01  Marc Glisse  

gcc/
* match.pd (-(-A)): Rewrite.

gcc/testsuite/
* gcc.dg/negneg.c: New file.

--
Marc GlisseIndex: gcc/match.pd
===
--- gcc/match.pd	(revision 254289)
+++ gcc/match.pd	(working copy)
@@ -1498,24 +1498,33 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(with
 {
  tree t1 = type;
  if (INTEGRAL_TYPE_P (type)
 	 && TYPE_OVERFLOW_WRAPS (type) != TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
t1 = TYPE_OVERFLOW_WRAPS (type) ? type : TREE_TYPE (@1);
 }
 (convert (plus (convert:t1 @0) (convert:t1 @1))
  /* -(-A) -> A */
  (simplify
-  (negate (convert? (negate @1)))
-  (if (tree_nop_conversion_p (type, TREE_TYPE (@1))
-   && !TYPE_OVERFLOW_SANITIZED (type))
+  (negate (convert (negate @1)))
+  (if (INTEGRAL_TYPE_P (type)
+   && (TYPE_PRECISION (type) <= TYPE_PRECISION (TREE_TYPE (@1))
+	   || (!TYPE_UNSIGNED (TREE_TYPE (@1))
+	   && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@1
+   && !TYPE_OVERFLOW_SANITIZED (type)
+   && !TYPE_OVERFLOW_SANITIZED (TREE_TYPE (@1)))
(convert @1)))
+ (simplify
+  (negate (nop_convert (negate @1)))
+  (if (!TYPE_OVERFLOW_SANITIZED (type)
+   && !TYPE_OVERFLOW_SANITIZED (TREE_TYPE (@1)))
+   (view_convert @1)))
 
  /* We can't reassociate floating-point unless -fassociative-math
 or fixed-point plus or minus because of saturation to +-Inf.  */
  (if ((!FLOAT_TYPE_P (type) || flag_associative_math)
   && !FIXED_POINT_TYPE_P (type))
 
   /* Match patterns that allow contracting a plus-minus pair
  irrespective of overflow issues.  */
   /* (A +- B) - A   ->  +- B */
   /* (A +- B) -+ B  ->  A */
Index: gcc/testsuite/gcc.dg/negneg.c
===
--- gcc/testsuite/gcc.dg/negneg.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/negneg.c	(working copy)
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O -frounding-math -fdump-tree-optimized-raw -Wno-psabi" } */
+
+#define DEF(num, T1, T2) T2 f##num(T1 x) { \
+T1 y = -x; \
+T2 z = (T2)y; \
+return -z; \
+}
+DEF(0, int, long long)
+DEF(1, int, unsigned long long)
+DEF(2, long long, int)
+DEF(3, unsigned long long, int)
+DEF(4, long long, unsigned)
+DEF(5, unsigned long long, unsigned)
+//DEF(6, float, double)
+double f6(float x){return -(double)(-x);}
+
+typedef int vec __attribute__((vector_size(4*sizeof(int;
+typedef unsigned uvec __attribute__((vector_size(4*sizeof(int;
+void h(vec*p,uvec*q){
+  *q=-(uvec)(-*p);
+}
+
+/* { dg-final { scan-tree-dump-not "negate_expr" "optimized"} } */

Re: Adjust empty class parameter passing ABI (PR c++/60336)

[Marek Polacek]

On Fri, Oct 27, 2017 at 12:46:12PM +0200, Richard Biener wrote:
> On Fri, 27 Oct 2017, Jakub Jelinek wrote:
> 
> > On Fri, Oct 27, 2017 at 12:31:46PM +0200, Richard Biener wrote:
> > > I fear it doesn't work at all with LTO (you'll always get the old ABI
> > > if I read the patch correctly).  This is because the function
> > > computing the size looks at flag_abi_version which isn't saved
> > > per function / TU.
> > > 
> > > Similarly you'll never get the ABI warning with LTO (less of a big
> > > deal of course) because the langhook doesn't reflect things correctly
> > > either.
> > > 
> > > So...  can we instead compute whether a type is "empty" according
> > > to the ABI early and store the result in the type (thinking of
> > > doing this in layout_type?).  Similarly set a flag whether to
> > > warn.  Why do you warn from backends / code emission and not
> > > from the FEs?  Is that to avoid warnings for calls that got inlined?
> > > Maybe the FE could set a flag on the call itself (ok, somewhat
> > > awkward to funnel through gimple).
> > 
> > Warning in the FE is too early both because of the inlining, never
> > emitted functions and because whether an empty struct is passed differently
> > from the past matters on the backend (whether its psABI says it should be
> > not passed at all or not).
> > 
> > Perhaps if empty types are rare enough it could be an artificial attribute
> > on the type if we can't get a spare bit for that.  But computing in the FE
> > or before free_lang_data and saving on the type whether it is empty or not
> > seems reasonable to me.
> 
> There are 18 unused bits in tree_type_common if we don't want to re-use
> any.  For the warning I first thought of setting TREE_NO_WARNING on it
> but that bit is used already.  OTOH given the "fit" of TREE_NO_WARNING
> I'd move TYPE_ARTIFICIAL somewhere else.

All right, should be done in the below.  I've introduced two new flags,
TYPE_EMPTY_P (says whether the type is empty according to the psABI), and
TYPE_WARN_EMPTY_P (whether we should warn).  I've added two new fields to
type_type_common and moved TYPE_ARTIFICIAL there; TYPE_WARN_EMPTY_P is now
mapped to nowarning_flag.  So this should work with LTO, as demonstrated
by g++.dg/lto/pr60336_0.C.  

Regarding LTO and -Wabi warning, I've added Optimization to c.opt so that
we get warnings with LTO.  But as pointed out IRC, this doesn't fully work
with cross-inlining.  I tried to do some flags merging in inline_call, but
that didn't help, one of the problems is that warn_abi_version lives in
c-family only.  Not sure if I'll be able to improve things here though.

Bootstrapped/regtested on x86_64-linux, ppc64-linux, and aarch64-linux.
Bootstrap-lto passed on x86_64-linux and ppc64-linux.

2017-11-01  Marek Polacek  
H.J. Lu  
Jason Merrill  

PR c++/60336
PR middle-end/67239
PR target/68355
* c.opt (Wabi, Wabi=): Add Optimization.

* class.c (layout_class_type): Set TYPE_EMPTY_P and TYPE_WARN_EMPTY_P.
* cp-tree.h (array_type_nelts_top): Remove.
* tree.c (array_type_nelts_top): Move to tree.c.

* lto.c (compare_tree_sccs_1): Compare TYPE_WARN_EMPTY_P and
TYPE_EMPTY_P.

* calls.c (initialize_argument_information): Call
warn_parameter_passing_abi target hook.
(store_one_arg): Use 0 for empty record size.  Don't push 0 size
argument onto stack.
(must_pass_in_stack_var_size_or_pad): Return false for empty types.
* common.opt: Update -fabi-version description.
* config/i386/i386.c (init_cumulative_args): Set cum->warn_empty.
(ix86_function_arg_advance): Skip empty records.
(ix86_return_in_memory): Return false for empty types.
(ix86_gimplify_va_arg): Call int_maybe_empty_type_size instead of
int_size_in_bytes.
(ix86_is_empty_record_p): New function.
(ix86_warn_parameter_passing_abi): New function.
(TARGET_EMPTY_RECORD_P): Redefine.
(TARGET_WARN_PARAMETER_PASSING_ABI): Redefine.
* config/i386/i386.h (CUMULATIVE_ARGS): Add warn_empty.
* doc/tm.texi: Regenerated.
* doc/tm.texi.in (TARGET_EMPTY_RECORD_P,
TARGET_WARN_PARAMETER_PASSING_ABI): Add.
* explow.c (hard_function_value): Call int_maybe_empty_type_size
instead of int_size_in_bytes.
* expr.c (copy_blkmode_to_reg): Likewise.
* function.c (assign_parm_find_entry_rtl): Call
warn_parameter_passing_abi target hook.
(locate_and_pad_parm): Call maybe_empty_type_size instead
size_in_bytes.
* lto-streamer-out.c (hash_tree): Hash TYPE_EMPTY_P and
TYPE_WARN_EMPTY_P.
* target.def (empty_record_p, warn_parameter_passing_abi): New target
hook.
* targhooks.c (hook_void_CUMULATIVE_ARGS_tree): New hook.
(std_gimplify_va_arg_expr): Skip empty records.  Call

[Fortran, Patch, v1] Three small patches for character arrays

[Andre Vehreschild]

Hi all,

during development on OpenCoarrays I found these three issues in gfortran:

- caf_send: Did not treat char arrays as arrays when calling caf_send.
- gfc_trans_assignment_1: Conversion of character kind creates a loop variant
  temporary which must not be put before the loop body, but within.
- get_array_span: When doing pointer arithmetic on char arrays the character
  kind was not applied.

The attached patch fixes all of these issues for trunk and gcc-7. Bootstrapped
and regtested on x86_64-linux-gnu/f25. Ok for trunk and gcc-7?

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/fortran/ChangeLog:

2017-11-01  Andre Vehreschild  

* trans-expr.c (gfc_trans_assignment_1): Character kind conversion may
create a loop variant temporary, too.
* trans-intrinsic.c (conv_caf_send): Treat char arrays as arrays and
not as scalars.
* trans.c (get_array_span): Take the character kind into account when
doing pointer arithmetic.

gcc/testsuite/ChangeLog:

2017-11-01  Andre Vehreschild  

* gfortran.dg/coarray/send_char_array_1.f90: New test.

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 1a3e3d4..57b62a6 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -10084,12 +10084,16 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
  NOTE: This relies on having the exact dependence of the length type
  parameter available to the caller; gfortran saves it in the .mod files.
  NOTE ALSO: The concatenation operation generates a temporary pointer,
- whose allocation must go to the innermost loop.  */
+ whose allocation must go to the innermost loop.
+ NOTE ALSO (2): A character conversion may generate a temporary, too.  */
   if (flag_realloc_lhs
   && expr2->ts.type == BT_CHARACTER && expr1->ts.deferred
   && !(lss != gfc_ss_terminator
-	   && expr2->expr_type == EXPR_OP
-	   && expr2->value.op.op == INTRINSIC_CONCAT))
+	   && ((expr2->expr_type == EXPR_OP
+		&& expr2->value.op.op == INTRINSIC_CONCAT)
+	   || (expr2->expr_type == EXPR_FUNCTION
+		   && expr2->value.function.isym != NULL
+		   && expr2->value.function.isym->id == GFC_ISYM_CONVERSION
 gfc_add_block_to_block (, );
 
   /* Nullify the allocatable components corresponding to those of the lhs
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 532d3ab..b0f0ab2 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -1871,12 +1871,21 @@ conv_caf_send (gfc_code *code) {
   gfc_init_se (_se, NULL);
   if (lhs_expr->rank == 0)
 {
-  symbol_attribute attr;
-  gfc_clear_attr ();
-  gfc_conv_expr (_se, lhs_expr);
-  lhs_type = TREE_TYPE (lhs_se.expr);
-  lhs_se.expr = gfc_conv_scalar_to_descriptor (_se, lhs_se.expr, attr);
-  lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+  if (lhs_expr->ts.type == BT_CHARACTER && lhs_expr->ts.deferred)
+	{
+	  lhs_se.expr = gfc_get_tree_for_caf_expr (lhs_expr);
+	  lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+	}
+  else
+	{
+	  symbol_attribute attr;
+	  gfc_clear_attr ();
+	  gfc_conv_expr (_se, lhs_expr);
+	  lhs_type = TREE_TYPE (lhs_se.expr);
+	  lhs_se.expr = gfc_conv_scalar_to_descriptor (_se, lhs_se.expr,
+		   attr);
+	  lhs_se.expr = gfc_build_addr_expr (NULL_TREE, lhs_se.expr);
+	}
 }
   else if ((lhs_caf_attr.alloc_comp || lhs_caf_attr.pointer_comp)
 	   && lhs_caf_attr.codimension)
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index 53bc428..4115308 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -320,8 +320,12 @@ get_array_span (tree type, tree decl)
 	  || DECL_CONTEXT (TYPE_MAX_VALUE (TYPE_DOMAIN (type)))
 	== DECL_CONTEXT (decl)))
 {
-  span = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
-  span = fold_convert (gfc_array_index_type, span);
+  span = fold_convert (gfc_array_index_type,
+			   TYPE_MAX_VALUE (TYPE_DOMAIN (type)));
+  span = fold_build2 (MULT_EXPR, gfc_array_index_type,
+			  fold_convert (gfc_array_index_type,
+	TYPE_SIZE_UNIT (TREE_TYPE (type))),
+			  span);
 }
   /* Likewise for class array or pointer array references.  */
   else if (TREE_CODE (decl) == FIELD_DECL
diff --git a/gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90 b/gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90
new file mode 100644
index 000..800a8ac
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90
@@ -0,0 +1,54 @@
+!{ dg-do run }
+ 
+program send_convert_char_array
+
+  implicit none
+
+  character(kind=1, len=:), allocatable, codimension[:] :: co_str_k1_scal
+  character(kind=1, len=:), allocatable :: str_k1_scal
+  character(kind=4, len=:), allocatable, codimension[:] :: co_str_k4_scal
+  character(kind=4, len=:), allocatable :: str_k4_scal
+
+  character(kind=1, len=:), 

Re: [Patch, fortran] PR80850 - Sourced allocate() fails to allocate a pointer

[Paul Richard Thomas]

Committed to 7-branch as revision 254293. I will close the PR now.

Cheers

Paul

On 30 October 2017 at 22:16, Paul Richard Thomas
 wrote:
> Dear Andre,
>
> Committed to trunk as revision 254244.
>
> In order to debug the code, I was forced to use 7-branch for
> development since there were dependencies that detected the change in
> module number. 7-branch accepted the assignments without casts but I
> was forced to include them in trunk. As advertised the testcase just
> enforces the assignment to the _len field through a tree dump.
>
> 7-branch will come on Wednesday. Tomorrow is full of Halloween fun
>
> Thanks
>
> Paul
>
>
> On 30 October 2017 at 13:39, Andre Vehreschild  wrote:
>> Hi Paul,
>>
>> whoopsie, I remember that I inserted the check for _len > 0 in allocate(). So
>> it was me causing the bug. Thanks that you found it. The patch looks good to
>> me. Thanks for the work.
>>
>> - Andre
>>
>> On Mon, 30 Oct 2017 12:20:20 +
>> Paul Richard Thomas  wrote:
>>
>>> Dear All,
>>>
>>> This bug took a silly amount of effort to diagnose but once done, the
>>> fix was obvious.
>>>
>>> The bug is triggered in this function from the reporter's source file
>>> gfc_graph.F90:
>>>
>>> function GraphIterAppendVertex(this,vertex) result(ierr)
>>> !Appends a new vertex to the graph.
>>>  implicit none
>>>  integer(INTD):: ierr   !out: error code
>>>  class(graph_iter_t), intent(inout):: this  !inout:
>>> graph iterator
>>>  class(graph_vertex_t), intent(in), target:: vertex !in: new vertex
>>>  type(vert_link_refs_t):: vlr
>>>
>>>  ierr=this%vert_it%append(vertex) !<= right here!
>>> snip
>>>  return
>>> end function GraphIterAppendVertex
>>>
>>> 'vertex' is being passed to a class(*) dummy. As you will see from the
>>> attached patch and the ChangeLog, 'vertex' was being cast as unlimited
>>> polymorphic and assigned to the passed actual argument. This left the
>>> _len field indeterminate since it is not present in normal (limited?)
>>> polymorphic objects.
>>>
>>> Further down the way, in stsubs.F90(clone_object) an allocation is
>>> being made using the unlimited version of 'vertex as a source. Since
>>> the size passed to malloc for an unlimited source is, for  _len > 0,
>>> the value of the _len multiplied by the vtable _size, the amount of
>>> memory is also indeterminate and causes the operating system to flag a
>>> failed allocation, pretty much at random.
>>>
>>> The ChangeLog and the patch describe the fix sufficiently well as not
>>> to require further explanation. I will write a testcase that tests the
>>> tree dump for the _len field before committing the patch.
>>>
>>> Bootstraps and regtests on FC23/x86_64 - OK for 7- and 8-branches?
>>>
>>> If I do not receive any contrary comments, I will commit tonight.
>>>
>>> Regards
>>>
>>> Paul
>>>
>>> 2017-10-30  Paul Thomas  
>>>
>>> PR fortran/80850
>>> * trans_expr.c (gfc_conv_procedure_call): When passing a class
>>> argument to an unlimited polymorphic dummy, it is wrong to cast
>>> the passed expression as unlimited, unless it is unlimited. The
>>> correct way is to assign to each of the fields and set the _len
>>> field to zero.
>>
>>
>> --
>> Andre Vehreschild * Email: vehre ad gmx dot de
>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein



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

[PATCH 8/N][RFC] v2 GCOV: support multiple functions per a line

[Martin Liška]

Hi.

As shown from examples with -O2 optimization level, previous approach was not 
viable.
A more complex approach is necessary and can be shortly described as follows:

1) each function has assigned start and end line in a source file
2) group functions are these functions that begin on a line and there's another 
function
that begins on the same line (template initializations, deleting dtors, ...)
3) both source_file and function have 'vector lines':
   a) source_file::lines represent all lines of non-group functions
   b) function_info::lines exists if a function is a group function and 
represent lines that belong to the function
4) function_info::lines for a group of functions are summed to 
source_file::lines; that makes function
   output_lines easier
5) branches, calls and blocks are printed per function in a group, not to 
'global scope' lines
6) DECL_ARTIFICIAL functions are ignored

There are 2 examples that illustrate the approach:

1:7:class ClassB
-:8:{
-:9:public:
-:   10:  virtual ~ClassB ();
-:   11:};
-:   12:
3:   13:ClassB::~ClassB ()
-:   14:{
1:   15:  int r = inline_me (glob);
1:   16:  std::cout << "Bey, ClassB!" << r << std::endl;
2:   17:}
--
_ZN6ClassBD0Ev:
1:   13:ClassB::~ClassB ()
-:   14:{
-:   15:  int r = inline_me (glob);
-:   16:  std::cout << "Bey, ClassB!" << r << std::endl;
1:   17:}
--
_ZN6ClassBD2Ev:
2:   13:ClassB::~ClassB ()
-:   14:{
1:   15:  int r = inline_me (glob);
1:   16:  std::cout << "Bey, ClassB!" << r << std::endl;
1:   17:}
--
-:   18:
-:   19:int
1:   20:main (int argc, char **argv)
-:   21:{
1:   22:  ClassB *pObjB = new ClassB ();
1:   23:  delete pObjB;
-:   24:
1:   25:  if (argc == 123)
#:   26:return 1;
-:   27:
-:   28:  return 0;
-:   29:}
-:   30:
-:   31:
-:   32:static int
#:   33:inline_me(int a)
-:   34:{
   1*:   35:  return a * a;
-:   36:}

It's compiled with -O2 and it shows that ZN6ClassBD2Ev function executes also 
line 35, but the line is not counted
to function_info::lines as it does not live in function scope. Note that line 
35 is marked with '*'. That's because
I used -fkeep-inline-functions.

-:0:Source:test.cpp
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:0:Programs:1
-:1:template
-:2:class Foo
-:3:{
-:4:  public:
3:5:  Foo()
-:6:  {
3:7:b = 123;
3:8:  }
--
Foo::Foo():
#:5:  Foo()
-:6:  {
#:7:b = 123;
#:8:  }
--
Foo::Foo():
1:5:  Foo()
-:6:  {
1:7:b = 123;
1:8:  }
--
Foo::Foo():
2:5:  Foo()
-:6:  {
2:7:b = 123;
2:8:  }
--
-:9:
1:   10:  void test() { if (!b) __builtin_abort (); b = 111; }
--
Foo::test():
#:   10:  void test() { if (!b) __builtin_abort (); b = 111; }
%:   10-block  0
%:   10-block  1
--
Foo::test():
   1*:   10:  void test() { if (!b) __builtin_abort (); b = 111; }
1:   10-block  0
%:   10-block  1
--
Foo::test():
#:   10:  void test() { if (!b) __builtin_abort (); b = 111; }
%:   10-block  0
%:   10-block  1
--
-:   11:
-:   12:  private:
-:   13:  int b;
-:   14:};
-:   15:
-:   16:template class Foo;
-:   17:template class Foo;
-:   18:template class Foo;
-:   19:
1:   20:int main()
-:   21:{
1:   22:  Foo xx;
1:   22-block  0
1:   23:  Foo yy;
1:   23-block  0
1:   24:  Foo zz;
1:   24-block  0
1:   25:  xx.test();
1:   25-block  0
-:   26:
1:   27:  return 0;
1:   27-block  0
-:   28:}

This sample is illustration of how we aggregate statistics.

I've added changelog entry and I'm still planning to enhance documentation, add
some tests (which would be tricky) and small follow-up clean-up is planned.
In meantime I would appreciate a feedback.

Thanks,
Martin





   

>From cf05cc4b236d7fd58091a4fd3fd4e88bfee28c00 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 26 Oct 2017 10:39:40 +0200
Subject: [PATCH] GCOV: support multiple functions per a line

gcc/ChangeLog:

2017-11-01  Martin Liska  

	* coverage.c (coverage_begin_function): Output also end locus
	of a function and information 

[PATCH, testsuite, alpha]: Add testcase for glibc sqrt bug

[Uros Bizjak]

The testcase for an alpha glibc bug [1] that bit us again.

2017-11-01  Uros Bizjak  

* gcc.target/alpha/sqrt.c: New test.

Tested on alphaev68-linux-gnu, committed to mainline SVN.

[1] https://sourceware.org/ml/libc-alpha/2017-04/msg00256.html

Uros.
Index: gcc.target/alpha/sqrt.c
===
--- gcc.target/alpha/sqrt.c (nonexistent)
+++ gcc.target/alpha/sqrt.c (working copy)
@@ -0,0 +1,25 @@
+/* glibc bug, https://sourceware.org/ml/libc-alpha/2017-04/msg00256.html
+   When using software completions, we have to prevent assembler to match
+   input and output operands of sqrtt/sqrtf insn.  Fixed in glibc 2.26.  */
+/* { dg-do run } */
+/* { dg-options "-O2 -fno-builtin-sqrt -mieee" } */
+
+double sqrt (double);
+
+static double
+float64frombits (unsigned long b)
+{
+  union { unsigned long __b; double __d; } u = { .__b = b };
+  return u.__d;
+}
+
+int
+main (void)
+{
+  double a = float64frombits (2);
+
+  if (sqrt (a) != 3.1434555694052576e-162)
+__builtin_abort ();
+
+  return 0;
+}

Re: [PATCH] RISC-V: Document the medlow and medany code models

[Andrew Waterman]

Thanks for caring enough about our patches to even notice the grammar :)

On Tue, Oct 31, 2017 at 11:09 PM, Sandra Loosemore
 wrote:
> On 10/31/2017 10:27 PM, Andrew Waterman wrote:
>>
>> I have to disagree.  It's standard to not hyphenate an
>> adverb-adjective compound, since they tend not to be ambiguous.  But
>> if the standard in the GCC documentation is to hyphenate, I will not
>> stand in the way!
>
>
> Heh, you got me on this one -- it's one of those weird special cases, the
> "adverb ending in -ly plus participle" case listed here:
>
> http://www.chicagomanualofstyle.org/16/images/ch07_tab01.pdf
>
> So the patch is OK as-is, but maybe I need a few new brain cells.  :-P
>
> -Sandra
>

Re: [PATCH] RISC-V: Document the medlow and medany code models

[Sandra Loosemore]

On 10/31/2017 10:27 PM, Andrew Waterman wrote:

I have to disagree.  It's standard to not hyphenate an
adverb-adjective compound, since they tend not to be ambiguous.  But
if the standard in the GCC documentation is to hyphenate, I will not
stand in the way!


Heh, you got me on this one -- it's one of those weird special cases, 
the "adverb ending in -ly plus participle" case listed here:


http://www.chicagomanualofstyle.org/16/images/ch07_tab01.pdf

So the patch is OK as-is, but maybe I need a few new brain cells.  :-P

-Sandra