[Bug target/54589] struct offset add should be folded into address calculation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed for GCC9 and later.

[PATCH] Partial fix for asan on big endian targets (PR sanitizer/88289)

[Jakub Jelinek]

On Fri, Nov 30, 2018 at 12:44:04PM +0100, Martin Liška wrote:
> Ok, I'm sending updated version of the patch. I factored out the shadow memory
> byte emission into a class, it's responsible for underlying flushing and 
> guarantees
> that stores are 4B aligned (when beginning of stack vars is properly aligned
> to ASAN_RED_ZONE_SIZE).
> 
> So far I tested the patch on x86_64-linux-gnu and ppc64le-linux-gnu machine.

The patch broke most of the asan tests on powerpc64-linux unfortunately,
sorry for not catching it during patch review.

The following patch fixes most of them, bootstrapped/regtested on
powerpc64-linux, committed to trunk as obvious.

I'm still seeing some regressions, ICEs like:
FAIL: c-c++-common/asan/clone-test-1.c   -O1  (internal compiler error)
FAIL: c-c++-common/asan/clone-test-1.c   -O1  (test for excess errors)
Excess errors:
during RTL pass: expand
/home/jakub/gcc2/gcc/testsuite/c-c++-common/asan/clone-test-1.c:25:5: internal 
compiler error: in asan_clear_shadow, at asan.c:1181
0x10c52833 asan_clear_shadow
../../gcc/asan.c:1181
0x10c618b7 asan_emit_stack_protection(rtx_def*, rtx_def*, unsigned int, long*, 
tree_node**, int)
../../gcc/asan.c:1676
0x10621fe7 expand_used_vars
../../gcc/cfgexpand.c:2277
0x1062708f execute
../../gcc/cfgexpand.c:6338
That is
  gcc_assert ((len & 3) == 0);
To be debugged later.

2018-12-01  Jakub Jelinek  

PR sanitizer/88289
* asan.c (asan_redzone_buffer::flush_redzone_payload): Fix up
an off-by-one for BYTES_BIG_ENDIAN.

--- gcc/asan.c.jj   2018-11-30 19:59:59.675789930 +0100
+++ gcc/asan.c  2018-11-30 23:19:55.336780260 +0100
@@ -1326,7 +1326,7 @@ asan_redzone_buffer::flush_redzone_paylo
   for (unsigned i = 0; i < RZ_BUFFER_SIZE; i++)
 {
   unsigned char v
-   = m_shadow_bytes[BYTES_BIG_ENDIAN ? RZ_BUFFER_SIZE - i : i];
+   = m_shadow_bytes[BYTES_BIG_ENDIAN ? RZ_BUFFER_SIZE - i - 1 : i];
   val |= (unsigned HOST_WIDE_INT)v << (BITS_PER_UNIT * i);
   if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "%02x ", v);


Jakub

[Bug sanitizer/88289] [9 regression] r266664 causes asan to fail on many/most tests on BE

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Sat Dec  1 07:31:56 2018
New Revision: 266708

URL: https://gcc.gnu.org/viewcvs?rev=266708=gcc=rev
Log:
PR sanitizer/88289
* asan.c (asan_redzone_buffer::flush_redzone_payload): Fix up
an off-by-one for BYTES_BIG_ENDIAN.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c

[Bug target/54589] struct offset add should be folded into address calculation

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Sat Dec  1 07:27:58 2018
New Revision: 266707

URL: https://gcc.gnu.org/viewcvs?rev=266707=gcc=rev
Log:
PR target/54589
* combine.c (find_split_point): For invalid memory address
nonobj + obj + const, if reg + obj + const is valid addressing
mode, split at nonobj.  Use if rather than else if for the
fallback.  Comment fixes.

* gcc.target/i386/pr54589.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr54589.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"

[N1705695H at e dot ntu.edu.sg]

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

--- Comment #4 from N1705695H at e dot ntu.edu.sg ---
(In reply to Scott Gayou from comment #3)
> My last comment was a bit confusing. I can reproduce 2/3 on a standard
> system, and the other 1/3 requires dropping ulimit -s down a bit. (to 4096).

Hi，

I don't think you've made a clear analysis of the problem. This has nothing to
do with how much stack memory you set up. No matter how big your stack memory
is, it can still run out. The test case only give a small number of characters.
As you can imagine, you can still run out of memory by giving a lot of
characters.

In detail, the program requires the amount of resource such as time, memory,
power, etc. Memory exhaustion problems in the server can occur circumstantially
when programs are provided with inputs that exhibit worst-case behavior.
However, the high space complexity of the algorithm or poorly-designed programs
consume much more memory than necessary under well-conceived inputs. In
particular, stack memory is very limited. An attacker may use own function call
or multiple functions to call each other, exhausting stack memory. In other
words, no matter how large your stack memory is, it will always run out(by
given more "Z" or "U"). No matter how big you set it up, it's ultimately
limited. 

The problem itself is very difficult to fix. The problem is that C++ mangled
names have a recursive structure. Simple restriction cycles are not necessarily
good. Moreover, these examples give different stack frames. This is cause by
giving different string input. Some are call itself. Some are call different
function. In fact, it's hard to set recursive limits on every function.
Recursion limit would not fix all of these hence they are different root
cause(Loop calls involving six functions in a finite function stack frame).

Working on GCC Tuple Issues

[nick]

Greetings All,

Seems the code has changed and may actually require a better fix than just the 
functions
mentioned on this page, http://cplusplus.github.io/LWG/lwg-active.html#2899.

I am wondering if these are the functions or one of them firstly:
constexpr tuple(tuple<_UElements...>&& __in)

  
_Inherited(static_cast<_Tuple_impl<0, _UElements...>&&>(__in)) { }  

and why not just do all rvalue functions that are like this for 
all operators? Seems the spec is only mentioned a few functions
but noexpect on move is normally a good idea unless the C++
standard or the C++ library needs it for other template parsing
reasons.

Regards,

Nick

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[sandra at gcc dot gnu.org]

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

--- Comment #32 from sandra at gcc dot gnu.org ---
New patch posted for review here:

https://gcc.gnu.org/ml/gcc-patches/2018-12/msg4.html

[doc, rfc] document __builtin_setjmp and __builtin_longjmp

[Sandra Loosemore]

I have written a new patch for PR 59039 to address more of the comments 
there, as well as my own complaints about the draft patch attached to 
the issue.  I'd like to get some feedback on this one before I commit it.


-Sandra
2018-11-30  Sandra Loosemore  

	PR c/59039

	gcc/
	* doc/extend.texi (Nonlocal gotos): New section.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 266688)
+++ gcc/doc/extend.texi	(working copy)
@@ -27,6 +27,7 @@ extensions, accepted by GCC in C90 mode
 * Local Labels::Labels local to a block.
 * Labels as Values::Getting pointers to labels, and computed gotos.
 * Nested Functions::Nested function in GNU C.
+* Nonlocal Gotos::  Nonlocal gotos.
 * Constructing Calls::  Dispatching a call to another function.
 * Typeof::  @code{typeof}: referring to the type of an expression.
 * Conditionals::Omitting the middle operand of a @samp{?:} expression.
@@ -520,6 +521,61 @@ bar (int *array, int offset, int size)
 @}
 @end smallexample
 
+@node Nonlocal Gotos
+@section Nonlocal Gotos
+@cindex nonlocal gotos
+
+GCC provides the built-in functions @code{__builtin_setjmp} and
+@code{__builtin_longjmp} which are similar to, but not interchangeable
+with, the C library functions @code{setjmp} and @code{longjmp}.  
+The built-in versions are used internally by GCC's libraries
+to implement exception handling on some targets.  You should use the 
+standard C library functions declared in @code{} in user code
+instead of the builtins.
+
+@code{__builtin_setjmp} and @code{__builtin_longjmp} use GCC's normal
+mechanisms to save and restore registers using the stack on function
+entry and exit.  The jump buffer argument @var{buf} holds only the
+information needed to restore the stack frame, rather than the entire 
+set of saved register values.  
+
+An important caveat is that GCC arranges to save and restore only
+those registers known to the specific architecture variant being
+compiled for.  This can make @code{__builtin_setjmp} and
+@code{__builtin_longjmp} more efficient than their library
+counterparts in some cases, but it can also cause incorrect and
+mysterious behavior when mixing with code that uses the full register
+set.
+
+You should declare the jump buffer argument @var{buf} to the
+built-in functions as:
+
+@smallexample
+#include 
+intptr_t @var{buf}[5];
+@end smallexample
+
+@deftypefn {Built-in Function} {int} __builtin_setjmp (intptr_t *@var{buf})
+This function saves the current stack context in @var{buf}.  
+@code{__builtin_setjmp} returns 0 when returning directly,
+and 1 when returning from @code{__builtin_longjmp} using the same
+@var{buf}.
+@end deftypefn
+
+@deftypefn {Built-in Function} {void} __builtin_longjmp (intptr_t *@var{buf}, int @var{val})
+This function restores the stack context in @var{buf}, 
+saved by a previous call to @code{__builtin_setjmp}.  After
+@code{__builtin_longjmp} is finished, the program resumes execution as
+if the matching @code{__builtin_setjmp} returns the value @var{val},
+which must be 1.
+
+Because @code{__builtin_longjmp} depends on the function return
+mechanism to restore the stack context, it cannot be called
+from the same function calling @code{__builtin_setjmp} to
+initialize @var{buf}.  It can only be called from a function called
+(directly or indirectly) from the function calling @code{__builtin_setjmp}.
+@end deftypefn
+
 @node Constructing Calls
 @section Constructing Function Calls
 @cindex constructing calls

spare parts & equipment for steel mill

[fullmart]

Dear Sir/Madam,

  

Glad to hear that you’re in loop of metallurgy business. We specialize in this 
field for years with strength of roll providing, hot-rolled steel section and 
cold rolling service of technical upgrading of metallurgical factory all over 
the world. 

 

As a excellent service provider for technical upgrading of metallurgical 
factory and metallurgical spare parts, Shanghai Full Mart Co., Ltd focus on 
good quality products and perfect services to satisfy your procurement 
requirements and guarantee your factory running smoothly. Please visit our 
website www.sfmsupply.com for more products information.

 

For best quote of your inquiry, please do not hesitate to contact us. 





--

Best regards,
Liwei Sun
Shanghai Full Mart Co.,Ltd   
Website: http://www.sfmsupply.com 
Email: fullm...@vip.163.com
Add: No.58, Wuhe Rd, Minhang District, Shanghai, China

[Bug fortran/88048] [8/9 Regression] ICE in check_data_variable, at fortran/resolve.c:15491

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #1)
> Invalid code nearby, down to at least gcc-5 :
> 
> 
> $ cat z4.f90
> subroutine s(x)
>integer, allocatable :: x(:)
>data x(1:2) /3, 4/
> end 

Unrelated bug.

[Bug fortran/88048] [8/9 Regression] ICE in check_data_variable, at fortran/resolve.c:15491

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> With invalid code  :
> 
> 
> $ cat z1.f90
> program p
>integer, parameter :: a(2) = 1
>data a(2) /a(1)/
>print *, a
> end
> 
> 
> $ gfortran-7 -g -O0 -Wall -Wextra -fcheck=all z1.f90
> $ a.out
>1   1
> 
> 
> $ gfortran-9-2018 -c z1.f90
> f951: internal compiler error: check_data_variable(): Bad expression

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 266386)
+++ gcc/fortran/resolve.c   (working copy)
@@ -15492,7 +15492,10 @@ check_data_variable (gfc_data_variable *var, locus *wh
 e = e->value.function.actual->expr;

   if (e->expr_type != EXPR_VARIABLE)
-gfc_internal_error ("check_data_variable(): Bad expression");
+{
+  gfc_error ("Expecting definable entity near %L", where);
+  return false;
+}

   sym = e->symtree->n.sym;

@@ -15500,6 +15503,7 @@ check_data_variable (gfc_data_variable *var, locus *wh
 {
   gfc_error ("BLOCK DATA element %qs at %L must be in COMMON",
 sym->name, >declared_at);
+  return false;
 }

   if (e->ref == NULL && sym->as)

Re: [PATCH] Add missing noexpect causes in tuple for move functions

[nick]

On 2018-11-30 6:12 p.m., Ville Voutilainen wrote:
> On Sat, 1 Dec 2018 at 01:05, Nicholas Krause  wrote:
>>
>> This adds the remainging noexcept causes required for this cause
>> to meet the spec as dicussed last year and documented here:
>> http://cplusplus.github.io/LWG/lwg-active.html#2899.
> 
> I don't see how this change is sufficient; the noexcept-specs need to
> be added to tuple's
> special member functions, not just to _Tuple_impl, and your suggested
> patch contains no
> tests.
> 

It was tested I just didn't mention that as it was assumed, that's my mistake 
and
sorry for that. This was more just to make sure that this is fine. If you would
prefer I send a patch  cleaning it up for all the classes i.e. tuple, and it's 
version's that's fine. I just want to ask do you want a patch or a series will
each patch touching one of the tuple clases as I assume your the maintainer.

Cheers,

Nick

[Bug fortran/88079] warn about procedure arguments without INTENT

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
   Severity|normal  |enhancement

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Vivek Rao from comment #0)
> I think all new Fortran code should have the INTENT specified for the
> arguments of all procedures. I request that gfortran add a warning for code
> not doing this. If a warning is added, users who agree with my style
> recommendation can use a -Werror flag to force them to fix code without
> INTENTs for all arguments.
> 
> This is, of course, an enhancement request, not a bug report.

How does gfortran differential between new Fortran code and
old Fortran code.  It is the programmer's responsibility to 
know what he or she is doing.

[Bug fortran/88080] Add warning if IMPLICIT NONE is missing

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
   Severity|normal  |enhancement

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Vivek Rao from comment #0)
> I think new Fortran code should have IMPLICIT NONE in every procedure or
> preferably at the beginning of a program or MODULE. I request that gfortran
> add an option that warns when this is not the case. Users who want IMPLICIT
> NONE in all code can convert such a warning to an error.
> 
> This is, of course, an enhancement request and not a bug report.

How does gfortran differentiate between new Fortran code and old
Fortran code?  I think it is the programmer's responsibility to
learn how to use the tools given to them to his/hers advantage.

[Bug fortran/88139] ICE in get_c_type_name, at fortran/dump-parse-tree.c:3047

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/dump-parse-tree.c
===
--- gcc/fortran/dump-parse-tree.c   (revision 266386)
+++ gcc/fortran/dump-parse-tree.c   (working copy)
@@ -3259,6 +3259,14 @@ write_proc (gfc_symbol *sym)
 {
   gfc_symbol *s;
   s = f->sym;
+
+  if (!s)
+   {
+ gfc_error_now ("At %L, \"Nous sommes tous nes pour le mal\"",
+>declared_at);
+ return;
+   }
+
   rok = get_c_type_name (&(s->ts), NULL, , _name, ,
 , false);
   if (rok == T_ERROR)

Re: [RS6000] num_insns_constant ICE

[Segher Boessenkool]

On Fri, Nov 30, 2018 at 06:16:40PM +1030, Alan Modra wrote:
> On Thu, Nov 29, 2018 at 01:52:34PM -0600, Segher Boessenkool wrote:
> > On Sun, Nov 25, 2018 at 10:49:12PM +1030, Alan Modra wrote:
> > > +  while (nregs-- > 0)
> > > +{
> > > +  int ins = num_insns_constant_gpr (value);
> > 
> > You probably should mask "value" here so that it is only one GPR.
> > Alternatively, make num_insns_constant_gpr handle that.  Consider what
> > happens for a 64-bit number with 32-bit registers here?
> 
> Oh, right, the low part will always give an answer of 2 if the high
> parts isn't merely a sign extension.
> 
> > > + val = l[WORDS_BIG_ENDIAN ? 0 : 1] << 32;
> > 
> > This doesn't work, as in the other patch: long can be 32 bit.
> 
> Huh, I originally had "high" and "low" HOST_WIDE_INTs which avoided
> this sort of problem on 32-bit hosts.
> 
> Revised patch follows.  Bootstrapped and regression tested
> powerpc64le-linux.  Hopefully this has removed all the stupidity.

I think it is fine like this, or certainly an improvement :-)  Okay for
trunk.  Thanks!


Segher


>   * config/rs6000/rs6000.c (num_insns_constant_gpr): Renamed from
>   num_insns_constant_wide.  Make static.  Revise comment.
>   (num_insns_constant_multi): New function.
>   (num_insns_constant): Formatting.  Correct CONST_WIDE_INT
>   calculation.  Simplify and extract code common to both
>   CONST_INT and CONST_DOUBLE.  Add gcc_unreachable for unhandled
>   const_double modes.
>   * config/rs6000/rs6000-protos.h (num_insns_const_wide): Delete.

Re: [PATCH] Improve combiner's find_split_point (PR target/54589)

[Segher Boessenkool]

On Thu, Nov 29, 2018 at 04:36:01PM -0600, Segher Boessenkool wrote:
> Hi Jakub,
> 
> On Thu, Nov 29, 2018 at 10:49:21PM +0100, Jakub Jelinek wrote:
> > The following patch attempts to improve find_split_point inside of
> > complex MEM addresses, if the target supports REG + REG + const
> > addressing, but doesn't support more_complex_rtx + REG + const,
> > try to split it at more_complex_rtx rather than more_complex_rtx + REG.
> 
> > 2018-11-29  Jakub Jelinek  
> > 
> > PR target/54589
> > * combine.c (find_split_point): For invalid memory address
> > nonobj + obj + const, if reg + obj + const is valid addressing
> > mode, split at nonobj.  Use if rather than else if for the
> > fallback.  Comment fixes.
> > 
> > * gcc.target/i386/pr54589.c: New test.
> 
> That looks good, but let me try it on some bigger builds first.

Whoops, forgot to get back to you.  I tested it, and it looks fine, it
optimises the code quite often :-)  Please commit it to trunk.

Thanks,


Segher

[Bug fortran/88205] ICE in gfc_wide_strncasecmp, at fortran/scanner.c:249

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 266386)
+++ gcc/fortran/io.c(working copy)
@@ -2161,6 +2161,12 @@ gfc_match_open (void)

   if (!open->file && open->status)
 {
+ if (open->status->ts.type != BT_CHARACTER)
+   {
+gfc_error ("STATUS must be a default character type at %C");
+goto cleanup;
+   }
+
  if (open->status->expr_type == EXPR_CONSTANT
 && gfc_wide_strncasecmp (open->status->value.character.string,
   "scratch", 7) != 0)

Re: [PATCH] Added information about inline assembler in stack calculations (.su files)

[Jeff Law]

On 11/26/18 7:02 AM, Torbjorn SVENSSON wrote:
> Hi,
> 
> Attached is a small patch that, in case of inline assembler code, 
> indicates that the function stack usage is uncertain due to inline 
> assembler.
> 
> The test suite are using "nop" as an assembler instruction on all 
> targets, is this acceptable or is there a better way to test this?
> 
> Patch has been tested on gcc-arm-none-eabi-7-2018-q2-update for both 
> arm-none-eabi and x86_64-linux-gnu and SVN head (r266454) for 
> x86_64-linux-gnu.
One could argue that allocating stack space inside an ASM is a really
bad idea.  Consider things like dwarf debugging and unwind tables.  If
you're allocating stack inside an ASM that stuff is going to be totally
wrong.

So I think my question before moving forward with something like this is
whether or not it makes sense at all to bother dumping data for a
scenario that we'd probably suggest developers avoid to begin with.

jeff

Re: question about attribute aligned for functions

[Jeff Law]

On 11/29/18 8:34 AM, Martin Sebor wrote:
> 
> GCC does disallow decreasing the function alignment -- but only
> for functions that were already declared with a more restrictive
> one.  Like this:
> 
>   __attribute__ ((aligned (4))) void f (void);
> 
>   __attribute__ ((aligned (2))) void f (void);
> 
>   warning: ignoring attribute ‘aligned (2)’ because it conflicts with
> attribute ‘aligned (4)’
> 
> It doesn't warn about going from the default (say 16 on i86)
> to something smaller, and it honors that lower alignment up
> to the supported minimum.  It's probably worth clarifying in
> the manual.  Let me propose something.
Please do.  Thanks.

> 

 Whether or not to warn in general if the alignment attribute is smaller
 than the default may be subject to debate.  I guess it depends on the
 general intent that we'd find in real world codes.
>>>
>>> I would expect real world code to care about achieving at least
>>> the specified alignment.
>> If we only allow increasing, yes.  At which point what do the values 0
>> or 1 realistically mean?
> 
> If we only allowed increasing then both 0 and 1 would be
> meaningless.
> 
>>
>> If we allow decreasing, then the user may be asking for a smaller
>> alignment to achieve better code density.
> 
> Yes, that's definitely possible (I just opened pr88231 -
> aligned functions laid down inefficiently, as I noticed this
> doesn't work as well as it could and arguably should).  But they
> can't get it if the target doesn't support it.  In which case I
> think adding a new warning to point it out might be useful.  At
> the same time, users wanting maximum density across all their
> targets shouldn't have to worry about what the minimum alignment
> is on each of them and hardwire different constants into
> the attribute.  I think they should be able to specify 1 and
> have GCC round it up as necessary, with no warning.  So I'd make
> the new warning off by default.
That seems like a better UI than forcing the user to know what their
target actually supports.

So, yea I think I'm in agreement with where you're going.

jeff

[Bug fortran/88206] [7/8/9 Regression] ICE in gfc_match_type_spec, at fortran/match.c:2229

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> Affects versions 7,8,9 :
> 
> 
> $ cat z1.f90
> program p
>integer, parameter :: z(4) = [1,2,3,4]
>integer :: k = 2
>print *, [real(z(k))]
> end
> 
> 
> $ gfortran-6 -c z1.f90
> $
> $ gfortran-9-20181125 -c z1.f90
> f951: internal compiler error: Segmentation fault
> 0xb2bcff crash_signal
> ../../gcc/toplev.c:326
> 0x64ba3f gfc_match_type_spec(gfc_typespec*)
> ../../gcc/fortran/match.c:2229

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 266386)
+++ gcc/fortran/match.c (working copy)
@@ -2225,6 +2225,9 @@ found:
  return MATCH_NO;
}

+ if (e->expr_type != EXPR_CONSTANT)
+   goto ohno;
+
  gfc_next_char (); /* Burn the ')'. */
  ts->kind = (int) mpz_get_si (e->value.integer);
  if (gfc_validate_kind (ts->type, ts->kind , true) == -1)
@@ -2238,6 +2241,8 @@ found:
  return MATCH_YES;
}
 }
+
+ohno:

   /* If a type is not matched, simply return MATCH_NO.  */
   gfc_current_locus = old_locus;

Re: [PATCH] minor FDO profile related fixes

[Jeff Law]

On 11/9/18 7:12 PM, Indu Bhagat wrote:
> Changelog entry attached. Sorry about that.
> 
> Comments inline.
> 
> Thanks
> 
> On 11/09/2018 04:23 PM, Jeff Law wrote:
>> On 11/7/18 5:49 PM, Indu Bhagat wrote:
>>> diff --git a/gcc/coverage.c b/gcc/coverage.c
>>> index 599a3bb..7595e6c 100644
>>> --- a/gcc/coverage.c
>>> +++ b/gcc/coverage.c
>>> @@ -358,7 +358,7 @@ get_coverage_counts (unsigned counter, unsigned 
>>> cfg_checksum,
>>>
>>> if (warning_printed && dump_enabled_p ())
>>>   {
>>> dump_user_location_t loc
>>> -= dump_user_location_t::from_location_t (input_location);
>>> += dump_user_location_t::from_function_decl (current_function_decl);
>>>
>>> dump_printf_loc (MSG_MISSED_OPTIMIZATION, loc,
>>>  "use -Wno-error=coverage-mismatch to tolerate "
>>>
>>>  "the mismatch but performance may drop if the "
>>>
>> Patches should include a ChangeLog entry.  Because your patch didn't
>> include one, it's unclear if this hunk is something you really intended
>> to submit or not.  What's the point behind going from using
>> input_location to the function decl?
>>
> This is intended to be a part of the patch. The patch intends to make 
> opt-info and dumps related to ipa-profile more precise.
> 
> Using from_function_decl gives the precise location of the function. 
> from_location_t gives the same incorrect location for each function
> 
> with the coverage-mismatch issue in a compilation unit (location appears to 
> be the end of file)
OK.  And more generally we're trying to move away from input_location.
If associating the diagnostic with the function makes sense, then this
hunk is clearly OK.


>>> @@ -1317,12 +1327,12 @@ branch_prob (void)
>>> values.release ();
>>> free_edge_list (el);
>>> coverage_end_function (lineno_checksum, cfg_checksum);
>>> -  if (flag_branch_probabilities && profile_info)
>>> +  if (flag_branch_probabilities
>>> +  && (profile_status_for_fn (cfun) == PROFILE_READ))
>> So what's the point of this change?  Under what circumstances do the two
>> conditionals do something different.  I don't know this code well, but
>> ISTM that if profile_info is nonzero, then the profile status is going
>> to be PROFILE_READ.  Is that not the case?
> 
> On Trunk, there is a direct relationship between the three :
> 
> 1. (.gcda file) is present  --implies--> 2. profile_info set
> --implies--> 3. profile_status set to PROFILE_READ
Right.   That's the basic assumption I was working from.

> 
> But for functions added between profile-generate and profile-use, 3.
> should not be done based on 2.
> For such functions, profile_info may be set (because there is a .gcda
> file), but profile_status should not be set
> to PROFILE_READ, because such functions have no feedback data.
Ah, I see what you're getting at here.  THe sources have changed since
we gathered the profiling data.  In the case where new functions were
added to the source, we won't have profiling data for them.  So we
should be checking for profiling data attached to a function.  Got it.


> 
> 
> Changelog.precise-ipa-dump-optinfo.patch.ver1
> 
> gcc/ChangeLog:
> 
> 2018-11-07  "Indu Bhagat"  <"indu.bha...@oracle.com">
> 
>   * coverage.c (get_coverage_counts): Use from_function_decl for precise
>   function location.
>   * profile-count.c (profile_count::dump): Add handling for precise
>   profile quality.
>   * profile.c (compute_branch_probabilities): Rely on exec_counts instead
>   of profile_info to set x_profile_status of function.
>   (branch_prob): Do not set x_profile_status of function based on
>   profile_info. Done above based on exec_counts.
> 
I'll fix up the trivial extraneous curley braces nit and commit this
momentarily.

THanks,
Jeff

[Bug fortran/88228] ICE in check_null, at fortran/expr.c:2691

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (revision 266386)
+++ gcc/fortran/expr.c  (working copy)
@@ -2688,6 +2688,9 @@ check_transformational (gfc_expr *e)
 static match
 check_null (gfc_expr *e)
 {
+  if (e->expr_type == EXPR_CONSTANT)
+   return MATCH_NO;
+
   if (strcmp ("null", e->symtree->n.sym->name) != 0)
 return MATCH_NO;

@@ -2793,10 +2796,15 @@ gfc_check_init_expr (gfc_expr *e)
&& (m = check_transformational (e)) == MATCH_NO
&& (m = check_elemental (e)) == MATCH_NO)
  {
-   gfc_error ("Intrinsic function %qs at %L is not permitted "
-  "in an initialization expression",
-  e->symtree->n.sym->name, >where);
-   m = MATCH_ERROR;
+   if (e->expr_type == EXPR_CONSTANT)
+ return true;
+   else
+ {
+   gfc_error ("Intrinsic function %qs at %L is not permitted "
+  "in an initialization expression",
+  e->symtree->n.sym->name, >where);
+   m = MATCH_ERROR;
+ }
  }

if (m == MATCH_ERROR)

[Bug testsuite/85368] [8 regression] phi-opt-11 test fails on IBM Z

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 regression] phi-opt-11 |[8 regression] phi-opt-11
   |test fails on IBM Z |test fails on IBM Z

--- Comment #15 from Jakub Jelinek  ---
Hopefully fixed on the trunk now.

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 30 23:27:23 2018
New Revision: 266701

URL: https://gcc.gnu.org/viewcvs?rev=266701=gcc=rev
Log:
PR tree-optimization/88274
* tree-ssa-reassoc.c (optimize_range_tests_xor,
optimize_range_tests_diff): If type has smaller precision than
corresponding mode or if it has non-standard min/max, compute
everything in a standard type for the precision.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 30 23:26:41 2018
New Revision: 266700

URL: https://gcc.gnu.org/viewcvs?rev=266700=gcc=rev
Log:
PR testsuite/85368
* params.def (PARAM_LOGICAL_OP_NON_SHORT_CIRCUIT): New param.
* tree-ssa-ifcombine.c (ifcombine_ifandif): If
--param logical-op-non-short-circuit is present, override
LOGICAL_OP_NON_SHORT_CIRCUIT value from the param.
* fold-const.c (fold_range_test, fold_truth_andor): Likewise.

* lib/target-supports.exp (logical_op_short_circuit): Remove.
* gcc.dg/builtin-bswap-7.c: Remove logical_op_short_circuit
effective target, drop -mbranch-cost= options from the test and
instead pass --param logical-op-non-short-circuit=0 or
--param logical-op-non-short-circuit=1 depending on what the
tests meant to test.
* gcc.dg/pr21643.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-2.c: Likewise.
* gcc.dg/tree-ssa/phi-opt-11.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-4.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-3.c: Likewise.
* gcc.dg/tree-ssa/ssa-thread-14.c: Likewise.
* gcc.dg/tree-ssa/vrp47.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-11.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-16.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-14.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c: Likewise.
* gcc.dg/tree-ssa/vrp87.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c: Likewise.
* gcc.dg/tree-ssa/phi-opt-2.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-13.c: Likewise.
* gcc.dg/tree-ssa/ssa-thread-11.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c: Likewise.
* gcc.dg/tree-ssa/forwprop-28.c: Likewise.
* gcc.dg/binop-xor1.c: Likewise.
* gcc.dg/pr46309.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-18.c: New test.
* gcc.dg/tree-ssa/reassoc-32.c: Add
--param logical-op-non-short-circuit=1 to dg-options.
* gcc.dg/tree-ssa/reassoc-33.c: Likewise.
* gcc.dg/tree-ssa/reassoc-34.c: Likewise.
* gcc.dg/tree-ssa/reassoc-35.c: Likewise.
* gcc.dg/tree-ssa/reassoc-36.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-18.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/params.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/binop-xor1.c
trunk/gcc/testsuite/gcc.dg/builtin-bswap-7.c
trunk/gcc/testsuite/gcc.dg/pr21643.c
trunk/gcc/testsuite/gcc.dg/pr46309.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-32.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-14.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-16.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-13.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-14.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp87.c
trunk/gcc/testsuite/lib/target-supports.exp
trunk/gcc/tree-ssa-ifcombine.c

[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Better.

Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h  (revision 266386)
+++ gcc/fortran/gfortran.h  (working copy)
@@ -3374,7 +3374,7 @@ bool gfc_resolve_open (gfc_open *);
 void gfc_free_close (gfc_close *);
 bool gfc_resolve_close (gfc_close *);
 void gfc_free_filepos (gfc_filepos *);
-bool gfc_resolve_filepos (gfc_filepos *);
+bool gfc_resolve_filepos (gfc_filepos *, locus *);
 void gfc_free_inquire (gfc_inquire *);
 bool gfc_resolve_inquire (gfc_inquire *);
 void gfc_free_dt (gfc_dt *);
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 266386)
+++ gcc/fortran/resolve.c   (working copy)
@@ -11544,7 +11544,7 @@ start:
case EXEC_ENDFILE:
case EXEC_REWIND:
case EXEC_FLUSH:
- if (!gfc_resolve_filepos (code->ext.filepos))
+ if (!gfc_resolve_filepos (code->ext.filepos, >loc))
break;

  resolve_branch (code->ext.filepos->err, code);
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 266386)
+++ gcc/fortran/io.c(working copy)
@@ -2834,22 +2834,21 @@ cleanup:


 bool
-gfc_resolve_filepos (gfc_filepos *fp)
+gfc_resolve_filepos (gfc_filepos *fp, locus *where)
 {
   RESOLVE_TAG (_unit, fp->unit);
   RESOLVE_TAG (_iostat, fp->iostat);
   RESOLVE_TAG (_iomsg, fp->iomsg);
-  if (!gfc_reference_st_label (fp->err, ST_LABEL_TARGET))
-return false;

-  if (!fp->unit && (fp->iostat || fp->iomsg))
+  if (!fp->unit && (fp->iostat || fp->iomsg || fp->err))
 {
-  locus where;
-  where = fp->iostat ? fp->iostat->where : fp->iomsg->where;
-  gfc_error ("UNIT number missing in statement at %L", );
+  gfc_error ("UNIT number missing in statement at %L", where);
   return false;
 }

+  if (!gfc_reference_st_label (fp->err, ST_LABEL_TARGET))
+return false;
+
   if (fp->unit->expr_type == EXPR_CONSTANT
   && fp->unit->ts.type == BT_INTEGER
   && mpz_sgn (fp->unit->value.integer) < 0)

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[law at redhat dot com]

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

Bug 79768 Summary: `-Wmaybe-uninitialized' false positive with optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79768

   What|Removed |Added

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

[Bug middle-end/79768] `-Wmaybe-uninitialized' false positive with optimisation

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
Per c#9.

Re: [PATCH v5] Repeat jump threading after combine

[Jeff Law]

On 11/28/18 11:57 PM, Ilya Leoshkevich wrote:
> Repost of v4: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02067.html
> 
> Bootstrapped and regtested on x86_64-redhat-linux, s390x-redhat-linux
> and ppc64le-redhat-linux.
> 
> Consider the following RTL:
> 
> (insn (set (reg 65) (if_then_else (eq %cc 0) 1 0)))
> (insn (parallel [(set %cc (compare (reg 65) 0)) (clobber %scratch)]))
> (jump_insn (set %pc (if_then_else (ne %cc 0) (label_ref 23) %pc)))
> 
> Combine simplifies this into:
> 
> (note NOTE_INSN_DELETED)
> (note NOTE_INSN_DELETED)
> (jump_insn (set %pc (if_then_else (eq %cc 0) (label_ref 23) %pc)))
> 
> opening up the possibility to perform jump threading.
> 
> gcc/ChangeLog:
> 
> 2018-09-19  Ilya Leoshkevich  
> 
>   PR target/80080
>   * cfgcleanup.c (class pass_postreload_jump): New pass.
>   (pass_postreload_jump::execute): Likewise.
>   (make_pass_postreload_jump): Likewise.
>   * passes.def: Add pass_postreload_jump before
>   pass_postreload_cse.
>   * tree-pass.h (make_pass_postreload_jump): New pass.
OK
jeff

Re: [PATCH] Avoid weird integral types in reassoc range opts (PR tree-optimization/88274)

[Jeff Law]

On 11/30/18 1:44 PM, Jakub Jelinek wrote:
> Hi!
> 
> The following patch makes sure that we don't use weird integral types
> (either ones which have smaller precision than corresponding mode's
> precision, or ones like C++ -fstrict-enum enumeral types which have
> normal precision, but smaller TYPE_MAX_VALUE or larger TYPE_MIN_VALUE),
> because the constants could be outside of the range of those types.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2018-11-30  Jakub Jelinek  
> 
>   PR tree-optimization/88274
>   * tree-ssa-reassoc.c (optimize_range_tests_xor,
>   optimize_range_tests_diff): If type has smaller precision than
>   corresponding mode or if it has non-standard min/max, compute
>   everything in a standard type for the precision.
OK
jeff

[Bug rtl-optimization/88179] [9 regression][MIPS] pr84941.c ICE in lra_eliminate_reg_if_possible at lra-eliminations.c:1393 start with r266385

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law  ---
Fixed by Vlad's patch on the trunk.

Re: [PATCH] Comparison with an enum should mention enum value.

[Jeff Law]

On 11/30/18 2:49 AM, Martin Liška wrote:
> Hi.
> 
> This is one more clean up of the transition that I've just tested
> on x86_64-linux-gnu.
> 
> I'm planning to install it once I'll come back from vacation (27/12).
> 
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2018-11-29  Martin Liska  
> 
>   * builtins.c (expand_movstr): Compare with RETURN_BEGIN.
>   * expr.c (move_by_pieces): Likewise.
>   (store_by_pieces): Likewise.
>   (store_expr): Fix GNU coding style.
OK
jeff

Re: [PATCH] Introduce --param logical-op-non-short-circuit (PR testsuite/85368)

[Jeff Law]

On 11/30/18 1:50 PM, Jakub Jelinek wrote:
> Hi!
> 
> Until we stop depending on BRANCH_COST and LOGICAL_OP_NON_SHORT_CIRCUIT
> macros at least for early GIMPLE, I'm afraid the current state for the
> testsuite is terrible, on some targets it is enough to use
> -mbranch-cost={1,2} to pick either of the setting, but other targets,
> while they implement -mbranch-cost=, redefine LOGICAL_OP_NON_SHORT_CIRCUIT,
> so it ignores BRANCH_COST altogether, or sometimes, other targets don't
> implement -mbranch-cost= and have various complex definitions of BRANCH_COST
> or LOGICAL_OP_NON_SHORT_CIRCUIT depending on other command line options.
> 
> The following patch introduces a new param (not an option, to make it
> clearer it is intended primarily for the testsuite and we can more easily
> remove it again) that overrides the target's LOGICAL_OP_NON_SHORT_CIRCUIT
> and adjusts the testsuite to use it.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, Christophe has kindly
> tested it on ARM.  Ok for trunk?
> 
> 2018-11-30  Jakub Jelinek  
> 
>   PR testsuite/85368
>   * params.def (PARAM_LOGICAL_OP_NON_SHORT_CIRCUIT): New param.
>   * tree-ssa-ifcombine.c (ifcombine_ifandif): If
>   --param logical-op-non-short-circuit is present, override
>   LOGICAL_OP_NON_SHORT_CIRCUIT value from the param.
>   * fold-const.c (fold_range_test, fold_truth_andor): Likewise.
> 
>   * lib/target-supports.exp (logical_op_short_circuit): Remove.
>   * gcc.dg/builtin-bswap-7.c: Remove logical_op_short_circuit
>   effective target, drop -mbranch-cost= options from the test and
>   instead pass --param logical-op-non-short-circuit=0 or
>   --param logical-op-non-short-circuit=1 depending on what the
>   tests meant to test.
>   * gcc.dg/pr21643.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-2.c: Likewise.
>   * gcc.dg/tree-ssa/phi-opt-11.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-dom-thread-4.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-3.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-thread-14.c: Likewise.
>   * gcc.dg/tree-ssa/vrp47.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-dom-thread-11.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-dom-thread-16.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-dom-thread-14.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c: Likewise.
>   * gcc.dg/tree-ssa/vrp87.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c: Likewise.
>   * gcc.dg/tree-ssa/phi-opt-2.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-ifcombine-13.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-thread-11.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c: Likewise.
>   * gcc.dg/tree-ssa/forwprop-28.c: Likewise.
>   * gcc.dg/binop-xor1.c: Likewise.
>   * gcc.dg/pr46309.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-dom-thread-18.c: New test.
>   * gcc.dg/tree-ssa/reassoc-32.c: Add
>   --param logical-op-non-short-circuit=1 to dg-options.
>   * gcc.dg/tree-ssa/reassoc-33.c: Likewise.
>   * gcc.dg/tree-ssa/reassoc-34.c: Likewise.
>   * gcc.dg/tree-ssa/reassoc-35.c: Likewise.
>   * gcc.dg/tree-ssa/reassoc-36.c: Likewise.
OK.

Jeff

[committed] Fix style issue pointed out by Bernhard in my recent change

[Jeff Law]

Bernhard pointed out that we should be using


machine_mode 

rather than

enum machine_mode 

in one of my patches.  I guess old habits die hard.

Anyway, this trivial patch fixes the nit.  I'll try to remember to start
omitting the "enum" "class" and "struct" thingies more appropriately :-)



jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6c57ed0027e..0bf512d35a9 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2018-11-30  Jeff Law  
+
+   * optabs.c (expand_binop): Use "machine_mode" rather than
+   "enum machine mode" in most recent change.
+
 2018-11-30  Wilco Dijkstra  
 
PR middle-end/64242
diff --git a/gcc/optabs.c b/gcc/optabs.c
index 130b1182ef0..1f87e428816 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -1377,8 +1377,8 @@ expand_binop (machine_mode mode, optab binoptab, rtx op0, 
rtx op1,
   start_sequence ();
 
   /* Do the actual arithmetic.  */
-  enum machine_mode op0_mode = GET_MODE (op0);
-  enum machine_mode op1_mode = GET_MODE (op1);
+  machine_mode op0_mode = GET_MODE (op0);
+  machine_mode op1_mode = GET_MODE (op1);
   if (op0_mode == VOIDmode)
op0_mode = int_mode;
   if (op1_mode == VOIDmode)

Re: [PATCH] Add missing noexpect causes in tuple for move functions

[Ville Voutilainen]

On Sat, 1 Dec 2018 at 01:05, Nicholas Krause  wrote:
>
> This adds the remainging noexcept causes required for this cause
> to meet the spec as dicussed last year and documented here:
> http://cplusplus.github.io/LWG/lwg-active.html#2899.

I don't see how this change is sufficient; the noexcept-specs need to
be added to tuple's
special member functions, not just to _Tuple_impl, and your suggested
patch contains no
tests.

[Bug middle-end/64242] Longjmp expansion incorrect

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #6 from Jeffrey A. Law  ---
Fixed on trunk by Wilco's patch.

Re: C++ PATCH to implement C++20 P0634R3, Down with typename!

[Marek Polacek]

On Wed, Nov 28, 2018 at 05:09:23PM -0500, Jason Merrill wrote:
> On 11/12/18 10:27 AM, Marek Polacek wrote:
> > This patch implements C++20 P0634R3, Down with typename!
> > 
> > which makes 'typename' optional in several contexts specified in [temp.res].
> > 
> > The gist of the patch is in cp_parser_simple_type_specifier, where, if the
> > context makes typename optional and the id is qualified, we pretend we've
> > seen the typename keyword.
> 
> Sounds good.

\o/

> > There's quite a lot of churn because we need to be careful where we want
> > to make typename optional, and e.g. a flag in cp_parser would be too global.
> 
> Did you consider adding a cp_parser_flags parameter rather than a specific
> bool?  I don't feel strongly about it, but it would simplify things the next
> time we want to do something like this.

I think I did but ran out of time.  I've changed the boolean parameters to
cp_parser_flags in this patch.

> > The resolve_typename_type hunk was to make typename9.C work with -fconcepts.
> 
> Makes sense.
> 
> > +   const bool typename_optional_p = (cxx_dialect >= cxx2a);
> 
> I'm uncomfortable with repeating this in lots of places in the parser; I'd
> prefer to have one place where we control whether the feature is enabled or
> not.  This seems like the right place:
> > + bool typename_p = (flags & CP_PARSER_FLAGS_TYPENAME_OPTIONAL);
> > + type = cp_parser_type_name (parser, (qualified_p && typename_p));

Indeed, this was a nice cleanup.

> > I'm not sure about some of the bits in typename5.C, not quite sure if the
> > code is valid, but I didn't have time to investigate deeply and it seems
> > pretty obscure anyway.  There are preexisting cases when g++ and clang++
> > disagree.
> 
> > +  // ??? Not sure if these are (in)valid.
> 
> I think these are all valid, since the qualified-ids all appear as a
> decl-specifier of a member-declaration.

Ok, I found a bug in the previous version of this patch: when we saw the
template keyword, we didn't call cp_parser_type_name in
cp_parser_simple_type_specifier, as a result, typename was needed in
a member-declaration even though it now shouldn't.
 
Fixed by calling cp_parser_make_typename_type.

> > +  typedef typename A::template N a1;
> > +  typedef typename A::template N a2;
> > +  typename A::template N a3;
> > +  typename A::template N a4;
> > +  typedef A::N a5; // { dg-error "not a type|invalid" }
> > +  typedef A::N a6; // { dg-error "not a type|invalid" }
> 
> The ::template shouldn't be required here anymore: [temp.names] "In a
> qualified-id used as the name in a typename-specifier (12.7),
> elaborated-type-specifier (9.1.7.3), using-declaration (9.8), or
> class-or-decltype (10.6), an optional keyword template appearing at the top
> level is ignored. In these contexts, a < token is always assumed to
> introduce a template-argument-list."
> 
> This is C++17 DR 1710.  You don't need to implement it in this patch, but
> let's not test for the wrong behavior.  :)

Thanks for the pointer to that!  With ::template it now passes, as shown in
typename5.C.

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

2018-11-30  Marek Polacek  

Implement P0634R3, Down with typename!
* parser.c (CP_PARSER_FLAGS_TYPENAME_OPTIONAL): New enumerator.
(cp_parser_type_name): Remove declaration.
(cp_parser_postfix_expression): Pass CP_PARSER_FLAGS_TYPENAME_OPTIONAL
to cp_parser_type_id.
(cp_parser_new_type_id): Pass CP_PARSER_FLAGS_TYPENAME_OPTIONAL to
cp_parser_type_specifier_seq.
(cp_parser_lambda_declarator_opt): Pass
CP_PARSER_FLAGS_TYPENAME_OPTIONAL to
cp_parser_parameter_declaration_clause.
(cp_parser_condition): Pass CP_PARSER_FLAGS_NONE to
cp_parser_declarator.
(cp_parser_simple_declaration): Pass CP_PARSER_FLAGS_NONE to
cp_parser_init_declarator.
(cp_parser_conversion_type_id): Pass CP_PARSER_FLAGS_NONE to
cp_parser_type_specifier_seq.
(cp_parser_default_type_template_argument): Pass
CP_PARSER_FLAGS_TYPENAME_OPTIONAL to cp_parser_type_id.
(cp_parser_template_parameter): Pass CP_PARSER_FLAGS_TYPENAME_OPTIONAL
to cp_parser_parameter_declaration.
(cp_parser_explicit_instantiation): Pass CP_PARSER_FLAGS_NONE to
cp_parser_declarator.
(cp_parser_simple_type_specifier): Adjust call to cp_parser_type_name
to relay if we should treat the typename keyword as optional.  Maybe
call cp_parser_make_typename_type is parsing a template-id and it's
not a TYPE_DECL.
(cp_parser_type_name): Remove unused function.
(cp_parser_enum_specifier): Pass to CP_PARSER_FLAGS_NONE
cp_parser_type_specifier_seq.
(cp_parser_alias_declaration): Pass CP_PARSER_FLAGS_TYPENAME_OPTIONAL
to cp_parser_type_id.
(cp_parser_init_declarator): New parameter.  Pass 

Re: [PATCH] Fix PR64242

[Jeff Law]

On 11/29/18 12:26 PM, Wilco Dijkstra wrote:
> Fix PR64242 - the middle end expansion for long jmp updates the
> hard frame pointer before it reads the new stack pointer.  This
> results in a corrupted stack pointer if the jmp buffer is a local.
> The obvious fix is to insert a temporary.
> 
> AArch64 bootstrap & regress pass. OK to commit?
> 
> ChangeLog:
> 2018-11-29  Wilco Dijkstra  
> 
> gcc/
>   PR middle-end/64242
>   * builtins.c (expand_builtin_longjmp): Use a temporary when restoring
>   the frame pointer.
>   (expand_builtin_nonlocal_goto): Likewise.
> 
> testsuite/
>   PR middle-end/64242
>   * gcc.c-torture/execute/pr64242.c: New test.
THanks for tracking this down.  I'd like to have this run through my
next testing cycle, so I went ahead and installed  it for you.

Thanks again,
Jeff

[Bug middle-end/64242] Longjmp expansion incorrect

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Fri Nov 30 23:06:51 2018
New Revision: 266697

URL: https://gcc.gnu.org/viewcvs?rev=266697=gcc=rev
Log:
PR middle-end/64242
* builtins.c (expand_builtin_longjmp): Use a temporary when restoring
the frame pointer.
(expand_builtin_nonlocal_goto): Likewise.

* gcc.c-torture/execute/pr64242.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr64242.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[PATCH] Add missing noexpect causes in tuple for move functions

[Nicholas Krause]

This adds the remainging noexcept causes required for this cause
to meet the spec as dicussed last year and documented here:
http://cplusplus.github.io/LWG/lwg-active.html#2899.

Signed-off-by: Nicholas Krause 
---
 libstdc++-v3/include/std/tuple | 4 
 1 file changed, 4 insertions(+)

diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 56b97c25eed..d17512a1b7e 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -214,6 +214,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
enable_if::type>
 explicit
 constexpr _Tuple_impl(_UHead&& __head, _UTail&&... __tail)
+noexcept(__and_,
+ is_nothrow_move_constructible<_Inherited>>::value)
: _Inherited(std::forward<_UTail>(__tail)...),
  _Base(std::forward<_UHead>(__head)) { }
 
@@ -237,6 +239,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 constexpr _Tuple_impl(_Tuple_impl<_Idx, _UHead, _UTails...>&& __in)
+noexcept(__and_,
+ is_nothrow_move_constructible<_Inherited>>::value)
: _Inherited(std::move
 (_Tuple_impl<_Idx, _UHead, _UTails...>::_M_tail(__in))),
  _Base(std::forward<_UHead>
-- 
2.17.1

[PATCH] v4: C/C++: add fix-it hints for missing '&' and '*' (PR c++/87850)

[David Malcolm]

On Tue, 2018-11-20 at 22:23 +, Joseph Myers wrote:
> On Tue, 20 Nov 2018, David Malcolm wrote:
> 
> > Should I do:
> 
> You should do whatever is appropriate for the warning in
> question.  But if 
> what's appropriate for the warning in question includes types that
> are 
> compatible but not the same, the comments need to avoid saying it's
> about 
> the types being the same. 

Thanks.

Here's an updated version of the patch.  I added a new
  compatible_types_for_indirection_note_p
specifically for use by maybe_emit_indirection_note, and provided
implementations for C and C++.

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

OK for trunk?


Changed in v4: introduce a compatible_types_for_indirection_note_p
function, and use it in place of same_type_p.

Changed in v3: use same_type_p rather than pointer equality.
Provide implementation of same_type_p for C.

Changed in v2: add a note, and put the fix-it hint on that instead

Blurb follows:

This patch adds a note with a fix-it hint to various
pointer-vs-non-pointer diagnostics, suggesting the addition of
a leading '&' or '*'.

For example, note the ampersand fix-it hint in the following:

demo.c: In function 'int main()':
demo.c:5:22: error: invalid conversion from 'pthread_key_t' {aka 'unsigned int'}
   to 'pthread_key_t*' {aka 'unsigned int*'} [-fpermissive]
5 |   pthread_key_create(key, NULL);
  |  ^~~
  |  |
  |  pthread_key_t {aka unsigned int}
demo.c:5:22: note: possible fix: take the address with '&'
5 |   pthread_key_create(key, NULL);
  |  ^~~
  |  &
In file included from demo.c:1:
/usr/include/pthread.h:1122:47: note:   initializing argument 1 of
   'int pthread_key_create(pthread_key_t*, void (*)(void*))'
 1122 | extern int pthread_key_create (pthread_key_t *__key,
  |~~~^

gcc/c-family/ChangeLog:
PR c++/87850
* c-common.c: Include "gcc-rich-location.h".
(maybe_emit_indirection_note): New function.
* c-common.h (maybe_emit_indirection_note): New decl.
(compatible_types_for_indirection_note_p): New decl.

gcc/c/ChangeLog:
PR c++/87850
* c-typeck.c (compatible_types_for_indirection_note_p): New
function.
(convert_for_assignment): Call maybe_emit_indirection_note for
pointer vs non-pointer diagnostics.

gcc/cp/ChangeLog:
PR c++/87850
* call.c (convert_like_real): Call
maybe_emit_indirection_note for "invalid conversion" diagnostic.
* typeck.c (compatible_types_for_indirection_note_p): New
function.

gcc/testsuite/ChangeLog:
PR c++/87850
* c-c++-common/indirection-fixits.c: New test.
---
 gcc/c-family/c-common.c |  35 +++
 gcc/c-family/c-common.h |   4 +
 gcc/c/c-typeck.c|  18 +-
 gcc/cp/call.c   |   2 +
 gcc/cp/typeck.c |   8 +
 gcc/testsuite/c-c++-common/indirection-fixits.c | 299 
 6 files changed, 364 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/indirection-fixits.c

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 9d51815..f235c9d 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -48,6 +48,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimplify.h"
 #include "substring-locations.h"
 #include "spellcheck.h"
+#include "gcc-rich-location.h"
 #include "selftest.h"
 
 cpp_reader *parse_in;  /* Declared in c-pragma.h.  */
@@ -8420,6 +8421,40 @@ maybe_suggest_missing_token_insertion (rich_location 
*richloc,
 }
 }
 
+/* Potentially emit a note about likely missing '&' or '*',
+   depending on EXPR and EXPECTED_TYPE.  */
+
+void
+maybe_emit_indirection_note (location_t loc,
+tree expr, tree expected_type)
+{
+  gcc_assert (expr);
+  gcc_assert (expected_type);
+
+  tree actual_type = TREE_TYPE (expr);
+
+  /* Missing '&'.  */
+  if (TREE_CODE (expected_type) == POINTER_TYPE
+  && compatible_types_for_indirection_note_p (actual_type,
+ TREE_TYPE (expected_type))
+  && lvalue_p (expr))
+{
+  gcc_rich_location richloc (loc);
+  richloc.add_fixit_insert_before ("&");
+  inform (, "possible fix: take the address with %qs", "&");
+}
+
+  /* Missing '*'.  */
+  if (TREE_CODE (actual_type) == POINTER_TYPE
+  && compatible_types_for_indirection_note_p (TREE_TYPE (actual_type),
+ expected_type))
+{
+  gcc_rich_location richloc (loc);
+  richloc.add_fixit_insert_before ("*");
+  inform (, "possible fix: dereference with %qs", "*");
+}
+}
+
 #if CHECKING_P
 
 namespace selftest {
diff --git 

gcc-8-20181130 is now available

[gccadmin]

Snapshot gcc-8-20181130 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20181130/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch 
revision 266693

You'll find:

 gcc-8-20181130.tar.xzComplete GCC

  SHA256=8d1c72c1416e3ac931a5ec6627d6564aced39d84ec0e58a84e962f0aea293aff
  SHA1=e32ec7d8e273b4ffd365e8e1a4a35bfbbf0ffd7f

Diffs from 8-20181123 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug sanitizer/88289] [9 regression] r266664 causes asan to fail on many/most tests on BE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug sanitizer/88289] [9 regression] r266664 causes asan to fail on many/most tests on BE

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
E.g. on x86_64 in user-after-scope-5.c I see:
.string "1 48 40 9 values:10"
Partition 0: size 40 align 16
values
Flushing rzbuffer at offset -128 with: f1 f1 f1 f1
Flushing rzbuffer at offset -96 with: f1 f1 00 00
Flushing rzbuffer at offset -64 with: 00 00 00 f3
Flushing rzbuffer at offset -32 with: f3 f3 f3 f3
(wonder why the var is at offset 48 bytes rather than just 32 bytes).\

But on powerpc64 I see:
.string "1 48 40 9 values:10"
Partition 0: size 40 align 8
values
Flushing rzbuffer at offset -128 with: 00 f1 f1 f1
Flushing rzbuffer at offset -96 with: 00 00 00 f1
Flushing rzbuffer at offset -64 with: 00 f3 00 00
Flushing rzbuffer at offset -32 with: 00 f3 f3 f3

There is a clear off-by-one for BIG_ENDIAN, with following patch I get:

--- gcc/asan.c.jj   2018-11-30 19:59:59.675789930 +0100
+++ gcc/asan.c  2018-11-30 23:19:55.336780260 +0100
@@ -1326,7 +1326,7 @@ asan_redzone_buffer::flush_redzone_paylo
   for (unsigned i = 0; i < RZ_BUFFER_SIZE; i++)
 {
   unsigned char v
-   = m_shadow_bytes[BYTES_BIG_ENDIAN ? RZ_BUFFER_SIZE - i : i];
+   = m_shadow_bytes[BYTES_BIG_ENDIAN ? RZ_BUFFER_SIZE - i - 1 : i];
   val |= (unsigned HOST_WIDE_INT)v << (BITS_PER_UNIT * i);
   if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "%02x ", v);

Partition 0: size 40 align 8
values
Flushing rzbuffer at offset -128 with: f1 f1 f1 f1
Flushing rzbuffer at offset -96 with: 00 00 f1 f1
Flushing rzbuffer at offset -64 with: f3 00 00 00
Flushing rzbuffer at offset -32 with: f3 f3 f3 f3
Unpoisoning shadow stack for variable: values (40 B)

instead, which looks correct.

[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> With a missing file-unit-number, down to at least gcc-5 :
> 
> 
> $ cat z1.f90
> program p
>backspace (err=1)
>endfile (err=1)
>flush (err=1)
>rewind (err=1)
> end
> 
> 
> $ gfortran-9-20181125 -c z1.f90
> f951: internal compiler error: Segmentation fault
> 0xb2bcff crash_signal
> ../../gcc/toplev.c:326
> 0x63f696 gfc_resolve_filepos(gfc_filepos*)
> ../../gcc/fortran/io.c:2853
> 0x6850ab gfc_resolve_code(gfc_code*, gfc_namespace*)
> ../../gcc/fortran/resolve.c:11547
> 0x68702f resolve_codes


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 266386)
+++ gcc/fortran/resolve.c   (working copy)
@@ -11544,7 +11544,7 @@ start:
case EXEC_ENDFILE:
case EXEC_REWIND:
case EXEC_FLUSH:
- if (!gfc_resolve_filepos (code->ext.filepos))
+ if (!gfc_resolve_filepos (code->ext.filepos, >loc))
break;

  resolve_branch (code->ext.filepos->err, code);
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 266386)
+++ gcc/fortran/io.c(working copy)
@@ -2834,22 +2834,21 @@ cleanup:


 bool
-gfc_resolve_filepos (gfc_filepos *fp)
+gfc_resolve_filepos (gfc_filepos *fp, locus *where)
 {
   RESOLVE_TAG (_unit, fp->unit);
   RESOLVE_TAG (_iostat, fp->iostat);
   RESOLVE_TAG (_iomsg, fp->iomsg);
-  if (!gfc_reference_st_label (fp->err, ST_LABEL_TARGET))
-return false;

-  if (!fp->unit && (fp->iostat || fp->iomsg))
+  if (!fp->unit && (fp->iostat || fp->iomsg || fp->err))
 {
-  locus where;
-  where = fp->iostat ? fp->iostat->where : fp->iomsg->where;
-  gfc_error ("UNIT number missing in statement at %L", );
+  gfc_error ("UNIT number missing in statement at %L", where);
   return false;
 }

+  if (!gfc_reference_st_label (fp->err, ST_LABEL_TARGET))
+return false;
+
   if (fp->unit->expr_type == EXPR_CONSTANT
   && fp->unit->ts.type == BT_INTEGER
   && mpz_sgn (fp->unit->value.integer) < 0)

Re: [patch,openacc] Fix infinite recursion in OMP clause pretty-printing, default label

[Joseph Myers]

On Fri, 30 Nov 2018, Julian Brown wrote:

> ChangeLog
> 
> gcc/
> * tree-pretty-print.c (dump_omp_clause): Make default case
> gcc_unreachable.

OK.

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

Re: [patch,openacc] Fix infinite recursion in OMP clause pretty-printing, default label

[Jakub Jelinek]

On Fri, Nov 30, 2018 at 09:35:45PM +, Julian Brown wrote:
> How's this? (Obvious, but re-tested anyway.)
> 
> Thanks,
> 
> Julian
> 
> ChangeLog
> 
> gcc/
> * tree-pretty-print.c (dump_omp_clause): Make default case
> gcc_unreachable.

Ok, thanks.

> diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
> index 99eca4a..0861cc9 100644
> --- a/gcc/tree-pretty-print.c
> +++ b/gcc/tree-pretty-print.c
> @@ -1180,9 +1180,7 @@ dump_omp_clause (pretty_printer *pp, tree clause, int 
> spc, dump_flags_t flags)
>break;
>  
>  default:
> -  /* Should never happen.  */
> -  dump_generic_node (pp, clause, spc, flags, false);
> -  break;
> +  gcc_unreachable ();
>  }
>  }
>  


Jakub

Patch to fix PR88179

[Vladimir Makarov]

  The following patch fixes

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

  The patch was successfully bootstrapped and tested on x86-64.

   Committed as rev. 266682.

Index: ChangeLog
===
--- ChangeLog	(revision 266681)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2018-11-30  Vladimir Makarov  
+
+	PR rtl-optimization/88179
+	* lra-constraints.c (address_eliminator::address_eliminator):
+	Don't eleminate regs in illegitimate address.
+
 2018-11-30  David Malcolm  
 
 	PR preprocessor/88257
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 266678)
+++ lra-constraints.c	(working copy)
@@ -359,14 +359,20 @@ address_eliminator::address_eliminator (
   if (m_base_loc != NULL)
 {
   m_base_reg = *m_base_loc;
-  lra_eliminate_reg_if_possible (m_base_loc);
+  /* If we have non-legitimate address which is decomposed not in
+	 the way we expected, don't do elimination here.  In such case
+	 the address will be reloaded and elimination will be done in
+	 reload insn finally.  */
+  if (REG_P (m_base_reg))
+	lra_eliminate_reg_if_possible (m_base_loc);
   if (m_ad->base_term2 != NULL)
 	*m_ad->base_term2 = *m_ad->base_term;
 }
   if (m_index_loc != NULL)
 {
   m_index_reg = *m_index_loc;
-  lra_eliminate_reg_if_possible (m_index_loc);
+  if (REG_P (m_index_reg))
+	lra_eliminate_reg_if_possible (m_index_loc);
 }
 }
 

Re: [patch,openacc] Fix infinite recursion in OMP clause pretty-printing, default label

[Julian Brown]

On Thu, 29 Nov 2018 21:25:33 +
Joseph Myers  wrote:

> On Thu, 29 Nov 2018, Julian Brown wrote:
> 
> > On Thu, 20 Sep 2018 10:08:51 -0700
> > Cesar Philippidis  wrote:
> >   
> > > Apparently, Tom ran into an ICE when we were adding support for
> > > new clauses back in the gomp-4_0-branch days.  This patch
> > > shouldn't be necessary because all of the clauses are fully
> > > implemented now, but it may prevent similar bugs from occurring
> > > in the future at least during development.
> > > 
> > > Is this patch OK for trunk? I bootstrapped and regtested it for
> > > x86_64 Linux with nvptx offloading.  
> > 
> > Joseph, could you take a look at this please?  
> 
> Lots of other places in the same function use gcc_unreachable ().  I
> think using gcc_unreachable () here as well would be more appropriate
> than special-casing this one place in this function to use "unknown".

How's this? (Obvious, but re-tested anyway.)

Thanks,

Julian

ChangeLog

gcc/
* tree-pretty-print.c (dump_omp_clause): Make default case
gcc_unreachable.
diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
index 99eca4a..0861cc9 100644
--- a/gcc/tree-pretty-print.c
+++ b/gcc/tree-pretty-print.c
@@ -1180,9 +1180,7 @@ dump_omp_clause (pretty_printer *pp, tree clause, int spc, dump_flags_t flags)
   break;
 
 default:
-  /* Should never happen.  */
-  dump_generic_node (pp, clause, spc, flags, false);
-  break;
+  gcc_unreachable ();
 }
 }
 

[Bug testsuite/88290] New: [9 regression] 23_containers/deque/erasure.cc fails after r266672

[seurer at gcc dot gnu.org]

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

Bug ID: 88290
   Summary: [9 regression] 23_containers/deque/erasure.cc fails
after r266672
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/./gcc/xg++ -shared-libgcc
-B/home/seurer/gcc/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/ -isystem
/home/seurer/gcc/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc
-std=gnu++2a -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a -Wl,--gc-sections
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs
-lm -o ./erasure.exe
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:
In function 'void test01()':
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:30:
error: 'void num' has incomplete type
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:
In function 'void test02()':
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:40:
error: 'void num' has incomplete type
compiler exited with status 1
FAIL: 23_containers/deque/erasure.cc (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:30:
error: 'void num' has incomplete type
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:40:
error: 'void num' has incomplete type

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
This could also be a gold linker issue too.

But then again this is not the right place to report a gold or glibc issue. 
Try https://sourceware.org/bugzilla/ instead.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64-*-linux-gnu
 CC||pinskia at gcc dot gnu.org

--- Comment #9 from Andrew Pinski  ---
(In reply to jos...@codesourcery.com from comment #8)
> On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> 
> > The glibc commit that triggered this bug is:
> >  bfff8b1becd7d01c074177df7196ab327cd8c844 
> 
> That's the copyright date updates for 2017.

I was going to say that too.
Maybe:
https://sourceware.org/git/?p=glibc.git;a=commit;h=14d886edbd3d80b771e1c42fbd9217f9074de9c6

Re: [PATCH, libfortran] PR 88137 Initialize backtrace state once

[Janne Blomqvist]

On Fri, Nov 30, 2018 at 9:29 PM Janne Blomqvist 
wrote:

> On Fri, Nov 30, 2018 at 9:07 PM Thomas Schwinge 
> wrote:
>
>> Hi!
>>
>> On Thu, 22 Nov 2018 11:17:24 +0200, Janne Blomqvist <
>> blomqvist.ja...@gmail.com> wrote:
>> > From backtrace.h for backtrace_create_state:
>> >
>> >Calling this function allocates resources that can not be freed.
>> >There is no backtrace_free_state function.  The state is used to
>> >cache information that is expensive to recompute.  Programs are
>> >expected to call this function at most once and to save the return
>> >value for all later calls to backtrace functions.
>> >
>> > So instead of calling backtrace_create_state every time we wish to
>> > show a backtrace, do it once and store the result in a static
>> > variable.  libbacktrace allows multiple threads to access the state,
>> > so no need to use TLS.
>>
>> Hmm, OK, but...
>>
>> > --- a/libgfortran/runtime/backtrace.c
>> > +++ b/libgfortran/runtime/backtrace.c
>> > @@ -146,11 +146,15 @@ full_callback (void *data, uintptr_t pc, const
>> char *filename,
>> >  void
>> >  show_backtrace (bool in_signal_handler)
>> >  {
>> > -  struct backtrace_state *lbstate;
>> > +  /* Note that libbacktrace allows the state to be accessed from
>> > + multiple threads, so we don't need to use a TLS variable for the
>> > + state here.  */
>> > +  static struct backtrace_state *lbstate;
>> >struct mystate state = { 0, false, in_signal_handler };
>> > -
>> > -  lbstate = backtrace_create_state (NULL, __gthread_active_p (),
>> > - error_callback, NULL);
>> > +
>> > +  if (!lbstate)
>> > +lbstate = backtrace_create_state (NULL, __gthread_active_p (),
>> > +   error_callback, NULL);
>>
>> ... don't you still have to make sure that only one thread ever executes
>> "backtrace_create_state", and writes into "lbstate" (via locking, or
>> atomics, or "pthread_once", or some such)?  Or is that situation (more
>> than one thread entering "show_backtrace" with uninitialized "lbstate")
>> not possible to happen for other reasons?
>>
>
> I thought about that, but I think it probably(?) doesn't matter.
>
> - Two threads could race and run backtrace_create_state() in parallel, and
> probably we'd waste some memory then, but that was already possible before.
>
> - As for locking, the function can be called from a signal handler, so
> pthread_mutex is out. I guess I could implement a spinlock with atomics,
> but, meh, seems overkill.
>
> - And using atomics to access lbstate, it's an aligned pointer anyway, so
> while it's a race to access it, it shouldn't be possible to get a situation
> with a corrupted value for the pointer, right? I could use
> __atomic_load/store to access it, but that doesn't buy much in the end,
> does it, since the problem is parallel initialization, and not non-atomic
> access to the lbstate pointer? Or does gcc support targets with non-atomic
> access to aligned pointers?
>
> Or is there something I'm missing?
>

Using atomics for accessing the static variable can be done as below,
passes regtesting, Ok for trunk/8/7 with a ChangeLog?  If no objections,
I'll commit it as obvious in a few days.

diff --git a/libgfortran/runtime/backtrace.c
b/libgfortran/runtime/backtrace.c
index 3fc973a5e6d..93ea14af19d 100644
--- a/libgfortran/runtime/backtrace.c
+++ b/libgfortran/runtime/backtrace.c
@@ -149,15 +149,20 @@ show_backtrace (bool in_signal_handler)
   /* Note that libbacktrace allows the state to be accessed from
  multiple threads, so we don't need to use a TLS variable for the
  state here.  */
-  static struct backtrace_state *lbstate;
+  static struct backtrace_state *lbstate_saved;
+  struct backtrace_state *lbstate;
   struct mystate state = { 0, false, in_signal_handler };

+  lbstate = __atomic_load_n (_saved, __ATOMIC_RELAXED);
   if (!lbstate)
-lbstate = backtrace_create_state (NULL, __gthread_active_p (),
- error_callback, NULL);
-
-  if (lbstate == NULL)
-return;
+{
+  lbstate = backtrace_create_state (NULL, __gthread_active_p (),
+   error_callback, NULL);
+  if (lbstate)
+   __atomic_store_n (_saved, lbstate, __ATOMIC_RELAXED);
+  else
+   return;
+}

   if (!BACKTRACE_SUPPORTED || (in_signal_handler && BACKTRACE_USES_MALLOC))
 {


-- 
Janne Blomqvist

[Bug fortran/88269] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> With invalid code, down to at least gcc-5 :
> 
> 
> $ cat z1.f90
> program p
>write (end=1e1)
>write (end=1d1)
>write (end=1q1)
> end
> 
> 
> $ gfortran-9-20181125 -c z1.f90
> 0x619a5e gfc_format_decoder
> ../../gcc/fortran/error.c:947
> 0x131c83e pp_format(pretty_printer*, text_info*)
> ../../gcc/pretty-print.c:1390
> 0x13121e5 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
> ../../gcc/diagnostic.c:1015
> 0x6198fc gfc_error_opt
> ../../gcc/fortran/error.c:1313
> 0x61aea0 gfc_error(char const*, ...)
> ../../gcc/fortran/error.c:1342
> 0x63c9b2 check_io_constraints
> ../../gcc/fortran/io.c:3755


Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 266386)
+++ gcc/fortran/io.c(working copy)
@@ -3681,7 +3681,10 @@ check_io_constraints (io_kind k, gfc_dt *dt, gfc_code 
 #define io_constraint(condition,msg,arg)\
 if (condition) \
   {\
-gfc_error(msg,arg);\
+if ((arg)->lb != NULL) \
+  gfc_error(msg,arg);\
+else \
+  gfc_error(msg,_current_locus);\
 m = MATCH_ERROR;\
   }

@@ -3741,11 +3744,14 @@ if (condition) \
   if (expr && expr->ts.type != BT_CHARACTER)
 {

-  io_constraint (gfc_pure (NULL) && (k == M_READ || k == M_WRITE),
-"IO UNIT in %s statement at %C must be "
+  if (gfc_pure (NULL) && (k == M_READ || k == M_WRITE))
+   {
+ gfc_error ("IO UNIT in %s statement at %C must be "
 "an internal file in a PURE procedure",
 io_kind_name (k));
-
+ return MATCH_ERROR;
+   }
+ 
   if (k == M_READ || k == M_WRITE)
gfc_unset_implicit_pure (NULL);
 }

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:

> The glibc commit that triggered this bug is:
>  bfff8b1becd7d01c074177df7196ab327cd8c844 

That's the copyright date updates for 2017.

[Bug libgomp/88288] [OpenACC, libgomp] Adjust offsets for present data clauses

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
(In reply to cesar from comment #2)
> Why not update goacc_parallel_keyed to use gomp_map_val instead computing
> devaddrs manually? That would help reduce the number of duplicate mystery
> formulas in libgomp.

Right, that's something to look into (as I had just earlier mentioned in email,
too), but for now, the objective has been to actually get the bug fix
committed, using the patch that you had written in 2016 (when "gomp_map_val"
already existed, by the way).

[PATCH] Add *vec_concatv4sf_0 and *vec_concatv4si_0 insns (PR target/88278)

[Jakub Jelinek]

Hi!

As mentioned in the PR, while in vec_concatv2df or vec_concatv2di we have
alternatives where the lower half is low 64-bit part of a xmm reg or 64-bit
memory and upper half is zero using movq/vmovq (or movq2dq), for
vec_concatv4sf and vec_concatv4si we don't have anything similar, although
the operations do pretty much the same thing.  I'm not advocating to put
in alternatives with GPR operands as having V2SF or V2SI in a GPR is too
weird, but for the cases where a simple movq or vmovq instruction can move
64-bits and clear upper 64-bits these patterns look useful to me.

I had to tweak the pr53759.c testcase because it started FAILing, but only
because it changed:
-   vxorps  %xmm0, %xmm0, %xmm0
-   vmovlps (%rsi), %xmm0, %xmm0
+   vmovq   (%rsi), %xmm0
vaddps  %xmm0, %xmm0, %xmm0
vmovaps %xmm0, (%rdi)
ret
I've added a variant of that testcase that tests its original purpose by
using a register there not known to be all zeros.

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

2018-11-30  Jakub Jelinek  

PR target/88278
* config/i386/sse.md (*vec_concatv4sf_0, *vec_concatv4si_0): New insns.

* gcc.target/i386/pr88278.c: New test.
* gcc.target/i386/pr53759.c: Don't expect vmovlps insn, expect vmovq
instead.
* gcc.target/i386/pr53759-2.c: New test.

--- gcc/config/i386/sse.md.jj   2018-11-30 21:36:22.277762263 +0100
+++ gcc/config/i386/sse.md  2018-11-30 21:38:02.261120768 +0100
@@ -7248,6 +7248,17 @@ (define_insn "*vec_concatv4sf"
(set_attr "prefix" "orig,maybe_evex,orig,maybe_evex")
(set_attr "mode" "V4SF,V4SF,V2SF,V2SF")])
 
+(define_insn "*vec_concatv4sf_0"
+  [(set (match_operand:V4SF 0 "register_operand"   "=v")
+   (vec_concat:V4SF
+ (match_operand:V2SF 1 "nonimmediate_operand" "xm")
+ (match_operand:V2SF 2 "const0_operand"   " C")))]
+  "TARGET_SSE2"
+  "%vmovq\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix" "maybe_vex")
+   (set_attr "mode" "DF")])
+
 ;; Avoid combining registers from different units in a single alternative,
 ;; see comment above inline_secondary_memory_needed function in i386.c
 (define_insn "vec_set_0"
@@ -14409,6 +14420,23 @@ (define_insn "*vec_concatv4si"
(set_attr "prefix" "orig,maybe_evex,orig,orig,maybe_evex")
(set_attr "mode" "TI,TI,V4SF,V2SF,V2SF")])
 
+(define_insn "*vec_concatv4si_0"
+  [(set (match_operand:V4SI 0 "register_operand"   "=v,x")
+   (vec_concat:V4SI
+ (match_operand:V2SI 1 "nonimmediate_operand" "vm,?!*y")
+ (match_operand:V2SI 2 "const0_operand"   " C,C")))]
+  "TARGET_SSE2"
+  "@
+   %vmovq\t{%1, %0|%0, %1}
+   movq2dq\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix" "maybe_vex,orig")
+   (set_attr "mode" "TI")
+   (set (attr "preferred_for_speed")
+ (if_then_else (eq_attr "alternative" "1")
+   (symbol_ref "TARGET_INTER_UNIT_MOVES_FROM_VEC")
+   (symbol_ref "true")))])
+
 ;; movd instead of movq is required to handle broken assemblers.
 (define_insn "vec_concatv2di"
   [(set (match_operand:V2DI 0 "register_operand"
--- gcc/testsuite/gcc.target/i386/pr88278.c.jj  2018-11-30 21:38:02.261120768 
+0100
+++ gcc/testsuite/gcc.target/i386/pr88278.c 2018-11-30 21:38:02.261120768 
+0100
@@ -0,0 +1,34 @@
+/* PR target/88278 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -msse2 -mno-sse3 -fgimple -masm=att" } */
+/* { dg-final { scan-assembler-times "movq\[ \t]+\\(" 2 } } */
+/* { dg-final { scan-assembler-not "punpcklqdq\[ \t]+" } } */
+/* { dg-final { scan-assembler-not "pxor\[ \t]+" } } */
+
+typedef unsigned char v16qi __attribute__((vector_size(16)));
+typedef unsigned char v8qi __attribute__((vector_size(8)));
+typedef unsigned int v4si __attribute__((vector_size(16)));
+typedef unsigned int v2si __attribute__((vector_size(8)));
+
+v16qi __GIMPLE foo (unsigned char *p)
+{
+  v8qi _2;
+  v16qi _3;
+
+bb_2:
+  _2 = __MEM  (p_1(D));
+  _3 = _Literal (v16qi) { _2, _Literal (v8qi) { _Literal (unsigned char) 0, 
_Literal (unsigned char) 0, _Literal (unsigned char) 0, _Literal (unsigned 
char) 0, _Literal (unsigned char) 0, _Literal (unsigned char) 0, _Literal 
(unsigned char) 0 } };
+  return _3;
+}
+
+
+v4si __GIMPLE bar (unsigned int *p)
+{
+  v2si _2;
+  v4si _3;
+
+bb_2:
+  _2 = __MEM  (p_1(D));
+  _3 = _Literal (v4si) { _2, _Literal (v2si) { 0u, 0u } };
+  return _3;
+}
--- gcc/testsuite/gcc.target/i386/pr53759.c.jj  2016-05-22 12:20:04.184034591 
+0200
+++ gcc/testsuite/gcc.target/i386/pr53759.c 2018-11-30 22:04:56.432806470 
+0100
@@ -12,5 +12,6 @@ foo (__m128 *x, __m64 *y)
   *x = _mm_add_ps (b, b);
 }
 
-/* { dg-final { scan-assembler "vmovlps\[ \\t\]" } } */
+/* { dg-final { scan-assembler "vmovq\[ \\t\]" } } */
+/* { dg-final { scan-assembler-not "vmovlps\[ \\t\]" } } */
 /* { dg-final { scan-assembler-not "vshufps\[ \\t\]" } } */
--- gcc/testsuite/gcc.target/i386/pr53759-2.c.jj2018-11-30 

[committed] [PR88288, OpenACC, libgomp] Adjust offsets for present data clauses

[Thomas Schwinge]

Hi!

On Fri, 30 Nov 2018 17:55:17 +0800, Chung-Lin Tang  
wrote:
> On 2018/7/21 6:07 AM, Cesar Philippidis wrote:
> > This is another old gomp4 patch

The patch as posted here contains additional changes compared to the
original patch.  I removed these additional changes.

The Fortran test case included doesn't actually FAIL without the patch,
so I removed that one, too.  The C/C++ test case included is enough to
motivate the bug, and its fix.

> > that corrects a bug where the runtime
> > was passing the wrong offset for subarray data to the accelerator. The
> > original description of this patch can be found here
> > 

I wish PRs would get filed right when such things are discovered...  I
just filed  "[OpenACC, libgomp] Adjust
offsets for present data clauses".  (Better late than never...)

> I think this patch is pretty obvious; this is what the 'offset' field
> of struct target_var_desc is supposed to be used for, and is in line
> with other sites throughout target.c.

Thanks for having a look, I agree.

This will likely need to be fixed on all active release branches.

For now, committed to trunk in r266688:

commit 2110057d427ba710d7f60045fe33c161e6b181c4
Author: tschwinge 
Date:   Fri Nov 30 20:39:49 2018 +

[PR88288, OpenACC, libgomp] Adjust offsets for present data clauses

Make libgomp respect the on device offset of subarrays which may arise in
present data clauses.

libgomp/
PR libgomp/88288
* oacc-parallel.c (GOACC_parallel_keyed): Add offset to devaddrs.
* testsuite/libgomp.oacc-c-c++-common/pr88288.c: New test.

Reviewed-by: Thomas Schwinge 

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266688 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog  |  6 
 libgomp/oacc-parallel.c|  3 +-
 .../testsuite/libgomp.oacc-c-c++-common/pr88288.c  | 41 ++
 3 files changed, 49 insertions(+), 1 deletion(-)

diff --git libgomp/ChangeLog libgomp/ChangeLog
index a9dcbd808200..d095a196fb6c 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,3 +1,9 @@
+2018-11-30  Cesar Philippidis  
+
+   PR libgomp/88288
+   * oacc-parallel.c (GOACC_parallel_keyed): Add offset to devaddrs.
+   * testsuite/libgomp.oacc-c-c++-common/pr88288.c: New test.
+
 2018-11-30  Thomas Schwinge  
 
* testsuite/libgomp.oacc-fortran/lib-16-2.f90: New file.
diff --git libgomp/oacc-parallel.c libgomp/oacc-parallel.c
index b80ace585907..1e08af70b4da 100644
--- libgomp/oacc-parallel.c
+++ libgomp/oacc-parallel.c
@@ -232,7 +232,8 @@ GOACC_parallel_keyed (int device, void (*fn) (void *),
   devaddrs = gomp_alloca (sizeof (void *) * mapnum);
   for (i = 0; i < mapnum; i++)
 devaddrs[i] = (void *) (tgt->list[i].key->tgt->tgt_start
-   + tgt->list[i].key->tgt_offset);
+   + tgt->list[i].key->tgt_offset
+   + tgt->list[i].offset);
 
   acc_dev->openacc.exec_func (tgt_fn, mapnum, hostaddrs, devaddrs,
  async, dims, tgt);
diff --git libgomp/testsuite/libgomp.oacc-c-c++-common/pr88288.c 
libgomp/testsuite/libgomp.oacc-c-c++-common/pr88288.c
new file mode 100644
index ..d13e3359a3ec
--- /dev/null
+++ libgomp/testsuite/libgomp.oacc-c-c++-common/pr88288.c
@@ -0,0 +1,41 @@
+/* Test present data clauses in acc offloaded regions when the
+   subarray inside the present clause does not have the same base
+   offset value as the subarray in the enclosing acc data or acc enter
+   data variable.  */
+
+#include 
+
+void
+offset (int *data, int n)
+{
+  int i;
+
+#pragma acc parallel loop present (data[0:n])
+  for (i = 0; i < n; i++)
+data[i] = n;
+}
+
+int
+main ()
+{
+  const int n = 30;
+  int data[n], i;
+
+  for (i = 0; i < n; i++)
+data[i] = -1;
+
+#pragma acc data copy(data[0:n])
+  {
+offset (data + 10, 10);
+  }
+
+  for (i = 0; i < n; i++)
+{
+  if (i < 10 || i >= 20)
+   assert (data[i] == -1);
+  else
+   assert (data[i] == 10);
+}
+
+  return 0;
+}


Grüße
 Thomas

Re: [PATCH v3] Make function clone name numbering independent.

[Michael Ploujnikov]

Hi,

On 2018-11-30 2:25 a.m., Richard Biener wrote:
> +  unsigned _number = lto_clone_numbers->get_or_insert (
> + IDENTIFIER_POINTER (DECL_NAME (decl)));
>name = maybe_rewrite_identifier (name);
>symtab->change_decl_assembler_name (decl,
> -  clone_function_name_numbered (
> -  name, "lto_priv"));
> +  clone_function_name (
> +  name, "lto_priv", clone_number));
> 
> since we use 'name' from maybe_rewrite_identifier in the end wouldn't it
> make more sense to use that as a key for lto_clone_numbers?

Yup, that looks much better. Fixed it.

> For the ipa-hsa.c changes since we iterate over all defined functions
> we at most create a single clone per cgraph_node.  That means your
> hash-map keyed on cgraph_node is useless and you could use
> an unnumbered clone (or a static zero number).

Good catch. I was thinking of doing this, but it somehow fell through the 
cracks during the rebase.

> 
> -  SET_DECL_ASSEMBLER_NAME (new_decl, clone_function_name_numbered (old_decl,
> -   suffix));
> +  SET_DECL_ASSEMBLER_NAME (new_decl,
> +   clone_function_name (
> + IDENTIFIER_POINTER (
> +   DECL_ASSEMBLER_NAME (old_decl)),
> + suffix,
> + num_suffix));
> 
> can you please hide the implementation detail of accessing the assembler name
> by adding an overload to clone_function_name_numbered with an explicit
> number?

Done.


> 
> OK with those changes.
> 
> Thanks,
> Richard.

Thank you for the review. I will commit as soon as my last test run finishes.

- Michael
From ac1f1579d37804c97833d460ec6cd5b87d6184c7 Mon Sep 17 00:00:00 2001
From: Michael Ploujnikov 
Date: Thu, 1 Nov 2018 12:57:30 -0400
Subject: [PATCH 1/3] Make function assembly more independent.

This is achieved by having clone_function_name assign unique clone
numbers for each function independently.

gcc:

2018-11-30  Michael Ploujnikov  

	* cgraphclones.c: Replaced clone_fn_id_num with clone_fn_ids;
	hash map.
	(clone_function_name_numbered): Use clone_fn_ids.

gcc/testsuite:

2018-11-30  Michael Ploujnikov  

	* gcc.dg/independent-cloneids-1.c: New test.
---
 gcc/cgraphclones.c| 10 -
 gcc/testsuite/gcc.dg/independent-cloneids-1.c | 38 +++
 2 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/independent-cloneids-1.c

diff --git gcc/cgraphclones.c gcc/cgraphclones.c
index e17959c0ca..fdd84b60d3 100644
--- gcc/cgraphclones.c
+++ gcc/cgraphclones.c
@@ -513,7 +513,7 @@ cgraph_node::create_clone (tree new_decl, profile_count prof_count,
   return new_node;
 }
 
-static GTY(()) unsigned int clone_fn_id_num;
+static GTY(()) hash_map *clone_fn_ids;
 
 /* Return a new assembler name for a clone of decl named NAME.  Apart
from the string SUFFIX, the new name will end with a unique (for
@@ -525,7 +525,13 @@ static GTY(()) unsigned int clone_fn_id_num;
 tree
 clone_function_name_numbered (const char *name, const char *suffix)
 {
-  return clone_function_name (name, suffix, clone_fn_id_num++);
+  /* Initialize the function->counter mapping the first time it's
+ needed.  */
+  if (!clone_fn_ids)
+clone_fn_ids = hash_map::create_ggc (64);
+  unsigned int _counter = clone_fn_ids->get_or_insert (
+   IDENTIFIER_POINTER (get_identifier (name)));
+  return clone_function_name (name, suffix, suffix_counter++);
 }
 
 /* Return a new assembler name for a clone of DECL.  Apart from string
diff --git gcc/testsuite/gcc.dg/independent-cloneids-1.c gcc/testsuite/gcc.dg/independent-cloneids-1.c
new file mode 100644
index 00..3203895492
--- /dev/null
+++ gcc/testsuite/gcc.dg/independent-cloneids-1.c
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fipa-cp -fipa-cp-clone"  } */
+
+extern int printf (const char *, ...);
+
+static int __attribute__ ((noinline))
+foo (int arg)
+{
+  return 7 * arg;
+}
+
+static int __attribute__ ((noinline))
+bar (int arg)
+{
+  return arg * arg;
+}
+
+int
+baz (int arg)
+{
+  printf("%d\n", bar (3));
+  printf("%d\n", bar (4));
+  printf("%d\n", foo (5));
+  printf("%d\n", foo (6));
+  /* adding or removing the following call should not affect foo
+ function's clone numbering */
+  printf("%d\n", bar (7));
+  return foo (8);
+}
+
+/* { dg-final { scan-assembler-times {(?n)\m_*bar[.$_]constprop[.$_]0:} 1 } } */
+/* { dg-final { scan-assembler-times {(?n)\m_*bar[.$_]constprop[.$_]1:} 1 } } */
+/* { dg-final { scan-assembler-times {(?n)\m_*bar[.$_]constprop[.$_]2:} 1 } } */
+/* { dg-final { scan-assembler-times {(?n)\m_*foo[.$_]constprop[.$_]0:} 1 } } */
+/* { dg-final { scan-assembler-times {(?n)\m_*foo[.$_]constprop[.$_]1:} 1 } } */
+/* { dg-final { scan-assembler-times {(?n)\m_*foo[.$_]constprop[.$_]2:} 1 } } */
+/* { dg-final { scan-assembler-not {(?n)\m_*foo[.$_]constprop[.$_]3:} } } */
+/* { dg-final { scan-assembler-not {(?n)\m_*foo[.$_]constprop[.$_]4:} } } */
-- 
2.19.1

From 9656fc66b05c4ee9efd1b4a0533d564a35a85bc5 Mon Sep 17 00:00:00 2001
From: Michael Ploujnikov 
Date: Mon, 

Re: [patch,openacc] use existing local variable in cp_parser_oacc_enter_exit_data

[Thomas Schwinge]

Hi!

On Thu, 29 Nov 2018 21:33:37 +, Julian Brown  
wrote:
> On Wed, 26 Sep 2018 11:21:33 -0700
> Cesar Philippidis  wrote:
> 
> > This is an old gomp4 patch that updates the location of the clause for
> > acc enter/exit data. Apparently, it didn't impact any test cases. Is
> > this OK for trunk or should we drop it from OG8?
> > 
> > I bootstrapped and regtested it for x86_64 Linux with nvptx
> > offloading.
> 
> At least at a glance, there is no actual change to behaviour given in
> this patch, it is just an extremely minor cleanup. I.e. in:
> 
>   location_t loc = pragma_tok->location;
>   [...]
>   SET_EXPR_LOCATION (stmt, pragma_tok->location);
> 
> the variable "loc" is used in the SET_EXPR_LOCATION instead. It doesn't
> look like anything could mutate either variable in the interim.

Thanks, agreed.

> So, OK, or shall we just drop this?

This tiny change obviously should've been part of (much) earlier changes
(when that code was reworked, "loc" added), and has now gotten much too
much attention already; committed to trunk in r266687:

commit 52b928e7cd1b7dee36c4ea14b5ac9df3f022efd5
Author: tschwinge 
Date:   Fri Nov 30 20:39:40 2018 +

[C++] Use existing local variable in cp_parser_oacc_enter_exit_data

gcc/cp/
* parser.c (cp_parser_oacc_enter_exit_data): Use existing local
variable.

Reviewed-by: Thomas Schwinge 

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266687 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/cp/ChangeLog | 5 +
 gcc/cp/parser.c  | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git gcc/cp/ChangeLog gcc/cp/ChangeLog
index 98a2528783a9..2c8b7d10ae4e 100644
--- gcc/cp/ChangeLog
+++ gcc/cp/ChangeLog
@@ -1,3 +1,8 @@
+2018-11-30  James Norris  
+
+   * parser.c (cp_parser_oacc_enter_exit_data): Use existing local
+   variable.
+
 2018-11-29  Paolo Carlini  
 
* decl.c (compute_array_index_type_loc): New, like the current
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 3ef1eda45188..634485b5a8c7 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -38472,7 +38472,7 @@ cp_parser_oacc_enter_exit_data (cp_parser *parser, 
cp_token *pragma_tok,
   stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
   TREE_TYPE (stmt) = void_type_node;
   OMP_STANDALONE_CLAUSES (stmt) = clauses;
-  SET_EXPR_LOCATION (stmt, pragma_tok->location);
+  SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
   return stmt;
 }


Grüße
 Thomas

[Bug libgomp/88288] [OpenACC, libgomp] Adjust offsets for present data clauses

[cesar at gcc dot gnu.org]

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

--- Comment #2 from cesar at gcc dot gnu.org ---
Why not update goacc_parallel_keyed to use gomp_map_val instead computing
devaddrs manually? That would help reduce the number of duplicate mystery
formulas in libgomp.

Re: [PATCH, OpenACC] Properly handle wait clause with no arguments

[Thomas Schwinge]

Hi Chung-Lin!

On Wed, 07 Nov 2018 20:13:29 +0100, Thomas Schwinge  
wrote:
> On Thu, 30 Aug 2018 21:27:22 +0800, Chung-Lin Tang  
> wrote:
> > Hi, this patch properly handles OpenACC 'wait' clauses without arguments, 
> > making it an equivalent of "wait all".

> > (current trunk basically discards and ignores such argument-less wait
> > clauses)
> 
> Bugs should be filed, for later reference.  Now done:
>  "OpenACC wait clauses without
> async-arguments".  (I couldn't put you in CC because "clt...@gcc.gnu.org
> did not match anything"?)

This will, by the way, need to be fixed on all active release branches.


> No test cases included.  I'm working on a few, will post/commit later.

I thought I had also written a libgomp execution test case, during
travel/attending the SuperComputing 2018 conference, but I can't find it
right now...  ;-|

Anyway, with XFAILs (which you then please remove as part of your patch),
at least the following compile-time test cases now committed to trunk in
r266686:

commit 1d89613e77d7db420b13ce3ad8b98f07aaf474e8
Author: tschwinge 
Date:   Fri Nov 30 20:39:30 2018 +

[PR87924] Add (XFAILed) test cases for OpenACC wait clauses without 
async-arguments

gcc/testsuite/
PR c/87924
* c-c++-common/goacc/asyncwait-5.c: Update.
* gfortran.dg/goacc/asyncwait-5.f: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266686 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/testsuite/ChangeLog|  4 
 gcc/testsuite/c-c++-common/goacc/asyncwait-5.c | 21 +
 gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f  | 20 
 3 files changed, 45 insertions(+)

diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index 75ca70b4af28..68186d8ab837 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,5 +1,9 @@
 2018-11-30  Thomas Schwinge  
 
+   PR c/87924
+   * c-c++-common/goacc/asyncwait-5.c: Update.
+   * gfortran.dg/goacc/asyncwait-5.f: Likewise.
+
* c-c++-common/goacc/asyncwait-5.c: New file.
* gfortran.dg/goacc/asyncwait-5.f: Likewise.
 
diff --git gcc/testsuite/c-c++-common/goacc/asyncwait-5.c 
gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
index fe6f8a0cf2da..80d4a8477b93 100644
--- gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
+++ gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
@@ -11,4 +11,25 @@ void f()
 #pragma acc parallel async (2) wait (11, 12) wait (13)
   ;
   /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(13\\) 
wait\\(12\\) wait\\(11\\) async\\(2\\)\$" 1 "original" } } */
+
+
+#pragma acc parallel async (3) wait
+  ;
+  /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(-1\\) 
async\\(3\\)$" 1 "original" { xfail *-*-* } } } */
+
+#pragma acc parallel async (4) wait (100) wait
+  ;
+  /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(-1\\) 
wait\\(100\\) async\\(4\\)$" 1 "original" { xfail *-*-* } } } */
+
+#pragma acc parallel async (5) wait wait (101)
+  ;
+  /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(101\\) 
wait\\(-1\\) async\\(5\\)$" 1 "original" { xfail *-*-* } } } */
+
+#pragma acc parallel async (6) wait wait (102, 103) wait wait
+  ;
+  /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(-1\\) 
wait\\(-1\\) wait\\(103\\) wait\\(102\\) wait\\(-1\\) async\\(6\\)$" 1 
"original" { xfail *-*-* } } } */
+
+#pragma acc parallel async (7) wait (104) wait wait (105, 106)
+  ;
+  /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(106\\) 
wait\\(105\\) wait\\(-1\\) wait\\(104\\) async\\(7\\)$" 1 "original" { xfail 
*-*-* } } } */
 }
diff --git gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f 
gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f
index 59b886343af6..7ad5813b8a03 100644
--- gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f
+++ gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f
@@ -10,4 +10,24 @@
 !$ACC END PARALLEL
 ! { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel async\\(2\\) 
wait\\(11\\) wait\\(12\\) wait\\(13\\)$" 1 "original" } }
 
+!$ACC PARALLEL ASYNC (3) WAIT
+!$ACC END PARALLEL
+! { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel async\\(3\\) 
wait\\(-1\\)$" 1 "original" { xfail *-*-* } } }
+
+!$ACC PARALLEL ASYNC (4) WAIT (100) WAIT
+!$ACC END PARALLEL
+! { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel async\\(4\\) 
wait\\(100\\) wait\\(-1\\)$" 1 "original" { xfail *-*-* } } }
+
+!$ACC PARALLEL ASYNC (5) WAIT WAIT (101)
+!$ACC END PARALLEL
+! { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel async\\(5\\) 
wait\\(-1\\) wait\\(101\\)$" 1 "original" { xfail *-*-* } } }
+
+!$ACC PARALLEL ASYNC (6) WAIT WAIT (102, 103) WAIT WAIT
+!$ACC END PARALLEL
+! { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel async\\(6\\) 
wait\\(-1\\) wait\\(102\\) wait\\(103\\) wait\\(-1\\) wait\\(-1\\)$" 1 
"original" { 

[Bug debug/85550] [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jakub Jelinek  ---
Dup.

*** This bug has been marked as a duplicate of bug 87462 ***

[Bug debug/87462] [7/8 Regression] undefined reference error occurs when -g, -fdebug-types-section and -O2 are used at the same time

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
*** Bug 85550 has been marked as a duplicate of this bug. ***

[committed] Add testcase for already fixed PR debug/85550

[Jakub Jelinek]

Hi!

The following testcase has been fixed by Nathan with r266158
aka PR debug/88006 and PR debug/87462.  In order to close the PR, I've
tested following testcase on x86_64-linux and i686-linux and committed to
trunk.

2018-11-30  Jakub Jelinek  

PR debug/85550
* g++.dg/debug/dwarf2/pr85550.C: New test.

--- gcc/testsuite/g++.dg/debug/dwarf2/pr85550.C.jj  2018-11-30 
17:32:55.959892418 +0100
+++ gcc/testsuite/g++.dg/debug/dwarf2/pr85550.C 2018-11-30 17:33:46.842056407 
+0100
@@ -0,0 +1,17 @@
+// PR debug/85550
+// { dg-do link }
+// { dg-options "-O2 -g -fdebug-types-section" }
+
+struct A {
+  int bar () const { return 0; }
+};
+template 
+struct B {
+};
+
+B<::bar> b;
+
+int
+main ()
+{
+}

Jakub

[Bug debug/85550] [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 30 20:55:41 2018
New Revision: 266689

URL: https://gcc.gnu.org/viewcvs?rev=266689=gcc=rev
Log:
PR debug/85550
* g++.dg/debug/dwarf2/pr85550.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr85550.C
Modified:
trunk/gcc/testsuite/ChangeLog

[PATCH] Add missing noexpect causes in tuple for move functions

[Nicholas Krause]

This adds the remainging noexcept causes required for this cause
to meet the spec as dicussed last year and documented here:
http://cplusplus.github.io/LWG/lwg-active.html#2899.

Signed-off-by: Nicholas Krause 
---
 libstdc++-v3/include/std/tuple | 4 
 1 file changed, 4 insertions(+)

diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 56b97c25eed..d17512a1b7e 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -214,6 +214,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
enable_if::type>
 explicit
 constexpr _Tuple_impl(_UHead&& __head, _UTail&&... __tail)
+noexcept(__and_,
+ is_nothrow_move_constructible<_Inherited>>::value)
: _Inherited(std::forward<_UTail>(__tail)...),
  _Base(std::forward<_UHead>(__head)) { }
 
@@ -237,6 +239,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 constexpr _Tuple_impl(_Tuple_impl<_Idx, _UHead, _UTails...>&& __in)
+noexcept(__and_,
+ is_nothrow_move_constructible<_Inherited>>::value)
: _Inherited(std::move
 (_Tuple_impl<_Idx, _UHead, _UTails...>::_M_tail(__in))),
  _Base(std::forward<_UHead>
-- 
2.17.1

[C++ PATCH] Fix C++ parser endless diagnostics on CPP_PRAGMA_EOL (PR c++/88258)

[Jakub Jelinek]

Hi!

The following testcase endlessly diagnoses a syntax error.
The problem is that the various C++ parser routines to skip tokens until
something happily skip over CPP_PRAGMA that starts a pragma line, but
always stop at CPP_PRAGMA_EOL, but the caller expect them to stop at
something different.

The fix is similar to what the C FE already does, treat CPP_PRAGMA_EOL
as CPP_EOF only if in_pragma flag is set.  Otherwise we didn't really parse
CPP_PRAGMA normally and should skip everything until we find whatever we are
looking for.

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

2018-11-30  Jakub Jelinek  

PR c++/88258
* parser.c (cp_parser_skip_to_closing_parenthesis_1,
cp_parser_skip_to_end_of_statement,
cp_parser_skip_to_end_of_block_or_statement,
cp_parser_skip_to_closing_brace,
cp_parser_skip_to_closing_square_bracket,
cp_parser_skip_balanced_tokens): Don't treat CPP_PRAGMA_EOL specially
if in_pragma is false.

* g++.dg/gomp/pr88258.C: New test.

--- gcc/cp/parser.c.jj  2018-11-29 08:41:30.804788606 +0100
+++ gcc/cp/parser.c 2018-11-30 14:18:51.928839749 +0100
@@ -3556,8 +3556,11 @@ cp_parser_skip_to_closing_parenthesis_1
 
   switch (token->type)
{
-   case CPP_EOF:
case CPP_PRAGMA_EOL:
+ if (!parser->lexer->in_pragma)
+   break;
+ /* FALLTHRU */
+   case CPP_EOF:
  /* If we've run out of tokens, then there is no closing `)'.  */
  return 0;
 
@@ -3652,8 +3655,11 @@ cp_parser_skip_to_end_of_statement (cp_p
 
   switch (token->type)
{
-   case CPP_EOF:
case CPP_PRAGMA_EOL:
+ if (!parser->lexer->in_pragma)
+   break;
+ /* FALLTHRU */
+   case CPP_EOF:
  /* If we've run out of tokens, stop.  */
  return;
 
@@ -3742,8 +3748,11 @@ cp_parser_skip_to_end_of_block_or_statem
 
   switch (token->type)
{
-   case CPP_EOF:
case CPP_PRAGMA_EOL:
+ if (!parser->lexer->in_pragma)
+   break;
+ /* FALLTHRU */
+   case CPP_EOF:
  /* If we've run out of tokens, stop.  */
  return;
 
@@ -3792,8 +3801,11 @@ cp_parser_skip_to_closing_brace (cp_pars
 
   switch (token->type)
{
-   case CPP_EOF:
case CPP_PRAGMA_EOL:
+ if (!parser->lexer->in_pragma)
+   break;
+ /* FALLTHRU */
+   case CPP_EOF:
  /* If we've run out of tokens, stop.  */
  return false;
 
@@ -22498,8 +22510,11 @@ cp_parser_skip_to_closing_square_bracket
 
   switch (token->type)
{
-   case CPP_EOF:
case CPP_PRAGMA_EOL:
+ if (!parser->lexer->in_pragma)
+   break;
+ /* FALLTHRU */
+   case CPP_EOF:
  /* If we've run out of tokens, then there is no closing `]'.  */
  return false;
 
@@ -26008,8 +26023,11 @@ cp_parser_skip_balanced_tokens (cp_parse
   do
 switch (cp_lexer_peek_nth_token (parser->lexer, n++)->type)
   {
-  case CPP_EOF:
   case CPP_PRAGMA_EOL:
+   if (!parser->lexer->in_pragma)
+ break;
+   /* FALLTHRU */
+  case CPP_EOF:
/* Ran out of tokens.  */
return orig_n;
   case CPP_OPEN_PAREN:
--- gcc/testsuite/g++.dg/gomp/pr88258.C.jj  2018-11-30 14:26:00.806805739 
+0100
+++ gcc/testsuite/g++.dg/gomp/pr88258.C 2018-11-30 14:25:33.614251741 +0100
@@ -0,0 +1,11 @@
+// PR c++/88258
+// { dg-do compile }
+// { dg-options "-fopenmp" }
+
+void
+foo (bar int p)// { dg-error "variable or field|was not 
declared in this scope" }
+{
+  int i, x;
+  #pragma omp atomic write
+  x = 6;
+}

Jakub

[PATCH] Introduce --param logical-op-non-short-circuit (PR testsuite/85368)

[Jakub Jelinek]

Hi!

Until we stop depending on BRANCH_COST and LOGICAL_OP_NON_SHORT_CIRCUIT
macros at least for early GIMPLE, I'm afraid the current state for the
testsuite is terrible, on some targets it is enough to use
-mbranch-cost={1,2} to pick either of the setting, but other targets,
while they implement -mbranch-cost=, redefine LOGICAL_OP_NON_SHORT_CIRCUIT,
so it ignores BRANCH_COST altogether, or sometimes, other targets don't
implement -mbranch-cost= and have various complex definitions of BRANCH_COST
or LOGICAL_OP_NON_SHORT_CIRCUIT depending on other command line options.

The following patch introduces a new param (not an option, to make it
clearer it is intended primarily for the testsuite and we can more easily
remove it again) that overrides the target's LOGICAL_OP_NON_SHORT_CIRCUIT
and adjusts the testsuite to use it.

Bootstrapped/regtested on x86_64-linux and i686-linux, Christophe has kindly
tested it on ARM.  Ok for trunk?

2018-11-30  Jakub Jelinek  

PR testsuite/85368
* params.def (PARAM_LOGICAL_OP_NON_SHORT_CIRCUIT): New param.
* tree-ssa-ifcombine.c (ifcombine_ifandif): If
--param logical-op-non-short-circuit is present, override
LOGICAL_OP_NON_SHORT_CIRCUIT value from the param.
* fold-const.c (fold_range_test, fold_truth_andor): Likewise.

* lib/target-supports.exp (logical_op_short_circuit): Remove.
* gcc.dg/builtin-bswap-7.c: Remove logical_op_short_circuit
effective target, drop -mbranch-cost= options from the test and
instead pass --param logical-op-non-short-circuit=0 or
--param logical-op-non-short-circuit=1 depending on what the
tests meant to test.
* gcc.dg/pr21643.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-2.c: Likewise.
* gcc.dg/tree-ssa/phi-opt-11.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-4.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-3.c: Likewise.
* gcc.dg/tree-ssa/ssa-thread-14.c: Likewise.
* gcc.dg/tree-ssa/vrp47.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-11.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-16.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-14.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c: Likewise.
* gcc.dg/tree-ssa/vrp87.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c: Likewise.
* gcc.dg/tree-ssa/phi-opt-2.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-13.c: Likewise.
* gcc.dg/tree-ssa/ssa-thread-11.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c: Likewise.
* gcc.dg/tree-ssa/forwprop-28.c: Likewise.
* gcc.dg/binop-xor1.c: Likewise.
* gcc.dg/pr46309.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-18.c: New test.
* gcc.dg/tree-ssa/reassoc-32.c: Add
--param logical-op-non-short-circuit=1 to dg-options.
* gcc.dg/tree-ssa/reassoc-33.c: Likewise.
* gcc.dg/tree-ssa/reassoc-34.c: Likewise.
* gcc.dg/tree-ssa/reassoc-35.c: Likewise.
* gcc.dg/tree-ssa/reassoc-36.c: Likewise.

--- gcc/params.def.jj   2018-11-21 11:35:44.410041861 +0100
+++ gcc/params.def  2018-11-30 12:22:22.180688145 +0100
@@ -1360,6 +1360,11 @@ DEFPARAM(PARAM_AVOID_FMA_MAX_BITS,
 "Maximum number of bits for which we avoid creating FMAs.",
 0, 0, 512)
 
+DEFPARAM(PARAM_LOGICAL_OP_NON_SHORT_CIRCUIT,
+"logical-op-non-short-circuit",
+"True if a non-short-circuit operation is optimal.",
+-1, -1, 1)
+
 /*
 
 Local variables:
--- gcc/tree-ssa-ifcombine.c.jj 2018-11-29 08:41:32.681757293 +0100
+++ gcc/tree-ssa-ifcombine.c2018-11-30 12:29:42.936453120 +0100
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3.
 #include "gimplify-me.h"
 #include "tree-cfg.h"
 #include "tree-ssa.h"
+#include "params.h"
 
 #ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
 #define LOGICAL_OP_NON_SHORT_CIRCUIT \
@@ -563,7 +564,11 @@ ifcombine_ifandif (basic_block inner_con
{
  tree t1, t2;
  gimple_stmt_iterator gsi;
- if (!LOGICAL_OP_NON_SHORT_CIRCUIT || flag_sanitize_coverage)
+ bool logical_op_non_short_circuit = LOGICAL_OP_NON_SHORT_CIRCUIT;
+ if (PARAM_VALUE (PARAM_LOGICAL_OP_NON_SHORT_CIRCUIT) != -1)
+   logical_op_non_short_circuit
+ = PARAM_VALUE (PARAM_LOGICAL_OP_NON_SHORT_CIRCUIT);
+ if (!logical_op_non_short_circuit || flag_sanitize_coverage)
return false;
  /* Only do this optimization if the inner bb contains only the 
conditional. */
  if (!gsi_one_before_end_p (gsi_start_nondebug_after_labels_bb 
(inner_cond_bb)))
--- gcc/fold-const.c.jj 2018-10-19 10:59:03.857467657 +0200
+++ gcc/fold-const.c2018-11-30 12:27:50.739294835 +0100
@@ -5572,12 +5572,15 @@ fold_range_test (location_t loc, enum tr
   /* On machines where the branch cost is expensive, if this is a
  short-circuited 

[committed] Clean up Fortran OpenACC wait clause handling

[Thomas Schwinge]

Hi!

commit 3e3de40a5ab21d72f08071a7a40120dd05608cc1
Author: tschwinge 
Date:   Fri Nov 30 20:39:18 2018 +

Clean up Fortran OpenACC wait clause handling

"wait" can be deduced from "wait_list".

gcc/fortran/
* gfortran.h (struct gfc_omp_clauses): Remove "wait".  Adjust all
users.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266685 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/fortran/ChangeLog  | 3 +++
 gcc/fortran/gfortran.h | 2 +-
 gcc/fortran/openmp.c   | 7 ++-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git gcc/fortran/ChangeLog gcc/fortran/ChangeLog
index 435ecf82f970..76bb0b9f5c0c 100644
--- gcc/fortran/ChangeLog
+++ gcc/fortran/ChangeLog
@@ -1,5 +1,8 @@
 2018-11-30  Thomas Schwinge  
 
+   * gfortran.h (struct gfc_omp_clauses): Remove "wait".  Adjust all
+   users.
+
* openmp.c (gfc_match_omp_clauses): Support multiple OpenACC wait
clauses.
 
diff --git gcc/fortran/gfortran.h gcc/fortran/gfortran.h
index 4dd6298b3ddb..a14b4c44a18a 100644
--- gcc/fortran/gfortran.h
+++ gcc/fortran/gfortran.h
@@ -1345,7 +1345,7 @@ typedef struct gfc_omp_clauses
   gfc_expr_list *wait_list;
   gfc_expr_list *tile_list;
   unsigned async:1, gang:1, worker:1, vector:1, seq:1, independent:1;
-  unsigned wait:1, par_auto:1, gang_static:1;
+  unsigned par_auto:1, gang_static:1;
   unsigned if_present:1, finalize:1;
   locus loc;
 
diff --git gcc/fortran/openmp.c gcc/fortran/openmp.c
index e1560c1fe372..fb9c073ff779 100644
--- gcc/fortran/openmp.c
+++ gcc/fortran/openmp.c
@@ -1878,7 +1878,6 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const 
omp_mask mask,
  if ((mask & OMP_CLAUSE_WAIT)
  && gfc_match ("wait") == MATCH_YES)
{
- c->wait = true;
  match m = match_oacc_expr_list (" (", >wait_list, false);
  if (m == MATCH_ERROR)
{
@@ -4779,10 +4778,8 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses 
*omp_clauses,
 resolve_positive_int_expr (omp_clauses->worker_expr, "WORKER");
   if (omp_clauses->vector_expr)
 resolve_positive_int_expr (omp_clauses->vector_expr, "VECTOR");
-  if (omp_clauses->wait)
-if (omp_clauses->wait_list)
-  for (el = omp_clauses->wait_list; el; el = el->next)
-   resolve_scalar_int_expr (el->expr, "WAIT");
+  for (el = omp_clauses->wait_list; el; el = el->next)
+resolve_scalar_int_expr (el->expr, "WAIT");
   if (omp_clauses->collapse && omp_clauses->tile_list)
 gfc_error ("Incompatible use of TILE and COLLAPSE at %L", >loc);
   if (omp_clauses->depend_source && code->op != EXEC_OMP_ORDERED)


Grüße
 Thomas

[committed] Support multiple OpenACC wait clauses

[Thomas Schwinge]

Hi!

I ran into this while working on something else, and it turned into a
prerequisite.  Committed to trunk in r266684:

commit ba688147af7632d7e1c420c98f2d301f7b9e427c
Author: tschwinge 
Date:   Fri Nov 30 20:39:08 2018 +

Support multiple OpenACC wait clauses

Support for this is not explicitly called for in OpenACC 2.6, but given that
GCC internally decomposes "wait (1, 2)" into "wait (1) wait (2)" (similar 
for
other clauses, too), it's reasonable to also support that syntax in the 
front
ends -- which happens to already be the case for C, C++, and easy enough to 
do
for Fortran.

gcc/fortran/
* openmp.c (gfc_match_omp_clauses): Support multiple OpenACC wait
clauses.
gcc/testsuite/
* c-c++-common/goacc/asyncwait-5.c: New file.
* gfortran.dg/goacc/asyncwait-5.f: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266684 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/fortran/ChangeLog  |  5 +
 gcc/fortran/openmp.c   |  1 -
 gcc/testsuite/ChangeLog|  5 +
 gcc/testsuite/c-c++-common/goacc/asyncwait-5.c | 14 ++
 gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f  | 13 +
 5 files changed, 37 insertions(+), 1 deletion(-)

diff --git gcc/fortran/ChangeLog gcc/fortran/ChangeLog
index 06e7400eda7d..435ecf82f970 100644
--- gcc/fortran/ChangeLog
+++ gcc/fortran/ChangeLog
@@ -1,3 +1,8 @@
+2018-11-30  Thomas Schwinge  
+
+   * openmp.c (gfc_match_omp_clauses): Support multiple OpenACC wait
+   clauses.
+
 2018-11-27  Martin Liska  
 
* decl.c (gfc_match_gcc_builtin): New function.
diff --git gcc/fortran/openmp.c gcc/fortran/openmp.c
index 6430e61ea7a6..e1560c1fe372 100644
--- gcc/fortran/openmp.c
+++ gcc/fortran/openmp.c
@@ -1876,7 +1876,6 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const 
omp_mask mask,
  break;
case 'w':
  if ((mask & OMP_CLAUSE_WAIT)
- && !c->wait
  && gfc_match ("wait") == MATCH_YES)
{
  c->wait = true;
diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index 874c158f75dd..75ca70b4af28 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2018-11-30  Thomas Schwinge  
+
+   * c-c++-common/goacc/asyncwait-5.c: New file.
+   * gfortran.dg/goacc/asyncwait-5.f: Likewise.
+
 2018-11-30  Peter Bergner  
 
PR target/87496
diff --git gcc/testsuite/c-c++-common/goacc/asyncwait-5.c 
gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
new file mode 100644
index ..fe6f8a0cf2da
--- /dev/null
+++ gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
@@ -0,0 +1,14 @@
+/* Multiple OpenACC wait clauses.  */
+
+/* { dg-additional-options "-fdump-tree-original" } */
+
+void f()
+{
+#pragma acc parallel async (1) wait (14)
+  ;
+  /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(14\\) 
async\\(1\\)$" 1 "original" } } */
+
+#pragma acc parallel async (2) wait (11, 12) wait (13)
+  ;
+  /* { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel wait\\(13\\) 
wait\\(12\\) wait\\(11\\) async\\(2\\)\$" 1 "original" } } */
+}
diff --git gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f 
gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f
new file mode 100644
index ..59b886343af6
--- /dev/null
+++ gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f
@@ -0,0 +1,13 @@
+! Multiple OpenACC wait clauses.
+
+! { dg-additional-options "-fdump-tree-original" } 
+
+!$ACC PARALLEL ASYNC (1) WAIT (14)
+!$ACC END PARALLEL
+! { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel async\\(1\\) 
wait\\(14\\)$" 1 "original" } }
+
+!$ACC PARALLEL ASYNC (2) WAIT (11, 12) WAIT(13)
+!$ACC END PARALLEL
+! { dg-final { scan-tree-dump-times "(?n)#pragma acc parallel async\\(2\\) 
wait\\(11\\) wait\\(12\\) wait\\(13\\)$" 1 "original" } }
+
+  END


Grüße
 Thomas

[PATCH] Avoid weird integral types in reassoc range opts (PR tree-optimization/88274)

[Jakub Jelinek]

Hi!

The following patch makes sure that we don't use weird integral types
(either ones which have smaller precision than corresponding mode's
precision, or ones like C++ -fstrict-enum enumeral types which have
normal precision, but smaller TYPE_MAX_VALUE or larger TYPE_MIN_VALUE),
because the constants could be outside of the range of those types.

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

2018-11-30  Jakub Jelinek  

PR tree-optimization/88274
* tree-ssa-reassoc.c (optimize_range_tests_xor,
optimize_range_tests_diff): If type has smaller precision than
corresponding mode or if it has non-standard min/max, compute
everything in a standard type for the precision.

--- gcc/tree-ssa-reassoc.c.jj   2018-10-23 10:13:25.278875175 +0200
+++ gcc/tree-ssa-reassoc.c  2018-11-30 11:13:37.232393154 +0100
@@ -2537,8 +2537,23 @@ optimize_range_tests_xor (enum tree_code
   if (!tree_int_cst_equal (lowxor, highxor))
 return false;
 
+  exp = rangei->exp;
+  scalar_int_mode mode = as_a  (TYPE_MODE (type));
+  int prec = GET_MODE_PRECISION (mode);
+  if (TYPE_PRECISION (type) < prec
+  || (wi::to_wide (TYPE_MIN_VALUE (type))
+ != wi::min_value (prec, TYPE_SIGN (type)))
+  || (wi::to_wide (TYPE_MAX_VALUE (type))
+ != wi::max_value (prec, TYPE_SIGN (type
+{
+  type = build_nonstandard_integer_type (prec, TYPE_UNSIGNED (type));
+  exp = fold_convert (type, exp);
+  lowxor = fold_convert (type, lowxor);
+  lowi = fold_convert (type, lowi);
+  highi = fold_convert (type, highi);
+}
   tem = fold_build1 (BIT_NOT_EXPR, type, lowxor);
-  exp = fold_build2 (BIT_AND_EXPR, type, rangei->exp, tem);
+  exp = fold_build2 (BIT_AND_EXPR, type, exp, tem);
   lowj = fold_build2 (BIT_AND_EXPR, type, lowi, tem);
   highj = fold_build2 (BIT_AND_EXPR, type, highi, tem);
   if (update_range_test (rangei, rangej, NULL, 1, opcode, ops, exp,
@@ -2581,7 +2596,16 @@ optimize_range_tests_diff (enum tree_cod
   if (!integer_pow2p (tem1))
 return false;
 
-  type = unsigned_type_for (type);
+  scalar_int_mode mode = as_a  (TYPE_MODE (type));
+  int prec = GET_MODE_PRECISION (mode);
+  if (TYPE_PRECISION (type) < prec
+  || (wi::to_wide (TYPE_MIN_VALUE (type))
+ != wi::min_value (prec, TYPE_SIGN (type)))
+  || (wi::to_wide (TYPE_MAX_VALUE (type))
+ != wi::max_value (prec, TYPE_SIGN (type
+type = build_nonstandard_integer_type (prec, 1);
+  else
+type = unsigned_type_for (type);
   tem1 = fold_convert (type, tem1);
   tem2 = fold_convert (type, tem2);
   lowi = fold_convert (type, lowi);

Jakub

Re: [PATCH, OpenACC 2.5, libgomp] Add *_async versions of runtime library API functions

[Thomas Schwinge]

Hi!

On Mon, 10 Sep 2018 10:22:17 -0700, Cesar Philippidis  
wrote:
> On 09/10/2018 08:04 AM, Chung-Lin Tang wrote:
> > Index: libgomp/openacc_lib.h
> 
> I don't see a test case for this.

Right.  (Better test coverage would be desirable generally.)

> I believe that openacc_lib.h is used
> by fixed-mode Fortran programs (those that end in a .f). Can you add a
> fixed-mode version of lib-16.f90?

Not only with fixed-form, but also with free-form Fortran programs.
Committed to trunk in r266683:

commit d084eb0a61d209ee0d852089ea76a672f519883b
Author: tschwinge 
Date:   Fri Nov 30 20:38:57 2018 +

Add libgomp.oacc-fortran/lib-16-2.f90

This is a copy of libgomp.oacc-fortran/lib-16.f90, but does 'include
"openacc_lib.h"' instead of 'use openacc'.

libgomp/
* testsuite/libgomp.oacc-fortran/lib-16-2.f90: New file.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266683 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog   | 4 
 libgomp/testsuite/libgomp.oacc-fortran/{lib-16.f90 => lib-16-2.f90} | 3 ++-
 libgomp/testsuite/libgomp.oacc-fortran/lib-16.f90   | 1 +
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git libgomp/ChangeLog libgomp/ChangeLog
index d3c1bc36c145..a9dcbd808200 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,3 +1,7 @@
+2018-11-30  Thomas Schwinge  
+
+   * testsuite/libgomp.oacc-fortran/lib-16-2.f90: New file.
+
 2018-10-19  Richard Biener  
 
PR tree-optimization/88182
diff --git libgomp/testsuite/libgomp.oacc-fortran/lib-16.f90 
libgomp/testsuite/libgomp.oacc-fortran/lib-16-2.f90
similarity index 94%
copy from libgomp/testsuite/libgomp.oacc-fortran/lib-16.f90
copy to libgomp/testsuite/libgomp.oacc-fortran/lib-16-2.f90
index 9701b52dd257..fa76f65912fb 100644
--- libgomp/testsuite/libgomp.oacc-fortran/lib-16.f90
+++ libgomp/testsuite/libgomp.oacc-fortran/lib-16-2.f90
@@ -1,9 +1,10 @@
+! See also "lib-16.f90".
 ! { dg-do run }
 ! { dg-skip-if "" { *-*-* } { "*" } { "-DACC_MEM_SHARED=0" } }
 
 program main
-  use openacc
   implicit none
+  include "openacc_lib.h"
 
   integer, parameter :: N = 256
   integer, allocatable :: h(:)
diff --git libgomp/testsuite/libgomp.oacc-fortran/lib-16.f90 
libgomp/testsuite/libgomp.oacc-fortran/lib-16.f90
index 9701b52dd257..011f9cf31db4 100644
--- libgomp/testsuite/libgomp.oacc-fortran/lib-16.f90
+++ libgomp/testsuite/libgomp.oacc-fortran/lib-16.f90
@@ -1,3 +1,4 @@
+! See also "lib-16-2.f90".
 ! { dg-do run }
 ! { dg-skip-if "" { *-*-* } { "*" } { "-DACC_MEM_SHARED=0" } }
 


Grüße
 Thomas

[Bug c/87924] OpenACC wait clauses without async-arguments

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Nov 30 20:39:30 2018
New Revision: 266686

URL: https://gcc.gnu.org/viewcvs?rev=266686=gcc=rev
Log:
[PR87924] Add (XFAILed) test cases for OpenACC wait clauses without
async-arguments

gcc/testsuite/
PR c/87924
* c-c++-common/goacc/asyncwait-5.c: Update.
* gfortran.dg/goacc/asyncwait-5.f: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
trunk/gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f

[Bug libgomp/88288] [OpenACC, libgomp] Adjust offsets for present data clauses

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Nov 30 20:39:49 2018
New Revision: 266688

URL: https://gcc.gnu.org/viewcvs?rev=266688=gcc=rev
Log:
[PR88288, OpenACC, libgomp] Adjust offsets for present data clauses

Make libgomp respect the on device offset of subarrays which may arise in
present data clauses.

libgomp/
PR libgomp/88288
* oacc-parallel.c (GOACC_parallel_keyed): Add offset to devaddrs.
* testsuite/libgomp.oacc-c-c++-common/pr88288.c: New test.

Reviewed-by: Thomas Schwinge 

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr88288.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-parallel.c

[Bug sanitizer/88289] New: [9 regression] r266664 causes asan to fail on many/most tests on BE

[seurer at gcc dot gnu.org]

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

Bug ID: 88289
   Summary: [9 regression] r24 causes asan to fail on
many/most tests on BE
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

This appears to only cause it to fail on BE.

FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_AllocDeallocMismatch
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_AtoiAndFriendsOOBTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2 
AddressSanitizer_AttributeNoSanitizeAddressTest execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_BitFieldNegativeTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_BitFieldPositiveTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2 
AddressSanitizer_BufferOverflowAfterManyFrees execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_CallocReturnsZeroMem
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_CxxExceptionTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2 
AddressSanitizer_FileNameInGlobalReportTest execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_GlobalStringConstTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_GlobalTest execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeOOBInMemset
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeOOBRightTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeStructCopyTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LongDoubleNegativeTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LongJmpTest execution
test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_MallocUsableSizeTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  

[PATCH,RFC] PR target/61976 PowerPC & AIX parameter passing

[David Edelsohn]

This patch corrects the manner in which single element structures are
passed.  The implementation always has been wrong and did not match
the AIX ABI. The AIX ABI specifies that aggregates are passed by
values in GPRs, but GCC passes small floating point aggregates in
FPRs. The PPC64 BE ELFv1 Linux ABI was updated in the past to match
the behavior of GCC.

For AIX, the implementation can produce wrong code for the case of a
single precision floating point value (SFmode) argument in 64 bit
mode.

The rs6000 backend parameter passing code chose the location for
arguments based on the MODE of the argument. For small aggregates, GCC
packs the aggregate into a scalar mode and the function arg machinery
is presented with an argument mode of the scalar mode, as opposed to
BLKmode.

On AIX, this meant that a single element floating point aggregate
(float or double) is represented as SFmode or DFmode.  The current
rs6000 function arg machinery passes the arguments in FPRs.  On AIX,
argument are padded upwards in the register, as if the arguments are
strings, not numerical values.  In 64 bit mode, GCC dutifully shifts a
32 bit SFmode value so that it is loaded into the upper 32 bits of the
FPR.  Power FPRs always are 64 bit double precision format, regardless
of the precision, so the value loaded is garbage, in addition to being
passed in the wrong location.  In 32 bit mode (still the default for
AIX), GCC didn't try to shift the value, so it accidentally worked --
self consistently passing the value in an FPR that GCC interpreted as
word mode size.

This patch adds a test for the argument TYPE to override the floating
point argument passing for aggregates only for AIX.

Yes, this will break the ABI for GCC on AIX.  GCC was not following
the AIX ABI. No one really noticed. It only produced wrong code in 64
bit mode. Single element aggregates are rare.  The change sucks, but
it doesn't make sense to have GCC produce code that is incompatible
with the AIX ABI.

I am using AGGREGATE_TYPE_P() to test the type. I believe that macro
captures all GCC cases of interest. Please let me know if this seems
like the wrong choice.  The macro includes ARRAY_TYPE, but arrays
commonly are passed by reference or pointer, not by value, so I don't
believe that this will affect single element vectors, but please
correct me if I'm wrong.  Another option is RECORD_OR_UNION_TYPE_P().

I believe that this change will correct GCC's conformance with the AIX
ABI.  I realize that most people don't know enough or care enough
about AIX and the ABI to determine if the conformance is correct. I am
interested in any feedback about the mechanism (AGGREGATE_TYPE_P) used
to select the behavior.

Bootstrapped on powerpc-ibm-aix7.2.0.0

Thanks, David

* config/rs6000/rs6000.c (rs6000_function_arg): Don't pass aggregates
in FPRs on AIX.
(rs6000_arg_partial_bytes): Same.

Index: rs6000.c
===
--- rs6000.c(revision 266671)
+++ rs6000.c(working copy)
@@ -11989,7 +11989,8 @@ rs6000_function_arg (cumulative_args_t cum_v, mach
   if (elt_mode == TDmode && (cum->fregno % 2) == 1)
cum->fregno++;

-  if (USE_FP_FOR_ARG_P (cum, elt_mode))
+  if (USE_FP_FOR_ARG_P (cum, elt_mode)
+ && !(TARGET_AIX && AGGREGATE_TYPE_P (type)))
{
  rtx rvec[GP_ARG_NUM_REG + AGGR_ARG_NUM_REG + 1];
  rtx r, off;
@@ -12125,7 +12126,8 @@ rs6000_arg_partial_bytes (cumulative_args_t cum_v,

   align_words = rs6000_parm_start (mode, type, cum->words);

-  if (USE_FP_FOR_ARG_P (cum, elt_mode))
+  if (USE_FP_FOR_ARG_P (cum, elt_mode)
+  && !(TARGET_AIX && AGGREGATE_TYPE_P (type)))
 {
   unsigned long n_fpreg = (GET_MODE_SIZE (elt_mode) + 7) >> 3;

Re: [PATCH] Adjust offsets for present data clauses

[Thomas Schwinge]

Hi Julian!

On Fri, 30 Nov 2018 10:37:09 +, Julian Brown  
wrote:
> > On 2018/7/21 6:07 AM, Cesar Philippidis wrote:
> > > This is another old gomp4 patch that corrects a bug where the
> > > runtime was passing the wrong offset for subarray data to the
> > > accelerator. The original description of this patch can be found
> > > here 

> This one will be superseded

Well, this is clearly a bug, so should be addressed independently.  I
just filed  "[OpenACC, libgomp] Adjust
offsets for present data clauses".  (Better late than never...)

> by the attach/detach patch, I think (where
> the additional offset is added also, via calling "gomp_map_val".

Aha, good to know: during review, I wondered about whether that function
should actually be used.  (But it also isn't in other places in
"libgomp/target.c".)


Grüße
 Thomas

[Bug rtl-optimization/88179] [9 regression][MIPS] pr84941.c ICE in lra_eliminate_reg_if_possible at lra-eliminations.c:1393 start with r266385

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Nov 30 20:15:56 2018
New Revision: 266682

URL: https://gcc.gnu.org/viewcvs?rev=266682=gcc=rev
Log:
2018-11-30  Vladimir Makarov  

PR rtl-optimization/88179
* lra-constraints.c (address_eliminator::address_eliminator):
Don't eleminate regs in illegitimate address.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug target/85220] [meta-bug, nvptx] Run trunk with og7 openacc testcases and analyze execution failures

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc

--- Comment #5 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #1)
> FAIL: data_offset.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
> execution test
> FAIL: data_offset.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
> execution test

Filed PR88288.

[Bug sanitizer/88277] ASAN stack poisoning is using unaligned stores on e.g. x86_64

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #2 from Andi Kleen  ---
FWIW modern x86 CPUs are fairly good at unaligned accesses, so it might not be
worth it for performance.

[Bug libgomp/88288] New: [OpenACC, libgomp] Adjust offsets for present data clauses

[tschwinge at gcc dot gnu.org]

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

Bug ID: 88288
   Summary: [OpenACC, libgomp] Adjust offsets for present data
clauses
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, patch
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: cesar at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

As reported in ,
libgomp "is not respecting the on device offset of subarrays which may arise in
present data clauses", "causing SPEC_ACCEL 304.olbm to generate bogus results",
for example.

This will likely need to be fixed on all active release branches.

Re: [PATCH] Use proper location for tls_init function (PR c++/88263).

[Jason Merrill]

OK.

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
BTW, it is unclear to me how to reproduce it, I've tried
./cc1plus -quiet -O -msve-vector-bits=256 vcond_1.C -o vcond_1.s -nostdinc
-march=armv8.4-a+simd
with the match.pd changes reverted and the same without the reversion and the
generated assembly is identical.

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
FAILs just because it has too much scan-assembler in it and expects something
in particular, or do we generate worse code?
The patch certainly added some canonicalization that was previously done only
for scalar comparisons.

Re: [PATCH, libfortran] PR 88137 Initialize backtrace state once

[Janne Blomqvist]

On Fri, Nov 30, 2018 at 9:07 PM Thomas Schwinge 
wrote:

> Hi!
>
> On Thu, 22 Nov 2018 11:17:24 +0200, Janne Blomqvist <
> blomqvist.ja...@gmail.com> wrote:
> > From backtrace.h for backtrace_create_state:
> >
> >Calling this function allocates resources that can not be freed.
> >There is no backtrace_free_state function.  The state is used to
> >cache information that is expensive to recompute.  Programs are
> >expected to call this function at most once and to save the return
> >value for all later calls to backtrace functions.
> >
> > So instead of calling backtrace_create_state every time we wish to
> > show a backtrace, do it once and store the result in a static
> > variable.  libbacktrace allows multiple threads to access the state,
> > so no need to use TLS.
>
> Hmm, OK, but...
>
> > --- a/libgfortran/runtime/backtrace.c
> > +++ b/libgfortran/runtime/backtrace.c
> > @@ -146,11 +146,15 @@ full_callback (void *data, uintptr_t pc, const
> char *filename,
> >  void
> >  show_backtrace (bool in_signal_handler)
> >  {
> > -  struct backtrace_state *lbstate;
> > +  /* Note that libbacktrace allows the state to be accessed from
> > + multiple threads, so we don't need to use a TLS variable for the
> > + state here.  */
> > +  static struct backtrace_state *lbstate;
> >struct mystate state = { 0, false, in_signal_handler };
> > -
> > -  lbstate = backtrace_create_state (NULL, __gthread_active_p (),
> > - error_callback, NULL);
> > +
> > +  if (!lbstate)
> > +lbstate = backtrace_create_state (NULL, __gthread_active_p (),
> > +   error_callback, NULL);
>
> ... don't you still have to make sure that only one thread ever executes
> "backtrace_create_state", and writes into "lbstate" (via locking, or
> atomics, or "pthread_once", or some such)?  Or is that situation (more
> than one thread entering "show_backtrace" with uninitialized "lbstate")
> not possible to happen for other reasons?
>

I thought about that, but I think it probably(?) doesn't matter.

- Two threads could race and run backtrace_create_state() in parallel, and
probably we'd waste some memory then, but that was already possible before.

- As for locking, the function can be called from a signal handler, so
pthread_mutex is out. I guess I could implement a spinlock with atomics,
but, meh, seems overkill.

- And using atomics to access lbstate, it's an aligned pointer anyway, so
while it's a race to access it, it shouldn't be possible to get a situation
with a corrupted value for the pointer, right? I could use
__atomic_load/store to access it, but that doesn't buy much in the end,
does it, since the problem is parallel initialization, and not non-atomic
access to the lbstate pointer? Or does gcc support targets with non-atomic
access to aligned pointers?

Or is there something I'm missing?


-- 
Janne Blomqvist

[Bug target/88287] New: [9 Regression] aarch64/sve/vcond_1.C fails since r266620

[clyon at gcc dot gnu.org]

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

Bug ID: 88287
   Summary: [9 Regression] aarch64/sve/vcond_1.C fails since
r266620
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Since r266620, I have noticed that g++.target/aarch64/sve/vcond_1.C now fails.

[Bug tree-optimization/88285] [9 Regression] gcc.dg/predict-22.c fails on arm

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
However, this same commit also introduced a regression:
FAIL: gcc.c-torture/execute/20040709-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

with gcc configured
--target arm-none-linux-gnueabihf
--with-mode arm
--with-cpu cortex-a9
--with-fpu neon-fp16

Re: Gimpel lowering question.

[Michael Eager]

On 11/29/18 10:28, Michael Eager wrote:

On 11/28/18 14:37, Andrew Pinski wrote:

On Wed, Nov 28, 2018 at 9:47 AM Michael Eager  wrote:


On 11/28/18 09:10, Jeff Law wrote:

On 11/28/18 10:00 AM, Michael Eager wrote:
I have a small test case which generates poor quality code on my 
target.

Here is the original:

    if (cond1 == 2048 || cond2 == 8)
  {
    x = x + y;
  }
    return x;

This ends up generating a series of instructions to compute a flag 
with

the result of the condition followed by a single compare with zero and
a jump.  Better code would be two compares and two jumps.

The gimple is

    _1 = cond1 == 2048;
    _2 = cond2 == 8;
    _3 = _1 | _2;
    if (_3 != 0) goto ; else goto ;
...

so this poor code sequence is essentially a correct translation.

On MIPS, for the same test case, the gimple is different:

    if (cond1 == 2048) goto ; else goto ;
    :
    if (cond2 == 8) goto ; else goto ;
    :
...

which generates the better code sequence.

Can someone give me a pointer where to find where the lowering
pass decides to break up a condition into multiple tests?  Is
there a target configuration option which I have overlooked or
maybe set incorrectly?

BRANCH_COST, which comes into play during generation of the initial
trees as well in passes which try to optimize branchy code into
straighter code.


Thanks.  I did look at BRANCH_COST, and played with the values, but it
didn't seem to have any affect.  I'll take a closer look.


Look at LOGICAL_OP_NON_SHORT_CIRCUIT .  By defualt, it is defined as:
   (BRANCH_COST (optimize_function_for_speed_p (cfun), \
 false) >= 2)
But MIPS defines it as 0.

Changing  LOGICAL_OP_NON_SHORT_CIRCUIT to 0 will disable this 
optimization.


LOGICAL_OP_NON_SHORT_CIRCUIT controls both places where (cond1 == 2048
|| cond2 == 8) would remove the branch.

NOTE I think MIPS defines LOGICAL_OP_NON_SHORT_CIRCUIT incorrectly but
that is a different story.

Thanks,
Andrew Pinski


I set BRANCH_COST to 1 for both predicted and non-predicted branches.
This generates the shorter sequence with a compare, but I'm concerned
that it will adversely affect code generation elsewhere.  Branches are
higher cost than simple instructions.

Looking at the code generated with BRANCH_COST > 1, it doesn't do what
I indicated above.  This did not reduce the number of branches.
In both cases there are two branches in this short test case.  When
BRANCH_COST > 1, there are three instructions to do a compare vs one
when BRANCH_COST = 1.  I'm at a loss to see where there is any benefit.

I'll take a look at the LOGICAL_OP_NON_SHORT_CIRCUIT settings and see
if this makes a difference.



Setting LOGICAL_OP_NON_SHORT_CIRCUIT to zero generates the better code
sequence.  Thanks for the pointer.

I stepped through the code at the two places where
LOGICAL_OP_NON_SHORT_CIRCUIT is tested, with it set both to 0 and 1, and
it is not clear what the code is trying to do.  Or what this parameter
is really supposed to mean.  I'll have to go back and look again.

Setting LOGICAL_OP_NON_SHORT_CIRCUIT to 0 or 1 does not change the
number of branches.  Why this would depend on BRANCH_COST is not clear,
and especially why it would depend on the costs of branches which are
predicted to fail makes no sense to me.

Is there a use case which would help this make some sense?

--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306

Re: [PATCH, libfortran] PR 88137 Initialize backtrace state once

[Thomas Schwinge]

Hi!

On Thu, 22 Nov 2018 11:17:24 +0200, Janne Blomqvist  
wrote:
> From backtrace.h for backtrace_create_state:
> 
>Calling this function allocates resources that can not be freed.
>There is no backtrace_free_state function.  The state is used to
>cache information that is expensive to recompute.  Programs are
>expected to call this function at most once and to save the return
>value for all later calls to backtrace functions.
> 
> So instead of calling backtrace_create_state every time we wish to
> show a backtrace, do it once and store the result in a static
> variable.  libbacktrace allows multiple threads to access the state,
> so no need to use TLS.

Hmm, OK, but...

> --- a/libgfortran/runtime/backtrace.c
> +++ b/libgfortran/runtime/backtrace.c
> @@ -146,11 +146,15 @@ full_callback (void *data, uintptr_t pc, const char 
> *filename,
>  void
>  show_backtrace (bool in_signal_handler)
>  {
> -  struct backtrace_state *lbstate;
> +  /* Note that libbacktrace allows the state to be accessed from
> + multiple threads, so we don't need to use a TLS variable for the
> + state here.  */
> +  static struct backtrace_state *lbstate;
>struct mystate state = { 0, false, in_signal_handler };
> - 
> -  lbstate = backtrace_create_state (NULL, __gthread_active_p (),
> - error_callback, NULL);
> +
> +  if (!lbstate)
> +lbstate = backtrace_create_state (NULL, __gthread_active_p (),
> +   error_callback, NULL);

... don't you still have to make sure that only one thread ever executes
"backtrace_create_state", and writes into "lbstate" (via locking, or
atomics, or "pthread_once", or some such)?  Or is that situation (more
than one thread entering "show_backtrace" with uninitialized "lbstate")
not possible to happen for other reasons?


Grüße
 Thomas

[Bug target/88282] ICE in df_install_refs at gcc/df-scan.c:2379

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
(In reply to Tamar Christina from comment #3)
> This is caused by the change in r266385 for PR87718.
> 
> That causes the cost model to go completely off the rail and also changes
> the register classes.
> 

  Sorry for this. It was a very sensitive code change and I think it will take
some time until the code stabilize.  But I believe that what patch for PR87718
solves is the right direction for RA.

> Previously out costs were 0 in most cases, now we have large numbers like
> 65540004.
> 
> ```

  I'll investigate this too. The biggest problem with RA cost calculations is
that machine-dependent code for register move cost is not defined correctly for
all combinations of mode, regclass, regclass.  Unfortunately, the documentation
says nothing about it.  RA tries to solve this in some ways but not always
successfully. 

  In the current case the combination is DImode, SP_REG, GENERAL_REGS.

  I'll see what can I do in RA.  I have an idea. If it works the patch will be
ready on the next week.

[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  ---
Author: bergner
Date: Fri Nov 30 18:57:33 2018
New Revision: 266680

URL: https://gcc.gnu.org/viewcvs?rev=266680=gcc=rev
Log:
gcc/testsuite/
PR target/87496
* gcc.target/powerpc/pr86324-1.c: Add dg-skip-if selector.
Add -mcpu=power7 option.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr86324-1.c

[Bug fortran/88286] gfortran reports conflicting intent(in) with an intent(in) declared class variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (9.0).

Workaroud: use

CLASS(BT), INTENT(IN) ::b

Re: [wwwdocs] [PATCH]introduce new -flive-patching master option into gcc9

[Jeff Law]

On 11/30/18 10:03 AM, Qing Zhao wrote:
> Hi,
> 
> This is the patch for update https://gcc.gnu.org/gcc-9/changes.html 
>  to include the introducing of new 
> option
> -flive-patching into gcc9.
> 
> Okay for commit?
OK
jeff

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v3]

[Pedro Alves]

On 11/30/2018 05:41 PM, Nick Clifton wrote:
> @@ -4693,10 +4694,21 @@
>  demangle_nested_args (struct work_stuff *work, const char **mangled,
>string *declp)
>  {
> +  static unsigned long recursion_level = 0;
>string* saved_previous_argument;
>int result;
>int saved_nrepeats;
>  
> +  if ((work->options & DMGL_RECURSE_LIMIT)
> +  && work->recursion_level > DEMANGLE_RECURSION_LIMIT)
> +{
> +  /* FIXME: There ought to be a way to report that the recursion limit
> +  has been reached.  */
> +  return 0;
> +}
> +
> +  recursion_level ++;
> +

There's still a static recursion level counter here?

Thanks,
Pedro Alves

[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
And that hook indeed returns the need for secondary reload there, so looks like
LRA bug for not honoring it?

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v3]

[Jakub Jelinek]

Hi!

Just spelling nitpicking.

On Fri, Nov 30, 2018 at 05:41:35PM +, Nick Clifton wrote:
> +  order to dmangle truely complicated names, but it also leaves the tools

truly? Multiple times.

> +The @option{-r} option is a snyonym for the

synonym? Multiple times.

Jakub

Re: [PATCH][AArch64][2/3] Correct type attribute for mul and mneg instructions

[Steve Ellcey]

On Fri, 2018-11-30 at 15:37 +, Kyrill Tkachov wrote:
> 
> In thunderx2t99.md the reservation changes from thunderx2t99_mul to
> thunderx2t99_madd.
> 
> Steve, can you share whether the AArch64 MUL and MNEG instructions
> really do have different latencies and reservations from MADD and
> MSUB
> on Thunderx2? If so, then this change is wrong :( and we'll want to
> model these forms differently indeed.
> 
> Thanks,
> Kyrill

According to the thunderx2 documents I looked at, the mul/mneg
instructions do have the same latencies as madd/msub.  So this
patch is OK from that standpoint and fixes an existing problem
on Thunderx2.

Steve Ellcey

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v3]

[Nick Clifton]

Hi Guys,

>> I think it would be fine to have a large fixed limit plus a flag to
>> disable the limit.

Great - in which case please may I present version 3 of the patch.  In 
this version:

  * The cplus_demangle_set_recursion_limit() function has been removed
and instead a new constant - DEMANGLE_RECURSION_LIMIT - is defined in
demangle.h.

  * The recursion counters in cp-demangle.c have been merged into one
counter, now contained in the d_info structure.

  * In cplus-dem.c the recursion counter has been moved into the work
structure.

  * The description of the DMGL_RECURSE_LIMIT option in demangle.h has
been enhanced to add a note that if the option is not used, then
bug reports about stack overflows in the demangler will be rejected.

  * The binutils patch has been updated to reflect these changes.  The
addr2line, cxxfilt, nm and objdump programs now have two new options
--recurse-limit and --no-recurse-limit, with --recurse-limit being
the default.  The documentation is updated to describe these options
and to also add a note about bug reports being rejected if 
--no-recurse-limit is used.

What do you think, is this version acceptable ?

Cheers
  Nick

libiberty/ChangeLog
2018-11-29  Nick Clifton  

PR 87681
PR 87675
PR 87636
PR 87335
* cp-demangle.h (struct d_info): Add recursion_limit field.
* cp-demangle.c (d_function_type): If the recursion limit is 
enabled and reached, return with a failure result.
(d_demangle_callback): If the recursion limit is enabled, check
for a mangled string that is so long that there is not enough
stack space for the local arrays.
* cplus-dem.c (struct work): Add recursion_level field.
(demangle_nested_args): If the recursion limit is enabled and 
reached, return with a failure result.

include/ChangeLog
2018-11-29  Nick Clifton  

* demangle.h (DMGL_RECURSE_LIMIT): Define.
(DEMANGLE_RECURSION_LIMIT): Prototype.

binutils/ChangeLog
2018-11-29  Nick Clifton  

* addr2line.c (demangle_flags): New static variable.
(long_options): Add --recurse-limit and --no-recurse-limit.
(translate_address): Pass demangle_flags to bfd_demangle.
(main): Handle --recurse-limit and --no-recurse-limit options.
* cxxfilt.c (flags): Add DMGL_RECURSE_LIMIT.
(long_options): Add --recurse-limit and --no-recurse-limit.
(main): Handle new options.
* dlltool.c (gen_def_file): Include DMGL_RECURSE_LIMIT in flags
passed to cplus_demangle.
* nm.c (demangle_flags): New static variable.
(long_options): Add --recurse-limit and --no-recurse-limit.
(main): Handle new options.
* objdump.c (demangle_flags): New static variable.
(usage): Add --recurse-limit and --no-recurse-limit.
(long_options): Likewise.
(objdump_print_symname): Pass demangle_flags to bfd_demangle.
(disassemble_section): Likewise.
(dump_dymbols): Likewise.
(main): Handle new options.
* prdbg.c (demangle_flags): New static variable.
(tg_variable): Pass demangle_flags to demangler.
(tg_start_function): Likewise.
* stabs.c (demangle_flags): New static variable.
(stab_demangle_template): Pass demangle_flags to demangler.
(stab_demangle_v3_argtypes): Likewise.
(stab_demangle_v3_arg): Likewise.
* doc/binutuls.texi: Document new command line options.
* NEWS: Mention the new feature.
* testsuite/config/default.exp (CXXFILT): Define if not already
defined.
(CXXFILTFLAGS): Likewise.
* testsuite/binutils-all/cxxfilt.exp: New file.  Runs a few
simple tests of the cxxfilt program.
diff --git a/binutils/NEWS b/binutils/NEWS
index a3ee86ef7f..5ed61c8513 100644
--- a/binutils/NEWS
+++ b/binutils/NEWS
@@ -1,5 +1,16 @@
 -*- text -*-
 
+* The addr2line, c++filt, nm and objdump tools now have a limit on the
+  maximum amount of recursion that is allowed whilst demangling strings.
+  The value for this limit is defined by the DEMANGLE_RECRUSE_LIMIT
+  constant declared in the include/demangle.h header file.  At the time
+  of writing this constant has the value of 1024.
+
+  The --no-recurse-limit option can be used to remove the limit, restoring
+  the behaviour of earlier versions of these tools.  This may be needed in
+  order to dmangle truely complicated names, but it also leaves the tools
+  vulnerable to stack exhaustion from maliciously constructed mangled names.
+
 * Objdump's --disassemble option can now take a parameter, specifying the
   starting symbol for disassembly.  Disassembly will continue from this
   symbol up to the next symbol.
diff --git a/binutils/addr2line.c b/binutils/addr2line.c
index 008e62026e..3085806a4a 100644
--- a/binutils/addr2line.c
+++ b/binutils/addr2line.c
@@ -45,6 +45,9 @@ static bfd_boolean