[PATCH] libgcc: rs6000: tramp.S: fix placement of .cfi_endproc for __trampoline_setup

[Rasmus Villemoes]

Currently, .cfi_endproc and FUNC_END(__trampoline_setup) are placed
inside the #else branch of an "#if defined (__VXWORKS__) ...", so
non-pic vxworks does not get proper CFI nor a .size directive for
__trampoline_setup. I assume there's no magic reason for that (which
would warrant a comment), so move them outside.

== changelog ==

libgcc/

* config/rs6000/tramp.S (__trampoline_setup): Also emit .size
and .cfi_endproc directives for VxWorks targets.
---
 libgcc/config/rs6000/tramp.S | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libgcc/config/rs6000/tramp.S b/libgcc/config/rs6000/tramp.S
index 637f4510146..a9f0f3826dc 100644
--- a/libgcc/config/rs6000/tramp.S
+++ b/libgcc/config/rs6000/tramp.S
@@ -114,11 +114,10 @@ FUNC_START(__trampoline_setup)
addir30,r30,_GLOBAL_OFFSET_TABLE_-1b@l
 #endif
bl  JUMP_TARGET(abort)
+#endif
.cfi_endproc
 FUNC_END(__trampoline_setup)
 
-#endif
-
 #elif _CALL_ELF == 2
.type   trampoline_initial,@object
.align  3
-- 
2.19.1.6.gbde171bbf5

Re: [C++ PATCH] PR c++/87051

[Ville Voutilainen]

On Tue, 11 Dec 2018 at 20:58, Marek Polacek  wrote:
>
> On Thu, Sep 13, 2018 at 08:58:34PM +0300, Ville Voutilainen wrote:
> > On 13 September 2018 at 20:41, Jason Merrill  wrote:
> > >> Okay. Do you think we should have an sfk_kind for non-canonical
> > >> copy/move operations? That would presumably make it a tad more 
> > >> straightforward to go from
> > >> fndecl to whatever class bits, instead of what's currently there, where 
> > >> we say "yeah I had a fndecl,
> > >> now I turned it into an sfk_kind that says it's a copy constructor, but 
> > >> guess which one when you're
> > >> deeming its triviality". ;)
> > >
> > > I suppose it would be possible to have a more detailed sfk_kind for
> > > distinguishing between different signatures, but I'm inclined instead
> > > to stop using sfk_kind in trivial_fn_p.  Even if having an enumeration
> > > is convenient for dispatch (or bitmapping), it doesn't need to be the
> > > same enum.
> >
> > Yeah, the idea of using a different enum dawned on me straight after
> > sending that email. ;)
> > I'll give this approach a spin, more bits into the lang_type and a
> > different mapping, that way we should indeed
> > get correct answers for all cases.
>
> Hi Ville, any updates?

No, and not any time soon. Do you by any chance want to pick this up? :)

Re: [Ada] Gigi support for OpenACC pragmas

[Ghjuvan Lacambre]

On 2018-12-11, 11:14:24, Olivier Hainque wrote:

(A message that remained in my drafts box)


On 3 Dec 2018, at 16:50, Pierre-Marie de Rodat  wrote:

Matching front-end bits to support Acc_Kernels, Acc_Parallel,
Acc_Loop and Acc_Data.


Note that this was all originally contributed by Ghujan Lacambre
()

Olivier


Thank you for mentionning that, Olivier. Please note that this email
address was the one I used for university-related things, I do not know
how long it is supposed to keep working. If you ever need to contact me
again regarding this patch, please do so at ghju...@lacamb.re, this one
is more likely to keep working for a long time :).

--
Ghjuvan Lacambre

Re: [PATCH][libbacktrace] Add allocfail.sh test-case

[Tom de Vries]

[ Fixed ENOPATCH ]

On 12-12-18 08:03, Tom de Vries wrote:
> On 11-12-18 18:59, Ian Lance Taylor wrote:
>> On Wed, Nov 28, 2018 at 4:50 AM Tom de Vries  wrote:
>>>
>>> Add test-case that forces alloc.c functions to fail, and check whether fail
>>> handling is robust.
>>>
>>> This is the test-case for "[libbacktrace] Fix segfault upon allocation
>>> failure".  Without that patch, this test-case fails like this:
>>> ...
>>> allocfail.sh: line 71: 26041 Segmentation fault  (core dumped) \
>>>   ./allocfail $i > /dev/null 2>&1
>>> Unallowed fail found: 13
>>> FAIL allocfail.sh (exit status: 1)
>>> ...
>>>
>>> This is a seperate patch because the test-case is nontrivial.
>>>
>>> Bootstrapped and reg-tested on x86_64.
>>>
>>> OK for trunk?
>>>
>>> Thanks,
>>> - Tom
>>>
>>> [libbacktrace] Add allocfail.sh test-case
>>>
>>> 2018-11-27  Tom de Vries  
>>>
>>> * Makefile.am (TESTS): Add allocfail.sh.
>>> (check_PROGRAMS): Add allocfail.
>>> * Makefile.in: Regenerate.
>>> * instrumented_alloc.c: New file.  Redefine malloc and realloc.
>>> Include alloc.c.
>>> * allocfail.c: New file.
>>> * allocfail.sh: New file.
>>
>> Can you redo this without using GNU make features like $(filter-out) ?
> 
> Hi,
> 
> Done, and re-bootstrapped-and-regtested.
> 
> OK for trunk?
> 
> Thanks,
> - Tom
> 
[libbacktrace] Add allocfail.sh test-case

Add test-case that forces alloc.c functions to fail, and check whether fail
handling is robust.

This is the test-case for "[libbacktrace] Fix segfault upon allocation
failure".  Without that patch, this test-case fails like this:
...
allocfail.sh: line 71: 26041 Segmentation fault  (core dumped) \
  ./allocfail $i > /dev/null 2>&1
Unallowed fail found: 13
FAIL allocfail.sh (exit status: 1)
...

This is a seperate patch because the test-case is nontrivial.

Bootstrapped and reg-tested on x86_64.

2018-11-27  Tom de Vries  

	* Makefile.am (TESTS): Add allocfail.sh.
	(check_PROGRAMS): Add allocfail.
	* Makefile.in: Regenerate.
	* instrumented_alloc.c: New file.  Redefine malloc and realloc.
	Include alloc.c.
	* allocfail.c: New file.
	* allocfail.sh: New file.

---
 libbacktrace/Makefile.am  |  20 ++
 libbacktrace/Makefile.in  |  81 ++-
 libbacktrace/allocfail.c  | 136 ++
 libbacktrace/allocfail.sh | 105 +
 libbacktrace/instrumented_alloc.c | 114 
 5 files changed, 439 insertions(+), 17 deletions(-)

diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index 1a3680bc98c..9d489f7b418 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -145,6 +145,26 @@ unittest_alloc_LDADD = libbacktrace_alloc.la
 
 check_PROGRAMS += unittest_alloc
 
+check_LTLIBRARIES += libbacktrace_instrumented_alloc.la
+
+libbacktrace_instrumented_alloc_la_SOURCES = $(libbacktrace_la_SOURCES)
+libbacktrace_instrumented_alloc_la_LIBADD = $(BACKTRACE_FILE) $(FORMAT_FILE) \
+	read.lo instrumented_alloc.lo
+
+libbacktrace_instrumented_alloc_la_DEPENDENCIES = \
+	$(libbacktrace_instrumented_alloc_la_LIBADD)
+
+instrumented_alloc.lo: alloc.c
+
+allocfail_SOURCES = allocfail.c testlib.c
+allocfail_LDADD = libbacktrace_instrumented_alloc.la
+
+check_PROGRAMS += allocfail
+
+allocfail.sh: allocfail
+
+TESTS += allocfail.sh
+
 btest_SOURCES = btest.c testlib.c
 btest_CFLAGS = $(AM_CFLAGS) -g -O
 btest_LDADD = libbacktrace.la
diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in
index 6eaa1e28c01..7b18b9834e0 100644
--- a/libbacktrace/Makefile.in
+++ b/libbacktrace/Makefile.in
@@ -123,13 +123,14 @@ target_triplet = @target@
 check_PROGRAMS = $(am__EXEEXT_1) $(am__EXEEXT_2) $(am__EXEEXT_3)
 @NATIVE_TRUE@am__append_1 = test_elf test_xcoff_32 test_xcoff_64 \
 @NATIVE_TRUE@	test_pecoff test_unknown unittest unittest_alloc \
-@NATIVE_TRUE@	btest btest_alloc stest stest_alloc ztest \
-@NATIVE_TRUE@	ztest_alloc edtest edtest_alloc
-@HAVE_ZLIB_TRUE@@NATIVE_TRUE@am__append_2 = -lz
+@NATIVE_TRUE@	allocfail btest btest_alloc stest stest_alloc \
+@NATIVE_TRUE@	ztest ztest_alloc edtest edtest_alloc
+@NATIVE_TRUE@am__append_2 = allocfail.sh
 @HAVE_ZLIB_TRUE@@NATIVE_TRUE@am__append_3 = -lz
-@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@am__append_4 = ttest ttest_alloc
-@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_5 = dtest
-@HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@am__append_6 = ctestg ctesta \
+@HAVE_ZLIB_TRUE@@NATIVE_TRUE@am__append_4 = -lz
+@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@am__append_5 = ttest ttest_alloc
+@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_6 = dtest
+@HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@am__append_7 = ctestg ctesta \
 @HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@	ctestg_alloc \
 @HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@	ctesta_alloc
 subdir = .
@@ -169,6 +170,11 @@ am__objects_1 = atomic.lo dwarf.lo fileline.lo posix.lo print.lo \
 @NATIVE_TRUE@am_libbacktrace_alloc_la_OBJECTS = 

Re: [PATCH][libbacktrace] Add allocfail.sh test-case

[Tom de Vries]

On 11-12-18 18:59, Ian Lance Taylor wrote:
> On Wed, Nov 28, 2018 at 4:50 AM Tom de Vries  wrote:
>>
>> Add test-case that forces alloc.c functions to fail, and check whether fail
>> handling is robust.
>>
>> This is the test-case for "[libbacktrace] Fix segfault upon allocation
>> failure".  Without that patch, this test-case fails like this:
>> ...
>> allocfail.sh: line 71: 26041 Segmentation fault  (core dumped) \
>>   ./allocfail $i > /dev/null 2>&1
>> Unallowed fail found: 13
>> FAIL allocfail.sh (exit status: 1)
>> ...
>>
>> This is a seperate patch because the test-case is nontrivial.
>>
>> Bootstrapped and reg-tested on x86_64.
>>
>> OK for trunk?
>>
>> Thanks,
>> - Tom
>>
>> [libbacktrace] Add allocfail.sh test-case
>>
>> 2018-11-27  Tom de Vries  
>>
>> * Makefile.am (TESTS): Add allocfail.sh.
>> (check_PROGRAMS): Add allocfail.
>> * Makefile.in: Regenerate.
>> * instrumented_alloc.c: New file.  Redefine malloc and realloc.
>> Include alloc.c.
>> * allocfail.c: New file.
>> * allocfail.sh: New file.
> 
> Can you redo this without using GNU make features like $(filter-out) ?

Hi,

Done, and re-bootstrapped-and-regtested.

OK for trunk?

Thanks,
- Tom

答复: add taishanv110 pipeline scheduling

[wuyuan (E)]

HI Terry,Kyrill
I'm sorry to reply to your email after a week, it's a busy week.
Glad to receive your advice, Follow kyrill's advice ,adjust the reservation 
to 12 cycles, the result shows that it will not affect the scheduling 
performance.
I have modified the patch according to the suggestion(See modification  in 
the attachment),Please review. Anyway If you have more suggestions, I will 
continue to modify.



Thinks   

-邮件原件-
发件人: Kyrill Tkachov [mailto:kyrylo.tkac...@foss.arm.com] 
发送时间: 2018年12月6日 20:37
收件人: wuyuan (E) ; gcc-patches@gcc.gnu.org
抄送: Zhanghaijian (A) ; Zhangyichao (AB) 
; Yangfei (Felix) ; James 
Greenhalgh ; Richard Earnshaw 
; Ramana Radhakrishnan 
; Marcus Shawcroft 
主题: Re: add taishanv110 pipeline scheduling

Hi Wu,

I notice you CC'ed the arm maintainers. This is an aarch64 patch as the arm 
(aarch32) and aarch64 ports are separate in GCC.
I've added the aarch64 maintainers on CC for you.

On 06/12/18 01:31, wuyuan (E) wrote:
>
> Hi ARM maintainers:
>
> The taishanv110 core uses generic pipeline scheduling, which 
> restricted the performance of taishanv110 core. By adding the pipeline 
> scheduling of taishanv110 core in GCC,The performance of taishanv110 has been 
> improved.
>
> The patch  as follows, please join.
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>
> old mode 100644
>
> new mode 100755
>
> index c4ec556..d6cf1d3
>
> --- a/gcc/ChangeLog
>
> +++ b/gcc/ChangeLog
>
> @@ -1,3 +1,9 @@
>
> +2018-12-05  wuyuan 
>
> +
>
> +   * config/aarch64/aarch64-cores.def: New CPU.
>
> +   * config/aarch64/aarch64.md : Add "tsv110.md"
>
> +   * gcc/config/aarch64/tsv110.md : pipeline description
>
> +
>

No "gcc/" in the path. Also, I'd use "New file."

> 2018-11-26  David Malcolm 
>
>   * dump-context.h (dump_context::dump_loc): Convert 1st param 
> from
>
> diff --git a/gcc/config/aarch64/aarch64-cores.def 
> b/gcc/config/aarch64/aarch64-cores.def
>
> index 74be5db..8e84844 100644
>
> --- a/gcc/config/aarch64/aarch64-cores.def
>
> +++ b/gcc/config/aarch64/aarch64-cores.def
>
> @@ -99,7 +99,7 @@ AARCH64_CORE("ares", ares, cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_F
>
> /* ARMv8.4-A Architecture Processors.  */
>
> /* HiSilicon ('H') cores. */
>
> -AARCH64_CORE("tsv110", tsv110, cortexa57,8_4A, 
> AARCH64_FL_FOR_ARCH8_4 | AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES 
> | AARCH64_FL_SHA2, tsv110,   0x48, 0xd01, -1)
>
> +AARCH64_CORE("tsv110", tsv110, tsv110,8_4A, AARCH64_FL_FOR_ARCH8_4 | 
> AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, 
> tsv110,   0x48, 0xd01, -1)
>
> /* Qualcomm ('Q') cores. */
>
> AARCH64_CORE("saphira", saphira, saphira,8_4A,  
> AARCH64_FL_FOR_ARCH8_4 | AARCH64_FL_CRYPTO | AARCH64_FL_RCPC, saphira,   
> 0x51, 0xC01, -1)
>
> diff --git a/gcc/config/aarch64/aarch64.md 
> b/gcc/config/aarch64/aarch64.md
>
> index 82af4d4..5278d6b 100644
>
> --- a/gcc/config/aarch64/aarch64.md
>
> +++ b/gcc/config/aarch64/aarch64.md
>
> @@ -348,7 +348,7 @@
>
> (include "thunderx.md")
>
> (include "../arm/xgene1.md")
>
> (include "thunderx2t99.md")
>
> -
>
> +(include "tsv110.md")
>
> ;; ---
>
> ;; Jumps and other miscellaneous insns
>
> ;; ---
>
> diff --git a/gcc/config/aarch64/tsv110.md 
> b/gcc/config/aarch64/tsv110.md
>
> new file mode 100644
>
> index 000..e912447
>
> --- /dev/null
>
> +++ b/gcc/config/aarch64/tsv110.md
>
> @@ -0,0 +1,708 @@
>
> +;; tsv110 pipeline description
>
> +;; Copyright (C) 2014-2016 Free Software Foundation, Inc.
>
> +;;
>
> +;; This file is part of GCC.
>
> +;;
>
> +;; GCC is free software; you can redistribute it and/or modify it
>
> +;; under the terms of the GNU General Public License as published by
>
> +;; the Free Software Foundation; either version 3, or (at your 
> +option)
>
> +;; any later version.
>
> +;;
>
> +;; GCC is distributed in the hope that it will be useful, but
>
> +;; WITHOUT ANY WARRANTY; without even the implied warranty of
>
> +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>
> +;; General Public License for more details.
>
> +;;
>
> +;; You should have received a copy of the GNU General Public License
>
> +;; along with GCC; see the file COPYING3.  If not see
>
> +;; .
>
> +
>
> +(define_automaton "tsv110")
>
> +
>
> +(define_attr "tsv110_neon_type"
>
> +  "neon_arith_acc, neon_arith_acc_q,
>
> +   neon_arith_basic, neon_arith_complex,
>
> +   neon_reduc_add_acc, neon_multiply, neon_multiply_q,
>
> +   

Re: [doc PATCH] update attribute docs for C++

[Sandra Loosemore]

On 12/5/18 10:14 AM, Martin Sebor wrote:

On 12/4/18 8:49 PM, Sandra Loosemore wrote:

What is the "it" referenced in the user's questions you quoted?  The 
const/pure attributes?  Those are function attributes.  The text you 
are adding is in the type attribute section, so it seemed like it was 
trying to address a different problem: stating that you can attach 
type attributes to any struct/class type whether or not it is a 
"trivial" class, by some definition of that term.  If that's not the 
purpose of this paragraph, what is it?


Again: the purpose is to explain that it doesn't matter whether
an attribute applies to a struct or a C++ class with ctors, in
any context with any attribute, either function, or variable,
or even type(*).


OK.  My main concern is that I think a user looking up a specific 
function or variable attribute is unlikely to think of reading through 
the type attribute section for that particular tidbit of information. 
Maybe we need to do some larger reorganization of material to include an 
overview of attribute semantics as well as a section on attribute 
syntax, but TBH I'm not enthusiastic about tackling that rewrite at the 
moment.  :-P



To make things clear, we could (and at some point perhaps
should) also go and edit all the places that talk about
structs and unions and mention C++ classes.  It won't
unambiguously answer the user's question about PODs vs
non-trivial classes with ctors, but it would help.


I think it would be good to open an issue for a general review of this. 
I just recently fixed the specific instance of it for the packed 
attribute (PR 25759).


Going back to the last version of the patch posted, I have a couple nits 
about your newly added section of text:



+Some function attributes take one or more arguments that refer to
+the function's parameters by their positions within the function parameter
+list.  Such attribute arguments are referred to as @dfn{positional arguments}.
+Unless specified otherwise, positional arguments that specify properties
+of pointer types can also specify the same properties for the implicit C++


I think this should be

s/properties of pointer types/properties of parameters with pointer types/


+@code{this} argument in non-static member functions, and, to parameters of


s/and, to parameters of/and to parameters with/


+reference to a pointer type.  For ordinary functions, position one refers
+to the first parameter on the list.  In C++ non-static member functions,
+position one refers to the implicit @code{this} pointer.  The same
+restrictions and effects apply to function attributes used with ordinary
+functions or C++ member functions.
+
 GCC also supports attributes on
 variable declarations (@pxref{Variable Attributes}),
 labels (@pxref{Label Attributes}),


I think the patch is OK to commit with those changes.

-Sandra

Re: [C++ PATCH] Fix up __builtin_is_constant_evaluated (PR c++/88449)

[Jason Merrill]

On 12/11/18 11:34 AM, Jakub Jelinek wrote:

Hi!

While working on the libstdc++ patch for P0595R2, I've noticed that while
__builtin_is_constant_evaluated () directly works, when wrapped into
an constexpr inline noexcept function, it in some cases doesn't.  The
problem is that the constexpr call cache didn't take
ctx->pretend_const_required into account.

The following patch fixes it by just treating it like another magic
parameter.  Another option would be (but much more involved) to remember
during the constexpr.c processing whether we've seen during the evaluation
any calls to __builtin_is_constant_evaluated (that would require propagating
in all the spots that use a new context back to the old context).  Then
we could in the constexpr hash remember either that during the evaluation
of that constexpr call there was no __builtin_is_constant_evaluated seen,
or, if it has been seen, whether it was in ctx->pretend_const_required
mode or in !ctx->pretend_const_required mode.

I've bootstrapped/regtested on x86_64-linux and i686-linux the following
simpler version, ok for trunk?


OK.

Jason

[Committed] PR fortran/88155 -- Avoid NULL pointer reference

[Steve Kargl]

Committed as obvious.

The attached patch set an expression locus to gfc_current_locus
to avoid a NULL pointer reference when emitting an error message.
On beneficial fallout to this patch required a fix up to the
testcase gfortran.dg/pr70870_1.f90.

2018-12-11  Steven G. Kargl  

PR fortran/88155
* primary.c (gfc_match_structure_constructor):  Set the locus of
an expression to avoid a NULL pointer dereference.

2018-12-11  Steven G. Kargl  

PR fortran/88155
* gfortran.dg/pr70870_1.f90: Update testcase to use -std=gnu.
* gfortran.dg/pr88155.f90: New test.

-- 
Steve
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c	(revision 267034)
+++ gcc/fortran/primary.c	(working copy)
@@ -3212,6 +3212,7 @@ gfc_match_structure_constructor (gfc_symbol *sym, gfc_
   e = gfc_get_expr ();
   e->symtree = symtree;
   e->expr_type = EXPR_FUNCTION;
+  e->where = gfc_current_locus;
 
   gcc_assert (gfc_fl_struct (sym->attr.flavor)
 	  && symtree->n.sym->attr.flavor == FL_PROCEDURE);
Index: gcc/testsuite/gfortran.dg/pr70870_1.f90
===
--- gcc/testsuite/gfortran.dg/pr70870_1.f90	(revision 267034)
+++ gcc/testsuite/gfortran.dg/pr70870_1.f90	(working copy)
@@ -1,4 +1,5 @@
 ! { dg-do compile }
+! { dg-options "-std=gnu" }
 ! PR fortran/70870
 ! Contributed by Vittorio Zecca 
   type t
Index: gcc/testsuite/gfortran.dg/pr88155.f90
===
--- gcc/testsuite/gfortran.dg/pr88155.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr88155.f90	(working copy)
@@ -0,0 +1,9 @@
+! { dg-do compile }
+program p
+   type t
+  integer :: a
+   end type
+   type(t) :: x
+   data x /t()1/ ! { dg-error "No initializer for component" }
+   print *, x
+end

Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support

[Matthias Klose]

On 11.12.18 22:01, Cherry Zhang wrote:
> On Tue, Dec 11, 2018 at 3:51 PM Ian Lance Taylor  wrote:
> 
>> On Tue, Dec 11, 2018 at 6:52 AM Matthias Klose  wrote:
>>>
>>> On 10.12.18 16:54, Cherry Zhang wrote:
 On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose 
>> wrote:

> On 06.12.18 00:09, Ian Lance Taylor wrote:
>> This libgo patch by Cherry Zhang adds support for precise stack
>> scanning to the Go runtime.  This uses per-function stack maps stored
>> in the exception tables in the language-specific data area.  The
>> compiler needs to generate these stack maps; currently this is only
>> done by a version of LLVM, not by GCC.  Each safepoint in a function
>> is associated with a (real or dummy) landing pad, and its "type info"
>> in the exception table is a pointer to the stack map. When a stack is
>> scanned, the stack map is found by the stack unwinding code.
>>
>> For precise stack scan we need to unwind the stack. There are three
> cases:
>>
>> - If a goroutine is scanning its own stack, it can unwind the stack
>> and scan the frames.
>>
>> - If a goroutine is scanning another, stopped, goroutine, it cannot
>> directly unwind the target stack. We handle this by switching
>> (runtime.gogo) to the target g, letting it unwind and scan the stack,
>> and switch back.
>>
>> - If we are scanning a goroutine that is blocked in a syscall, we
>> send
>> a signal to the target goroutine's thread, and let the signal handler
>> unwind and scan the stack. Extra care is needed as this races with
>> enter/exit syscall.
>>
>> Currently this is only implemented on GNU/Linux.
>>
>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
>> to mainline.
>
> this broke the libgo build on ARM32:
>
> ../../../src/libgo/runtime/go-unwind.c: In function
> 'scanstackwithmap_callback':
> ../../../src/libgo/runtime/go-unwind.c:754:18: error:
>> '_URC_NORMAL_STOP'
> undeclared (first use in this function)
>   754 |   return _URC_NORMAL_STOP;
>   |  ^~~~
> ../../../src/libgo/runtime/go-unwind.c:754:18: note: each undeclared
> identifier
> is reported only once for each function i
> t appears in
> ../../../src/libgo/runtime/go-unwind.c: In function
> 'probestackmaps_callback':
> ../../../src/libgo/runtime/go-unwind.c:802:10: error:
>> '_URC_NORMAL_STOP'
> undeclared (first use in this function)
>   802 |   return _URC_NORMAL_STOP;
>   |  ^~~~
> ../../../src/libgo/runtime/go-unwind.c:803:1: warning: control
>> reaches end
> of
> non-void function [-Wreturn-type]
>   803 | }
>   | ^
> make[6]: *** [Makefile:1474: runtime/go-unwind.lo] Error 1
> make[6]: Leaving directory
> '/<>/build/arm-linux-gnueabihf/libgo'
>
>
 Hell Matthias,

 Thank you for the report. And sorry about the breakage. Does
 https://go-review.googlesource.com/c/gofrontend/+/153417 (or the patch
 below) fix ARM32 build? I don't have an ARM32 machine at hand to test.
>>>
>>> this fixes the build.
>>>
>>> currently running the testsuite, almost every test case core dumps on
>>> arm-linux-gnueabihf
>>
>> I committed Cherry's patch to trunk, since it looks reasonable to me.
>> Cherry, Matthias, let me know if you figure out why programs are
>> failing.
>>
>>
> Thank you.
> 
> I don't know for the moment. I'm trying to find an ARM32 machine so I can
> test.
> 
> Matthias, is it convenient for you to share a stack trace for the failing
> programs? That would be very helpful. Thanks!

I'll do a local build this weekend. For now you find the build log at
https://launchpad.net/ubuntu/+source/gcc-snapshot/1:20181210-0ubuntu1/+build/15759748

Re: [PATCH 1/9]: C++ P0482R5 char8_t: Documentation updates

[Sandra Loosemore]

On 11/5/18 12:39 PM, Tom Honermann wrote:

This patch adds documentation for new -fchar8_t and -fno-char8_t options.

gcc/ChangeLog:

2018-11-04  Tom Honermann  
  * doc/invoke.texi (-fchar8_t): Document new option.



My comments are all about nitpicky formatting things.


diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 57491f1033c..cd3a2a715db 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -206,7 +206,7 @@ in the following sections.
 @item C++ Language Options
 @xref{C++ Dialect Options,,Options Controlling C++ Dialect}.
 @gccoptlist{-fabi-version=@var{n}  -fno-access-control @gol
--faligned-new=@var{n}  -fargs-in-order=@var{n}  -fcheck-new @gol
+-faligned-new=@var{n}  -fargs-in-order=@var{n}  -fchar8_t -fcheck-new @gol


Please consistently use 2 spaces (not just 1) to separate options on the 
same line in a @gccoptlist environment.



 -fconstexpr-depth=@var{n}  -fconstexpr-loop-limit=@var{n} @gol
 -fno-elide-constructors @gol
 -fno-enforce-eh-specs @gol
@@ -2432,6 +2432,53 @@ but few users will need to override the default of
 
 This flag is enabled by default for @option{-std=c++17}.
 
+@item -fchar8_t

+@itemx -fno-char8_t
+@opindex fchar8_t
+@opindex fno-char8_t
+Enable support for the P0482 proposal including the addition of a
+new @code{char8_t} fundamental type, changes to the types of UTF-8
+string and character literals, new signatures for user defined
+literals, and new specializations of standard library class templates
+@code{std::numeric_limits}, @code{std::char_traits},
+and @code{std::hash}.
+
+This option enables functions to be overloaded for ordinary and UTF-8
+strings:
+
+@smallexample
+int f(const char *);// #1
+int f(const char8_t *); // #2
+int v1 = f("text"); // Calls #1
+int v2 = f(u8"text");   // Calls #2
+@end smallexample
+
+and introduces new signatures for user defined literals:


@noindent immediately before the continued sentence of the paragraph 
before the example.


Also please hyphenate "user-defined" here.


+
+@smallexample
+int operator""_udl1(char8_t);
+int v3 = u8'x'_udl1;
+int operator""_udl2(const char8_t*, std::size_t);
+int v4 = u8"text"_udl2;
+template int operator""_udl3();
+int v5 = u8"text"_udl3;
+@end smallexample
+
+The change to the types of UTF-8 string and character literals introduces
+incompatibilities with ISO C++11 and later standards.  For example, the
+following code is well-formed under ISO C++11, but is ill-formed when
+@option{-fchar8_t} is specified.
+
+@smallexample
+char ca[] = u8"text";   // error: char-array initialized from wide string
+const char *cp = u8"text";  // error: invalid conversion from 'const char8_t*' 
to 'const char*'
+int f(const char*);
+auto v = f(u8"text");   // error: invalid conversion from 'const char8_t*' 
to 'const char*'
+std::string s1@{u8"text"@};   // error: no matching function for call to 
'std::basic_string::basic_string()'
+using namespace std::literals;
+std::string s2 = u8"text"s; // error: conversion from 'basic_string' to 
non-scalar type 'basic_string' requested
+@end smallexample


The formatting of this code example is way too wide to fit on the page 
of the printed/PDF manual.  I suggest putting the comments on separate 
lines from the code and breaking them across multiple lines where 
necessary.  If you format the example for <80 columns it will probably 
fit, although you should check the PDF if at all possible.



+
 @item -fcheck-new
 @opindex fcheck-new
 Check that the pointer returned by @code{operator new} is non-null



-Sandra

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Jason Merrill]

On 12/11/18 6:08 PM, Martin Sebor wrote:

On 12/11/18 3:52 PM, Marek Polacek wrote:

On Tue, Dec 11, 2018 at 03:46:37PM -0700, Martin Sebor wrote:

On 12/11/18 1:47 PM, Jakub Jelinek wrote:

On Tue, Dec 11, 2018 at 01:36:58PM -0700, Martin Sebor wrote:

Attached is an updated version of the patch that restores
the original behavior for the positional argument validation
(i.e., prior to r266195) for integral types except bool as
discussed.


I thought Jason wanted to also warn for scoped enums in C++.


I missed that.  It seems needlessly restrictive to me to reject
the preferred kind of an enum when ordinary enums are accepted.
Jason, can you confirm that you really want a warning for B
below when there is none for A (GCC 8 doesn't complain about
either, Clang complains about both, ICC about neither when
using alloc_size -- it doesn't understand alloc_align):

   enum A { /* ... */ };
   __attribute__ ((alloc_align (1))) void* f (A);

   enum class B { /* ... */ };
   __attribute__ ((alloc_align (1))) void* g (B);

The only use case I can think of for enums is in APIs that try
to restrict the available choices of alignment to those of
the enumerators.  In that use case, I would expect it to make
no difference whether the enum is ordinary or the scoped kind.


The reason was that C++ scoped enumerations don't implicitly convert to
integral types.


I'm not sure we're talking about the same thing.  There is no
conversion in the use case I described, the attribute argument
just refers to the function parameter, and the function is called
with an argument of the enumerated type of the parameter.  Like
this:

   enum class Alignment { a4 = 4, a8 = 8 };

   __attribute__ ((alloc_align (1))) void*
   aligned_alloc (Alignment, size_t);

   void *p = aligned_alloc (Alignment::a8, 32);

My question is: if we think it makes sense to accept this use
case with ordinary enums why would we not want to make it possible
with scoped enums?  People tend to think of the latter as preferable
over the former.


OK, I suppose it's reasonable to allow scoped enums as well.

Jason

[Committed] PR fortran/88249 -- Check for UNIT in file positioning

[Steve Kargl]

I've committed the attached patch.  It does two things.
(1) It adds checking for a UNIT number when a file positioning
statement contains ERR=.  (2) It passes a locus so that a
sensible error message is printed,

2018-12-11  Steven G. Kargl  

PR fortran/88249
* gfortran.h: Update prototype for gfc_resolve_filepos().
* io.c (gfc_resolve_filepos): Check for UNIT number if ERR= is present.
Use passed in locus for error message.
* resolve.c (gfc_resolve_code): Pass locus in gfc_resolve_filepos()
call.

2018-12-11  Steven G. Kargl  

PR fortran/88249
* gfortran.dg/pr88249.f90: New test.
-- 
Steve
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h	(revision 267033)
+++ gcc/fortran/gfortran.h	(working copy)
@@ -3395,7 +3395,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/io.c
===
--- gcc/fortran/io.c	(revision 267033)
+++ gcc/fortran/io.c	(working copy)
@@ -2849,21 +2849,20 @@ 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
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 267033)
+++ gcc/fortran/resolve.c	(working copy)
@@ -11545,7 +11545,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/testsuite/gfortran.dg/pr88249.f90
===
--- gcc/testsuite/gfortran.dg/pr88249.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr88249.f90	(working copy)
@@ -0,0 +1,7 @@
+! { dg-do compile }
+program p
+   backspace (err=1) ! { dg-error "UNIT number missing" }
+   endfile (err=1)   ! { dg-error "UNIT number missing" }
+   flush (err=1) ! { dg-error "UNIT number missing" }
+   rewind (err=1)! { dg-error "UNIT number missing" }
+end

[Patch 2/4][Aarch64] v2: Implement Aarch64 SIMD ABI

[Steve Ellcey]

This is the modified version of the second of my Aarch64 SIMD ABI patches.
While implementing this functionality I found I wanted
targetm.simd_clone.adjust to be called when creating SIMD clone definitions
and also when creating SIMD clone declarations.  The current
implementation (used only by x86) only called this target function when
creating clone definitions.  I added a second argument to the target
function to say if it was creating a definition or a declaration and
modified the i386 code to do nothing on declarations, thus maintaining
its current behavour.

This allowed my to add the aarch64_vector_pcs attribute to SIMD clone
declarations and definitions on Aarch64. 

I considered comparing node->decl and cfun->decl to differentiate
between definitions and declarations instead of using a new argument
but having an argument seemed cleaner and clearer.

Tested on x86 and aarch64.

Steve Ellcey
sell...@marvell.com


2018-12-11  Steve Ellcey  

* config/aarch64/aarch64.c (cgraph.h): New include.
(aarch64_simd_clone_compute_vecsize_and_simdlen): New function.
(aarch64_simd_clone_adjust): Ditto.
(aarch64_simd_clone_usable): Ditto.
(TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN): New macro.
(TARGET_SIMD_CLONE_ADJUST): Ditto.
(TARGET_SIMD_CLONE_USABLE): Ditto.
* config/i386/i386.c (ix86_simd_clone_adjust): Add new argument.
* omp-simd-clone.c (simd_clone_adjust): Add new argument
to targetm.simd_clone.adjust call.
(expand_simd_clones): Add new targetm.simd_clone.adjust call.
* target.def (simd_clone_adjust): Add new argument.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index ea7e79f..40f18ef 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -40,6 +40,7 @@
 #include "regs.h"
 #include "emit-rtl.h"
 #include "recog.h"
+#include "cgraph.h"
 #include "diagnostic.h"
 #include "insn-attr.h"
 #include "alias.h"
@@ -17936,6 +17937,135 @@ aarch64_estimated_poly_value (poly_int64 val)
   return val.coeffs[0] + val.coeffs[1] * over_128 / 128;
 }
 
+/* Set CLONEI->vecsize_mangle, CLONEI->mask_mode, CLONEI->vecsize_int,
+   CLONEI->vecsize_float and if CLONEI->simdlen is 0, also
+   CLONEI->simdlen.  Return 0 if SIMD clones shouldn't be emitted,
+   or number of vecsize_mangle variants that should be emitted.  */
+
+static int
+aarch64_simd_clone_compute_vecsize_and_simdlen (struct cgraph_node *node,
+	struct cgraph_simd_clone *clonei,
+	tree base_type,
+	int num ATTRIBUTE_UNUSED)
+{
+  int ret = 0;
+
+  if (clonei->simdlen
+  && (clonei->simdlen < 2
+	  || clonei->simdlen > 1024
+	  || (clonei->simdlen & (clonei->simdlen - 1)) != 0))
+{
+  warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+		  "unsupported simdlen %d", clonei->simdlen);
+  return 0;
+}
+
+  tree ret_type = TREE_TYPE (TREE_TYPE (node->decl));
+  if (TREE_CODE (ret_type) != VOID_TYPE)
+switch (TYPE_MODE (ret_type))
+  {
+  case E_QImode:
+  case E_HImode:
+  case E_SImode:
+  case E_DImode:
+  case E_SFmode:
+  case E_DFmode:
+  /* case E_SCmode: */
+  /* case E_DCmode: */
+	break;
+  default:
+	warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+		"unsupported return type %qT for simd\n", ret_type);
+	return 0;
+  }
+
+  tree t;
+  for (t = DECL_ARGUMENTS (node->decl); t; t = DECL_CHAIN (t))
+/* FIXME: Shouldn't we allow such arguments if they are uniform?  */
+switch (TYPE_MODE (TREE_TYPE (t)))
+  {
+  case E_QImode:
+  case E_HImode:
+  case E_SImode:
+  case E_DImode:
+  case E_SFmode:
+  case E_DFmode:
+  /* case E_SCmode: */
+  /* case E_DCmode: */
+	break;
+  default:
+	warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+		"unsupported argument type %qT for simd\n", TREE_TYPE (t));
+	return 0;
+  }
+
+  if (TARGET_SIMD)
+{
+clonei->vecsize_mangle = 'n';
+clonei->mask_mode = VOIDmode;
+clonei->vecsize_int = 128;
+clonei->vecsize_float = 128;
+
+if (clonei->simdlen == 0)
+  {
+  if (SCALAR_INT_MODE_P (TYPE_MODE (base_type)))
+	clonei->simdlen = clonei->vecsize_int;
+  else
+	clonei->simdlen = clonei->vecsize_float;
+  clonei->simdlen /= GET_MODE_BITSIZE (SCALAR_TYPE_MODE (base_type));
+  }
+else if (clonei->simdlen > 16)
+  {
+  /* If it is possible for given SIMDLEN to pass CTYPE value in
+	 registers (v0-v7) accept that SIMDLEN, otherwise warn and don't
+	 emit corresponding clone.  */
+  int cnt = GET_MODE_BITSIZE (SCALAR_TYPE_MODE (base_type)) * clonei->simdlen;
+  if (SCALAR_INT_MODE_P (TYPE_MODE (base_type)))
+	cnt /= clonei->vecsize_int;
+  else
+	cnt /= clonei->vecsize_float;
+  if (cnt > 8)
+	{
+	warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+		"unsupported simdlen %d", clonei->simdlen);
+	return 0;
+	}
+  }
+  ret = 1;
+}
+  return ret;
+}
+
+/* Add 

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Martin Sebor]

On 12/11/18 3:52 PM, Marek Polacek wrote:

On Tue, Dec 11, 2018 at 03:46:37PM -0700, Martin Sebor wrote:

On 12/11/18 1:47 PM, Jakub Jelinek wrote:

On Tue, Dec 11, 2018 at 01:36:58PM -0700, Martin Sebor wrote:

Attached is an updated version of the patch that restores
the original behavior for the positional argument validation
(i.e., prior to r266195) for integral types except bool as
discussed.


I thought Jason wanted to also warn for scoped enums in C++.


I missed that.  It seems needlessly restrictive to me to reject
the preferred kind of an enum when ordinary enums are accepted.
Jason, can you confirm that you really want a warning for B
below when there is none for A (GCC 8 doesn't complain about
either, Clang complains about both, ICC about neither when
using alloc_size -- it doesn't understand alloc_align):

   enum A { /* ... */ };
   __attribute__ ((alloc_align (1))) void* f (A);

   enum class B { /* ... */ };
   __attribute__ ((alloc_align (1))) void* g (B);

The only use case I can think of for enums is in APIs that try
to restrict the available choices of alignment to those of
the enumerators.  In that use case, I would expect it to make
no difference whether the enum is ordinary or the scoped kind.


The reason was that C++ scoped enumerations don't implicitly convert to
integral types.


I'm not sure we're talking about the same thing.  There is no
conversion in the use case I described, the attribute argument
just refers to the function parameter, and the function is called
with an argument of the enumerated type of the parameter.  Like
this:

  enum class Alignment { a4 = 4, a8 = 8 };

  __attribute__ ((alloc_align (1))) void*
  aligned_alloc (Alignment, size_t);

  void *p = aligned_alloc (Alignment::a8, 32);

My question is: if we think it makes sense to accept this use
case with ordinary enums why would we not want to make it possible
with scoped enums?  People tend to think of the latter as preferable
over the former.

Martin

Fix PR ada/88429

[Eric Botcazou]

This is the failure of the libada build when the compiler is configured with 
--disable-shared in a multilib setup, a regression present on the mainline.
To be honest, I don't quite grasp why this doesn't also fail the same way in 
default mode.  While I was at it, I have done something I had wanted to do for 
quite some time, namely having a 1-1 mapping between the Makefile targets in 
libada/Makefile and ada/gcc-interface/Makefile for the library.

Bootstrapped/regtested on x86_64-suse-linux w/ and w/o --disable-shared and w/ 
and w/o --disable-ada, applied on the mainline.


2018-12-11  Eric Botcazou  

PR ada/88429
* configure.ac (default_gnatlib_target): Set to gnatlib instead of
gnatlib-plain if --disable-shared.
* configure: Regenerate.
* Makefile.in (all): Replace gnatlib prerequisite with libada.
(ADA_RTS_SUBDIR): Delete.
(libada): New target, renamed from...
(gnatlib): ...this.  Merge with other library targets.
(gnatlib-plain): Delete.
(install-gnatlib): Rename to...
(install-libada): ...this.
(install): Replace install-gnatlib prerequisite with install-libada.


2018-12-11  Eric Botcazou  

PR ada/88429
* gcc-interface/Makefile.in (./stamp-gnatlib1-$(RTSDIR)): Also pass
MULTISUBDIR to sub-make and add quotes around $(THREAD_KIND).
(gnatlib-shared-dual): Also pass PICFLAG_FOR_TARGET to sub-make.
(gnatlib-sjlj): Also pass MULTISUBDIR to sub-make, but do not pass
PICFLAG_FOR_TARGET.
(gnatlib-zcx): Likewise.

-- 
Eric BotcazouIndex: libada/Makefile.in
===
--- libada/Makefile.in	(revision 267029)
+++ libada/Makefile.in	(working copy)
@@ -16,7 +16,7 @@
 # .
 
 # Default target; must be first.
-all: gnatlib
+all: libada
 	$(MULTIDO) $(AM_MAKEFLAGS) DO=all multi-do # $(MAKE)
 
 .PHONY: all
@@ -70,7 +70,6 @@ target_noncanonical:=@target_noncanonica
 version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/BASE-VER)
 libsubdir := $(libdir)/gcc/$(target_noncanonical)/$(version)$(MULTISUBDIR)
 ADA_RTS_DIR=$(GCC_DIR)/ada/rts$(subst /,_,$(MULTISUBDIR))
-ADA_RTS_SUBDIR=./rts$(subst /,_,$(MULTISUBDIR))
 
 # exeext should not be used because it's the *host* exeext.  We're building
 # a *target* library, aren't we?!?  Likewise for CC.  Still, provide bogus
@@ -96,20 +95,12 @@ LIBADA_FLAGS_TO_PASS = \
 	"GCC_FOR_TARGET=$(CC)" \
 "CFLAGS=$(CFLAGS)"
 
-# Rules to build gnatlib.
-.PHONY: gnatlib gnatlib-plain gnatlib-sjlj gnatlib-zcx gnatlib-shared osconstool
-gnatlib: @default_gnatlib_target@
+.PHONY: libada gnatlib gnatlib-shared gnatlib-sjlj gnatlib-zcx osconstool
 
-gnatlib-plain: osconstool $(GCC_DIR)/ada/Makefile
-	test -f stamp-libada || \
-	$(MAKE) -C $(GCC_DIR)/ada $(LIBADA_FLAGS_TO_PASS) gnatlib \
-	&& touch stamp-libada
-	-rm -rf adainclude
-	-rm -rf adalib
-	$(LN_S_RECURSIVE) $(ADA_RTS_DIR) adainclude
-	$(LN_S_RECURSIVE) $(ADA_RTS_DIR) adalib
+# Rules to build and install libada.
+libada: @default_gnatlib_target@
 
-gnatlib-sjlj gnatlib-zcx gnatlib-shared: osconstool $(GCC_DIR)/ada/Makefile
+gnatlib gnatlib-shared gnatlib-sjlj gnatlib-zcx: osconstool $(GCC_DIR)/ada/Makefile
 	test -f stamp-libada || \
 	$(MAKE) -C $(GCC_DIR)/ada $(LIBADA_FLAGS_TO_PASS) $@ \
 	&& touch stamp-libada
@@ -121,7 +112,7 @@ gnatlib-sjlj gnatlib-zcx gnatlib-shared:
 osconstool:
 	$(MAKE) -C $(GCC_DIR)/ada $(LIBADA_FLAGS_TO_PASS) ./bldtools/oscons/xoscons
 
-install-gnatlib: $(GCC_DIR)/ada/Makefile
+install-libada: $(GCC_DIR)/ada/Makefile
 	$(MAKE) -C $(GCC_DIR)/ada $(LIBADA_FLAGS_TO_PASS) install-gnatlib
 
 # Check uninstalled version.
@@ -148,7 +139,7 @@ TAGS:
 .PHONY: check installcheck info dvi pdf html
 
 # Installation rules.
-install: install-gnatlib
+install: install-libada
 	$(MULTIDO) $(AM_MAKEFLAGS) DO=install multi-do # $(MAKE)
 
 install-strip: install
Index: libada/configure
===
--- libada/configure	(revision 267029)
+++ libada/configure	(working copy)
@@ -3264,7 +3264,7 @@ fi
 if test ${enable_shared} = yes; then
   default_gnatlib_target="gnatlib-shared"
 else
-  default_gnatlib_target="gnatlib-plain"
+  default_gnatlib_target="gnatlib"
 fi
 
 
Index: libada/configure.ac
===
--- libada/configure.ac	(revision 267029)
+++ libada/configure.ac	(working copy)
@@ -129,7 +129,7 @@ AC_PROG_LN_S
 if test ${enable_shared} = yes; then
   default_gnatlib_target="gnatlib-shared"
 else
-  default_gnatlib_target="gnatlib-plain"
+  default_gnatlib_target="gnatlib"
 fi
 AC_SUBST([default_gnatlib_target])
 
Index: gcc/ada/gcc-interface/Makefile.in
===
--- gcc/ada/gcc-interface/Makefile.in	(revision 267029)
+++ gcc/ada/gcc-interface/Makefile.in	(working copy)
@@ -1,5 +1,5 @@
 # Makefile for GNU 

Re: [Patch 1/4][Aarch64] v2: Implement Aarch64 SIMD ABI

[Steve Ellcey]

On Fri, 2018-12-07 at 17:34 +, Richard Sandiford wrote:
> 
> I'm not an expert on this stuff, but it looks like:
> 
>   struct cgraph_node *node = cgraph_node::get (fndecl);
>   return node && node->simdclone;
> 
> might work.  But in some ways it would be cleaner to add the
> aarch64_vector_pcs attribute for SIMD clones, e.g. via a new hook,
> so that the function type is "correct".

I have changed this to add the aarch64_vector_pcs attribute to clones.
To do this I had to tweak the targetm.simd_clone.adjust target
function, but I did not have to add a new target function.  That change
is part of Patch 2/4 and I will resubmit that after this email.  The
change in this patch is to just check for the aarch64_vector_pcs
attribute and not look at the simd attribute to determine the ABI.

> 
> > @@ -4863,6 +4949,7 @@ aarch64_process_components (sbitmap
> > components, bool prologue_p)
> >mergeable with the current one into a pair.  */
> >if (!satisfies_constraint_Ump (mem)
> > || GP_REGNUM_P (regno) != GP_REGNUM_P (regno2)
> > +   || (aarch64_simd_decl_p (cfun->decl) && (FP_REGNUM_P
> > (regno)))
> 
> Formatting nit: redundant brackets around FP_REGNUM_P (regno).

Fixed.

> > 
> > -(define_insn "simple_return"
> > +(define_expand "simple_return"
> > +  [(simple_return)]
> > +  "aarch64_use_simple_return_insn_p ()"
> > +  ""
> > +)
> > +
> > +(define_insn "*simple_return"
> >[(simple_return)]
> >""
> >"ret"
> 
> Can't you just change the condition on the existing define_insn,
> without turning it in a define_expand?  Worth a comment explaining
> why if not.

Yes, I am not sure why I did it this way (ciopying some other target
probably) but I got rid of the define_expand and changed the
define_insn and things seem to work fine.

> 
> > @@ -1487,6 +1538,23 @@
> >[(set_attr "type" "neon_store1_2reg")]
> >  )
> > 
> > +(define_insn "storewb_pair_"
> > +  [(parallel
> > +[(set (match_operand:P 0 "register_operand" "=")
> > +  (plus:P (match_operand:P 1 "register_operand" "0")
> > +  (match_operand:P 4 "aarch64_mem_pair_offset"
> > "n")))
> > + (set (mem:TX (plus:P (match_dup 0)
> > +  (match_dup 4)))
> 
> Should be indented under the (match_dup 0).

Fixed.

> 
> > +  (match_operand:TX 2 "register_operand" "w"))
> > + (set (mem:TX (plus:P (match_dup 0)
> > +  (match_operand:P 5 "const_int_operand" "n")))
> > +  (match_operand:TX 3 "register_operand" "w"))])]
> 
> Think this last part should be:
> 
>  (set (mem:TX (plus:P (plus:P (match_dup 0)
>   (match_dup 4))
>   (match_operand:P 5 "const_int_operand"
> "n")))
>   (match_operand:TX 3 "register_operand" "w"))])]

I think you are right about this.  What I have for
loadwb_pair_ matches what is there for
loadwb_pair_.  If this one is wrong, then I assume
the others are wrong too?  This won't make a practical difference since
we call these with gen_loadwb_pair*_* calls and not via pattern
recognition, but still they should be right.  Should I change them
all?  I did not change this as part of this patch.

> 
> > +  "TARGET_SIMD &&
> > +   INTVAL (operands[5]) == INTVAL (operands[4]) + GET_MODE_SIZE
> > (mode)"
> 
> && should be on the second line (which makes the line long enough to
> need breaking).

Fixed.

> 
> > diff --git a/gcc/testsuite/gcc.target/aarch64/torture/simd-abi-2.c
> > 
> 
> Comment doesn't match code: this is testing a normal PCS function.

Fixed.
> 
> > +++ b/gcc/testsuite/gcc.target/aarch64/torture/simd-abi-5.c
> 
> This is a nice test, but I think it would also be good to have versions
> that don't clobber full register pairs.  E.g. one without q9 and another
> without q10 would test individual STR Qs.

I added two new tests for this, simd-abi-6.c and simd-abi-7.c.

Steve Ellcey
sell...@marvell.com



ChangeLog:

2018-12-11  Steve Ellcey  

* config/aarch64/aarch64-protos.h (aarch64_use_simple_return_insn_p):
New prototype.
(aarch64_epilogue_uses): Ditto.
* config/aarch64/aarch64.c (aarch64_attribute_table): New array.
(aarch64_simd_decl_p): New function.
(aarch64_reg_save_mode): New function.
(aarch64_function_ok_for_sibcall): Check for simd calls.
(aarch64_layout_frame): Check for simd function.
(aarch64_gen_storewb_pair): Handle E_TFmode.
(aarch64_push_regs): Use aarch64_reg_save_mode to get mode.
(aarch64_gen_loadwb_pair): Handle E_TFmode.
(aarch64_pop_regs): Use aarch64_reg_save_mode to get mode.
(aarch64_gen_store_pair): Handle E_TFmode.
(aarch64_gen_load_pair): Ditto.
(aarch64_save_callee_saves): Handle different mode sizes.
(aarch64_restore_callee_saves): Ditto.
(aarch64_components_for_bb): Check for simd function.
(aarch64_epilogue_uses): New function.
(aarch64_process_components): Check for 

Re: [C++ PATCH] Fix up __builtin_is_constant_evaluated handling in array type sizes (PR c++/88446, take 2)

[Jason Merrill]

On 12/11/18 4:38 PM, Jakub Jelinek wrote:

On Tue, Dec 11, 2018 at 03:35:39PM -0500, Marek Polacek wrote:

  tree
-maybe_constant_value (tree t, tree decl)
+maybe_constant_value (tree t, tree decl, bool pretend_const_required)
  {
tree r;
  


Could you please describe the new param in the comment?

Perhaps use /*pretend_const_required=*/true?


Thanks, changed both, plus I've changed the other function's descriptions
of that argument from the P0595R1 term (required to be const-evaluated)
to the P0595R2 term (manifestly const-evaluated).

Ok for trunk?  Or should I also change pretend_const_required argument
name to manifestly_const_eval or something similar?


I think so, yes.  OK with that change.

Jason

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Marek Polacek]

On Tue, Dec 11, 2018 at 03:46:37PM -0700, Martin Sebor wrote:
> On 12/11/18 1:47 PM, Jakub Jelinek wrote:
> > On Tue, Dec 11, 2018 at 01:36:58PM -0700, Martin Sebor wrote:
> > > Attached is an updated version of the patch that restores
> > > the original behavior for the positional argument validation
> > > (i.e., prior to r266195) for integral types except bool as
> > > discussed.
> > 
> > I thought Jason wanted to also warn for scoped enums in C++.
> 
> I missed that.  It seems needlessly restrictive to me to reject
> the preferred kind of an enum when ordinary enums are accepted.
> Jason, can you confirm that you really want a warning for B
> below when there is none for A (GCC 8 doesn't complain about
> either, Clang complains about both, ICC about neither when
> using alloc_size -- it doesn't understand alloc_align):
> 
>   enum A { /* ... */ };
>   __attribute__ ((alloc_align (1))) void* f (A);
> 
>   enum class B { /* ... */ };
>   __attribute__ ((alloc_align (1))) void* g (B);
> 
> The only use case I can think of for enums is in APIs that try
> to restrict the available choices of alignment to those of
> the enumerators.  In that use case, I would expect it to make
> no difference whether the enum is ordinary or the scoped kind.

The reason was that C++ scoped enumerations don't implicitly convert to
integral types.

Marek

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Martin Sebor]

On 12/11/18 1:47 PM, Jakub Jelinek wrote:

On Tue, Dec 11, 2018 at 01:36:58PM -0700, Martin Sebor wrote:

Attached is an updated version of the patch that restores
the original behavior for the positional argument validation
(i.e., prior to r266195) for integral types except bool as
discussed.


I thought Jason wanted to also warn for scoped enums in C++.


I missed that.  It seems needlessly restrictive to me to reject
the preferred kind of an enum when ordinary enums are accepted.
Jason, can you confirm that you really want a warning for B
below when there is none for A (GCC 8 doesn't complain about
either, Clang complains about both, ICC about neither when
using alloc_size -- it doesn't understand alloc_align):

  enum A { /* ... */ };
  __attribute__ ((alloc_align (1))) void* f (A);

  enum class B { /* ... */ };
  __attribute__ ((alloc_align (1))) void* g (B);

The only use case I can think of for enums is in APIs that try
to restrict the available choices of alignment to those of
the enumerators.  In that use case, I would expect it to make
no difference whether the enum is ordinary or the scoped kind.




+  else if (code == INTEGER_TYPE)
+   /* For integers, accept enums, wide characters and other types
+  that match INTEGRAL_TYPE_P except for bool.  */
+   type_match = (INTEGRAL_TYPE_P (argtype)
+ && TREE_CODE (argtype) != BOOLEAN_TYPE);


So it would better be:
type_match = (TREE_CODE (argtype) == INTEGER_TYPE
  || (TREE_CODE (argtype) == ENUMERAL_TYPE
  && !ENUM_IS_SCOPED (argtype)));


--- gcc/doc/extend.texi (revision 266966)
+++ gcc/doc/extend.texi (working copy)
@@ -2471,7 +2471,9 @@ The @code{aligned} attribute can also be used for
  @item alloc_align (@var{position})
  @cindex @code{alloc_align} function attribute
  The @code{alloc_align} attribute may be applied to a function that
-returns a pointer and takes at least one argument of an integer type.
+returns a pointer and takes at least one argument of an integer or
+enumerated type, but not @code{bool}.  Arguments of other types are
+diagnosed.


The keyword is _Bool in C, so wouldn't it be better to say but not Boolean
type or but not @code{bool} or @code{_Bool}?


It makes little difference.  Established practice in the manual
is @code{bool} (14 occurrences).  There are just three instances
of @code{_Bool} in prose in doc/*.texi.  It's simpler to refer
to @code{bool} unless we are specifically talking about the C
keyword/type.

Martin

[PATCH] C++: better locations for bogus initializations (PR c++/88375)

[David Malcolm]

PR c++/88375 reports that errors relating to invalid conversions in
initializations are reported at unhelpfully vague locations, as in
e.g.:

enum struct a : int {
  one, two
};

struct foo {
  int e1, e2;
  a e3;
} arr[] = {
  { 1, 2, a::one },
  { 3, a::two },
  { 4, 5, a::two }
};

for which g++ trunk emits the vague:

pr88375.cc:12:1: error: cannot convert 'a' to 'int' in initialization
   12 | };
  | ^

with the error at the final closing brace.

This patch uses location information for the initializers, converting the
above to:

pr88375.cc:10:11: error: cannot convert 'a' to 'int' in initialization
   10 |   { 3, a::two },
  |~~~^~~
  |   |
  |   a

highlighting which subexpression is problematic, and its type.

Ideally we'd also issue a note showing the field decl being initialized,
but that turned out to be more invasive.

This patch relies on:

 "[PATCH 1/2] v3: C++: more location wrapper nodes (PR c++/43064, PR c++/43486)"
 https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00500.html

and:

 "[PATCH 2/2] v2: C++: improvements to binary operator diagnostics (PR
c++/87504)"
 https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00236.html

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu, on top of
those patches.

OK for trunk, if those patches are approved?

Thanks
Dave

gcc/cp/ChangeLog:
PR c++/88375
* typeck.c (convert_for_assignment): Capture location of rhs
before stripping, and if available.  Use the location when
complaining about bad conversions, labelling it with the
rhstype if the location was present.
* typeck2.c (digest_init_r): Capture location of init before
stripping.

gcc/testsuite/ChangeLog:
PR c++/88375
* g++.dg/init/pr88375-2.C: New test.
* g++.dg/init/pr88375.C: New test.
---
 gcc/cp/typeck.c   | 43 +--
 gcc/cp/typeck2.c  | 10 
 gcc/testsuite/g++.dg/init/pr88375-2.C | 41 +
 gcc/testsuite/g++.dg/init/pr88375.C   | 26 +
 4 files changed, 99 insertions(+), 21 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/init/pr88375-2.C
 create mode 100644 gcc/testsuite/g++.dg/init/pr88375.C

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index ded6b24..4191a5d 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -8824,6 +8824,9 @@ convert_for_assignment (tree type, tree rhs,
   tree rhstype;
   enum tree_code coder;
 
+  location_t loc = cp_expr_loc_or_loc (rhs, input_location);
+  bool has_loc = cp_expr_location (rhs) != UNKNOWN_LOCATION;
+
   /* Strip NON_LVALUE_EXPRs since we aren't using as an lvalue,
  but preserve location wrappers.  */
   if (TREE_CODE (rhs) == NON_LVALUE_EXPR
@@ -8864,7 +8867,7 @@ convert_for_assignment (tree type, tree rhs,
   if (coder == VOID_TYPE)
 {
   if (complain & tf_error)
-   error ("void value not ignored as it ought to be");
+   error_at (loc, "void value not ignored as it ought to be");
   return error_mark_node;
 }
 
@@ -8936,35 +8939,43 @@ convert_for_assignment (tree type, tree rhs,
 rhstype, type,
 fndecl, parmnum);
  else
-   switch (errtype)
- {
+   {
+ range_label_for_type_mismatch label (rhstype, type);
+ gcc_rich_location richloc (loc, has_loc ?  : NULL);
+ switch (errtype)
+   {
case ICR_DEFAULT_ARGUMENT:
- error ("cannot convert %qH to %qI in default argument",
-rhstype, type);
+ error_at (,
+   "cannot convert %qH to %qI in default argument",
+   rhstype, type);
  break;
case ICR_ARGPASS:
- error ("cannot convert %qH to %qI in argument passing",
-rhstype, type);
+ error_at (,
+   "cannot convert %qH to %qI in argument passing",
+   rhstype, type);
  break;
case ICR_CONVERTING:
- error ("cannot convert %qH to %qI",
-rhstype, type);
+ error_at (, "cannot convert %qH to %qI",
+   rhstype, type);
  break;
case ICR_INIT:
- error ("cannot convert %qH to %qI in initialization",
-rhstype, type);
+ error_at (,
+   "cannot convert %qH to %qI in initialization",
+   rhstype, type);
  break;
case ICR_RETURN:
- 

[C++ PATCH] Fix up __builtin_is_constant_evaluated handling in array type sizes (PR c++/88446, take 2)

[Jakub Jelinek]

On Tue, Dec 11, 2018 at 03:35:39PM -0500, Marek Polacek wrote:
> >  tree
> > -maybe_constant_value (tree t, tree decl)
> > +maybe_constant_value (tree t, tree decl, bool pretend_const_required)
> >  {
> >tree r;
> >  
> 
> Could you please describe the new param in the comment?
> 
> Perhaps use /*pretend_const_required=*/true?

Thanks, changed both, plus I've changed the other function's descriptions
of that argument from the P0595R1 term (required to be const-evaluated)
to the P0595R2 term (manifestly const-evaluated).

Ok for trunk?  Or should I also change pretend_const_required argument
name to manifestly_const_eval or something similar?

2018-12-11  Jakub Jelinek  

PR c++/88446
* cp-tree.h (maybe_constant_value): Add pretend_const_required
argument.
* constexpr.c (cxx_eval_builtin_function_call): Formatting fix.
(cxx_eval_outermost_constant_expr, maybe_constant_init_1): Adjust
pretend_const_required argument description in function comments.
(maybe_constant_value): Likewise.  If true, don't cache and call
cxx_eval_outermost_constant_expr with true as pretend_const_required.
* decl.c (compute_array_index_type_loc): Call maybe_constant_value
with true as pretend_const_required.

* g++.dg/cpp2a/is-constant-evaluated3.C: New test.

--- gcc/cp/cp-tree.h.jj 2018-12-11 18:15:27.495406106 +0100
+++ gcc/cp/cp-tree.h2018-12-11 22:25:29.994213808 +0100
@@ -7663,7 +7663,7 @@ extern bool require_rvalue_constant_expr
 extern bool require_potential_rvalue_constant_expression (tree);
 extern tree cxx_constant_value (tree, tree = NULL_TREE);
 extern tree cxx_constant_init  (tree, tree = NULL_TREE);
-extern tree maybe_constant_value   (tree, tree = NULL_TREE);
+extern tree maybe_constant_value   (tree, tree = NULL_TREE, bool = 
false);
 extern tree maybe_constant_init(tree, tree = 
NULL_TREE, bool = false);
 extern tree fold_non_dependent_expr(tree, tsubst_flags_t = 
tf_warning_or_error);
 extern tree fold_simple(tree);
--- gcc/cp/constexpr.c.jj   2018-12-11 21:35:05.450412282 +0100
+++ gcc/cp/constexpr.c  2018-12-11 22:30:57.785880411 +0100
@@ -1204,7 +1204,7 @@ cxx_eval_builtin_function_call (const co
   /* For __builtin_is_constant_evaluated, defer it if not
  ctx->pretend_const_required, otherwise fold it to true.  */
   if (fndecl_built_in_p (fun, CP_BUILT_IN_IS_CONSTANT_EVALUATED,
-  BUILT_IN_FRONTEND))
+BUILT_IN_FRONTEND))
 {
   if (!ctx->pretend_const_required)
{
@@ -5014,7 +5014,7 @@ instantiate_constexpr_fns (tree t)
STRICT has the same sense as for constant_value_1: true if we only allow
conforming C++ constant expressions, or false if we want a constant value
even if it doesn't conform.
-   PRETEND_CONST_REQUIRED is true if T is required to be const-evaluated as
+   PRETEND_CONST_REQUIRED is true if T is manifestly const-evaluated as
per P0595 even when ALLOW_NON_CONSTANT is true.  */
 
 static tree
@@ -5266,12 +5266,14 @@ fold_simple (tree t)
 
 /* If T is a constant expression, returns its reduced value.
Otherwise, if T does not have TREE_CONSTANT set, returns T.
-   Otherwise, returns a version of T without TREE_CONSTANT.  */
+   Otherwise, returns a version of T without TREE_CONSTANT.
+   PRETEND_CONST_REQUIRED is true if T is manifestly const-evaluated
+   as per P0595.  */
 
 static GTY((deletable)) hash_map *cv_cache;
 
 tree
-maybe_constant_value (tree t, tree decl)
+maybe_constant_value (tree t, tree decl, bool pretend_const_required)
 {
   tree r;
 
@@ -5288,6 +5290,9 @@ maybe_constant_value (tree t, tree decl)
 /* No caching or evaluation needed.  */
 return t;
 
+  if (pretend_const_required)
+return cxx_eval_outermost_constant_expr (t, true, true, true, decl);
+
   if (cv_cache == NULL)
 cv_cache = hash_map::create_ggc (101);
   if (tree *cached = cv_cache->get (t))
@@ -5391,7 +5396,7 @@ fold_non_dependent_expr (tree t,
 /* Like maybe_constant_value, but returns a CONSTRUCTOR directly, rather
than wrapped in a TARGET_EXPR.
ALLOW_NON_CONSTANT is false if T is required to be a constant expression.
-   PRETEND_CONST_REQUIRED is true if T is required to be const-evaluated as
+   PRETEND_CONST_REQUIRED is true if T is manifestly const-evaluated as
per P0595 even when ALLOW_NON_CONSTANT is true.  */
 
 static tree
--- gcc/cp/decl.c.jj2018-12-11 21:27:27.735860813 +0100
+++ gcc/cp/decl.c   2018-12-11 22:31:35.953259399 +0100
@@ -9646,7 +9646,11 @@ compute_array_index_type_loc (location_t
{
  size = instantiate_non_dependent_expr_sfinae (size, complain);
  size = build_converted_constant_expr (size_type_node, size, complain);
- size = maybe_constant_value (size);
+ /* Pedantically a constant expression is required here and 

Re: C++ PATCH for c++/88216, ICE with class type in non-type template parameter

[Marek Polacek]

On Tue, Dec 11, 2018 at 10:48:17AM -0500, Jason Merrill wrote:
> On 12/10/18 2:52 PM, Marek Polacek wrote:
> > +  if (processing_template_decl && value_dependent_expression_p (expr))
> 
> You don't need to check processing_template_decl before
> value_dependent_expression_p.

Ok.
 
> I would lean toward checking for value-dependence in
> convert_nontype_argument, which already does that a lot.  Enough, actually,
> that perhaps we should remember the result in a local variable.

I've moved the call, but I didn't add a local variable for the result,
because I was afraid that, since EXPR is being modified on some of the
codepaths, its value-dependent-ness (is that a term?) may change.

Thanks,

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

2018-12-11  Marek Polacek  

PR c++/88216 - ICE with class type in non-type template parameter.
* mangle.c (write_expression): Handle TARGET_EXPR and
VIEW_CONVERT_EXPR.
* pt.c (convert_nontype_argument): Don't call
get_template_parm_object for value-dependent expressions.

* g++.dg/cpp2a/nontype-class9.C: New test.

diff --git gcc/cp/mangle.c gcc/cp/mangle.c
index 64415894bc5..56247883010 100644
--- gcc/cp/mangle.c
+++ gcc/cp/mangle.c
@@ -2836,13 +2836,21 @@ write_expression (tree expr)
 {
   enum tree_code code = TREE_CODE (expr);
 
+  if (TREE_CODE (expr) == TARGET_EXPR)
+{
+  expr = TARGET_EXPR_INITIAL (expr);
+  code = TREE_CODE (expr);
+}
+
   /* Skip NOP_EXPR and CONVERT_EXPR.  They can occur when (say) a pointer
  argument is converted (via qualification conversions) to another type.  */
   while (CONVERT_EXPR_CODE_P (code)
 || location_wrapper_p (expr)
 /* Parentheses aren't mangled.  */
 || code == PAREN_EXPR
-|| code == NON_LVALUE_EXPR)
+|| code == NON_LVALUE_EXPR
+|| (code == VIEW_CONVERT_EXPR
+&& TREE_CODE (TREE_OPERAND (expr, 0)) == TEMPLATE_PARM_INDEX))
 {
   expr = TREE_OPERAND (expr, 0);
   code = TREE_CODE (expr);
diff --git gcc/cp/pt.c gcc/cp/pt.c
index 8560e588593..3b378ee9ff4 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -7123,7 +7123,8 @@ convert_nontype_argument (tree type, tree expr, 
tsubst_flags_t complain)
 {
   /* Replace the argument with a reference to the corresponding template
 parameter object.  */
-  expr = get_template_parm_object (expr, complain);
+  if (!value_dependent_expression_p (expr))
+   expr = get_template_parm_object (expr, complain);
   if (expr == error_mark_node)
return NULL_TREE;
 }
diff --git gcc/testsuite/g++.dg/cpp2a/nontype-class9.C 
gcc/testsuite/g++.dg/cpp2a/nontype-class9.C
new file mode 100644
index 000..737f712be47
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/nontype-class9.C
@@ -0,0 +1,29 @@
+// PR c++/88216
+// { dg-do compile { target c++2a } }
+
+template  struct same;
+template  struct same {};
+
+struct T { };
+
+template 
+struct U { };
+
+template 
+void f (U)
+{
+  same s;
+  same s2;
+}
+
+template
+U u;
+
+T t;
+U u2;
+
+void
+g ()
+{
+  f(u2);
+}

Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support

[Cherry Zhang via gcc-patches]

On Tue, Dec 11, 2018 at 3:51 PM Ian Lance Taylor  wrote:

> On Tue, Dec 11, 2018 at 6:52 AM Matthias Klose  wrote:
> >
> > On 10.12.18 16:54, Cherry Zhang wrote:
> > > On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose 
> wrote:
> > >
> > >> On 06.12.18 00:09, Ian Lance Taylor wrote:
> > >>> This libgo patch by Cherry Zhang adds support for precise stack
> > >>> scanning to the Go runtime.  This uses per-function stack maps stored
> > >>> in the exception tables in the language-specific data area.  The
> > >>> compiler needs to generate these stack maps; currently this is only
> > >>> done by a version of LLVM, not by GCC.  Each safepoint in a function
> > >>> is associated with a (real or dummy) landing pad, and its "type info"
> > >>> in the exception table is a pointer to the stack map. When a stack is
> > >>> scanned, the stack map is found by the stack unwinding code.
> > >>>
> > >>> For precise stack scan we need to unwind the stack. There are three
> > >> cases:
> > >>>
> > >>> - If a goroutine is scanning its own stack, it can unwind the stack
> > >>> and scan the frames.
> > >>>
> > >>> - If a goroutine is scanning another, stopped, goroutine, it cannot
> > >>> directly unwind the target stack. We handle this by switching
> > >>> (runtime.gogo) to the target g, letting it unwind and scan the stack,
> > >>> and switch back.
> > >>>
> > >>> - If we are scanning a goroutine that is blocked in a syscall, we
> send
> > >>> a signal to the target goroutine's thread, and let the signal handler
> > >>> unwind and scan the stack. Extra care is needed as this races with
> > >>> enter/exit syscall.
> > >>>
> > >>> Currently this is only implemented on GNU/Linux.
> > >>>
> > >>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> > >>> to mainline.
> > >>
> > >> this broke the libgo build on ARM32:
> > >>
> > >> ../../../src/libgo/runtime/go-unwind.c: In function
> > >> 'scanstackwithmap_callback':
> > >> ../../../src/libgo/runtime/go-unwind.c:754:18: error:
> '_URC_NORMAL_STOP'
> > >> undeclared (first use in this function)
> > >>   754 |   return _URC_NORMAL_STOP;
> > >>   |  ^~~~
> > >> ../../../src/libgo/runtime/go-unwind.c:754:18: note: each undeclared
> > >> identifier
> > >> is reported only once for each function i
> > >> t appears in
> > >> ../../../src/libgo/runtime/go-unwind.c: In function
> > >> 'probestackmaps_callback':
> > >> ../../../src/libgo/runtime/go-unwind.c:802:10: error:
> '_URC_NORMAL_STOP'
> > >> undeclared (first use in this function)
> > >>   802 |   return _URC_NORMAL_STOP;
> > >>   |  ^~~~
> > >> ../../../src/libgo/runtime/go-unwind.c:803:1: warning: control
> reaches end
> > >> of
> > >> non-void function [-Wreturn-type]
> > >>   803 | }
> > >>   | ^
> > >> make[6]: *** [Makefile:1474: runtime/go-unwind.lo] Error 1
> > >> make[6]: Leaving directory
> > >> '/<>/build/arm-linux-gnueabihf/libgo'
> > >>
> > >>
> > > Hell Matthias,
> > >
> > > Thank you for the report. And sorry about the breakage. Does
> > > https://go-review.googlesource.com/c/gofrontend/+/153417 (or the patch
> > > below) fix ARM32 build? I don't have an ARM32 machine at hand to test.
> >
> > this fixes the build.
> >
> > currently running the testsuite, almost every test case core dumps on
> > arm-linux-gnueabihf
>
> I committed Cherry's patch to trunk, since it looks reasonable to me.
> Cherry, Matthias, let me know if you figure out why programs are
> failing.
>
>
Thank you.

I don't know for the moment. I'm trying to find an ARM32 machine so I can
test.

Matthias, is it convenient for you to share a stack trace for the failing
programs? That would be very helpful. Thanks!

Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support

[Ian Lance Taylor]

On Tue, Dec 11, 2018 at 6:52 AM Matthias Klose  wrote:
>
> On 10.12.18 16:54, Cherry Zhang wrote:
> > On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose  wrote:
> >
> >> On 06.12.18 00:09, Ian Lance Taylor wrote:
> >>> This libgo patch by Cherry Zhang adds support for precise stack
> >>> scanning to the Go runtime.  This uses per-function stack maps stored
> >>> in the exception tables in the language-specific data area.  The
> >>> compiler needs to generate these stack maps; currently this is only
> >>> done by a version of LLVM, not by GCC.  Each safepoint in a function
> >>> is associated with a (real or dummy) landing pad, and its "type info"
> >>> in the exception table is a pointer to the stack map. When a stack is
> >>> scanned, the stack map is found by the stack unwinding code.
> >>>
> >>> For precise stack scan we need to unwind the stack. There are three
> >> cases:
> >>>
> >>> - If a goroutine is scanning its own stack, it can unwind the stack
> >>> and scan the frames.
> >>>
> >>> - If a goroutine is scanning another, stopped, goroutine, it cannot
> >>> directly unwind the target stack. We handle this by switching
> >>> (runtime.gogo) to the target g, letting it unwind and scan the stack,
> >>> and switch back.
> >>>
> >>> - If we are scanning a goroutine that is blocked in a syscall, we send
> >>> a signal to the target goroutine's thread, and let the signal handler
> >>> unwind and scan the stack. Extra care is needed as this races with
> >>> enter/exit syscall.
> >>>
> >>> Currently this is only implemented on GNU/Linux.
> >>>
> >>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> >>> to mainline.
> >>
> >> this broke the libgo build on ARM32:
> >>
> >> ../../../src/libgo/runtime/go-unwind.c: In function
> >> 'scanstackwithmap_callback':
> >> ../../../src/libgo/runtime/go-unwind.c:754:18: error: '_URC_NORMAL_STOP'
> >> undeclared (first use in this function)
> >>   754 |   return _URC_NORMAL_STOP;
> >>   |  ^~~~
> >> ../../../src/libgo/runtime/go-unwind.c:754:18: note: each undeclared
> >> identifier
> >> is reported only once for each function i
> >> t appears in
> >> ../../../src/libgo/runtime/go-unwind.c: In function
> >> 'probestackmaps_callback':
> >> ../../../src/libgo/runtime/go-unwind.c:802:10: error: '_URC_NORMAL_STOP'
> >> undeclared (first use in this function)
> >>   802 |   return _URC_NORMAL_STOP;
> >>   |  ^~~~
> >> ../../../src/libgo/runtime/go-unwind.c:803:1: warning: control reaches end
> >> of
> >> non-void function [-Wreturn-type]
> >>   803 | }
> >>   | ^
> >> make[6]: *** [Makefile:1474: runtime/go-unwind.lo] Error 1
> >> make[6]: Leaving directory
> >> '/<>/build/arm-linux-gnueabihf/libgo'
> >>
> >>
> > Hell Matthias,
> >
> > Thank you for the report. And sorry about the breakage. Does
> > https://go-review.googlesource.com/c/gofrontend/+/153417 (or the patch
> > below) fix ARM32 build? I don't have an ARM32 machine at hand to test.
>
> this fixes the build.
>
> currently running the testsuite, almost every test case core dumps on
> arm-linux-gnueabihf

I committed Cherry's patch to trunk, since it looks reasonable to me.
Cherry, Matthias, let me know if you figure out why programs are
failing.

Ian

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Jakub Jelinek]

On Tue, Dec 11, 2018 at 01:36:58PM -0700, Martin Sebor wrote:
> Attached is an updated version of the patch that restores
> the original behavior for the positional argument validation
> (i.e., prior to r266195) for integral types except bool as
> discussed.

I thought Jason wanted to also warn for scoped enums in C++.

> +  else if (code == INTEGER_TYPE)
> + /* For integers, accept enums, wide characters and other types
> +that match INTEGRAL_TYPE_P except for bool.  */
> + type_match = (INTEGRAL_TYPE_P (argtype)
> +   && TREE_CODE (argtype) != BOOLEAN_TYPE);

So it would better be:
type_match = (TREE_CODE (argtype) == INTEGER_TYPE
  || (TREE_CODE (argtype) == ENUMERAL_TYPE
  && !ENUM_IS_SCOPED (argtype)));

> --- gcc/doc/extend.texi   (revision 266966)
> +++ gcc/doc/extend.texi   (working copy)
> @@ -2471,7 +2471,9 @@ The @code{aligned} attribute can also be used for
>  @item alloc_align (@var{position})
>  @cindex @code{alloc_align} function attribute
>  The @code{alloc_align} attribute may be applied to a function that
> -returns a pointer and takes at least one argument of an integer type.
> +returns a pointer and takes at least one argument of an integer or
> +enumerated type, but not @code{bool}.  Arguments of other types are
> +diagnosed.

The keyword is _Bool in C, so wouldn't it be better to say but not Boolean
type or but not @code{bool} or @code{_Bool}?
And it should mention the scoped enumeration types for C++ too
(+ testsuite coverage for them).

Jakub

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Martin Sebor]

On 12/11/18 12:17 AM, Jakub Jelinek wrote:

On Mon, Dec 10, 2018 at 04:30:11PM -0700, Martin Sebor wrote:

Some of my testing exposed a minor problem in GCC 9's validation
of the type of function parameters referred to by attribute
positional arguments.  Whereas GCC 8 accepts all C integer types,
including enumerated types, such as:

   enum AllocAlign { Align16 = 16, Align32 = 32 };

   __attribute__ ((alloc_align (1))) void*
   alloc (size_t, enum AllocAlign)

GCC 9 only accepts signed and unsigned integer types.  This change
(introduced by myself) was unintentional, and a fix for it is in
the attached trivial patch.  I plan to commit it without approval
in the next day or so unless any concerns or suggestions come up.


Attached is an updated version of the patch that restores
the original behavior for the positional argument validation
(i.e., prior to r266195) for integral types except bool as
discussed.

Martin
Index: gcc/c-family/c-attribs.c
===
--- gcc/c-family/c-attribs.c	(revision 266966)
+++ gcc/c-family/c-attribs.c	(working copy)
@@ -498,10 +498,11 @@ attribute_takes_identifier_p (const_tree attr_id)
 
 /* Verify that argument value POS at position ARGNO to attribute NAME
applied to function TYPE refers to a function parameter at position
-   POS and the expected type CODE.  If so, return POS after default
-   conversions, if any.  Otherwise, issue appropriate warnings and
-   return null.  A non-zero 1-based ARGNO should be passed ib by
-   callers only for attributes with more than one argument.  */
+   POS and the expected type CODE.  Treat CODE == INTEGER_TYPE as
+   matching all C integral types except bool.  If successful, return
+   POS after default conversions, if any.  Otherwise, issue appropriate
+   warnings and return null.  A non-zero 1-based ARGNO should be passed
+   in by callers only for attributes with more than one argument.  */
 
 tree
 positional_argument (const_tree fntype, const_tree atname, tree pos,
@@ -630,11 +631,11 @@ positional_argument (const_tree fntype, const_tree
 	  return NULL_TREE;
 	}
 
-  /* Where the expected code is STRING_CST accept any pointer
-	 to a narrow character type, qualified or otherwise.  */
   bool type_match;
   if (code == STRING_CST && POINTER_TYPE_P (argtype))
 	{
+	  /* Where the expected code is STRING_CST accept any pointer
+	 to a narrow character type, qualified or otherwise.  */
 	  tree type = TREE_TYPE (argtype);
 	  type = TYPE_MAIN_VARIANT (type);
 	  type_match = (type == char_type_node
@@ -641,6 +642,11 @@ positional_argument (const_tree fntype, const_tree
 			|| type == signed_char_type_node
 			|| type == unsigned_char_type_node);
 	}
+  else if (code == INTEGER_TYPE)
+	/* For integers, accept enums, wide characters and other types
+	   that match INTEGRAL_TYPE_P except for bool.  */
+	type_match = (INTEGRAL_TYPE_P (argtype)
+		  && TREE_CODE (argtype) != BOOLEAN_TYPE);
   else
 	type_match = TREE_CODE (argtype) == code;
 
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 266966)
+++ gcc/doc/extend.texi	(working copy)
@@ -2471,7 +2471,9 @@ The @code{aligned} attribute can also be used for
 @item alloc_align (@var{position})
 @cindex @code{alloc_align} function attribute
 The @code{alloc_align} attribute may be applied to a function that
-returns a pointer and takes at least one argument of an integer type.
+returns a pointer and takes at least one argument of an integer or
+enumerated type, but not @code{bool}.  Arguments of other types are
+diagnosed.
 It indicates that the returned pointer is aligned on a boundary given
 by the function argument at @var{position}.  Meaningful alignments are
 powers of 2 greater than one.  GCC uses this information to improve
@@ -2495,7 +2497,9 @@ given by parameter 1.
 @itemx alloc_size (@var{position-1}, @var{position-2})
 @cindex @code{alloc_size} function attribute
 The @code{alloc_size} attribute may be applied to a function that
-returns a pointer and takes at least one argument of an integer type.
+returns a pointer and takes at least one argument of an integer or
+enumerated type, but not @code{bool}.  Arguments of other types are
+diagnosed.
 It indicates that the returned pointer points to memory whose size is
 given by the function argument at @var{position-1}, or by the product
 of the arguments at @var{position-1} and @var{position-2}.  Meaningful
Index: gcc/testsuite/c-c++-common/attributes-4.c
===
--- gcc/testsuite/c-c++-common/attributes-4.c	(nonexistent)
+++ gcc/testsuite/c-c++-common/attributes-4.c	(working copy)
@@ -0,0 +1,47 @@
+/* PR c/88363 - alloc_align attribute doesn't accept enumerated arguments
+   Verify that attribute positional arguments can refer to all C integer
+   types in both C and C++.
+   { dg-do compile }
+   { 

Re: [C++ PATCH] Fix up __builtin_is_constant_evaluated handling in array type sizes (PR c++/88446)

[Marek Polacek]

On Tue, Dec 11, 2018 at 05:39:25PM +0100, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, while we allow VLAs in some contexts in C++ as
> an extension, they aren't standard and the standard requires in those spots
> constant expressions, thus __builtin_is_constant_evaluated () needs to be
> true if those sizes are indeed constant expressions.
> 
> Fixed by calling cxx_eval_outermost_constant_expr with
> pretend_const_required too in that case.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2018-12-11  Jakub Jelinek  
> 
>   PR c++/88446
>   * cp-tree.h (maybe_constant_value): Add pretend_const_required
>   argument.
>   * constexpr.c (maybe_constant_value): Likewise.  If true, don't
>   cache and call cxx_eval_outermost_constant_expr with true as
>   pretend_const_required.
>   * decl.c (compute_array_index_type_loc): Call maybe_constant_value
>   with true as pretend_const_required.
> 
>   * g++.dg/cpp2a/is-constant-evaluated3.C: New test.
> 
> --- gcc/cp/cp-tree.h.jj   2018-12-07 00:23:15.024998595 +0100
> +++ gcc/cp/cp-tree.h  2018-12-11 13:55:51.933845503 +0100
> @@ -7663,7 +7663,7 @@ extern bool require_rvalue_constant_expr
>  extern bool require_potential_rvalue_constant_expression (tree);
>  extern tree cxx_constant_value   (tree, tree = 
> NULL_TREE);
>  extern tree cxx_constant_init(tree, tree = 
> NULL_TREE);
> -extern tree maybe_constant_value (tree, tree = NULL_TREE);
> +extern tree maybe_constant_value (tree, tree = NULL_TREE, bool = 
> false);
>  extern tree maybe_constant_init  (tree, tree = 
> NULL_TREE, bool = false);
>  extern tree fold_non_dependent_expr  (tree, tsubst_flags_t = 
> tf_warning_or_error);
>  extern tree fold_simple  (tree);
> --- gcc/cp/constexpr.c.jj 2018-12-11 12:01:27.968941683 +0100
> +++ gcc/cp/constexpr.c2018-12-11 13:56:50.382890876 +0100
> @@ -5244,7 +5244,7 @@ fold_simple (tree t)
>  static GTY((deletable)) hash_map *cv_cache;
>  
>  tree
> -maybe_constant_value (tree t, tree decl)
> +maybe_constant_value (tree t, tree decl, bool pretend_const_required)
>  {
>tree r;
>  

Could you please describe the new param in the comment?

> --- gcc/cp/decl.c.jj  2018-12-07 00:23:15.0 +0100
> +++ gcc/cp/decl.c 2018-12-11 13:57:30.779231098 +0100
> @@ -9645,7 +9645,10 @@ compute_array_index_type_loc (location_t
>   {
> size = instantiate_non_dependent_expr_sfinae (size, complain);
> size = build_converted_constant_expr (size_type_node, size, complain);
> -   size = maybe_constant_value (size);
> +   /* Pedantically a constant expression is required here and so
> +  __builtin_is_constant_evaluated () should fold to true if it
> +  is successfully folded into a constant.  */
> +   size = maybe_constant_value (size, NULL_TREE, true);

Perhaps use /*pretend_const_required=*/true?

Marek

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Jason Merrill]

On Tue, Dec 11, 2018 at 2:46 PM Martin Sebor  wrote:
> On 12/11/18 11:15 AM, Joseph Myers wrote:
> > On Tue, 11 Dec 2018, Martin Sebor wrote:
> >
> >> I recently brought up the question of the write w/o approval
> >> policy on the gcc list:
> >>
> >>https://gcc.gnu.org/ml/gcc/2018-11/msg00165.html
> >>
> >> looking for clarification.  Except for Jeff's comment (which
> >> I'm afraid didn't really clarify things), didn't get any.
> >
> > I think "will the person who objects to my work the most be able to find a
> > fault with my fix?" in the policy on obviousness is clear enough.  A
> > policy decision on what is or is not part of a language extension can't be
> > obvious, and nor can determining subtle questions of exactly what the
> > definition of some internal interface is or should be.
>
> Anything that someone might find fault with is so broad as to
> remove the ability to make the judgment in any case.  Reviewers
> have been known to find fault with the slightest things, from
> trivial formatting nits, to punctuation in comments, to names
> of variables, to the location of new tests, to ChangeLogs.
>
> If the policy's intent is not to let people make judgment calls
> then it ought to be updated.  I have no proposal for changes to
> it at the moment, but I don't see how anyone can reasonably
> object to someone posting a patch and saying "if there are no
> objections I will go ahead and commit this change because I think
> it's obviously correct."  If even that is against the policy then
> change it to make that clear (though I sincerely hope that isn't
> so).

I don't think anyone objected to your mail, they were just disagreeing
that the patch was obvious.  That is also a judgment call.  IMO
there's no need to have an ironclad policy here, since the
consequences of a particular change being "wrongly" consider either
obvious or non-obvious are small.

Jason

PING Re: [PATCH 2/2] v2: C++: improvements to binary operator diagnostics (PR c++/87504)

[David Malcolm]

Ping re this patch:
  "[PATCH 2/2] v2: C++: improvements to binary operator diagnostics (PR
c++/87504)"
 https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00236.html

(...which is dependent on:
  "[PATCH 1/2] v3: C++: more location wrapper nodes (PR c++/43064, PR
c++/43486)"
 https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00500.html )

Thanks
Dave

On Tue, 2018-12-04 at 17:35 -0500, David Malcolm wrote:
> The v1 patch:
>   https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00303.html
> has bitrotten somewhat, so here's v2 of the patch, updated relative
> to r266740.
> 
> Blurb from v1 patch follows:
> 
> The C frontend is able (where expression locations are available) to
> print
> problems with binary operators in 3-location form, labelling the
> types of
> the expressions:
> 
>   arg_0 op arg_1
>   ~ ^~ ~
> ||
> |arg1 type
> arg0 type
> 
> The C++ frontend currently just shows the combined location:
> 
>   arg_0 op arg_1
>   ~~^~~~
> 
> and fails to highlight where the subexpressions are, or their types.
> 
> This patch introduces a op_location_t struct for handling the above
> operator-location vs combined-location split, and a new
> class binary_op_rich_location for displaying the above, so that the
> C++ frontend is able to use the more detailed 3-location form for
> type mismatches in binary operators, and for -Wtautological-compare
> (where types are not displayed).  Both forms can be seen in this
> example:
> 
> bad-binary-ops.C:69:20: error: no match for 'operator&&' (operand
> types are
>   's' and 't')
>69 |   return ns_4::foo && ns_4::inner::bar;
>   |  ~ ^~ 
>   ||   |
>   |s   t
> bad-binary-ops.C:69:20: note: candidate: 'operator&&(bool, bool)'
> 
>69 |   return ns_4::foo && ns_4::inner::bar;
>   |  ~~^~~
> 
> The patch also allows from some uses of macros in
> -Wtautological-compare, where both sides of the comparison have
> been spelled the same way, e.g.:
> 
> Wtautological-compare-ranges.c:23:11: warning: self-comparison always
>evaluates to true [-Wtautological-compare]
>23 |   if (FOO == FOO);
>   |   ^~
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu, in
> conjunction with the previous patch.
> 
> OK for trunk?
> Dave
> 
> gcc/c-family/ChangeLog:
>   PR c++/87504
>   * c-common.h (warn_tautological_cmp): Convert 1st param from
>   location_t to const op_location_t &.
>   * c-warn.c (find_array_ref_with_const_idx_r): Strip location
>   wrapper when testing for INTEGER_CST.
>   (warn_tautological_bitwise_comparison): Convert 1st param from
>   location_t to const op_location_t &; use it to build a
>   binary_op_rich_location, and use this.
>   (spelled_the_same_p): New function.
>   (warn_tautological_cmp): Convert 1st param from location_t to
>   const op_location_t &.  Warn for macro expansions if
>   spelled_the_same_p.  Use binary_op_rich_location.
> 
> gcc/c/ChangeLog:
>   PR c++/87504
>   * c-typeck.c (class maybe_range_label_for_tree_type_mismatch):
>   Move from here to gcc-rich-location.h and gcc-rich-location.c.
>   (build_binary_op): Use struct op_location_t and
>   class binary_op_rich_location.
> 
> gcc/cp/ChangeLog:
>   PR c++/87504
>   * call.c (op_error): Convert 1st param from location_t to
>   const op_location_t &.  Use binary_op_rich_location for binary
>   ops.
>   (build_conditional_expr_1): Convert 1st param from location_t
> to
>   const op_location_t &.
>   (build_conditional_expr): Likewise.
>   (build_new_op_1): Likewise.
>   (build_new_op): Likewise.
>   * cp-tree.h (build_conditional_expr): Likewise.
>   (build_new_op): Likewise.
>   (build_x_binary_op): Likewise.
>   (cp_build_binary_op): Likewise.
>   * parser.c (cp_parser_primary_expression): Build a location
>   for id-expression nodes.
>   (cp_parser_binary_expression): Use an op_location_t when
>   calling build_x_binary_op.
>   (cp_parser_operator): Build a location for user-defined
> literals.
>   * typeck.c (build_x_binary_op): Convert 1st param from
> location_t
>   to const op_location_t &.
>   (cp_build_binary_op): Likewise.  Use binary_op_rich_location.
> 
> gcc/ChangeLog:
>   PR c++/87504
>   * gcc-rich-location.c
>   (maybe_range_label_for_tree_type_mismatch::get_text): Move here
> from
>   c/c-typeck.c.
>   (binary_op_rich_location::binary_op_rich_location): New ctor.
>   (binary_op_rich_location::use_operator_loc_p): New function.
>   * gcc-rich-location.h
>   (class maybe_range_label_for_tree_type_mismatch)): Move here
> from
>   c/c-typeck.c.
>   (struct op_location_t): New forward decl.
>   (class binary_op_rich_location): New class.
>   * tree.h (struct 

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Martin Sebor]

On 12/11/18 11:15 AM, Joseph Myers wrote:

On Tue, 11 Dec 2018, Martin Sebor wrote:


I recently brought up the question of the write w/o approval
policy on the gcc list:

   https://gcc.gnu.org/ml/gcc/2018-11/msg00165.html

looking for clarification.  Except for Jeff's comment (which
I'm afraid didn't really clarify things), didn't get any.


I think "will the person who objects to my work the most be able to find a
fault with my fix?" in the policy on obviousness is clear enough.  A
policy decision on what is or is not part of a language extension can't be
obvious, and nor can determining subtle questions of exactly what the
definition of some internal interface is or should be.


Anything that someone might find fault with is so broad as to
remove the ability to make the judgment in any case.  Reviewers
have been known to find fault with the slightest things, from
trivial formatting nits, to punctuation in comments, to names
of variables, to the location of new tests, to ChangeLogs.

If the policy's intent is not to let people make judgment calls
then it ought to be updated.  I have no proposal for changes to
it at the moment, but I don't see how anyone can reasonably
object to someone posting a patch and saying "if there are no
objections I will go ahead and commit this change because I think
it's obviously correct."  If even that is against the policy then
change it to make that clear (though I sincerely hope that isn't
so).

Martin

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Martin Sebor]

On 12/11/18 11:15 AM, Marek Polacek wrote:

On Tue, Dec 11, 2018 at 09:59:27AM -0700, Martin Sebor wrote:

[*] The change in the patch is obvious enough to me.  All it
does is accept more of the things that are accepted by GCC 8
(enums, bools, wchar_t, etc.) and that inadvertently started
to be rejected as a result of my prior change.   That the rules
can be made more restrictive is something different.
  
Obvious changes should be obvious to anyone, not just the committer, IMHO.  I
don't think we should make the rules more restrictive; 


I was referring to the rules of what expression the compiler accepts
as positional parameters.


what we have in place
seems to have worked fine and I would have thought it's clear that changing
what the compiler accepts will never be an obvious change, unlike, say, fixing
a test that fails with -m32 because it uses 'unsigned long' instead of size_t.


If that's the intent it should be stated in the policy then.  Seems
simple enough:

  Obvious fixes that have no impact on constructs accepted
  or rejected by the compiler can be committed without
  prior approval.

I have no problem with this clarification.  I just wouldn't have
thought it to apply to restoring previous behavior that I myself
had inadvertently removed (i.e., fixing my own regression).


I recently brought up the question of the write w/o approval
policy on the gcc list:

   https://gcc.gnu.org/ml/gcc/2018-11/msg00165.html

looking for clarification.  Except for Jeff's comment (which
I'm afraid didn't really clarify things), didn't get any.

You (the maintainers) have put it in place.  If you don't intend
for the rest of us to make use of it, or if it's not meant to be
interpreted to give us the freedom to decide what is or isn't
obvious, then change it. But it's disingenuous to claim that "We
don't want to get overly restrictive about checkin policies" and
then chastise people each time they say they might check something
in on their own.


...or fixing typos in comments and formatting fixes should be obvious, adding
new tests for fixed bugs likely as well, but outlining semantics in a comment
doesn't strike me as obvious at all.  "When in doubt, ask for a review."


I was not in doubt, but I posted the patch for review just
the same, didn't I?

If by "outlining semantics in a comment" you are referring to
the patch mentioned in the other thread then if such changes are
also not meant to fall under obvious then again, update the policy:

  Obvious fixes that have no impact on constructs accepted
  or rejected by the compiler and that do not outline the semantics
  of GCC internals in comments can be committed without prior
  approval.

In both of these cases I posted the patch and invited feedback
to make sure that was seemed clearly correct to me wouldn't be
viewed differently by others.  That still seems perfectly
appropriate to me.  But if even that isn't acceptable then update
the policy to make it clear that posting a patch and saying that
you'll commit it if no one objects is also against the rules.

Martin

Re: [PATCH] Fix up split-path-11.c testcase (Re: [committed] [PR tree-optimization/80520] Throttle path splitting slightly.)

[Jeff Law]

On 12/11/18 10:15 AM, Jakub Jelinek wrote:
> On Mon, Dec 10, 2018 at 09:56:46PM -0700, Jeff Law wrote:
>> commit d90b13427e4940adabc4320c68ca88513dee2eef
>> Author: Jeff Law 
>> Date:   Mon Dec 10 21:46:41 2018 -0700
>>
>> PR tree-optimization/80520
>> * gimple-ssa-split-paths.c (is_feasible_trace): Recognize half
>> diamonds that are likely if convertable.
>> 
>> * gcc.dg/tree-ssa/split-path-5.c: Update expected output.
>> * gcc.dg/tree-ssa/split-path-11.c: New test.
>>
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/split-path-11.c
>> @@ -0,0 +1,14 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -fsplit-paths -fdump-tree-split-paths-details -w" } */
>> +
>> +void foo(unsigned long *M)
>> +{
>> +  for (unsigned long k = 0; k < 227; ++k)
>> +{
>> +  unsigned long y =
>> +((M[k] & 0x8000) | (M[k + 1] & 0x7fff));
>> +  M[k] = (M[k + 397] ^ (y >> 1) ^ ((y & 1) ? 2567483615 : 0));
>> +}
>> +}
>> +
>> +/* { dg-final { scan-tree-dump-times "join point for if-convertable 
>> half-diamond" 1 "split-paths" } } */
> 
> This testcase fails on ILP32 targets like i?86-linux*.
> 
> Fixed thusly, ok for trunk?
> 
> 2018-12-11  Jakub Jelinek  
> 
>   PR tree-optimization/80520
>   * gcc.dg/tree-ssa/split-path-11.c (foo): Make the test ilp32 target
>   clean.
Yes.  Sorry for the testing noise.
jeff

Re: [C++ PATCH] PR c++/87051

[Marek Polacek]

On Thu, Sep 13, 2018 at 08:58:34PM +0300, Ville Voutilainen wrote:
> On 13 September 2018 at 20:41, Jason Merrill  wrote:
> >> Okay. Do you think we should have an sfk_kind for non-canonical
> >> copy/move operations? That would presumably make it a tad more 
> >> straightforward to go from
> >> fndecl to whatever class bits, instead of what's currently there, where we 
> >> say "yeah I had a fndecl,
> >> now I turned it into an sfk_kind that says it's a copy constructor, but 
> >> guess which one when you're
> >> deeming its triviality". ;)
> >
> > I suppose it would be possible to have a more detailed sfk_kind for
> > distinguishing between different signatures, but I'm inclined instead
> > to stop using sfk_kind in trivial_fn_p.  Even if having an enumeration
> > is convenient for dispatch (or bitmapping), it doesn't need to be the
> > same enum.
> 
> Yeah, the idea of using a different enum dawned on me straight after
> sending that email. ;)
> I'll give this approach a spin, more bits into the lang_type and a
> different mapping, that way we should indeed
> get correct answers for all cases.

Hi Ville, any updates?

Marek

Re: [C++ PATCH] FIx constexpr virtual function call handling on ia64 (PR c++/87861)

[Jason Merrill]

On 12/8/18 4:07 AM, Jakub Jelinek wrote:

On Thu, Sep 27, 2018 at 01:15:46AM -0400, Jason Merrill wrote:

/usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:33:26:
 error: non-constant condition for static assertion
/usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:33:23: 
error: expression '((& X2::_ZTV2X2) + 16)' does not designate a 'constexpr' 
function
/usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:37:27:
 error: non-constant condition for static assertion
/usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:37:24: 
error: expression '((& X2::_ZTV2X2) + 16)' does not designate a 'constexpr' 
function
/usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:41:26:
 error: non-constant condition for static assertion
/usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:41:23: 
error: expression '((& X4::_ZTV2X4) + 16)' does not designate a 'constexpr' 
function
/usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:45:26:
 error: non-constant condition for static assertion
/usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:45:23: 
error: expression '((& X4::_ZTV2X4) + 16)' does not designate a 'constexpr' 
function
/usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:49:27:
 error: non-constant condition for static assertion
/usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:49:24: 
error: expression '((& X4::_ZTV2X4) + 16)' does not designate a 'constexpr' 
function
compiler exited with status 1
FAIL: g++.dg/cpp2a/constexpr-virtual2.C   (test for excess errors)


I think the primary problem here is:
   /* When using function descriptors, the address of the
  vtable entry is treated as a function pointer.  */
   if (TARGET_VTABLE_USES_DESCRIPTORS)
 e2 = build1 (NOP_EXPR, TREE_TYPE (e2),
  cp_build_addr_expr (e2, complain));
in typeck.c, on non-descriptor targets we have an INDIRECT_REF where we
read the vtable function pointer.  On ia64, the above optimizes the
INDIRECT_REF away, so what the cxx_eval_call_expression actually gets
after constexpr evaluating the CALL_FN is not ADDR_EXPR of a function,
but the address of the function descriptor (e.g. &_ZTV2X2 + 16 ).

So, perhaps in cxx_eval_call_expression we need:
if (TREE_CODE (fun) == ADDR_EXPR)
 fun = TREE_OPERAND (fun, 0);
+  else if (TARGET_VTABLE_USES_DESCRIPTORS
+  && TREE_CODE (fun) == POINTER_PLUS_EXPR
+  && ...)
where we verify that p+ first argument is ADDR_EXPR of a virtual table,
second arg is INTEGER_CST and just walk the DECL_INITIAL of that, finding
the FDESC_EXPR at the right offset (therefore, I believe you need following
rather than the patch you've posted, so that you can actually find it) and
finally pick the function from the FDESC_EXPR entry.
Makes me wonder what happens with indirect calls in constexpr evaluation,
e.g. if I do:
constexpr int bar () { return 42; }
constexpr int foo () { int (*fn) () = bar; return fn (); }
static_assert (foo () == 42);
but apparently this works.

--- gcc/cp/class.c.jj   2018-09-20 09:56:59.229751895 +0200
+++ gcc/cp/class.c  2018-09-20 10:12:17.447370890 +0200
@@ -9266,7 +9266,6 @@ build_vtbl_initializer (tree binfo,
tree vcall_index;
tree fn, fn_original;
tree init = NULL_TREE;
-  tree idx = size_int (jx++);

fn = BV_FN (v);
fn_original = fn;
@@ -9370,7 +9369,7 @@ build_vtbl_initializer (tree binfo,
   int i;
   if (init == size_zero_node)
 for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
- CONSTRUCTOR_APPEND_ELT (*inits, idx, init);
+ CONSTRUCTOR_APPEND_ELT (*inits, size_int (jx++), init);
   else
 for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i)
   {
@@ -9378,11 +9377,11 @@ build_vtbl_initializer (tree binfo,
  fn, build_int_cst (NULL_TREE, i));
 TREE_CONSTANT (fdesc) = 1;

-   CONSTRUCTOR_APPEND_ELT (*inits, idx, fdesc);
+   CONSTRUCTOR_APPEND_ELT (*inits, size_int (jx++), fdesc);
   }
 }
else
-   CONSTRUCTOR_APPEND_ELT (*inits, idx, init);
+   CONSTRUCTOR_APPEND_ELT (*inits, size_int (jx++), init);
  }
  }


This patch is OK.  And your suggestion for cxx_eval_call_expression
sounds right, too.  Marek, will you follow up on that?


Here is the full patch.  Besides the above already posted hunks and
proposed cxx_eval_call_expression changes I had to also divide token
in the OBJ_TYPE_REF handling by TARGET_VTABLE_USES_DESCRIPTORS, because
DECL_VINDEX of the second virtual table function is there 2 and of the third
4 etc.

Tested with a cross to ia64-linux on all the constexpr-virtual*.C testcases,
Jeff tested it on 

Re: C++ PATCH for c++/86608, reading constexpr volatile variable

[Jason Merrill]

OK.
On Tue, Dec 11, 2018 at 1:35 PM Marek Polacek  wrote:
>
> On Tue, Dec 11, 2018 at 10:26:00AM -0500, Jason Merrill wrote:
> > On 12/10/18 8:48 PM, Marek Polacek wrote:
> > > A template-argument for a non-type template-parameter shall be a converted
> > > constant expression.  But an lvalue-to-rvalue conversion applied to a 
> > > volatile
> > > glvalue is not allowed to be part of the evaluation of a constant 
> > > expression.
> > > So this test should be rejected.
> >
> > It occurred to me after my note on IRC that the
> > potential_constant_expression_1 test we were talking about,
> >
> >   if (TREE_THIS_VOLATILE (t) && !DECL_P (t))
> >
> > ought to test want_rval rather than !DECL_P so that we consistently reject
> > the lvalue-to-rvalue conversion, and not other uses of a volatile lvalue.
> > And the diagnostic ought to talk about that rather than "side-effects".
>
> Done.
>
> > It might still be appropriate to change non_const_var_error, but I'd think
> > it could check TREE_THIS_VOLATILE itself, rather than the caller; I don't
> > see a need for the two calls to differ in their handling of volatile
> > variables.
>
> This change was no longer needed...
>
> > Perhaps decl_maybe_constant_var_p should return false for constexpr
> > volatile, as well.
>
> ...neither was this but I did it all the same because I think it's reasonable.
>
> Like I said, not planning to backport it, but I could be easily convinced.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-12-11  Marek Polacek  
>
> PR c++/86608 - reading constexpr volatile variable.
> * constexpr.c (potential_constant_expression_1): Check want_rval
> instead of checking if we have a decl.
> * decl2.c (decl_maybe_constant_var_p): Don't consider volatile
> constexpr variables as maybe constant.
>
> * g++.dg/cpp0x/constexpr-volatile2.C: New test.
> * g++.dg/cpp0x/pr65327.C: Add dg-error.
>
> diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
> index 1c844a8c2ef..44db38029bf 100644
> --- gcc/cp/constexpr.c
> +++ gcc/cp/constexpr.c
> @@ -5476,10 +5476,11 @@ potential_constant_expression_1 (tree t, bool 
> want_rval, bool strict, bool now,
> available, so we don't bother with switch tracking.  */
>  return true;
>
> -  if (TREE_THIS_VOLATILE (t) && !DECL_P (t))
> +  if (TREE_THIS_VOLATILE (t) && want_rval)
>  {
>if (flags & tf_error)
> -error_at (loc, "expression %qE has side-effects", t);
> +   error_at (loc, "lvalue-to-rvalue conversion of a volatile lvalue "
> + "%qE with type %qT", t, TREE_TYPE (t));
>return false;
>  }
>if (CONSTANT_CLASS_P (t))
> diff --git gcc/cp/decl2.c gcc/cp/decl2.c
> index a8bf28a0cd9..1b3e758b625 100644
> --- gcc/cp/decl2.c
> +++ gcc/cp/decl2.c
> @@ -4313,7 +4313,7 @@ decl_maybe_constant_var_p (tree decl)
>tree type = TREE_TYPE (decl);
>if (!VAR_P (decl))
>  return false;
> -  if (DECL_DECLARED_CONSTEXPR_P (decl))
> +  if (DECL_DECLARED_CONSTEXPR_P (decl) && !TREE_THIS_VOLATILE (decl))
>  return true;
>if (DECL_HAS_VALUE_EXPR_P (decl))
>  /* A proxy isn't constant.  */
> diff --git gcc/testsuite/g++.dg/cpp0x/constexpr-volatile2.C 
> gcc/testsuite/g++.dg/cpp0x/constexpr-volatile2.C
> new file mode 100644
> index 000..0def8d73731
> --- /dev/null
> +++ gcc/testsuite/g++.dg/cpp0x/constexpr-volatile2.C
> @@ -0,0 +1,13 @@
> +// PR c++/86608
> +// { dg-do compile { target c++11 } }
> +
> +template struct X {};
> +
> +int
> +main ()
> +{
> +  static constexpr volatile int a = 3;
> +  constexpr volatile int b = 2;
> +  return (sizeof(X) // { dg-error "lvalue-to-rvalue 
> conversion of a volatile lvalue" }
> + + sizeof(X)); // { dg-error "lvalue-to-rvalue 
> conversion of a volatile lvalue" }
> +}
> diff --git gcc/testsuite/g++.dg/cpp0x/pr65327.C 
> gcc/testsuite/g++.dg/cpp0x/pr65327.C
> index c6cefaba692..5176b3c3204 100644
> --- gcc/testsuite/g++.dg/cpp0x/pr65327.C
> +++ gcc/testsuite/g++.dg/cpp0x/pr65327.C
> @@ -15,4 +15,4 @@ constexpr volatile int
>  bar ()
>  {
>return i;
> -}
> +} // { dg-error "lvalue-to-rvalue conversion of a volatile lvalue" }

Re: C++ PATCH for c++/86608, reading constexpr volatile variable

[Marek Polacek]

On Tue, Dec 11, 2018 at 10:26:00AM -0500, Jason Merrill wrote:
> On 12/10/18 8:48 PM, Marek Polacek wrote:
> > A template-argument for a non-type template-parameter shall be a converted
> > constant expression.  But an lvalue-to-rvalue conversion applied to a 
> > volatile
> > glvalue is not allowed to be part of the evaluation of a constant 
> > expression.
> > So this test should be rejected.
> 
> It occurred to me after my note on IRC that the
> potential_constant_expression_1 test we were talking about,
> 
>   if (TREE_THIS_VOLATILE (t) && !DECL_P (t))
> 
> ought to test want_rval rather than !DECL_P so that we consistently reject
> the lvalue-to-rvalue conversion, and not other uses of a volatile lvalue.
> And the diagnostic ought to talk about that rather than "side-effects".

Done.

> It might still be appropriate to change non_const_var_error, but I'd think
> it could check TREE_THIS_VOLATILE itself, rather than the caller; I don't
> see a need for the two calls to differ in their handling of volatile
> variables.

This change was no longer needed...

> Perhaps decl_maybe_constant_var_p should return false for constexpr
> volatile, as well.

...neither was this but I did it all the same because I think it's reasonable.

Like I said, not planning to backport it, but I could be easily convinced.

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

2018-12-11  Marek Polacek  

PR c++/86608 - reading constexpr volatile variable.
* constexpr.c (potential_constant_expression_1): Check want_rval
instead of checking if we have a decl.
* decl2.c (decl_maybe_constant_var_p): Don't consider volatile
constexpr variables as maybe constant.

* g++.dg/cpp0x/constexpr-volatile2.C: New test.
* g++.dg/cpp0x/pr65327.C: Add dg-error.

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 1c844a8c2ef..44db38029bf 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -5476,10 +5476,11 @@ potential_constant_expression_1 (tree t, bool 
want_rval, bool strict, bool now,
available, so we don't bother with switch tracking.  */
 return true;
 
-  if (TREE_THIS_VOLATILE (t) && !DECL_P (t))
+  if (TREE_THIS_VOLATILE (t) && want_rval)
 {
   if (flags & tf_error)
-error_at (loc, "expression %qE has side-effects", t);
+   error_at (loc, "lvalue-to-rvalue conversion of a volatile lvalue "
+ "%qE with type %qT", t, TREE_TYPE (t));
   return false;
 }
   if (CONSTANT_CLASS_P (t))
diff --git gcc/cp/decl2.c gcc/cp/decl2.c
index a8bf28a0cd9..1b3e758b625 100644
--- gcc/cp/decl2.c
+++ gcc/cp/decl2.c
@@ -4313,7 +4313,7 @@ decl_maybe_constant_var_p (tree decl)
   tree type = TREE_TYPE (decl);
   if (!VAR_P (decl))
 return false;
-  if (DECL_DECLARED_CONSTEXPR_P (decl))
+  if (DECL_DECLARED_CONSTEXPR_P (decl) && !TREE_THIS_VOLATILE (decl))
 return true;
   if (DECL_HAS_VALUE_EXPR_P (decl))
 /* A proxy isn't constant.  */
diff --git gcc/testsuite/g++.dg/cpp0x/constexpr-volatile2.C 
gcc/testsuite/g++.dg/cpp0x/constexpr-volatile2.C
new file mode 100644
index 000..0def8d73731
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-volatile2.C
@@ -0,0 +1,13 @@
+// PR c++/86608
+// { dg-do compile { target c++11 } }
+
+template struct X {};
+
+int
+main ()
+{
+  static constexpr volatile int a = 3;
+  constexpr volatile int b = 2;
+  return (sizeof(X) // { dg-error "lvalue-to-rvalue conversion 
of a volatile lvalue" }
+ + sizeof(X)); // { dg-error "lvalue-to-rvalue 
conversion of a volatile lvalue" }
+}
diff --git gcc/testsuite/g++.dg/cpp0x/pr65327.C 
gcc/testsuite/g++.dg/cpp0x/pr65327.C
index c6cefaba692..5176b3c3204 100644
--- gcc/testsuite/g++.dg/cpp0x/pr65327.C
+++ gcc/testsuite/g++.dg/cpp0x/pr65327.C
@@ -15,4 +15,4 @@ constexpr volatile int
 bar ()
 {
   return i;
-}
+} // { dg-error "lvalue-to-rvalue conversion of a volatile lvalue" }

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Joseph Myers]

On Tue, 11 Dec 2018, Martin Sebor wrote:

> I recently brought up the question of the write w/o approval
> policy on the gcc list:
> 
>   https://gcc.gnu.org/ml/gcc/2018-11/msg00165.html
> 
> looking for clarification.  Except for Jeff's comment (which
> I'm afraid didn't really clarify things), didn't get any.

I think "will the person who objects to my work the most be able to find a 
fault with my fix?" in the policy on obviousness is clear enough.  A 
policy decision on what is or is not part of a language extension can't be 
obvious, and nor can determining subtle questions of exactly what the 
definition of some internal interface is or should be.

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

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Marek Polacek]

On Tue, Dec 11, 2018 at 09:59:27AM -0700, Martin Sebor wrote:
> [*] The change in the patch is obvious enough to me.  All it
> does is accept more of the things that are accepted by GCC 8
> (enums, bools, wchar_t, etc.) and that inadvertently started
> to be rejected as a result of my prior change.   That the rules
> can be made more restrictive is something different.
 
Obvious changes should be obvious to anyone, not just the committer, IMHO.  I
don't think we should make the rules more restrictive; what we have in place
seems to have worked fine and I would have thought it's clear that changing
what the compiler accepts will never be an obvious change, unlike, say, fixing
a test that fails with -m32 because it uses 'unsigned long' instead of size_t.

> I recently brought up the question of the write w/o approval
> policy on the gcc list:
> 
>   https://gcc.gnu.org/ml/gcc/2018-11/msg00165.html
> 
> looking for clarification.  Except for Jeff's comment (which
> I'm afraid didn't really clarify things), didn't get any.
> 
> You (the maintainers) have put it in place.  If you don't intend
> for the rest of us to make use of it, or if it's not meant to be
> interpreted to give us the freedom to decide what is or isn't
> obvious, then change it. But it's disingenuous to claim that "We
> don't want to get overly restrictive about checkin policies" and
> then chastise people each time they say they might check something
> in on their own.

...or fixing typos in comments and formatting fixes should be obvious, adding
new tests for fixed bugs likely as well, but outlining semantics in a comment
doesn't strike me as obvious at all.  "When in doubt, ask for a review."

Marek

Re: [PATCH][libbacktrace] Add allocfail.sh test-case

[Ian Lance Taylor via gcc-patches]

On Wed, Nov 28, 2018 at 4:50 AM Tom de Vries  wrote:
>
> Add test-case that forces alloc.c functions to fail, and check whether fail
> handling is robust.
>
> This is the test-case for "[libbacktrace] Fix segfault upon allocation
> failure".  Without that patch, this test-case fails like this:
> ...
> allocfail.sh: line 71: 26041 Segmentation fault  (core dumped) \
>   ./allocfail $i > /dev/null 2>&1
> Unallowed fail found: 13
> FAIL allocfail.sh (exit status: 1)
> ...
>
> This is a seperate patch because the test-case is nontrivial.
>
> Bootstrapped and reg-tested on x86_64.
>
> OK for trunk?
>
> Thanks,
> - Tom
>
> [libbacktrace] Add allocfail.sh test-case
>
> 2018-11-27  Tom de Vries  
>
> * Makefile.am (TESTS): Add allocfail.sh.
> (check_PROGRAMS): Add allocfail.
> * Makefile.in: Regenerate.
> * instrumented_alloc.c: New file.  Redefine malloc and realloc.
> Include alloc.c.
> * allocfail.c: New file.
> * allocfail.sh: New file.

Can you redo this without using GNU make features like $(filter-out) ?

Ian

Re: [PATCH 2/4] c/c++, asm: Use nicer error for duplicate asm qualifiers

[Martin Sebor]

+   {
+ error_at (loc, "duplicate asm qualifier %qE", token->value);


We have been making an effort to quote keywords, identifiers,
option names, and other such things in diagnostics.  In
the message above and all others like it in this patch kit
that mention "asm" the keyword should be quoted the same
way as the name of the qualifier.

Thanks
Martin

[PATCH] Fix up split-path-11.c testcase (Re: [committed] [PR tree-optimization/80520] Throttle path splitting slightly.)

[Jakub Jelinek]

On Mon, Dec 10, 2018 at 09:56:46PM -0700, Jeff Law wrote:
> commit d90b13427e4940adabc4320c68ca88513dee2eef
> Author: Jeff Law 
> Date:   Mon Dec 10 21:46:41 2018 -0700
> 
> PR tree-optimization/80520
> * gimple-ssa-split-paths.c (is_feasible_trace): Recognize half
> diamonds that are likely if convertable.
> 
> * gcc.dg/tree-ssa/split-path-5.c: Update expected output.
> * gcc.dg/tree-ssa/split-path-11.c: New test.
> 
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/split-path-11.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fsplit-paths -fdump-tree-split-paths-details -w" } */
> +
> +void foo(unsigned long *M)
> +{
> +  for (unsigned long k = 0; k < 227; ++k)
> +{
> +  unsigned long y =
> + ((M[k] & 0x8000) | (M[k + 1] & 0x7fff));
> +  M[k] = (M[k + 397] ^ (y >> 1) ^ ((y & 1) ? 2567483615 : 0));
> +}
> +}
> +
> +/* { dg-final { scan-tree-dump-times "join point for if-convertable 
> half-diamond" 1 "split-paths" } } */

This testcase fails on ILP32 targets like i?86-linux*.

Fixed thusly, ok for trunk?

2018-12-11  Jakub Jelinek  

PR tree-optimization/80520
* gcc.dg/tree-ssa/split-path-11.c (foo): Make the test ilp32 target
clean.

--- gcc/testsuite/gcc.dg/tree-ssa/split-path-11.c.jj2018-12-11 
11:02:09.009065808 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/split-path-11.c   2018-12-11 
18:10:33.811169259 +0100
@@ -1,13 +1,13 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fsplit-paths -fdump-tree-split-paths-details -w" } */
 
-void foo(unsigned long *M)
+void foo(unsigned long long *M)
 {
-  for (unsigned long k = 0; k < 227; ++k)
+  for (unsigned long long k = 0; k < 227; ++k)
 {
-  unsigned long y =
-   ((M[k] & 0x8000) | (M[k + 1] & 0x7fff));
-  M[k] = (M[k + 397] ^ (y >> 1) ^ ((y & 1) ? 2567483615 : 0));
+  unsigned long long y =
+   ((M[k] & 0x8000ULL) | (M[k + 1] & 0x7fffULL));
+  M[k] = (M[k + 397] ^ (y >> 1) ^ ((y & 1) ? 2567483615ULL : 0));
 }
 }
 


Jakub

Re: [PATCH] Add std::is_constant_evaluated wrapper around __builtin_is_constant_evaluated

[Jonathan Wakely]

On 11/12/18 17:35 +0100, Jakub Jelinek wrote:

Hi!

The following patch adds std::is_constant_evaluated to the library.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
(relies on the previously posted C++ FE patch).

2018-12-11  Jakub Jelinek  

P0595R2 - is_constant_evaluated
* include/bits/c++config (_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED):
Define if __builtin_is_constant_evaluated is available.
* include/std/type_traits (std::is_constant_evaluated): New constexpr
inline function.
* testsuite/20_util/is_constant_evaluated/1.cc: New test.
* testsuite/20_util/is_constant_evaluated/noexcept.cc: New test.


OK, thanks.

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Martin Sebor]

On 12/11/18 12:17 AM, Jakub Jelinek wrote:

On Mon, Dec 10, 2018 at 04:30:11PM -0700, Martin Sebor wrote:

Some of my testing exposed a minor problem in GCC 9's validation
of the type of function parameters referred to by attribute
positional arguments.  Whereas GCC 8 accepts all C integer types,
including enumerated types, such as:

   enum AllocAlign { Align16 = 16, Align32 = 32 };

   __attribute__ ((alloc_align (1))) void*
   alloc (size_t, enum AllocAlign)

GCC 9 only accepts signed and unsigned integer types.  This change
(introduced by myself) was unintentional, and a fix for it is in
the attached trivial patch.  I plan to commit it without approval
in the next day or so unless any concerns or suggestions come up.


There is nothing obvious about this, so please don't commit it without
approval.


See (*) below.


GCC 8 and older used to accept
even float or void * or struct arguments and just ignored them.
I think we need to discuss what types we want to allow without warnings and
what we should warn.


Silently accepting invalid arguments like void* or structs and
proceeding to ignore them is in my view a bug.  Clang diagnoses
both and that seems like the appropriate choice, so that's what
I implemented in r266195 back in November.  This patch doesn't
change that; rather, it accepts more of the things that were
accepted previously and that r266195 unintentionally rejected:
bool, enums, and wide characters.  I welcome feedback on this
decision which is why I posted the patch here before checking
it in.


As I wrote in the PR, I believe e.g. using alloc_align/alloc_size with
bool/_Bool is just a clear bug, you can store 0 or 1 in there, but e.g.
alignment 0 doesn't make sense.


I'm fine with being more restrictive and rejecting bool.  Clang
accepts it but I agree that it's far more likely a bug in user
code (and an oversight in Clang).


Enums are on the border line, I'll defer to C/C++ maintainers whether we
want to include that or not.


From Jason's and Marek's responses it sounds like accepting enums
here is appropriate.  (Clang also accepts them.)  I will go ahead
and make the change for bool alone then.



Jakub



[*] The change in the patch is obvious enough to me.  All it
does is accept more of the things that are accepted by GCC 8
(enums, bools, wchar_t, etc.) and that inadvertently started
to be rejected as a result of my prior change.   That the rules
can be made more restrictive is something different.

I recently brought up the question of the write w/o approval
policy on the gcc list:

  https://gcc.gnu.org/ml/gcc/2018-11/msg00165.html

looking for clarification.  Except for Jeff's comment (which
I'm afraid didn't really clarify things), didn't get any.

You (the maintainers) have put it in place.  If you don't intend
for the rest of us to make use of it, or if it's not meant to be
interpreted to give us the freedom to decide what is or isn't
obvious, then change it. But it's disingenuous to claim that "We
don't want to get overly restrictive about checkin policies" and
then chastise people each time they say they might check something
in on their own.

[PATCH] Fix cleanup_auto_inc_dec on x86 (PR rtl-optimization/88416)

[Jakub Jelinek]

Hi!

As mentioned in the PR, x86 (maybe a couple of other targets) isn't an
AUTO_INC_DEC target, it doesn't have REG_INC notes nor wants the generic
code to synthetize any pre/post inc/dec/modify, but does support push/pop
patterns that use those RTL codes.

If unlucky enough, as on the following testcase, we can end up with trying
to propagate such pre/post inc/dec into a DEBUG_INSN, which is invalid.

As cleanup_auto_inc_dec calls copy_rtx which is pretty much the same
function as cleanup_auto_inc_dec in the way how it performs deep copy of the
RTX, except that cleanup_auto_inc_dec also handles the pre/post
inc/dec/modify, I think the easiest fix is just to remove the special case,
it shouldn't make it any slower on !AUTO_INC_DEC targets.

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

2018-12-11  Jakub Jelinek  

PR rtl-optimization/88416
* valtrack.c (cleanup_auto_inc_dec): Handle pre/post-inc/dec/modify
even if !AUTO_INC_DEC.

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

--- gcc/valtrack.c.jj   2018-01-04 00:43:16.100702765 +0100
+++ gcc/valtrack.c  2018-12-11 15:39:05.746898166 +0100
@@ -56,8 +56,6 @@ static rtx
 cleanup_auto_inc_dec (rtx src, machine_mode mem_mode ATTRIBUTE_UNUSED)
 {
   rtx x = src;
-  if (!AUTO_INC_DEC)
-return copy_rtx (x);
 
   const RTX_CODE code = GET_CODE (x);
   int i;
--- gcc/testsuite/gcc.target/i386/pr88416.c.jj  2018-12-11 15:41:44.552308649 
+0100
+++ gcc/testsuite/gcc.target/i386/pr88416.c 2018-12-11 15:41:36.977432165 
+0100
@@ -0,0 +1,5 @@
+/* PR rtl-optimization/88416 */
+/* { dg-do compile } */
+/* { dg-options "-O1 -fvar-tracking-assignments -fno-forward-propagate --param 
max-cse-insns=1" } */
+
+#include "writeeflags-1.c"

Jakub

[C++ PATCH] Fix up __builtin_is_constant_evaluated handling in array type sizes (PR c++/88446)

[Jakub Jelinek]

Hi!

As mentioned in the PR, while we allow VLAs in some contexts in C++ as
an extension, they aren't standard and the standard requires in those spots
constant expressions, thus __builtin_is_constant_evaluated () needs to be
true if those sizes are indeed constant expressions.

Fixed by calling cxx_eval_outermost_constant_expr with
pretend_const_required too in that case.

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

2018-12-11  Jakub Jelinek  

PR c++/88446
* cp-tree.h (maybe_constant_value): Add pretend_const_required
argument.
* constexpr.c (maybe_constant_value): Likewise.  If true, don't
cache and call cxx_eval_outermost_constant_expr with true as
pretend_const_required.
* decl.c (compute_array_index_type_loc): Call maybe_constant_value
with true as pretend_const_required.

* g++.dg/cpp2a/is-constant-evaluated3.C: New test.

--- gcc/cp/cp-tree.h.jj 2018-12-07 00:23:15.024998595 +0100
+++ gcc/cp/cp-tree.h2018-12-11 13:55:51.933845503 +0100
@@ -7663,7 +7663,7 @@ extern bool require_rvalue_constant_expr
 extern bool require_potential_rvalue_constant_expression (tree);
 extern tree cxx_constant_value (tree, tree = NULL_TREE);
 extern tree cxx_constant_init  (tree, tree = NULL_TREE);
-extern tree maybe_constant_value   (tree, tree = NULL_TREE);
+extern tree maybe_constant_value   (tree, tree = NULL_TREE, bool = 
false);
 extern tree maybe_constant_init(tree, tree = 
NULL_TREE, bool = false);
 extern tree fold_non_dependent_expr(tree, tsubst_flags_t = 
tf_warning_or_error);
 extern tree fold_simple(tree);
--- gcc/cp/constexpr.c.jj   2018-12-11 12:01:27.968941683 +0100
+++ gcc/cp/constexpr.c  2018-12-11 13:56:50.382890876 +0100
@@ -5244,7 +5244,7 @@ fold_simple (tree t)
 static GTY((deletable)) hash_map *cv_cache;
 
 tree
-maybe_constant_value (tree t, tree decl)
+maybe_constant_value (tree t, tree decl, bool pretend_const_required)
 {
   tree r;
 
@@ -5261,6 +5261,9 @@ maybe_constant_value (tree t, tree decl)
 /* No caching or evaluation needed.  */
 return t;
 
+  if (pretend_const_required)
+return cxx_eval_outermost_constant_expr (t, true, true, true, decl);
+
   if (cv_cache == NULL)
 cv_cache = hash_map::create_ggc (101);
   if (tree *cached = cv_cache->get (t))
--- gcc/cp/decl.c.jj2018-12-07 00:23:15.0 +0100
+++ gcc/cp/decl.c   2018-12-11 13:57:30.779231098 +0100
@@ -9645,7 +9645,10 @@ compute_array_index_type_loc (location_t
{
  size = instantiate_non_dependent_expr_sfinae (size, complain);
  size = build_converted_constant_expr (size_type_node, size, complain);
- size = maybe_constant_value (size);
+ /* Pedantically a constant expression is required here and so
+__builtin_is_constant_evaluated () should fold to true if it
+is successfully folded into a constant.  */
+ size = maybe_constant_value (size, NULL_TREE, true);
 
  if (!TREE_CONSTANT (size))
size = osize;
--- gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated3.C.jj  2018-12-11 
14:11:34.235458615 +0100
+++ gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated3.C 2018-12-11 
14:09:55.319073715 +0100
@@ -0,0 +1,26 @@
+// P0595R1
+// { dg-do run { target c++14 } }
+
+struct false_type { static constexpr bool value = false; };
+struct true_type { static constexpr bool value = true; };
+template
+struct is_same : false_type {};
+template
+struct is_same : true_type {};
+
+int a[__builtin_is_constant_evaluated () ? 1 : 2];
+int b[1];
+static_assert (is_same::value, "");
+
+int
+main ()
+{
+  int c[__builtin_is_constant_evaluated () ? 3 : 4];
+  int d[3];
+  static_assert (is_same::value, "");
+  int (*e)[7][9] = new int[__builtin_is_constant_evaluated () ? -1 : 5]
+ [__builtin_is_constant_evaluated () ? 7 : 8]
+ [__builtin_is_constant_evaluated () ? 9 : 10];
+  e[0][0][0] = 6;
+  delete[] e;
+}

Jakub

[PATCH] Add std::is_constant_evaluated wrapper around __builtin_is_constant_evaluated

[Jakub Jelinek]

Hi!

The following patch adds std::is_constant_evaluated to the library.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
(relies on the previously posted C++ FE patch).

2018-12-11  Jakub Jelinek  

P0595R2 - is_constant_evaluated
* include/bits/c++config (_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED):
Define if __builtin_is_constant_evaluated is available.
* include/std/type_traits (std::is_constant_evaluated): New constexpr
inline function.
* testsuite/20_util/is_constant_evaluated/1.cc: New test.
* testsuite/20_util/is_constant_evaluated/noexcept.cc: New test.

--- libstdc++-v3/include/bits/c++config.jj  2018-08-01 20:14:18.214540951 
+0200
+++ libstdc++-v3/include/bits/c++config 2018-12-11 12:23:21.417491141 +0100
@@ -627,6 +627,9 @@ namespace std
 # define _GLIBCXX_HAVE_BUILTIN_HAS_UNIQ_OBJ_REP 1
 # define _GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE 1
 # define _GLIBCXX_HAVE_BUILTIN_LAUNDER 1
+# if __GNUC__ >= 9
+#  define _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED 1
+# endif
 #elif defined(__is_identifier)
 // For non-GNU compilers:
 # if ! __is_identifier(__has_unique_object_representations)
@@ -638,6 +641,9 @@ namespace std
 # if ! __is_identifier(__builtin_launder)
 #  define _GLIBCXX_HAVE_BUILTIN_LAUNDER 1
 # endif
+# if ! __is_identifier(__builtin_is_constant_evaluated)
+#  define _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED 1
+# endif
 #endif // GCC
 
 // End of prewritten config; the settings discovered at configure time follow.
--- libstdc++-v3/include/std/type_traits.jj 2018-11-29 14:39:27.231036940 
+0100
+++ libstdc++-v3/include/std/type_traits2018-12-11 12:24:44.713130332 
+0100
@@ -3029,6 +3029,12 @@ template 
   template
 using unwrap_ref_decay_t = typename unwrap_ref_decay<_Tp>::type;
 
+#ifdef _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED
+  constexpr inline bool
+  is_constant_evaluated() noexcept
+  { return __builtin_is_constant_evaluated(); }
+#endif
+
 #endif // C++2a
 
 _GLIBCXX_END_NAMESPACE_VERSION
--- libstdc++-v3/testsuite/20_util/is_constant_evaluated/1.cc.jj
2018-12-11 10:30:11.964508310 +0100
+++ libstdc++-v3/testsuite/20_util/is_constant_evaluated/1.cc   2018-12-11 
12:25:36.495284363 +0100
@@ -0,0 +1,80 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+
+#include 
+#include 
+
+template
+struct X { int v = N; };
+X x; // type X
+int y = 4;
+int a = std::is_constant_evaluated() ? y : 1; // initializes a to 1
+int b = std::is_constant_evaluated() ? 2 : y; // initializes b to 2
+int c = y + (std::is_constant_evaluated() ? 2 : y); // initializes c to 2*y
+int d = std::is_constant_evaluated(); // initializes d to 1
+int e = d + std::is_constant_evaluated(); // initializes e to 1 + 0
+
+constexpr int
+foo(int x)
+{
+  const int n = std::is_constant_evaluated() ? 13 : 17; // n == 13
+  int m = std::is_constant_evaluated() ? 13 : 17; // m might be 13 or 17 (see 
below)
+  char arr[n] = {}; // char[13]
+  return m + sizeof (arr) + x;
+}
+
+constexpr int
+bar()
+{
+  const int n = std::is_constant_evaluated() ? 13 : 17;
+  X x1;
+  X x2;
+  static_assert(std::is_same::value,
+   "x1/x2's type");
+  return x1.v + x2.v;
+}
+
+int p = foo(0); // m == 13; initialized to 26
+int q = p + foo(0); // m == 17 for this call; initialized to 56
+static_assert(bar() == 26, "bar");
+
+struct S { int a, b; };
+
+S s = { std::is_constant_evaluated() ? 2 : 3, y };
+S t = { std::is_constant_evaluated() ? 2 : 3, 4 };
+
+static_assert(std::is_same >::value, "x's type");
+
+void
+test01()
+{
+  VERIFY( a == 1 && b == 2 && c == 8 && d == 1 && e == 1 && p == 26 );
+  VERIFY( q == 56 && s.a == 3 && s.b == 4 && t.a == 2 && t.b == 4 );
+  VERIFY( foo (y) == 34 );
+  if constexpr (foo (0) != 26)
+VERIFY( 0 );
+  constexpr int w = foo (0);
+  VERIFY( w == 26 );
+}
+
+int main()
+{
+  test01();
+}
--- libstdc++-v3/testsuite/20_util/is_constant_evaluated/noexcept.cc.jj 
2018-12-11 10:48:27.923528892 +0100
+++ libstdc++-v3/testsuite/20_util/is_constant_evaluated/noexcept.cc
2018-12-11 12:25:45.138143167 +0100
@@ -0,0 +1,23 @@
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }
+
+// Copyright 

[C++ PATCH] Fix up __builtin_is_constant_evaluated (PR c++/88449)

[Jakub Jelinek]

Hi!

While working on the libstdc++ patch for P0595R2, I've noticed that while
__builtin_is_constant_evaluated () directly works, when wrapped into
an constexpr inline noexcept function, it in some cases doesn't.  The
problem is that the constexpr call cache didn't take
ctx->pretend_const_required into account.

The following patch fixes it by just treating it like another magic
parameter.  Another option would be (but much more involved) to remember
during the constexpr.c processing whether we've seen during the evaluation
any calls to __builtin_is_constant_evaluated (that would require propagating
in all the spots that use a new context back to the old context).  Then
we could in the constexpr hash remember either that during the evaluation
of that constexpr call there was no __builtin_is_constant_evaluated seen,
or, if it has been seen, whether it was in ctx->pretend_const_required
mode or in !ctx->pretend_const_required mode.

I've bootstrapped/regtested on x86_64-linux and i686-linux the following
simpler version, ok for trunk?

2018-12-11  Jakub Jelinek  

PR c++/88449
* constexpr.c (struct constexpr_call): Add pretend_const_required
member.
(constexpr_call_hasher::equal): Return false if pretend_const_required
members differ.
(cxx_eval_call_expression): Adjust new_call initialization.  Hash in
ctx->pretend_const_required.

* g++.dg/cpp2a/is-constant-evaluated1.C: Change from dg-do compile
to dg-do run.
(e): Adjust comment with correct expected value.
(main): Expect e == 1.
* g++.dg/cpp2a/is-constant-evaluated2.C: New test.

--- gcc/cp/constexpr.c.jj   2018-12-07 16:18:42.481847741 +0100
+++ gcc/cp/constexpr.c  2018-12-11 12:01:27.968941683 +0100
@@ -973,6 +973,8 @@ struct GTY((for_user)) constexpr_call {
   /* The hash of this call; we remember it here to avoid having to
  recalculate it when expanding the hash table.  */
   hashval_t hash;
+  /* Whether __builtin_is_constant_evaluated() should evaluate to true.  */
+  bool pretend_const_required;
 };
 
 struct constexpr_call_hasher : ggc_ptr_hash
@@ -1052,6 +1054,8 @@ constexpr_call_hasher::equal (constexpr_
 return true;
   if (lhs->hash != rhs->hash)
 return false;
+  if (lhs->pretend_const_required != rhs->pretend_const_required)
+return false;
   if (!constexpr_fundef_hasher::equal (lhs->fundef, rhs->fundef))
 return false;
   lhs_bindings = lhs->bindings;
@@ -1500,7 +1504,8 @@ cxx_eval_call_expression (const constexp
 {
   location_t loc = cp_expr_loc_or_loc (t, input_location);
   tree fun = get_function_named_in_call (t);
-  constexpr_call new_call = { NULL, NULL, NULL, 0 };
+  constexpr_call new_call
+= { NULL, NULL, NULL, 0, ctx->pretend_const_required };
   bool depth_ok;
 
   if (fun == NULL_TREE)
@@ -1642,8 +1647,11 @@ cxx_eval_call_expression (const constexp
   constexpr_call *entry = NULL;
   if (depth_ok && !non_constant_args && ctx->strict)
 {
-  new_call.hash = iterative_hash_template_arg
-   (new_call.bindings, constexpr_fundef_hasher::hash (new_call.fundef));
+  new_call.hash = constexpr_fundef_hasher::hash (new_call.fundef);
+  new_call.hash
+   = iterative_hash_template_arg (new_call.bindings, new_call.hash);
+  new_call.hash
+   = iterative_hash_object (ctx->pretend_const_required, new_call.hash);
 
   /* If we have seen this call before, we are done.  */
   maybe_initialize_constexpr_call_table ();
--- gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated1.C.jj  2018-08-26 
22:41:13.778935483 +0200
+++ gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated1.C 2018-12-11 
11:57:55.027418581 +0100
@@ -1,5 +1,5 @@
 // P0595R1
-// { dg-do compile { target c++14 } }
+// { dg-do run { target c++14 } }
 
 template struct X { int v = N; };
 X<__builtin_is_constant_evaluated ()> x; // type X
@@ -8,7 +8,7 @@ int a = __builtin_is_constant_evaluated
 int b = __builtin_is_constant_evaluated () ? 2 : y; // initializes b to 2
 int c = y + (__builtin_is_constant_evaluated () ? 2 : y); // initializes c to 
2*y
 int d = __builtin_is_constant_evaluated (); // initializes d to 1
-int e = d + __builtin_is_constant_evaluated (); // initializes e to 0
+int e = d + __builtin_is_constant_evaluated (); // initializes e to 1 + 0
 
 struct false_type { static constexpr bool value = false; };
 struct true_type { static constexpr bool value = true; };
@@ -50,7 +50,7 @@ static_assert (is_same struct X { int v = N; };
+X x; // type X
+int y = 4;
+int a = is_constant_evaluated () ? y : 1; // initializes a to 1
+int b = is_constant_evaluated () ? 2 : y; // initializes b to 2
+int c = y + (is_constant_evaluated () ? 2 : y); // initializes c to 2*y
+int d = is_constant_evaluated (); // initializes d to 1
+int e = d + is_constant_evaluated (); // initializes e to 1 + 0
+
+struct false_type { static constexpr bool value = false; };
+struct true_type { static constexpr bool value = true; };
+template
+struct 

Re: [PATCH] Add TREE_CODE == SSA_NAME checks to register_edge_assert_for_2 (PR tree-optimization/88444)

[Richard Biener]

On Tue, 11 Dec 2018, Jakub Jelinek wrote:

> Hi!
> 
> Most spots in vr-values* and tree-vrp* check if convert rhs1 is SSA_NAME,
> but these 3 spots don't.  It can appear if some pass doesn't fold stmts
> after changing them.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

> 2018-12-11  Jakub Jelinek  
> 
>   PR tree-optimization/88444
>   * tree-vrp.c (register_edge_assert_for_2): Only register assertions
>   for conversions if rhs1 is a SSA_NAME.
> 
>   * gcc.dg/pr88444.c: New test.
> 
> --- gcc/tree-vrp.c.jj 2018-12-07 00:27:25.419941079 +0100
> +++ gcc/tree-vrp.c2018-12-11 09:39:27.994469666 +0100
> @@ -2894,6 +2894,7 @@ register_edge_assert_for_2 (tree name, e
>   {
> name2 = gimple_assign_rhs1 (def_stmt);
> if (CONVERT_EXPR_CODE_P (rhs_code)
> +   && TREE_CODE (name2) == SSA_NAME
> && INTEGRAL_TYPE_P (TREE_TYPE (name2))
> && TYPE_UNSIGNED (TREE_TYPE (name2))
> && prec == TYPE_PRECISION (TREE_TYPE (name2))
> @@ -2990,6 +2991,7 @@ register_edge_assert_for_2 (tree name, e
> wide_int rmin, rmax;
> tree rhs1 = gimple_assign_rhs1 (def_stmt);
> if (INTEGRAL_TYPE_P (TREE_TYPE (rhs1))
> +   && TREE_CODE (rhs1) == SSA_NAME
> /* Make sure the relation preserves the upper/lower boundary of
>the range conservatively.  */
> && (comp_code == NE_EXPR
> @@ -3054,6 +3056,7 @@ register_edge_assert_for_2 (tree name, e
>   {
> names[1] = gimple_assign_rhs1 (def_stmt2);
> if (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt2))
> +   || TREE_CODE (names[1]) != SSA_NAME
> || !INTEGRAL_TYPE_P (TREE_TYPE (names[1]))
> || (TYPE_PRECISION (TREE_TYPE (name2))
> != TYPE_PRECISION (TREE_TYPE (names[1]
> --- gcc/testsuite/gcc.dg/pr88444.c.jj 2018-12-11 09:43:50.062166005 +0100
> +++ gcc/testsuite/gcc.dg/pr88444.c2018-12-11 09:43:34.393423360 +0100
> @@ -0,0 +1,30 @@
> +/* PR tree-optimization/88444 */
> +/* { dg-do compile } */
> +/* { dg-options "-O1 -ftree-vrp -fno-tree-ccp -fno-tree-forwprop 
> -fno-tree-fre" } */
> +
> +int v;
> +
> +int
> +foo (int, int);
> +
> +static inline int
> +bar (long int x)
> +{
> +  return !!x ? x : 1;
> +}
> +
> +static inline void
> +baz (int x)
> +{
> +  v += foo (0, 0) + bar (x);
> +}
> +
> +void
> +qux (void)
> +{
> +  int a = 0;
> +  v = v || foo (0, 0);
> +  v = v || foo (0, 0);
> +  v = v || foo (0, 0);
> +  baz (a);
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[PATCH] Add TREE_CODE == SSA_NAME checks to register_edge_assert_for_2 (PR tree-optimization/88444)

[Jakub Jelinek]

Hi!

Most spots in vr-values* and tree-vrp* check if convert rhs1 is SSA_NAME,
but these 3 spots don't.  It can appear if some pass doesn't fold stmts
after changing them.

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

2018-12-11  Jakub Jelinek  

PR tree-optimization/88444
* tree-vrp.c (register_edge_assert_for_2): Only register assertions
for conversions if rhs1 is a SSA_NAME.

* gcc.dg/pr88444.c: New test.

--- gcc/tree-vrp.c.jj   2018-12-07 00:27:25.419941079 +0100
+++ gcc/tree-vrp.c  2018-12-11 09:39:27.994469666 +0100
@@ -2894,6 +2894,7 @@ register_edge_assert_for_2 (tree name, e
{
  name2 = gimple_assign_rhs1 (def_stmt);
  if (CONVERT_EXPR_CODE_P (rhs_code)
+ && TREE_CODE (name2) == SSA_NAME
  && INTEGRAL_TYPE_P (TREE_TYPE (name2))
  && TYPE_UNSIGNED (TREE_TYPE (name2))
  && prec == TYPE_PRECISION (TREE_TYPE (name2))
@@ -2990,6 +2991,7 @@ register_edge_assert_for_2 (tree name, e
  wide_int rmin, rmax;
  tree rhs1 = gimple_assign_rhs1 (def_stmt);
  if (INTEGRAL_TYPE_P (TREE_TYPE (rhs1))
+ && TREE_CODE (rhs1) == SSA_NAME
  /* Make sure the relation preserves the upper/lower boundary of
 the range conservatively.  */
  && (comp_code == NE_EXPR
@@ -3054,6 +3056,7 @@ register_edge_assert_for_2 (tree name, e
{
  names[1] = gimple_assign_rhs1 (def_stmt2);
  if (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt2))
+ || TREE_CODE (names[1]) != SSA_NAME
  || !INTEGRAL_TYPE_P (TREE_TYPE (names[1]))
  || (TYPE_PRECISION (TREE_TYPE (name2))
  != TYPE_PRECISION (TREE_TYPE (names[1]
--- gcc/testsuite/gcc.dg/pr88444.c.jj   2018-12-11 09:43:50.062166005 +0100
+++ gcc/testsuite/gcc.dg/pr88444.c  2018-12-11 09:43:34.393423360 +0100
@@ -0,0 +1,30 @@
+/* PR tree-optimization/88444 */
+/* { dg-do compile } */
+/* { dg-options "-O1 -ftree-vrp -fno-tree-ccp -fno-tree-forwprop 
-fno-tree-fre" } */
+
+int v;
+
+int
+foo (int, int);
+
+static inline int
+bar (long int x)
+{
+  return !!x ? x : 1;
+}
+
+static inline void
+baz (int x)
+{
+  v += foo (0, 0) + bar (x);
+}
+
+void
+qux (void)
+{
+  int a = 0;
+  v = v || foo (0, 0);
+  v = v || foo (0, 0);
+  v = v || foo (0, 0);
+  baz (a);
+}

Jakub

Re: [PATCH 1/3][GCC] Add new target hook asm_post_cfi_startproc

[Sam Tebbs]

On 11/5/18 10:18 AM, Sam Tebbs wrote:

> On 11/05/2018 07:54 AM, Richard Biener wrote:
>> On Fri, 2 Nov 2018, Sam Tebbs wrote:
>>
>>> On 11/02/2018 05:28 PM, Sam Tebbs wrote:
>>>
 Hi all,

 This patch adds a new target hook called "asm_post_cfi_startproc". This 
 hook is
 intended to be used by the aarch64 backend to emit a directive that enables
 support for unwinding frames signed with the pointer authentication B-key. 
 This
 hook is triggered after the ".cfi_startproc" directive is emitted in
 gcc/dwarf2out.c.

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

 Ok for trunk?
>> Can you explain why existing prologue/cfi emission points are not
>> enough?
> I couldn't find any target hooks that were triggered at the
> assembly-printing level at the correct point in time (after
> .cfi_startproc is emitted), please do point me to one if that is not the
> case.
>
> An alternative could have been to implement a new reg_note but that
> would have meant adding target-specific code to target-agnostic files
> and wouldn't have been as flexible.
>
> Sam
>
 gcc/
 2018-11-02  Sam Tebbs

* doc/tm.texi (TARGET_ASM_POST_CFI_STARTPROC): Define.
* doc/tm.texi.in (TARGET_ASM_POST_CFI_STARTPROC): Define.
* dwarf2out.c (dwarf2out_do_cfi_startproc): Trigger the hook.
* hooks.c (hook_void_FILEptr_tree): Define.
* hooks.h (hook_void_FILEptr_tree): Define.
* target.def (post_cfi_startproc): Define.
>>> CCing global reviewers and dwarf maintainers.
>>>
>>>
>>>
ping 4. There are previous pings in another thread with more maintainers 
CC'ed, but pinging here as this is where the conversation has been.

Re: PR88346, Inconsistent list of CPUs supported by the rs6000 backend after r266502

[David Edelsohn]

On Mon, Dec 10, 2018 at 6:17 PM Segher Boessenkool
 wrote:
>
> Hi Alan,
>
> Let's ask David?  (Cc:ed).  Strange that no one noticed powerpc64 before;
> titan and rs64 aren't so strange though ;-)

The patch is okay with me. Thanks for catching the renaming and the
processor missing from the list. I don't think that there are any rs64
systems remaining in the field and AIX customers don't try to utilize
GCC processor options as aggressively as Linux and embedded users.

Thanks, David

>
>
> Segher
>
>
> On Fri, Dec 07, 2018 at 09:00:39PM +1030, Alan Modra wrote:
> > This patch removes the %e error for AIX, since it seems there has been
> > no attempt to keep ASM_CPU_SPEC cpu support up to date for AIX, and
> > adds missing entries to ASM_CPU_SPEC in rs6000.h.  Removing the %e
> > isn't ideal, but leaving it in and hitting a compiler error for -mcpu
> > cases where the AIX assembler works fine with default options, is
> > worse.
> >
> > The rs64a->rs64 name change happened a long time ago as a fix for
> > PR20813 (git commit c92b4c3f5b).
> >
> > Bootstrapped and regression tested powerpc64le-linux.  OK?
> >
> >   PR 88346
> >   * config/rs6000/rs6000.h (ASM_CPU_SPEC): Correct %e message.  Handle
> >   -mcpu=rs64, not -mcpu=rs64a.  Handle -mcpu=powerpc64 and -mcpu=titan.
> >   * config/rs6000/driver-rs6000.c (asm_names): Similarly.
> >   * config/rs6000/aix71.h (ASM_CPU_SPEC): Delete %e message.  Handle
> >   -mcpu=rs64, not -mcpu=rs64a.
> >   * config/rs6000/aix72.h (ASM_CPU_SPEC): Likewise.
> >
> > diff --git a/gcc/config/rs6000/aix71.h b/gcc/config/rs6000/aix71.h
> > index 2398ed64baa..d2fbba4f509 100644
> > --- a/gcc/config/rs6000/aix71.h
> > +++ b/gcc/config/rs6000/aix71.h
> > @@ -77,7 +77,7 @@ do {  
> >   \
> >mcpu=power4: -mpwr4; \
> >mcpu=power3: -m620; \
> >mcpu=powerpc: -mppc; \
> > -  mcpu=rs64a: -mppc; \
> > +  mcpu=rs64: -mppc; \
> >mcpu=603: -m603; \
> >mcpu=603e: -m603; \
> >mcpu=604: -m604; \
> > @@ -88,8 +88,7 @@ do {  
> >   \
> >!mcpu*: %{mvsx: -mpwr6; \
> >   maltivec: -m970; \
> >   maix64|mpowerpc64: -mppc64; \
> > - : %(asm_default)}; \
> > -  :%eMissing -mcpu option in ASM_SPEC_CPU?\n} \
> > + : %(asm_default)}} \
> >  -many"
> >
> >  #undef   ASM_DEFAULT_SPEC
> > diff --git a/gcc/config/rs6000/aix72.h b/gcc/config/rs6000/aix72.h
> > index cfb0258acce..211010748c6 100644
> > --- a/gcc/config/rs6000/aix72.h
> > +++ b/gcc/config/rs6000/aix72.h
> > @@ -77,7 +77,7 @@ do {  
> >   \
> >mcpu=power4: -mpwr4; \
> >mcpu=power3: -m620; \
> >mcpu=powerpc: -mppc; \
> > -  mcpu=rs64a: -mppc; \
> > +  mcpu=rs64: -mppc; \
> >mcpu=603: -m603; \
> >mcpu=603e: -m603; \
> >mcpu=604: -m604; \
> > @@ -88,8 +88,7 @@ do {  
> >   \
> >!mcpu*: %{mvsx: -mpwr6; \
> >   maltivec: -m970; \
> >   maix64|mpowerpc64: -mppc64; \
> > - : %(asm_default)}; \
> > -  :%eMissing -mcpu option in ASM_SPEC_CPU?\n} \
> > + : %(asm_default)}} \
> >  -many"
> >
> >  #undef   ASM_DEFAULT_SPEC
> > diff --git a/gcc/config/rs6000/driver-rs6000.c 
> > b/gcc/config/rs6000/driver-rs6000.c
> > index 0a48d46d658..51c6b79e741 100644
> > --- a/gcc/config/rs6000/driver-rs6000.c
> > +++ b/gcc/config/rs6000/driver-rs6000.c
> > @@ -449,7 +449,7 @@ static const struct asm_name asm_names[] = {
> >{ "power8","-mpwr8" },
> >{ "power9","-mpwr9" },
> >{ "powerpc",   "-mppc" },
> > -  { "rs64a", "-mppc" },
> > +  { "rs64",  "-mppc" },
> >{ "603",   "-m603" },
> >{ "603e",  "-m603" },
> >{ "604",   "-m604" },
> > @@ -477,8 +477,9 @@ static const struct asm_name asm_names[] = {
> >{ "power9","-mpower9" },
> >{ "a2","-ma2" },
> >{ "powerpc",   "-mppc" },
> > +  { "powerpc64", "-mppc64" },
> >{ "powerpc64le", "%{mpower9-vector:-mpower9;:-mpower8}" },
> > -  { "rs64a", "-mppc64" },
> > +  { "rs64",  "-mppc64" },
> >{ "401",   "-mppc" },
> >{ "403",   "-m403" },
> >{ "405",   "-m405" },
> > @@ -519,6 +520,7 @@ static const struct asm_name asm_names[] = {
> >{ "e500mc64",  "-me500mc64" },
> >{ "e5500", "-me5500" },
> >{ "e6500", "-me6500" },
> > +  { "titan", "-mtitan" },
> >{ NULL,"\
> >  %{mpower9-vector: -mpower9; \
> >mpower8-vector|mcrypto|mdirect-move|mhtm: -mpower8; \
> > diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
> > index 2a62679bdb8..e7e998d1492 100644
> > --- a/gcc/config/rs6000/rs6000.h
> > +++ b/gcc/config/rs6000/rs6000.h
> > @@ -87,9 +87,10 @@
> >mcpu=power4: -mpower4; \
> >mcpu=power3: -mppc64; \
> >mcpu=powerpc: -mppc; \
> > +  mcpu=powerpc64: -mppc64; \
> >

Re: [PATCH, ARM] Improve robustness of -mslow-flash-data

[Thomas Preudhomme]

Hi Kyrill,

I've tested on armeb-none-eabi with -mslow-flash-data for both
-mfloat-abi=hard and -mfloat-abi=soft. Both show no regression and the
former shows some new PASS.

Regarding the part you are hesitant about, the code was taken from
aarch64_reinterpret_float_as_int in config/aarch64/aarch64.c. I'm not
too keen on splitting the patch unless it's just for review (ie still
committed as one) since the changes really go together. The tighter
predicate and constraint are to prevent normal pattern to match when
-mslow-flash-data is in effect while the new splitter and expander is
to deal with load under those circumstances.

Best regards,

Thomas
On Fri, 30 Nov 2018 at 14:11, Kyrill Tkachov
 wrote:
>
> Hi Thomas,
>
> On 19/11/18 17:56, Thomas Preudhomme wrote:
> > Hi,
> >
> > Current code to handle -mslow-flash-data in machine description files
> > suffers from a number of issues which this patch fixes:
> >
> > 1) The insn_and_split in vfp.md to load a generic floating-point
> > constant via GPR first and move it to VFP register are guarded by
> > !reload_completed which is forbidden explicitely in the GCC internals
> > documentation section 17.2 point 3;
> >
> > 2) A number of testcase in the testsuite ICEs under -mslow-flash-data
> > when targeting the hardfloat ABI [1];
> >
> > 3) Instructions performing load from literal pool are not disabled.
> >
> > These problems are addressed by 2 separate actions:
> >
> > 1) Making the splitters take a clobber and changing the expanders
> > accordingly to generate a mov with clobber in cases where a literal
> > pool would be used. The splitter can thus be enabled after reload since
> > it does not call gen_reg_rtx anymore;
> >
> > 2) Adding new predicates and constraints to disable literal pool loads
> > in existing instructions when -mslow-flash-data is in effect.
> >
>
> Please split these into two separate patches so we can more clearly see which 
> changes address which problem
>
> > The patch also rework the splitter for DFmode slightly to generate an
> > intermediate DI load instead of 2 intermediate SI loads, thus relying on
> > the existing DI splitters instead of redoing their job. At last, the
> > patch adds some missing arm_fp_ok effective target to some of the
> > slow-flash-data testcases.
> >
> > [1]
> > c-c++-common/Wunused-var-3.c
> > gcc.c-torture/compile/pr72771.c
> > gcc.c-torture/compile/vector-5.c
> > gcc.c-torture/compile/vector-6.c
> > gcc.c-torture/execute/20030914-1.c
> > gcc.c-torture/execute/20050316-1.c
> > gcc.c-torture/execute/pr59643.c
> > gcc.dg/builtin-tgmath-1.c
> > gcc.dg/debug/pr55730.c
> > gcc.dg/graphite/interchange-7.c
> > gcc.dg/pr56890-2.c
> > gcc.dg/pr68474.c
> > gcc.dg/pr80286.c
> > gcc.dg/torture/pr35227.c
> > gcc.dg/torture/pr65077.c
> > gcc.dg/torture/pr86363.c
> > g++.dg/torture/pr81112.C
> > g++.dg/torture/pr82985.C
> > g++.dg/warn/Wunused-var-7.C
> > and a lot more in libstdc++ in special_functions/*_comp_ellint_* and
> > special_functions/*_ellint_* directories.
> >
> > ChangeLog entries are as follows:
> >
> > *** gcc/ChangeLog ***
> >
> > 2018-11-14  Thomas Preud'homme 
> >
> > * config/arm/arm.md (arm_movdi): Split if -mslow-flash-data and
> > source is a constant that would be loaded by literal pool.
> > (movsf expander): Generate a no_literal_pool_sf_immediate insn if
> > -mslow-flash-data is present, targeting hardfloat ABI and source is 
> > a
> > float constant that cannot be loaded via vmov.
> > (movdf expander): Likewise but generate a 
> > no_literal_pool_df_immediate
> > insn.
> > (arm_movsf_soft_insn): Split if -mslow-flash-data and source is a
> > float constant that would be loaded by literal pool.
> > (softfloat constant movsf splitter): Splitter for the above case.
> > (movdf_soft_insn): Split if -mslow-flash-data and source is a float
> > constant that would be loaded by literal pool.
> > (softfloat constant movdf splitter): Splitter for the above case.
> > * config/arm/constraints.md (Pz): Document existing constraint.
> > (Ha): Define constraint.
> > (Tu): Likewise.
> > * config/arm/predicates.md (hard_sf_operand): New predicate.
> > (hard_df_operand): Likewise.
> > * config/arm/thumb2.md (thumb2_movsi_insn): Split if
> > -mslow-flash-data and constant would be loaded by literal pool.
> > * constant/arm/vfp.md (thumb2_movsi_vfp): Likewise and disable 
> > constant
> > load in VFP register.
> > (movdi_vfp): Likewise.
> > (thumb2_movsf_vfp): Use hard_sf_operand as predicate for source to
> > prevent match for a constant load if -mslow-flash-data and constant
> > cannot be loaded via vmov.  Adapt constraint accordingly by
> > using Ha instead of E for generic floating-point constant load.
> > (thumb2_movdf_vfp): Likewise using hard_df_operand predicate 
> > instead.
> >   

PING^2: [PATCH] i386; Add -mmanual-endbr and cf_check function attribute

[H.J. Lu]

On Mon, Dec 3, 2018 at 5:45 AM H.J. Lu  wrote:
>
> On Mon, Jun 18, 2018 at 2:20 AM Richard Biener
>  wrote:
> >
> > On Fri, Jun 15, 2018 at 2:59 PM H.J. Lu  wrote:
> > >
> > > Currently GCC inserts ENDBR instruction at entries of all non-static
> > > functions, unless LTO compilation is used.  Marking all functions,
> > > which are not called indirectly with nocf_check attribute, is not
> > > ideal since 99% of functions in a program may be of this kind.
> > >
> > > This patch adds -mmanual-endbr and cf_check function attribute.  They
> > > can be used together with -fcf-protection such that ENDBR instruction
> > > is inserted only at entries of functions with cf_check attribute.  It
> > > can limit number of ENDBR instructions to reduce program size.
> > >
> > > OK for trubk?
> >
> > I wonder if the linker could assist with ENDBR creation by
> > redirecting all non-direct call relocs to a linker-generated
> > stub with ENBR and a direct branch?
> >
>
> The goal of this patch is to add as few as ENDBR as possible
> to reduce program size as much as possible.   Also there is no
> relocation for indirect branch via register.
>

Hi Honza, Jakub, Jeff, Richard,

Here is the rebased patch.  Can you guys take a look?

Thanks.


-- 
H.J.
From 5934c6be6495b2d6f278646e25f9e684f6610e2b Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 14 Jun 2018 09:19:27 -0700
Subject: [PATCH] i386; Add -mmanual-endbr and cf_check function attribute

Currently GCC inserts ENDBR instruction at entries of all non-static
functions, unless LTO compilation is used.  Marking all functions,
which are not called indirectly with nocf_check attribute, is not
ideal since 99% of functions in a program may be of this kind.

This patch adds -mmanual-endbr and cf_check function attribute.  They
can be used together with -fcf-protection such that ENDBR instruction
is inserted only at entries of functions with cf_check attribute.  It
can limit number of ENDBR instructions to reduce program size.

gcc/

	* config/i386/i386.c (rest_of_insert_endbranch): Insert ENDBR
	at the function entry only when -mmanual-endbr isn't used or
	there is cf_check function attribute.
	(ix86_attribute_table): Add cf_check.
	* config/i386/i386.opt: Add -mmanual-endbr.
	* doc/extend.texi: Document cf_check attribute.
	* doc/invoke.texi: Document -mmanual-endbr.

gcc/testsuite/

	* gcc.target/i386/cf_check-1.c: New test.
	* gcc.target/i386/cf_check-2.c: Likewise.
	* gcc.target/i386/cf_check-3.c: Likewise.
	* gcc.target/i386/cf_check-4.c: Likewise.
	* gcc.target/i386/cf_check-5.c: Likewise.
---
 gcc/config/i386/i386.c |  6 ++
 gcc/config/i386/i386.opt   |  5 +
 gcc/doc/extend.texi|  7 +++
 gcc/doc/invoke.texi|  9 -
 gcc/testsuite/gcc.target/i386/cf_check-1.c | 11 +++
 gcc/testsuite/gcc.target/i386/cf_check-2.c | 11 +++
 gcc/testsuite/gcc.target/i386/cf_check-3.c | 11 +++
 gcc/testsuite/gcc.target/i386/cf_check-4.c | 10 ++
 gcc/testsuite/gcc.target/i386/cf_check-5.c |  9 +
 9 files changed, 78 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/cf_check-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/cf_check-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/cf_check-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/cf_check-4.c
 create mode 100644 gcc/testsuite/gcc.target/i386/cf_check-5.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 3e2fdfa86ff..b05c538c097 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2638,6 +2638,9 @@ rest_of_insert_endbranch (void)
 
   if (!lookup_attribute ("nocf_check",
 			 TYPE_ATTRIBUTES (TREE_TYPE (cfun->decl)))
+  && (!flag_manual_endbr
+	  || lookup_attribute ("cf_check",
+			   DECL_ATTRIBUTES (cfun->decl)))
   && !cgraph_node::get (cfun->decl)->only_called_directly_p ())
 {
   /* Queue ENDBR insertion to x86_function_profiler.  */
@@ -45246,6 +45249,9 @@ static const struct attribute_spec ix86_attribute_table[] =
 ix86_handle_fentry_name, NULL },
   { "fentry_section", 1, 1, true, false, false, false,
 ix86_handle_fentry_name, NULL },
+  { "cf_check", 0, 0, true, false, false, false,
+ix86_handle_fndecl_attribute, NULL },
+
   /* End element.  */
   { NULL, 0, 0, false, false, false, false, NULL, NULL }
 };
diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index b30b55b7826..007e88b57f9 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -1028,6 +1028,11 @@ Target Report Undocumented Var(flag_cet_switch) Init(0)
 Turn on CET instrumentation for switch statements that use a jump table and
 an indirect jump.
 
+mmanual-endbr
+Target Report Var(flag_manual_endbr) Init(0)
+Insert ENDBR instruction at function entry only via cf_check attribute
+for CET instrumentation.
+
 mforce-indirect-call
 Target Report Var(flag_force_indirect_call) Init(0)
 Make 

Re: [PATCH] [RFC] PR target/52813 and target/11807

[Richard Sandiford]

Dimitar Dimitrov  writes:
> On понеделник, 10 декември 2018 г. 11:21:53 EET Richard Sandiford wrote:
>> Dimitar Dimitrov  writes:
>> > I have tested this fix on x86_64 host, and found no regression in the C
>> > and C++ testsuites.  I'm marking this patch as RFC simply because I don't
>> > have experience with other architectures, and I don't have a setup to
>> > test all architectures supported by GCC.
>> > 
>> > gcc/ChangeLog:
>> > 
>> > 2018-12-07  Dimitar Dimitrov  
>> > 
>> >* cfgexpand.c (asm_clobber_reg_is_valid): Also produce
>> >error when stack pointer is clobbered.
>> >(expand_asm_stmt): Refactor clobber check in separate function.
>> > 
>> > gcc/testsuite/ChangeLog:
>> > 
>> > 2018-12-07  Dimitar Dimitrov  
>> > 
>> >* gcc.target/i386/pr52813.c: New test.
>> > 
>> > Signed-off-by: Dimitar Dimitrov 
>> 
>> LGTM.  Do you have a copyright assignment on file?  'Fraid this is
>> probably big enough to need one.
> Yes, I have copyright assignment.

OK, great.  I went ahead and applied the patch.

Thanks,
Richard

Re: [C++ Patch] Add location_t parameter to grokvardecl

[Jason Merrill]

On 12/10/18 5:23 AM, Paolo Carlini wrote:

Hi,

the other day I noticed that we weren't getting right the first location 
of pr53037-4.C, for a variable, whereas the next one, for a function, 
was Ok. Indeed, we were passing a location only to grokfndecl. In other 
terms, I found a good empirical reason to move the declaration of the 
local loc = declarator ? declarator->id_loc : input_location further up 
;) Tested x86_64-linux.


OK.

Jason

Re: [PATCH 2/4] c/c++, asm: Use nicer error for duplicate asm qualifiers

[David Malcolm]

On Tue, 2018-12-11 at 10:35 -0500, David Malcolm wrote:
> On Mon, 2018-12-10 at 22:47 +, Segher Boessenkool wrote:
> 
> [...]
> 
> > diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> > index 121a91c..652e53c 100644
> > --- a/gcc/c/c-parser.c
> > +++ b/gcc/c/c-parser.c
> > @@ -6360,41 +6360,54 @@ c_parser_for_statement (c_parser *parser,
> > bool ivdep, unsigned short unroll,
> >  static tree
> >  c_parser_asm_statement (c_parser *parser)
> >  {
> > -  tree quals, str, outputs, inputs, clobbers, labels, ret;
> > -  bool simple, is_volatile, is_inline, is_goto;
> > +  tree str, outputs, inputs, clobbers, labels, ret;
> > +  bool simple;
> >location_t asm_loc = c_parser_peek_token (parser)->location;
> >int section, nsections;
> >  
> >gcc_assert (c_parser_next_token_is_keyword (parser, RID_ASM));
> >c_parser_consume_token (parser);
> >  
> > -  quals = NULL_TREE;
> > -  is_volatile = false;
> > -  is_inline = false;
> > -  is_goto = false;
> > +  /* Handle the asm-qualifier-list.  */
> > +  location_t volatile_loc = UNKNOWN_LOCATION;
> > +  location_t inline_loc = UNKNOWN_LOCATION;
> > +  location_t goto_loc = UNKNOWN_LOCATION;
> >for (;;)
> >  {
> > -  switch (c_parser_peek_token (parser)->keyword)
> > +  c_token *token = c_parser_peek_token (parser);
> > +  location_t loc = token->location;
> > +  switch (token->keyword)
> > {
> > case RID_VOLATILE:
> > - if (is_volatile)
> > -   break;
> > - is_volatile = true;
> > - quals = c_parser_peek_token (parser)->value;
> > + if (volatile_loc)
> > +   {
> > + error_at (loc, "duplicate asm qualifier %qE", token-
> > > value);
> > 
> > + inform (volatile_loc, "first seen here");
> > +   }
> 
> Thanks for the improvements.
> 
> Is there test coverage for these errors and notes?
> 
> A diagnostic nit (new with gcc 9): please add an:
> auto_diagnostic_group d;
> to the start of the guarded block, so that the "error" and "note" are
> known to be related.
> 
> See:  
> https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html
> #Group-logically-related-diagnostics

For bonus points, these could offer fix-it hints, so that an IDE can
offer to delete the duplicate qualifier token.  The above code could
be:

  if (volatile_loc)
complain_about_duplicate_asm_qualifier (token->value, loc,
volatile_loc);
  else
volatile_loc = loc;


void
complain_about_duplicate_asm_qualifier (tree value,
location_t duplicate_loc,
location_t first_loc)
{
   auto_diagnostic_group d;
   gcc_rich_location richloc (duplicate_loc);
   richloc.add_fixit_remove ();
   error_at (, "duplicate asm qualifier %qE", value);
   inform (first_loc, "first seen here");
}

or somesuch, where rich_location::add_fixit_remove adds a fix-it hint
suggesting the removal of all of "loc", the duplicate token; given that
it's 5 lines at this point, a subroutine seems justified, to eliminate
duplication at the 6 sites it's done.

Caveat: haven't tried to compile the above.

Dave


> > + else
> > +   volatile_loc = loc;
> >   c_parser_consume_token (parser);
> >   continue;
> >  
> > case RID_INLINE:
> > - if (is_inline)
> > -   break;
> > - is_inline = true;
> > + if (inline_loc)
> > +   {
> > + error_at (loc, "duplicate asm qualifier %qE", token-
> > > value);
> > 
> > + inform (inline_loc, "first seen here");
> 
> Likewise.
> 
> > +   }
> > + else
> > +   inline_loc = loc;
> >   c_parser_consume_token (parser);
> >   continue;
> >  
> > case RID_GOTO:
> > - if (is_goto)
> > -   break;
> > - is_goto = true;
> > + if (goto_loc)
> > +   {
> > + error_at (loc, "duplicate asm qualifier %qE", token-
> > > value);
> > 
> > + inform (goto_loc, "first seen here");
> > +   }
> 
> Likewise.
> 
> > + else
> > +   goto_loc = loc;
> >   c_parser_consume_token (parser);
> >   continue;
> 
> [...]
>  
> > diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> > index 1cc34ba..06a6bb0 100644
> > --- a/gcc/cp/parser.c
> > +++ b/gcc/cp/parser.c
> > @@ -19649,29 +19646,50 @@ cp_parser_asm_definition (cp_parser*
> > parser)
> >  }
> >  
> >/* Handle the asm-qualifier-list.  */
> > +  location_t volatile_loc = UNKNOWN_LOCATION;
> > +  location_t inline_loc = UNKNOWN_LOCATION;
> > +  location_t goto_loc = UNKNOWN_LOCATION;
> >if (cp_parser_allow_gnu_extensions_p (parser))
> >  for (;;)
> >{
> > +   cp_token *token = cp_lexer_peek_token (parser->lexer);
> > +   location_t loc = token->location;
> > switch (cp_lexer_peek_token (parser->lexer)->keyword)
> >   {
> >   case RID_VOLATILE:
> > -   if (volatile_p)
> > - break;
> > -   volatile_p = true;
> > +   if (volatile_loc)
> > + {
> > +   error_at (loc, 

Re: C++ PATCH for c++/88216, ICE with class type in non-type template parameter

[Jason Merrill]

On 12/10/18 2:52 PM, Marek Polacek wrote:

+  if (processing_template_decl && value_dependent_expression_p (expr))


You don't need to check processing_template_decl before 
value_dependent_expression_p.


I would lean toward checking for value-dependence in 
convert_nontype_argument, which already does that a lot.  Enough, 
actually, that perhaps we should remember the result in a local variable.


Jason

[PATCH 6/9][GCC][AArch64] Add Armv8.3-a complex intrinsics

[Tamar Christina]

Hi All,

This patch adds NEON intrinsics and tests for the Armv8.3-a complex
multiplication and add instructions with a rotate along the Argand plane.

The instructions are documented in the ArmARM[1] and the intrinsics 
specification
will be published on the Arm website [2].

The Lane versions of these instructions are special in that they always select 
a pair.
using index 0 means selecting lane 0 and 1.  Because of this the range check 
for the
intrinsics require special handling.

[1] 
https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
[2] https://developer.arm.com/docs/101028/latest

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

Ok for trunk?

Thanks,
Tamar

gcc/ChangeLog:

2018-12-11  Tamar Christina  

* config/aarch64/aarch64-builtins.c (enum aarch64_type_qualifiers): Add 
qualifier_lane_pair_index.
(TYPES_QUADOP_LANE_PAIR): New.
(aarch64_simd_expand_args): Use it.
(aarch64_simd_expand_builtin): Likewise.
* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Add 
__ARM_FEATURE_COMPLEX.
* config/aarch64/aarch64-simd-builtins.def (fcadd90, fcadd270, fcmla0, 
fcmla90,
fcmla180, fcmla270, fcmla_lane0, fcmla_lane90, fcmla_lane180, 
fcmla_lane270,
fcmla_laneq0, fcmla_laneq90, fcmla_laneq180, fcmla_laneq270,
fcmlaq_lane0, fcmlaq_lane90, fcmlaq_lane180, fcmlaq_lane270): New.
* config/aarch64/aarch64-simd.md (aarch64_fcmla_lane,
aarch64_fcmla_laneq, aarch64_fcmlaq_lane): New.
* config/aarch64/arm_neon.h:
(vcadd_rot90_f16): New.
(vcaddq_rot90_f16): New.
(vcadd_rot270_f16): New.
(vcaddq_rot270_f16): New.
(vcmla_f16): New.
(vcmlaq_f16): New.
(vcmla_lane_f16): New.
(vcmla_laneq_f16): New.
(vcmlaq_lane_f16): New.
(vcmlaq_rot90_lane_f16): New.
(vcmla_rot90_laneq_f16): New.
(vcmla_rot90_lane_f16): New.
(vcmlaq_rot90_f16): New.
(vcmla_rot90_f16): New.
(vcmlaq_laneq_f16): New.
(vcmla_rot180_laneq_f16): New.
(vcmla_rot180_lane_f16): New.
(vcmlaq_rot180_f16): New.
(vcmla_rot180_f16): New.
(vcmlaq_rot90_laneq_f16): New.
(vcmlaq_rot270_laneq_f16): New.
(vcmlaq_rot270_lane_f16): New.
(vcmla_rot270_laneq_f16): New.
(vcmlaq_rot270_f16): New.
(vcmla_rot270_f16): New.
(vcmlaq_rot180_laneq_f16): New.
(vcmlaq_rot180_lane_f16): New.
(vcmla_rot270_lane_f16): New.
(vcadd_rot90_f32): New.
(vcaddq_rot90_f32): New.
(vcaddq_rot90_f64): New.
(vcadd_rot270_f32): New.
(vcaddq_rot270_f32): New.
(vcaddq_rot270_f64): New.
(vcmla_f32): New.
(vcmlaq_f32): New.
(vcmlaq_f64): New.
(vcmla_lane_f32): New.
(vcmla_laneq_f32): New.
(vcmlaq_lane_f32): New.
(vcmlaq_laneq_f32): New.
(vcmla_rot90_f32): New.
(vcmlaq_rot90_f32): New.
(vcmlaq_rot90_f64): New.
(vcmla_rot90_lane_f32): New.
(vcmla_rot90_laneq_f32): New.
(vcmlaq_rot90_lane_f32): New.
(vcmlaq_rot90_laneq_f32): New.
(vcmla_rot180_f32): New.
(vcmlaq_rot180_f32): New.
(vcmlaq_rot180_f64): New.
(vcmla_rot180_lane_f32): New.
(vcmla_rot180_laneq_f32): New.
(vcmlaq_rot180_lane_f32): New.
(vcmlaq_rot180_laneq_f32): New.
(vcmla_rot270_f32): New.
(vcmlaq_rot270_f32): New.
(vcmlaq_rot270_f64): New.
(vcmla_rot270_lane_f32): New.
(vcmla_rot270_laneq_f32): New.
(vcmlaq_rot270_lane_f32): New.
(vcmlaq_rot270_laneq_f32): New.

gcc/testsuite/ChangeLog:

2018-12-11  Tamar Christina  

* gcc.target/aarch64/advsimd-intrinsics/vector-complex.c: New test.
* gcc.target/aarch64/advsimd-intrinsics/vector-complex_f16.c: New test.

-- 
diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index 8cced94567008e28b1761ec8771589a3925f2904..aaf18a909828b3eeac9d3b676f429923609972a3 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -102,7 +102,10 @@ enum aarch64_type_qualifiers
   /* Lane indices - must be in range, and flipped for bigendian.  */
   qualifier_lane_index = 0x200,
   /* Lane indices for single lane structure loads and stores.  */
-  qualifier_struct_load_store_lane_index = 0x400
+  qualifier_struct_load_store_lane_index = 0x400,
+  /* Lane indices selected in pairs. - must be in range, and flipped for
+ bigendian.  */
+  qualifier_lane_pair_index = 0x800,
 };
 
 typedef struct
@@ -171,6 +174,11 @@ aarch64_types_ternopu_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
 #define TYPES_TERNOPUI (aarch64_types_ternopu_imm_qualifiers)
 
 
+static enum aarch64_type_qualifiers
+aarch64_types_quadop_lane_pair_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { 

[PATCH 9/9][GCC][Arm] Add ACLE intrinsics for complex mutliplication and addition

[Tamar Christina]

Hi All,

This patch adds NEON intrinsics and tests for the Armv8.3-a complex
multiplication and add instructions with a rotate along the Argand plane.

The instructions are documented in the ArmARM[1] and the intrinsics 
specification
will be published on the Arm website [2].

The Lane versions of these instructions are special in that they always select 
a pair.
using index 0 means selecting lane 0 and 1.  Because of this the range check 
for the
intrinsics require special handling.

On Arm, in order to implement some of the lane intrinsics we're using the 
structure of the
register file.  The lane variant of these instructions always select a D 
register, but the data
itself can be stored in Q registers.  This means that for single precision 
complex numbers you are
only allowed to select D[0] but using the register file layout you can get the 
range 0-1 for lane indices
by selecting between Dn[0] and Dn+1[0].

Same reasoning applies for half float complex numbers, except there your D 
register indexes can be 0 or 1, so you have
a total range of 4 elements (for a V8HF).


[1] 
https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
[2] https://developer.arm.com/docs/101028/latest

Bootstrapped Regtested on arm-none-gnueabihf and no issues.

Ok for trunk?

Thanks,
Tamar

gcc/ChangeLog:

2018-12-11  Tamar Christina  

* config/arm/arm-builtins.c
(enum arm_type_qualifiers): Add qualifier_lane_pair_index.
(MAC_LANE_PAIR_QUALIFIERS): New.
(arm_expand_builtin_args): Use it.
(arm_expand_builtin_1): Likewise.
* config/arm/arm-protos.h (neon_vcmla_lane_prepare_operands): New.
* config/arm/arm.c (neon_vcmla_lane_prepare_operands): New.
* config/arm/arm-c.c (arm_cpu_builtins): Add __ARM_FEATURE_COMPLEX.
* config/arm/arm_neon.h:
(vcadd_rot90_f16): New.
(vcaddq_rot90_f16): New.
(vcadd_rot270_f16): New.
(vcaddq_rot270_f16): New.
(vcmla_f16): New.
(vcmlaq_f16): New.
(vcmla_lane_f16): New.
(vcmla_laneq_f16): New.
(vcmlaq_lane_f16): New.
(vcmlaq_laneq_f16): New.
(vcmla_rot90_f16): New.
(vcmlaq_rot90_f16): New.
(vcmla_rot90_lane_f16): New.
(vcmla_rot90_laneq_f16): New.
(vcmlaq_rot90_lane_f16): New.
(vcmlaq_rot90_laneq_f16): New.
(vcmla_rot180_f16): New.
(vcmlaq_rot180_f16): New.
(vcmla_rot180_lane_f16): New.
(vcmla_rot180_laneq_f16): New.
(vcmlaq_rot180_lane_f16): New.
(vcmlaq_rot180_laneq_f16): New.
(vcmla_rot270_f16): New.
(vcmlaq_rot270_f16): New.
(vcmla_rot270_lane_f16): New.
(vcmla_rot270_laneq_f16): New.
(vcmlaq_rot270_lane_f16): New.
(vcmlaq_rot270_laneq_f16): New.
(vcadd_rot90_f32): New.
(vcaddq_rot90_f32): New.
(vcadd_rot270_f32): New.
(vcaddq_rot270_f32): New.
(vcmla_f32): New.
(vcmlaq_f32): New.
(vcmla_lane_f32): New.
(vcmla_laneq_f32): New.
(vcmlaq_lane_f32): New.
(vcmlaq_laneq_f32): New.
(vcmla_rot90_f32): New.
(vcmlaq_rot90_f32): New.
(vcmla_rot90_lane_f32): New.
(vcmla_rot90_laneq_f32): New.
(vcmlaq_rot90_lane_f32): New.
(vcmlaq_rot90_laneq_f32): New.
(vcmla_rot180_f32): New.
(vcmlaq_rot180_f32): New.
(vcmla_rot180_lane_f32): New.
(vcmla_rot180_laneq_f32): New.
(vcmlaq_rot180_lane_f32): New.
(vcmlaq_rot180_laneq_f32): New.
(vcmla_rot270_f32): New.
(vcmlaq_rot270_f32): New.
(vcmla_rot270_lane_f32): New.
(vcmla_rot270_laneq_f32): New.
(vcmlaq_rot270_lane_f32): New.
(vcmlaq_rot270_laneq_f32): New.
* config/arm/arm_neon_builtins.def (vcadd90, vcadd270, vcmla0, vcmla90,
vcmla180, vcmla270, vcmla_lane0, vcmla_lane90, vcmla_lane180, 
vcmla_lane270,
vcmla_laneq0, vcmla_laneq90, vcmla_laneq180, vcmla_laneq270,
vcmlaq_lane0, vcmlaq_lane90, vcmlaq_lane180, vcmlaq_lane270): New.
* config/arm/neon.md (neon_vcmla_lane,
neon_vcmla_laneq, neon_vcmlaq_lane): New.

gcc/testsuite/ChangeLog:

2018-12-11  Tamar Christina  

* gcc.target/aarch64/advsimd-intrinsics/vector-complex.c: Add AArch32 
regexpr.
* gcc.target/aarch64/advsimd-intrinsics/vector-complex_f16.c: Likewise.

-- 
diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index 563ca51dcd0d63046d2bf577ca86d5f70a466bcf..1c7eac4b9eae55b76687b9239a2d71f31cc7b8d9 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -82,7 +82,10 @@ enum arm_type_qualifiers
   /* A void pointer.  */
   qualifier_void_pointer = 0x800,
   /* A const void pointer.  */
-  qualifier_const_void_pointer = 0x802
+  qualifier_const_void_pointer = 0x802,
+  /* Lane indices selected in pairs - must be within range of 

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Marek Polacek]

On Tue, Dec 11, 2018 at 08:17:26AM +0100, Jakub Jelinek wrote:
> On Mon, Dec 10, 2018 at 04:30:11PM -0700, Martin Sebor wrote:
> > Some of my testing exposed a minor problem in GCC 9's validation
> > of the type of function parameters referred to by attribute
> > positional arguments.  Whereas GCC 8 accepts all C integer types,
> > including enumerated types, such as:
> > 
> >   enum AllocAlign { Align16 = 16, Align32 = 32 };
> > 
> >   __attribute__ ((alloc_align (1))) void*
> >   alloc (size_t, enum AllocAlign)
> > 
> > GCC 9 only accepts signed and unsigned integer types.  This change
> > (introduced by myself) was unintentional, and a fix for it is in
> > the attached trivial patch.  I plan to commit it without approval
> > in the next day or so unless any concerns or suggestions come up.
> 
> There is nothing obvious about this, so please don't commit it without
> approval.  GCC 8 and older used to accept

I agree that this isn't an obvious change.

> even float or void * or struct arguments and just ignored them.
> I think we need to discuss what types we want to allow without warnings and
> what we should warn.
> As I wrote in the PR, I believe e.g. using alloc_align/alloc_size with
> bool/_Bool is just a clear bug, you can store 0 or 1 in there, but e.g.
> alignment 0 doesn't make sense.
> Enums are on the border line, I'll defer to C/C++ maintainers whether we
> want to include that or not.

For C, I'd allow them (and I think I've made a change to that effect in the
past in the C FE).

Marek

Re: [PATCH 2/4] c/c++, asm: Use nicer error for duplicate asm qualifiers

[David Malcolm]

On Mon, 2018-12-10 at 22:47 +, Segher Boessenkool wrote:

[...]

> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index 121a91c..652e53c 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -6360,41 +6360,54 @@ c_parser_for_statement (c_parser *parser,
> bool ivdep, unsigned short unroll,
>  static tree
>  c_parser_asm_statement (c_parser *parser)
>  {
> -  tree quals, str, outputs, inputs, clobbers, labels, ret;
> -  bool simple, is_volatile, is_inline, is_goto;
> +  tree str, outputs, inputs, clobbers, labels, ret;
> +  bool simple;
>location_t asm_loc = c_parser_peek_token (parser)->location;
>int section, nsections;
>  
>gcc_assert (c_parser_next_token_is_keyword (parser, RID_ASM));
>c_parser_consume_token (parser);
>  
> -  quals = NULL_TREE;
> -  is_volatile = false;
> -  is_inline = false;
> -  is_goto = false;
> +  /* Handle the asm-qualifier-list.  */
> +  location_t volatile_loc = UNKNOWN_LOCATION;
> +  location_t inline_loc = UNKNOWN_LOCATION;
> +  location_t goto_loc = UNKNOWN_LOCATION;
>for (;;)
>  {
> -  switch (c_parser_peek_token (parser)->keyword)
> +  c_token *token = c_parser_peek_token (parser);
> +  location_t loc = token->location;
> +  switch (token->keyword)
>   {
>   case RID_VOLATILE:
> -   if (is_volatile)
> - break;
> -   is_volatile = true;
> -   quals = c_parser_peek_token (parser)->value;
> +   if (volatile_loc)
> + {
> +   error_at (loc, "duplicate asm qualifier %qE", token-
> >value);
> +   inform (volatile_loc, "first seen here");
> + }

Thanks for the improvements.

Is there test coverage for these errors and notes?

A diagnostic nit (new with gcc 9): please add an:
auto_diagnostic_group d;
to the start of the guarded block, so that the "error" and "note" are
known to be related.

See:
https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html#Group-logically-related-diagnostics


> +   else
> + volatile_loc = loc;
> c_parser_consume_token (parser);
> continue;
>  
>   case RID_INLINE:
> -   if (is_inline)
> - break;
> -   is_inline = true;
> +   if (inline_loc)
> + {
> +   error_at (loc, "duplicate asm qualifier %qE", token-
> >value);
> +   inform (inline_loc, "first seen here");

Likewise.

> + }
> +   else
> + inline_loc = loc;
> c_parser_consume_token (parser);
> continue;
>  
>   case RID_GOTO:
> -   if (is_goto)
> - break;
> -   is_goto = true;
> +   if (goto_loc)
> + {
> +   error_at (loc, "duplicate asm qualifier %qE", token-
> >value);
> +   inform (goto_loc, "first seen here");
> + }

Likewise.

> +   else
> + goto_loc = loc;
> c_parser_consume_token (parser);
> continue;

[...]
 
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 1cc34ba..06a6bb0 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -19649,29 +19646,50 @@ cp_parser_asm_definition (cp_parser*
> parser)
>  }
>  
>/* Handle the asm-qualifier-list.  */
> +  location_t volatile_loc = UNKNOWN_LOCATION;
> +  location_t inline_loc = UNKNOWN_LOCATION;
> +  location_t goto_loc = UNKNOWN_LOCATION;
>if (cp_parser_allow_gnu_extensions_p (parser))
>  for (;;)
>{
> + cp_token *token = cp_lexer_peek_token (parser->lexer);
> + location_t loc = token->location;
>   switch (cp_lexer_peek_token (parser->lexer)->keyword)
> {
> case RID_VOLATILE:
> - if (volatile_p)
> -   break;
> - volatile_p = true;
> + if (volatile_loc)
> +   {
> + error_at (loc, "duplicate asm qualifier %qT", token-
> >u.value);
> + inform (volatile_loc, "first seen here");

Likewise.

> +   }
> + else
> +   volatile_loc = loc;
>   cp_lexer_consume_token (parser->lexer);
>   continue;
>  
> case RID_INLINE:
> - if (inline_p || !parser->in_function_body)
> + if (!parser->in_function_body)
> break;
> - inline_p = true;
> + if (inline_loc)
> +   {
> + error_at (loc, "duplicate asm qualifier %qT", token-
> >u.value);
> + inform (inline_loc, "first seen here");

Likewise.

> +   }
> + else
> +   inline_loc = loc;
>   cp_lexer_consume_token (parser->lexer);
>   continue;
>  
> case RID_GOTO:
> - if (goto_p || !parser->in_function_body)
> + if (!parser->in_function_body)
> break;
> - goto_p = true;
> + if (goto_loc)
> +   {
> + error_at (loc, "duplicate asm qualifier %qT", token-
> >u.value);
> + inform (goto_loc, "first seen here");

Likewise.

> +   }
> + else
> +   goto_loc = loc;
>   cp_lexer_consume_token 

Re: C++ PATCH for c++/86608, reading constexpr volatile variable

[Jason Merrill]

On 12/10/18 8:48 PM, Marek Polacek wrote:

A template-argument for a non-type template-parameter shall be a converted
constant expression.  But an lvalue-to-rvalue conversion applied to a volatile
glvalue is not allowed to be part of the evaluation of a constant expression.
So this test should be rejected.


It occurred to me after my note on IRC that the 
potential_constant_expression_1 test we were talking about,


  if (TREE_THIS_VOLATILE (t) && !DECL_P (t))

ought to test want_rval rather than !DECL_P so that we consistently 
reject the lvalue-to-rvalue conversion, and not other uses of a volatile 
lvalue.  And the diagnostic ought to talk about that rather than 
"side-effects".


It might still be appropriate to change non_const_var_error, but I'd 
think it could check TREE_THIS_VOLATILE itself, rather than the caller; 
I don't see a need for the two calls to differ in their handling of 
volatile variables.


Perhaps decl_maybe_constant_var_p should return false for constexpr 
volatile, as well.


Jason

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

[Jason Merrill]

On 12/11/18 2:17 AM, Jakub Jelinek wrote:

On Mon, Dec 10, 2018 at 04:30:11PM -0700, Martin Sebor wrote:

Some of my testing exposed a minor problem in GCC 9's validation
of the type of function parameters referred to by attribute
positional arguments.  Whereas GCC 8 accepts all C integer types,
including enumerated types, such as:

   enum AllocAlign { Align16 = 16, Align32 = 32 };

   __attribute__ ((alloc_align (1))) void*
   alloc (size_t, enum AllocAlign)

GCC 9 only accepts signed and unsigned integer types.  This change
(introduced by myself) was unintentional, and a fix for it is in
the attached trivial patch.  I plan to commit it without approval
in the next day or so unless any concerns or suggestions come up.


There is nothing obvious about this, so please don't commit it without
approval.  GCC 8 and older used to accept
even float or void * or struct arguments and just ignored them.
I think we need to discuss what types we want to allow without warnings and
what we should warn.
As I wrote in the PR, I believe e.g. using alloc_align/alloc_size with
bool/_Bool is just a clear bug, you can store 0 or 1 in there, but e.g.
alignment 0 doesn't make sense.
Enums are on the border line, I'll defer to C/C++ maintainers whether we
want to include that or not.


I'd think we should allow (unscoped) enums in most places where we want 
an integer constant.


Jason

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

[Umesh Kalappa]

Thank you Segher, will work on your suggestions.

Umesh

On Tue, Dec 11, 2018, 19:23 Segher Boessenkool  Hi Umesh,
>
> On Tue, Dec 11, 2018 at 05:30:48PM +0530, Umesh Kalappa wrote:
> > Please find the attached patch for the subjected issue .
> >
> > Do please let me know your thoughts and comments on the same .
>
> First of all: do you have a copyright assignment with the FSF?
>
> Second: please don't send application/octet-stream attachments.
>
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index ee5f183..d1c0edb 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,14 @@
> +2018-12-06  Lokesh Janghel  
> +
> +PR target/84762
> +* config/rs6000/rs6000.c (rs6000_return_in_msb): Retrun in svr4
> for
> +small struct value.
> +(rs6000_option_override_internal): Modify the condition for aix or
> +svr4.
> +   * config/rs6000/rs6000.opt : Modify the -msvr4-struct-return
> option.
> +   * config/rs6000/rs6000-opts.h : Add enum for svr4 option (Big
> endian
> +   and Little endian).
>
> The changelog should not be part of the patch, but written before it.
> Not as diff, just as the text it is.
>
> Indent is one tab.  Not a tab and a space, not nine spaces.
>
> There shouldn't be trailing spaces.
>
> There should not be a space before a colon.
>
> "Modify XYZ." means that you should have "(XYZ): Modify." instead; but
> you probably can say more than just "Modify", too.  Like, _what_ have you
> changed about it :-)
>
> s/retrun/return/
>
> The changelog should mention everything you change.  I haven't checked
> if it does here, but all the testcases are missing (those have their own
> changelog, in gcc/testsuite/ChangeLog).
>
> +/* Return small structs in register,
> +   gnu: LSB-aligned,
> +   standard: MSB-aligned*/
>
> This should end with dot space space */
>
> +enum rs6000_svr4_struct_return {
> +  SVR4_STRUCT_RETURN_GNU=1,
> +  SVR4_STRUCT_RETURN_STD
> +};
>
> I think a simple boolean would be easier?
>
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 2765263..4751b61 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -4632,7 +4632,8 @@ rs6000_option_override_internal (bool global_init_p)
>/* Set aix_struct_return last, after the ABI is determined.
>  If -maix-struct-return or -msvr4-struct-return was explicitly
>  used, don't override with the ABI default.  */
> -  if (!global_options_set.x_aix_struct_return)
> +  if (!global_options_set.x_aix_struct_return
> +  && !rs6000_current_svr4_struct_return)
> aix_struct_return = (DEFAULT_ABI != ABI_V4 || DRAFT_V4_STRUCT_RET);
>
> Why this change?
>
>  static bool
>  rs6000_return_in_msb (const_tree valtype)
>  {
> -  return (DEFAULT_ABI == ABI_ELFv2
> - && BYTES_BIG_ENDIAN
> +  return ((DEFAULT_ABI == ABI_ELFv2
> +  || (DEFAULT_ABI == ABI_V4
> +  && rs6000_current_svr4_struct_return == SVR4_STRUCT_RETURN_STD))
> + && BYTES_BIG_ENDIAN
>   && AGGREGATE_TYPE_P (valtype)
>   && (rs6000_function_arg_padding (TYPE_MODE (valtype), valtype)
>   == PAD_UPWARD));
>
> Indents are with tabs, not eight spaces.  There never should be tabs
> after spaces though.
>
> Please write this as
>
>   if (DEFAULT_ABI == ABI_ELFv2
>   && BYTES_BIG_ENDIAN
>   && AGGREGATE_TYPE_P (valtype)
>   && (rs6000_function_arg_padding (TYPE_MODE (valtype), valtype)
>   == PAD_UPWARD))
> return true;
>
>   if (DEFAULT_ABI == ABI_V4
>   && rs6000_current_svr4_struct_return == SVR4_STRUCT_RETURN_STD
>   && BYTES_BIG_ENDIAN
>   && AGGREGATE_TYPE_P (valtype)
>   && (rs6000_function_arg_padding (TYPE_MODE (valtype), valtype)
>   == PAD_UPWARD))
> return true;
>
>   return false;
>
> But, on the other hand, you should do this in rs6000_function_arg_padding
> instead I think.
>
> -msvr4-struct-return
> -Target Report RejectNegative Var(aix_struct_return,0) Save
> -Return small structures in registers (SVR4 default).
> +msvr4-struct-return=
> +Target RejectNegative Joined Enum(rs6000_svr4_struct_return)
> Var(rs6000_current_svr4_struct_return)
> +-msvr4-struct-return=[standard,gnu] Return small structures in registers
> (SVR4 default).
> +
> +Enum
> +Name(rs6000_svr4_struct_return) Type(enum rs6000_svr4_struct_return)
> +
> +EnumValue
> +Enum(rs6000_svr4_struct_return) String(standard)
> Value(SVR4_STRUCT_RETURN_STD)
> +
> +EnumValue
> +Enum(rs6000_svr4_struct_return) String(gnu) Value(SVR4_STRUCT_RETURN_GNU)
>
> You are removing the -msvr4-struct-return option (without =).  We shouldn't
> delete command line options.
>
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,10 @@
> +2018-12-06  Lokesh Janghel  
> +
> +PR target/84762
> +* gcc.target/pr84762-1.c: New testcase.
> +* gcc.target/pr84762-2.c: New testcase.
> +* gcc.target/pr84762-3.c: New testcase.
>
> These 

Re: [PATCH, OpenACC] Add support for gang local storage allocation in shared memory

[Julian Brown]

On Fri, 17 Aug 2018 18:39:00 +0200
Bernhard Reutner-Fischer  wrote:

> On 16 August 2018 17:46:43 CEST, Julian Brown
>  wrote:
> >On Wed, 15 Aug 2018 21:56:54 +0200
> >Bernhard Reutner-Fischer  wrote:
> >  
> >> On 15 August 2018 18:46:37 CEST, Julian Brown
> >>  wrote:  
> >> >On Mon, 13 Aug 2018 12:06:21 -0700
> >> >Cesar Philippidis  wrote:
> >> 
> >> atttribute has more t than strictly necessary. 
> >> Don't like signed integer levels where they should be some
> >> unsigned. Also don't like single switch cases instead of if.
> >> And omitting function comments even if the hook way above is
> >> documented may be ok ish but is a bit lazy ;)  
> >
> >Here's a new version with those comments addressed. I also changed
> >the logic around a little to avoid adding decls to the vec in
> >omp_context which would never be given the gang-private attribute.
> >
> >Re-tested with offloading to NVPTX.
> >
> >OK?  
> 
> (TREE_CODE (var) == VAR_DECL
> Is nowadays known as VAR_P (decl), FWIW.

Fixed. (And also Tom's formatting nit mentioned in another email.)

> ISTM that global variables are not JIT-friendly.
> No further comments from me.

Probably true, but AFAIK nobody's trying to use the (GCC) JIT with the
PTX backend, and the backend already uses global variables for several
other purposes. Of course PTX code is JIT'ted itself by the NVidia
runtime, but I guess that's not what you were referring to!

Is this version OK? Re-tested with offloading to NVPTX.

Thanks,

Julian
commit 3335ddfa72944be5359280116e8eb4febd4ed3c7
Author: Julian Brown 
Date:   Thu Aug 9 20:27:04 2018 -0700

[OpenACC] Add support for gang local storage allocation in shared memory

2018-08-10  Julian Brown  
	Chung-Lin Tang  

	gcc/
	* config/nvptx/nvptx.c (tree-hash-traits.h): Include.
	(gangprivate_shared_size): New global variable.
	(gangprivate_shared_align): Likewise.
	(gangprivate_shared_sym): Likewise.
	(gangprivate_shared_hmap): Likewise.
	(nvptx_option_override): Initialize gangprivate_shared_sym,
	gangprivate_shared_align.
	(nvptx_file_end): Output gangprivate_shared_sym.
	(nvptx_goacc_expand_accel_var): New function.
	(nvptx_set_current_function): New function.
	(TARGET_SET_CURRENT_FUNCTION): Define hook.
	(TARGET_GOACC_EXPAND_ACCEL): Likewise.
	* doc/tm.texi (TARGET_GOACC_EXPAND_ACCEL_VAR): Document new hook.
	* doc/tm.texi.in (TARGET_GOACC_EXPAND_ACCEL_VAR): Likewise.
	* expr.c (expand_expr_real_1): Remap decls marked with the
	"oacc gangprivate" attribute.
	* omp-low.c (omp_context): Add oacc_partitioning_level and
	oacc_addressable_var_decls fields.
	(new_omp_context): Initialize oacc_addressable_var_decls in new
	omp_context.
	(delete_omp_context): Delete oacc_addressable_var_decls in old
	omp_context.
	(lower_oacc_head_tail): Record partitioning-level count in omp context.
	(oacc_record_private_var_clauses, oacc_record_vars_in_bind)
	(mark_oacc_gangprivate): New functions.
	(lower_omp_for): Call oacc_record_private_var_clauses with "for"
	clauses.  Call mark_oacc_gangprivate for gang-partitioned loops.
	(lower_omp_target): Call oacc_record_private_var_clauses with "target"
	clauses.
	Call mark_oacc_gangprivate for offloaded target regions.
	(lower_omp_1): Call vars_in_bind for GIMPLE_BIND within OMP regions.
	* target.def (expand_accel_var): New hook.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/gang-private-1.c: New test.
	* testsuite/libgomp.oacc-c-c++-common/loop-gwv-2.c: New test.
	* testsuite/libgomp.oacc-c/pr85465.c: New test.
	* testsuite/libgomp.oacc-fortran/gangprivate-attrib-1.f90: New test.

diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 9903a27..02c2847 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -73,6 +73,7 @@
 #include "cfgloop.h"
 #include "fold-const.h"
 #include "intl.h"
+#include "tree-hash-traits.h"
 
 /* This file should be included last.  */
 #include "target-def.h"
@@ -137,6 +138,12 @@ static unsigned worker_red_size;
 static unsigned worker_red_align;
 static GTY(()) rtx worker_red_sym;
 
+/* Shared memory block for gang-private variables.  */
+static unsigned gangprivate_shared_size;
+static unsigned gangprivate_shared_align;
+static GTY(()) rtx gangprivate_shared_sym;
+static hash_map gangprivate_shared_hmap;
+
 /* Global lock variable, needed for 128bit worker & gang reductions.  */
 static GTY(()) tree global_lock_var;
 
@@ -210,6 +217,10 @@ nvptx_option_override (void)
   SET_SYMBOL_DATA_AREA (worker_red_sym, DATA_AREA_SHARED);
   worker_red_align = GET_MODE_ALIGNMENT (SImode) / BITS_PER_UNIT;
 
+  gangprivate_shared_sym = gen_rtx_SYMBOL_REF (Pmode, "__gangprivate_shared");
+  SET_SYMBOL_DATA_AREA (gangprivate_shared_sym, DATA_AREA_SHARED);
+  gangprivate_shared_align = GET_MODE_ALIGNMENT (SImode) / BITS_PER_UNIT;
+
   diagnose_openacc_conflict (TARGET_GOMP, 

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

[Pedro Alves]

On 12/11/2018 02:25 PM, Ian Lance Taylor wrote:
> On Tue, Dec 11, 2018 at 3:05 AM Pedro Alves  wrote:

>> Ian earlier mentioned that we've wanted to avoid malloc because some
>> programs call the demangler from a signal handler, but it seems like
>> we already do, these functions already aren't safe to use from
>> signal handlers as is.  Where does the "we can't use malloc" idea
>> come from?  Is there some entry point that avoids
>> the malloc/realloc/free calls?
> 
> cplus_demangle_v3_callback and cplus_demangle_print_callback.

Ah, gotcha.  Thanks!  Interesting.

Pedro Alves

Fix alignment of dynamically allocated stack areas on ppc-vxworks

[Olivier Hainque]

Hello,

The attached patch, provided by Eric Botcazou (thanks!), installs
definitions of RS6000_STARTING_FRAME_OFFSET and STACK_DYNAMIC_OFFSET
for PowerPC VxWorks, which has STACK_BOUNDARY set to 128
unconditionally.

AFAICS, this is the third OS config file doing this, after Darwin
and AIX. It seems like we could (should ?) account for STACK_BOUNDARY
or maybe PREFERRED_STACK_BOUNDARY in the common rs6000.h definition.

We have tested this successfully with a gcc-8 based compiler for
powerpc-wrs-vxworks, where this fixes SEGVs observed on Ada programs
performing dynamic stack allocations.

With Kind Regards,

Olivier

2018-12-11  Eric Botcazou  

* config/rs6000/vxworks.h (RS6000_STARTING_FRAME_OFFSET): Define,
accounting for STACK_BOUNDARY 128.
(STACK_DYNAMIC_OFFSET): Likewise.

diff --git a/gcc/config/rs6000/vxworks.h b/gcc/config/rs6000/vxworks.h
index d2033f6..24fe9ba 100644
--- a/gcc/config/rs6000/vxworks.h
+++ b/gcc/config/rs6000/vxworks.h
@@ -116,7 +116,7 @@ VXWORKS_ADDITIONAL_CPP_SPEC
 #undef SDATA_DEFAULT_SIZE
 #define SDATA_DEFAULT_SIZE (TARGET_VXWORKS_RTP ? 8 : 0)
 
-/* Enforce 16bytes alignment for the stack pointer, to permit general
+/* Enforce 16-byte alignment for the stack pointer, to permit general
compliance with e.g. Altivec instructions requirements.  Make sure
this isn't overruled by the EABI constraints.  */
 
@@ -128,6 +128,40 @@ VXWORKS_ADDITIONAL_CPP_SPEC
 
 #undef  ABI_STACK_BOUNDARY
 
+/* Offset within stack frame to start allocating local variables at.
+   If FRAME_GROWS_DOWNWARD, this is the offset to the END of the
+   first local allocated.  Otherwise, it is the offset to the BEGINNING
+   of the first local allocated.
+
+   On the RS/6000, the frame pointer is the same as the stack pointer,
+   except for dynamic allocations.  So we start after the fixed area and
+   outgoing parameter area.
+
+   If the function uses dynamic stack space (CALLS_ALLOCA is set), that
+   space needs to be aligned to STACK_BOUNDARY, i.e. the sum of the
+   sizes of the fixed area and the parameter area must be a multiple of
+   STACK_BOUNDARY.  */
+
+#undef RS6000_STARTING_FRAME_OFFSET
+#define RS6000_STARTING_FRAME_OFFSET   \
+  (cfun->calls_alloca  \
+   ? RS6000_ALIGN (crtl->outgoing_args_size + RS6000_SAVE_AREA, 16)\
+   : (RS6000_ALIGN (crtl->outgoing_args_size, 16) + RS6000_SAVE_AREA))
+
+/* Offset from the stack pointer register to an item dynamically
+   allocated on the stack, e.g., by `alloca'.
+
+   The default value for this macro is `STACK_POINTER_OFFSET' plus the
+   length of the outgoing arguments.  The default is correct for most
+   machines.  See `function.c' for details.
+
+   This value must be a multiple of STACK_BOUNDARY (hard coded in
+   `emit-rtl.c').  */
+#undef STACK_DYNAMIC_OFFSET
+#define STACK_DYNAMIC_OFFSET(FUNDECL)  \
+   RS6000_ALIGN (crtl->outgoing_args_size.to_constant ()   \
++ STACK_POINTER_OFFSET, 16)
+
 #undef SUBSUBTARGET_OVERRIDE_OPTIONS
 #define SUBSUBTARGET_OVERRIDE_OPTIONS  \
   do { \

Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support

[Matthias Klose]

On 10.12.18 16:54, Cherry Zhang wrote:
> On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose  wrote:
> 
>> On 06.12.18 00:09, Ian Lance Taylor wrote:
>>> This libgo patch by Cherry Zhang adds support for precise stack
>>> scanning to the Go runtime.  This uses per-function stack maps stored
>>> in the exception tables in the language-specific data area.  The
>>> compiler needs to generate these stack maps; currently this is only
>>> done by a version of LLVM, not by GCC.  Each safepoint in a function
>>> is associated with a (real or dummy) landing pad, and its "type info"
>>> in the exception table is a pointer to the stack map. When a stack is
>>> scanned, the stack map is found by the stack unwinding code.
>>>
>>> For precise stack scan we need to unwind the stack. There are three
>> cases:
>>>
>>> - If a goroutine is scanning its own stack, it can unwind the stack
>>> and scan the frames.
>>>
>>> - If a goroutine is scanning another, stopped, goroutine, it cannot
>>> directly unwind the target stack. We handle this by switching
>>> (runtime.gogo) to the target g, letting it unwind and scan the stack,
>>> and switch back.
>>>
>>> - If we are scanning a goroutine that is blocked in a syscall, we send
>>> a signal to the target goroutine's thread, and let the signal handler
>>> unwind and scan the stack. Extra care is needed as this races with
>>> enter/exit syscall.
>>>
>>> Currently this is only implemented on GNU/Linux.
>>>
>>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
>>> to mainline.
>>
>> this broke the libgo build on ARM32:
>>
>> ../../../src/libgo/runtime/go-unwind.c: In function
>> 'scanstackwithmap_callback':
>> ../../../src/libgo/runtime/go-unwind.c:754:18: error: '_URC_NORMAL_STOP'
>> undeclared (first use in this function)
>>   754 |   return _URC_NORMAL_STOP;
>>   |  ^~~~
>> ../../../src/libgo/runtime/go-unwind.c:754:18: note: each undeclared
>> identifier
>> is reported only once for each function i
>> t appears in
>> ../../../src/libgo/runtime/go-unwind.c: In function
>> 'probestackmaps_callback':
>> ../../../src/libgo/runtime/go-unwind.c:802:10: error: '_URC_NORMAL_STOP'
>> undeclared (first use in this function)
>>   802 |   return _URC_NORMAL_STOP;
>>   |  ^~~~
>> ../../../src/libgo/runtime/go-unwind.c:803:1: warning: control reaches end
>> of
>> non-void function [-Wreturn-type]
>>   803 | }
>>   | ^
>> make[6]: *** [Makefile:1474: runtime/go-unwind.lo] Error 1
>> make[6]: Leaving directory
>> '/<>/build/arm-linux-gnueabihf/libgo'
>>
>>
> Hell Matthias,
> 
> Thank you for the report. And sorry about the breakage. Does
> https://go-review.googlesource.com/c/gofrontend/+/153417 (or the patch
> below) fix ARM32 build? I don't have an ARM32 machine at hand to test.

this fixes the build.

currently running the testsuite, almost every test case core dumps on
arm-linux-gnueabihf

Matthias

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

[Umesh Kalappa]

Thank you Jakub for the information.

Will make a note of it.

Umesh



On Tue, Dec 11, 2018, 17:58 Jakub Jelinek  On Tue, Dec 11, 2018 at 05:30:48PM +0530, Umesh Kalappa wrote:
> > Hi All,
> >
> > Please find the attached patch for the subjected issue .
> >
> > Do please let me know your thoughts and comments on the same .
>
> Not a patch review (will defer that to rs6000 maintainers), but
> some comments on gcc-patches patch submissions.
>
> The subject should ideally start with [PATCH] or similar,
> then have some short summary of what the patch is about and if
> it fixes some PR, just PR something/12345 reference,
> the subjects you are posting like:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762
> don't say anything relevant except for the PR 84762 number,
> so anyone reading gcc-patches needs to open that bug in order to even find
> out if it is something for him or somebody else.
>
> If you are sending a patch for an area that has some maintainer(s),
> usually you should either mention those maintainers in To: (and CC:
> gcc-patches) or To: gcc-patches, CC: the maintainers, to draw their
> attention.  See MAINTAINERS file in GCC tree.
>
> The mail body should start with a short explanation of what the problem is
> and how are you solving it, again, so that people don't have to jump to
> bugzilla to find out (of course, short is enough, no need to duplicate
> dozens of comments from the PR), should include information on what
> target(s) it has been bootstrapped/regtested.  And, it is always better if
> it is the patch author that posts it, or is at least CCed so that he can
> answer review questions.
>
> Thanks.
>
> Jakub
>

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

[Ian Lance Taylor via gcc-patches]

On Tue, Dec 11, 2018 at 3:05 AM Pedro Alves  wrote:
>
> I noticed that the comment on top of __cxa_demangle says:
>
>   "If OUTPUT_BUFFER is not long enough, it is expanded using realloc."
>
> and __cxa_demangle calls 'free'.
>
> And d_demangle, seemingly the workhorse for __cxa_demangle says:
>
> /* Entry point for the demangler.  If MANGLED is a g++ v3 ABI mangled
>name, return a buffer allocated with malloc holding the demangled
>name.  OPTIONS is the usual libiberty demangler options.  On
>success, this sets *PALC to the allocated size of the returned
>buffer.  On failure, this sets *PALC to 0 for a bad name, or 1 for
>a memory allocation failure, and returns NULL.  */
>
> cplus_demangle, the entry point that gdb uses, also relies on malloc.
>
> Ian earlier mentioned that we've wanted to avoid malloc because some
> programs call the demangler from a signal handler, but it seems like
> we already do, these functions already aren't safe to use from
> signal handlers as is.  Where does the "we can't use malloc" idea
> come from?  Is there some entry point that avoids
> the malloc/realloc/free calls?

cplus_demangle_v3_callback and cplus_demangle_print_callback.

Ian

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

[Segher Boessenkool]

Hi Umesh,

On Tue, Dec 11, 2018 at 05:30:48PM +0530, Umesh Kalappa wrote:
> Please find the attached patch for the subjected issue .
> 
> Do please let me know your thoughts and comments on the same .

First of all: do you have a copyright assignment with the FSF?

Second: please don't send application/octet-stream attachments.


diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ee5f183..d1c0edb 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2018-12-06  Lokesh Janghel  
+
+PR target/84762
+* config/rs6000/rs6000.c (rs6000_return_in_msb): Retrun in svr4 for
+small struct value.
+(rs6000_option_override_internal): Modify the condition for aix or
+svr4. 
+   * config/rs6000/rs6000.opt : Modify the -msvr4-struct-return option.
+   * config/rs6000/rs6000-opts.h : Add enum for svr4 option (Big endian 
+   and Little endian).

The changelog should not be part of the patch, but written before it.
Not as diff, just as the text it is.

Indent is one tab.  Not a tab and a space, not nine spaces.

There shouldn't be trailing spaces.

There should not be a space before a colon.

"Modify XYZ." means that you should have "(XYZ): Modify." instead; but
you probably can say more than just "Modify", too.  Like, _what_ have you
changed about it :-)

s/retrun/return/

The changelog should mention everything you change.  I haven't checked
if it does here, but all the testcases are missing (those have their own
changelog, in gcc/testsuite/ChangeLog).

+/* Return small structs in register,
+   gnu: LSB-aligned,
+   standard: MSB-aligned*/

This should end with dot space space */

+enum rs6000_svr4_struct_return {
+  SVR4_STRUCT_RETURN_GNU=1,
+  SVR4_STRUCT_RETURN_STD
+};

I think a simple boolean would be easier?

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 2765263..4751b61 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4632,7 +4632,8 @@ rs6000_option_override_internal (bool global_init_p)
   /* Set aix_struct_return last, after the ABI is determined.
 If -maix-struct-return or -msvr4-struct-return was explicitly
 used, don't override with the ABI default.  */
-  if (!global_options_set.x_aix_struct_return)
+  if (!global_options_set.x_aix_struct_return
+  && !rs6000_current_svr4_struct_return)
aix_struct_return = (DEFAULT_ABI != ABI_V4 || DRAFT_V4_STRUCT_RET);

Why this change?

 static bool
 rs6000_return_in_msb (const_tree valtype)
 {
-  return (DEFAULT_ABI == ABI_ELFv2
- && BYTES_BIG_ENDIAN
+  return ((DEFAULT_ABI == ABI_ELFv2
+  || (DEFAULT_ABI == ABI_V4
+  && rs6000_current_svr4_struct_return == SVR4_STRUCT_RETURN_STD))
+ && BYTES_BIG_ENDIAN
  && AGGREGATE_TYPE_P (valtype)
  && (rs6000_function_arg_padding (TYPE_MODE (valtype), valtype)
  == PAD_UPWARD));

Indents are with tabs, not eight spaces.  There never should be tabs
after spaces though.

Please write this as

  if (DEFAULT_ABI == ABI_ELFv2
  && BYTES_BIG_ENDIAN
  && AGGREGATE_TYPE_P (valtype)
  && (rs6000_function_arg_padding (TYPE_MODE (valtype), valtype)
  == PAD_UPWARD))
return true;

  if (DEFAULT_ABI == ABI_V4
  && rs6000_current_svr4_struct_return == SVR4_STRUCT_RETURN_STD
  && BYTES_BIG_ENDIAN
  && AGGREGATE_TYPE_P (valtype)
  && (rs6000_function_arg_padding (TYPE_MODE (valtype), valtype)
  == PAD_UPWARD))
return true;

  return false;

But, on the other hand, you should do this in rs6000_function_arg_padding
instead I think.

-msvr4-struct-return
-Target Report RejectNegative Var(aix_struct_return,0) Save
-Return small structures in registers (SVR4 default).
+msvr4-struct-return=
+Target RejectNegative Joined Enum(rs6000_svr4_struct_return)  
Var(rs6000_current_svr4_struct_return)
+-msvr4-struct-return=[standard,gnu] Return small structures in registers (SVR4 
default).
+
+Enum
+Name(rs6000_svr4_struct_return) Type(enum rs6000_svr4_struct_return)
+
+EnumValue
+Enum(rs6000_svr4_struct_return) String(standard) Value(SVR4_STRUCT_RETURN_STD) 
+
+EnumValue
+Enum(rs6000_svr4_struct_return) String(gnu) Value(SVR4_STRUCT_RETURN_GNU) 

You are removing the -msvr4-struct-return option (without =).  We shouldn't
delete command line options.

--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,10 @@
+2018-12-06  Lokesh Janghel  
+
+PR target/84762
+* gcc.target/pr84762-1.c: New testcase.
+* gcc.target/pr84762-2.c: New testcase.
+* gcc.target/pr84762-3.c: New testcase.

These should be before the patch as well.

+++ b/gcc/testsuite/gcc.target/powerpc/pr84762-1.c
@@ -0,0 +1,9 @@
+/* { dg-do run { target powerpc*-*-* rs6000-*-* } } */

You don't have to mention the target in gcc.target/powerpc; just say

+/* { dg-do run } */

+struct smallstruct { char a; char b; char c; };
+
+struct smallstruct f(void)
+{
+  struct smallstruct s = { 

Re: [PATCH 6/6, OpenACC, libgomp] Async re-work, nvptx changes (revised, v2)

[Chung-Lin Tang]

On 2018/12/10 6:02 PM, Chung-Lin Tang wrote:

On 2018/12/7 04:57 AM, Thomas Schwinge wrote>> --- 
a/libgomp/plugin/plugin-nvptx.c

+++ b/libgomp/plugin/plugin-nvptx.c



+struct goacc_asyncqueue *
+GOMP_OFFLOAD_openacc_async_construct (void)
+{
+  struct goacc_asyncqueue *aq
+    = GOMP_PLUGIN_malloc (sizeof (struct goacc_asyncqueue));
+  aq->cuda_stream = NULL;
+  CUDA_CALL_ASSERT (cuStreamCreate, >cuda_stream, CU_STREAM_DEFAULT);


Curiously (this was the same in the code before): does this have to be
"CU_STREAM_DEFAULT" instead of "CU_STREAM_NON_BLOCKING", because we want
to block anything from running in parallel with "acc_async_sync" GPU
kernels, that use the "NULL" stream?  (Not asking you to change this now,
but I wonder if this is overly strict?)


IIUC, this non-blocking only pertains to the "Legacy Default Stream" in CUDA, 
which we're pretty much ignoring; we should be using the newer per-thread default stream 
model. We could review this issue later.


+  if (aq->cuda_stream == NULL)
+    GOMP_PLUGIN_fatal ("CUDA stream create NULL\n");


Can this actually happen, given the "CUDA_CALL_ASSERT" usage above?


Hmm, yeah I think this is superfluous too...


+  CUDA_CALL_ASSERT (cuStreamSynchronize, aq->cuda_stream);


Why is the synchronization needed here?


I don't remember, could likely be something added during debug.
I'll remove this and test if things are okay.


I have removed the above seemingly unneeded lines and re-tested, appears okay.
Also the formerly attached version seemed to for some reason had many conflicts
with older code, all resolved in this v2 nvptx part.

Thanks,
Chung-Lin
Index: libgomp/plugin/cuda/cuda.h
===
--- libgomp/plugin/cuda/cuda.h  (revision 266973)
+++ libgomp/plugin/cuda/cuda.h  (working copy)
@@ -54,7 +54,11 @@ typedef enum {
   CUDA_ERROR_INVALID_CONTEXT = 201,
   CUDA_ERROR_NOT_FOUND = 500,
   CUDA_ERROR_NOT_READY = 600,
-  CUDA_ERROR_LAUNCH_FAILED = 719
+  CUDA_ERROR_LAUNCH_FAILED = 719,
+  CUDA_ERROR_COOPERATIVE_LAUNCH_TOO_LARGE = 720,
+  CUDA_ERROR_NOT_PERMITTED = 800,
+  CUDA_ERROR_NOT_SUPPORTED = 801,
+  CUDA_ERROR_UNKNOWN = 999
 } CUresult;
 
 typedef enum {
@@ -173,6 +177,8 @@ CUresult cuModuleLoadData (CUmodule *, const void
 CUresult cuModuleUnload (CUmodule);
 CUresult cuOccupancyMaxPotentialBlockSize(int *, int *, CUfunction,
  CUoccupancyB2DSize, size_t, int);
+typedef void (*CUstreamCallback)(CUstream, CUresult, void *);
+CUresult cuStreamAddCallback(CUstream, CUstreamCallback, void *, unsigned int);
 CUresult cuStreamCreate (CUstream *, unsigned);
 #define cuStreamDestroy cuStreamDestroy_v2
 CUresult cuStreamDestroy (CUstream);
Index: libgomp/plugin/cuda-lib.def
===
--- libgomp/plugin/cuda-lib.def (revision 266973)
+++ libgomp/plugin/cuda-lib.def (working copy)
@@ -42,6 +42,7 @@ CUDA_ONE_CALL (cuModuleLoad)
 CUDA_ONE_CALL (cuModuleLoadData)
 CUDA_ONE_CALL (cuModuleUnload)
 CUDA_ONE_CALL_MAYBE_NULL (cuOccupancyMaxPotentialBlockSize)
+CUDA_ONE_CALL (cuStreamAddCallback)
 CUDA_ONE_CALL (cuStreamCreate)
 CUDA_ONE_CALL (cuStreamDestroy)
 CUDA_ONE_CALL (cuStreamQuery)
Index: libgomp/plugin/plugin-nvptx.c
===
--- libgomp/plugin/plugin-nvptx.c   (revision 266973)
+++ libgomp/plugin/plugin-nvptx.c   (working copy)
@@ -192,21 +192,18 @@ cuda_error (CUresult r)
 static unsigned int instantiated_devices = 0;
 static pthread_mutex_t ptx_dev_lock = PTHREAD_MUTEX_INITIALIZER;
 
-struct cuda_map
+/* NVPTX/CUDA specific definition of asynchronous queues.  */
+struct goacc_asyncqueue
 {
-  CUdeviceptr d;
-  size_t size;
-  bool active;
-  struct cuda_map *next;
+  CUstream cuda_stream;
 };
 
-struct ptx_stream
+struct nvptx_callback
 {
-  CUstream stream;
-  pthread_t host_thread;
-  bool multithreaded;
-  struct cuda_map *map;
-  struct ptx_stream *next;
+  void (*fn) (void *);
+  void *ptr;
+  struct goacc_asyncqueue *aq;
+  struct nvptx_callback *next;
 };
 
 /* Thread-specific data for PTX.  */
@@ -213,120 +210,13 @@ static pthread_mutex_t ptx_dev_lock = PTHREAD_MUTE
 
 struct nvptx_thread
 {
-  struct ptx_stream *current_stream;
+  /* We currently have this embedded inside the plugin because libgomp manages
+ devices through integer target_ids.  This might be better if using an
+ opaque target-specific pointer directly from gomp_device_descr.  */
   struct ptx_device *ptx_dev;
 };
 
-static struct cuda_map *
-cuda_map_create (size_t size)
-{
-  struct cuda_map *map = GOMP_PLUGIN_malloc (sizeof (struct cuda_map));
 
-  assert (map);
-
-  map->next = NULL;
-  map->size = size;
-  map->active = false;
-
-  CUDA_CALL_ERET (NULL, cuMemAlloc, >d, size);
-  assert (map->d);
-
-  return map;
-}
-
-static void
-cuda_map_destroy (struct cuda_map *map)
-{
-  CUDA_CALL_ASSERT (cuMemFree, map->d);
-  free (map);
-}
-
-/* The 

Re: [PATCH 4/6, OpenACC, libgomp] Async re-work, libgomp/target.c changes (revised, v2)

[Chung-Lin Tang]

On 2018/12/7 1:43 AM, Jakub Jelinek wrote:

On Thu, Dec 06, 2018 at 06:21:16PM +0100, Thomas Schwinge wrote:

On Tue, 25 Sep 2018 21:11:24 +0800, Chung-Lin Tang  
wrote:

Hi Jakub,
This part has changes to 'struct goacc_asyncqueue*' arguments to various
memory copying/mapping functions. To lessen the amount of code changes new 
'gomp_map/unmap_vars_async'
functions names are used (with the non-async original names defined with the 
asyncqueue==NULL).


Is that the way you'd like this to be done, or should instead that
"struct goacc_asyncqueue *aq" parameter be added/passed through all the
existing functions?  (The latter would be my preference, actually.)


I'd prefer not to increase the amount of arguments where possible, because
many of the functions already have more arguments than can be passed in
registers.  Could it be e.g. added into gomp_coalesce_buf which is already
passed around?

Another option would be to use always_inline as C template if the OpenMP and
OpenACC needs diverge too much, then have simply small wrappers that just
call the always_inline function, in one case with the argument NULL or other
constant, in another one with whatever it has been called with.

Jakub


I have revised the patch to make both gomp_[un]map_vars and 
gomp_[un]map_vars_async
point to gomp_[un]map_vars_internal, which is static always_inline. This should
alleviate that part of the concerns.

Thanks,
Chung-Lin

Index: libgomp/target.c
===
--- libgomp/target.c(revision 266973)
+++ libgomp/target.c(working copy)
@@ -177,6 +177,22 @@ gomp_device_copy (struct gomp_device_descr *device
 }
 }
 
+static inline void
+goacc_device_copy_async (struct gomp_device_descr *devicep,
+bool (*copy_func) (int, void *, const void *, size_t,
+   struct goacc_asyncqueue *),
+const char *dst, void *dstaddr,
+const char *src, const void *srcaddr,
+size_t size, struct goacc_asyncqueue *aq)
+{
+  if (!copy_func (devicep->target_id, dstaddr, srcaddr, size, aq))
+{
+  gomp_mutex_unlock (>lock);
+  gomp_fatal ("Copying of %s object [%p..%p) to %s object [%p..%p) failed",
+ src, srcaddr, srcaddr + size, dst, dstaddr, dstaddr + size);
+}
+}
+
 /* Infrastructure for coalescing adjacent or nearly adjacent (in device 
addresses)
host to device memory transfers.  */
 
@@ -263,8 +279,9 @@ gomp_to_device_kind_p (int kind)
 }
 }
 
-static void
+attribute_hidden void
 gomp_copy_host2dev (struct gomp_device_descr *devicep,
+   struct goacc_asyncqueue *aq,
void *d, const void *h, size_t sz,
struct gomp_coalesce_buf *cbuf)
 {
@@ -293,14 +310,23 @@ gomp_copy_host2dev (struct gomp_device_descr *devi
}
}
 }
-  gomp_device_copy (devicep, devicep->host2dev_func, "dev", d, "host", h, sz);
+  if (aq)
+goacc_device_copy_async (devicep, devicep->openacc.async.host2dev_func,
+"dev", d, "host", h, sz, aq);
+  else
+gomp_device_copy (devicep, devicep->host2dev_func, "dev", d, "host", h, 
sz);
 }
 
-static void
+attribute_hidden void
 gomp_copy_dev2host (struct gomp_device_descr *devicep,
+   struct goacc_asyncqueue *aq,
void *h, const void *d, size_t sz)
 {
-  gomp_device_copy (devicep, devicep->dev2host_func, "host", h, "dev", d, sz);
+  if (aq)
+goacc_device_copy_async (devicep, devicep->openacc.async.dev2host_func,
+"host", h, "dev", d, sz, aq);
+  else
+gomp_device_copy (devicep, devicep->dev2host_func, "host", h, "dev", d, 
sz);
 }
 
 static void
@@ -318,7 +344,8 @@ gomp_free_device_memory (struct gomp_device_descr
Helper function of gomp_map_vars.  */
 
 static inline void
-gomp_map_vars_existing (struct gomp_device_descr *devicep, splay_tree_key oldn,
+gomp_map_vars_existing (struct gomp_device_descr *devicep,
+   struct goacc_asyncqueue *aq, splay_tree_key oldn,
splay_tree_key newn, struct target_var_desc *tgt_var,
unsigned char kind, struct gomp_coalesce_buf *cbuf)
 {
@@ -340,7 +367,7 @@ static inline void
 }
 
   if (GOMP_MAP_ALWAYS_TO_P (kind))
-gomp_copy_host2dev (devicep,
+gomp_copy_host2dev (devicep, aq,
(void *) (oldn->tgt->tgt_start + oldn->tgt_offset
  + newn->host_start - oldn->host_start),
(void *) newn->host_start,
@@ -358,8 +385,8 @@ get_kind (bool short_mapkind, void *kinds, int idx
 }
 
 static void
-gomp_map_pointer (struct target_mem_desc *tgt, uintptr_t host_ptr,
- uintptr_t target_offset, uintptr_t bias,
+gomp_map_pointer (struct target_mem_desc *tgt, struct goacc_asyncqueue *aq,
+ uintptr_t host_ptr, 

Re: [PATCH] Delete powerpcspe

[Jeff Law]

On 12/11/18 1:44 AM, Richard Biener wrote:
> On Mon, Dec 10, 2018 at 9:13 PM Segher Boessenkool
>  wrote:
>>
>> On Mon, Dec 10, 2018 at 06:25:31PM +, Andrew Jenner wrote:
>>> Sorry for the slow response on this, I was on vacation last week.
>>>
>>> On 03/12/2018 21:48, Jakub Jelinek wrote:
 I'd give the maintainers the last week to act if they don't want this
 to happen and if nothing happens, commit it.  PR81084 lists all the reasons
 why it should be removed when it is totally unmaintained.
 Just make sure to put stuff that belongs there to gcc/ChangeLog and without
 gcc/ prefixes.
>>>
>>> Yes, please go ahead and commit
>>
>> Committed to trunk as r266961.
>>
>>> - it's not fair on other maintainers to
>>> have to work around my lack of action on this port. I will continue to
>>> work on it out-of-tree and hope to restore it once it is in proper shape.
>>
>> The more important thing is maintenance...  Regular and/or frequent tests
>> (posted to gcc-testresults@), bug tracker maintenance, etc.  You need to
>> be visible.
> 
> Very much agreed on that.  Though if we pull out this card we're applying
> double-standards here considering for example ia64 or some embedded ports.
The biggest problem with the embedded ports is lack of reliable
simulator testing combined with reduced address space availability.  So
you end up with a test that works fine today, but due to a runtime clash
of the stack and heap it may well fail tomorrow due to an unrelated code
change (by changing what's on the stack and where).  Or worse yet, you
end up with hundreds of tests that time out, causing the testrun to go
on so long it's useless.

One way to deal with these problems is to create a fake simulator that
always returns success.  That's what my tester does for the embedded
targets.  That allows us to do reliable compile-time tests as well as
the various scan-whatever tests.

It would be trivial to start sending those results to gcc-testresults.

jeff

Re: Too strict synchronization with the local (host) thread?

[Chung-Lin Tang]

On 2018/12/7 11:56 PM, Thomas Schwinge wrote:

--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-79.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-79.c
@@ -114,6 +114,7 @@ main (int argc, char **argv)
  
for (i = 0; i < N; i++)

  {
+  stream = (CUstream) acc_get_cuda_stream (i & 1);
r = cuLaunchKernel (delay, 1, 1, 1, 1, 1, 1, 0, stream, kargs, 0);

What's the motivation for this change?


To place work on both streams 0 and 1.


..., and this change are needed because we're now more strictly
synchronizing with the local (host) thread.

Regarding the case of "libgomp.oacc-c-c++-common/lib-81.c", as currently
present:

 [...]
   for (i = 0; i < N; i++)
 {
   r = cuLaunchKernel (delay, 1, 1, 1, 1, 1, 1, 0, streams[i], kargs, 
0);
   if (r != CUDA_SUCCESS)
 {
   fprintf (stderr, "cuLaunchKernel failed: %d\n", r);
   abort ();
 }
 }

This launches N kernels on N separate async queues/CUDA streams, [0..N).

   acc_wait_all_async (N);

Then, the "acc_wait_all_async (N)" -- in my understanding! -- should
*not*  synchronize with the local (host) thread, but instead just set up
the additional async queue/CUDA stream N to "depend" on [0..N).

   for (i = 0; i <= N; i++)
 {
   if (acc_async_test (i) != 0)
 abort ();
 }

Thus, all [0..N) should then still be "acc_async_test (i) != 0" (still
running).

   acc_wait (N);

Here, the "acc_wait (N)" would synchronize the local (host) thread with
async queue/CUDA stream N and thus recursively with [0..N).

   for (i = 0; i <= N; i++)
 {
   if (acc_async_test (i) != 1)
 abort ();
 }
 [...]

So, then all these async queues/CUDA streams here indeed are
"acc_async_test (i) != 1", thas is, idle.


Now, the more strict synchronization with the local (host) thread is not
wrong in term of correctness, but I suppose it will impact performance of
otherwise asynchronous operations, which now get synchronized too much?

Or, of course, I'm misunderstanding something...


IIRC, we encountered many issues where people misunderstood the meaning of 
"wait+async",
using it as if the local host sync happened, where in our original 
implementation it does not.

Also some areas of the OpenACC spec were vague on whether the local host 
synchronization should
or should not happen; basically, the wording treated as if it was only an 
implementation detail
and didn't matter, and didn't acknowledge that this would be something visible 
to the user.

At the end, IIRC, I decided that adding a local host synchronization is easier 
for all of us,
and took the opportunity of the re-org to make this change.

That said, I didn't notice those tests you listed above were meant to test such 
delicate behavior.


(For avoidance of doubt, I would accept the "async re-work" as is, but we
should eventually clarify this, and restore the behavior we -- apparently
-- had before, where we didn't synchronize so much?  (So, technically,
the "async re-work" would constitute a regression for this kind of
usage?)


It's not hard to restore the old behavior, just a few lines to delete. Although 
as described
above, this change was deliberate.

This might be another issue to raise with the committee. I think I tried on 
this exact issue
a long time ago, but never got answers.

Thanks,
Chung-Lin

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

[Jonathan Wakely]

On 11/12/18 13:28 +0100, Jakub Jelinek wrote:

On Tue, Dec 11, 2018 at 05:30:48PM +0530, Umesh Kalappa wrote:

Hi All,

Please find the attached patch for the subjected issue .

Do please let me know your thoughts and comments on the same .


Not a patch review (will defer that to rs6000 maintainers), but
some comments on gcc-patches patch submissions.

The subject should ideally start with [PATCH] or similar,
then have some short summary of what the patch is about and if
it fixes some PR, just PR something/12345 reference,
the subjects you are posting like:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762
don't say anything relevant except for the PR 84762 number,
so anyone reading gcc-patches needs to open that bug in order to even find
out if it is something for him or somebody else.

If you are sending a patch for an area that has some maintainer(s),
usually you should either mention those maintainers in To: (and CC:
gcc-patches) or To: gcc-patches, CC: the maintainers, to draw their
attention.  See MAINTAINERS file in GCC tree.

The mail body should start with a short explanation of what the problem is
and how are you solving it, again, so that people don't have to jump to
bugzilla to find out (of course, short is enough, no need to duplicate
dozens of comments from the PR), should include information on what
target(s) it has been bootstrapped/regtested.  And, it is always better if
it is the patch author that posts it, or is at least CCed so that he can
answer review questions.


Also, as noted at https://gcc.gnu.org/contribute.html#patches the
ChangeLog entry should be in plain text, not part of the patch.

"The ChangeLog entries should be plaintext rather than part of the
patch since the top of the ChangeLog changes rapidly and a patch to
the ChangeLog would probably no longer apply by the time your patch is
reviewed."

Some people add it as a second attachment, e.g.
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02524.html
or just inline in the email body, e.g.
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00622.html
Either is better than including the ChangeLog entry as part of the
patch itself.

Following the https://gcc.gnu.org/contribute.html#patches policies
will make it much more likely that patches will be seen by the right
people and reviewed.

Re: [C PATCH] Fix ubsan -fsanitize=float-cast-overflow ICE (PR sanitizer/88426)

[Marek Polacek]

On Tue, Dec 11, 2018 at 08:21:50AM +0100, Jakub Jelinek wrote:
> Hi!
> 
> The following testcase ICEs since the c_save_expr removal.  Unlike other
> spots where we use save_expr and potentially pass that to function ubsan
> calls, in this case we weren't calling c_fully_fold and
> c_fully_fold_internal unfortunately doesn't recurse into CALL_EXPRs, so
> the gimplifier then sees C_MAYBE_CONST_EXPRs and ICEs on them.  E.g.
> for shift sanitization etc. we call c_fully_fold like this.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2018-12-11  Jakub Jelinek  
> 
>   PR sanitizer/88426
>   * c-convert.c (convert): Call c_fully_fold before calling
>   ubsan_instrument_float_cast.
> 
>   * c-c++-common/ubsan/float-cast-overflow-11.c: New test.

Ok, thanks.

Marek

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

[Jakub Jelinek]

On Tue, Dec 11, 2018 at 05:30:48PM +0530, Umesh Kalappa wrote:
> Hi All,
> 
> Please find the attached patch for the subjected issue .
> 
> Do please let me know your thoughts and comments on the same .

Not a patch review (will defer that to rs6000 maintainers), but
some comments on gcc-patches patch submissions.

The subject should ideally start with [PATCH] or similar,
then have some short summary of what the patch is about and if
it fixes some PR, just PR something/12345 reference,
the subjects you are posting like:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762
don't say anything relevant except for the PR 84762 number,
so anyone reading gcc-patches needs to open that bug in order to even find
out if it is something for him or somebody else.

If you are sending a patch for an area that has some maintainer(s),
usually you should either mention those maintainers in To: (and CC:
gcc-patches) or To: gcc-patches, CC: the maintainers, to draw their
attention.  See MAINTAINERS file in GCC tree.

The mail body should start with a short explanation of what the problem is
and how are you solving it, again, so that people don't have to jump to
bugzilla to find out (of course, short is enough, no need to duplicate
dozens of comments from the PR), should include information on what
target(s) it has been bootstrapped/regtested.  And, it is always better if
it is the patch author that posts it, or is at least CCed so that he can
answer review questions.

Thanks.

Jakub

Re: [Ada] Add "Global => null" contracts to Ada.Calendar routines

[Piotr Trojanek]

On Tue, 11 Dec 2018 12:48:15 +0100, Florian Weimer wrote:
> * Pierre-Marie de Rodat:
> 
> > procedure Split
> >   (Date: Time;
> >Year: out Year_Number;
> >Month   : out Month_Number;
> >Day : out Day_Number;
> > -  Seconds : out Day_Duration);
> > +  Seconds : out Day_Duration)
> > +   with
> > + Global => null;
> 
> Is this really correct? Doesn't this call UTC_Time_Offset eventually, via
> Formatting_Operations.Split with Use_TZ => False?

You are right. I will remove the Global contracts from non-arithmetic routines.
Thanks for noticing this!

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

[Umesh Kalappa]

Hi All,

Please find the attached patch for the subjected issue .

Do please let me know your thoughts and comments on the same .

Thank you
~Umesh


pr84762.patch
Description: Binary data

Re: [Ada] Add "Global => null" contracts to Ada.Calendar routines

[Florian Weimer]

* Pierre-Marie de Rodat:

> procedure Split
>   (Date: Time;
>Year: out Year_Number;
>Month   : out Month_Number;
>Day : out Day_Number;
> -  Seconds : out Day_Duration);
> +  Seconds : out Day_Duration)
> +   with
> + Global => null;

Is this really correct?  Doesn't this call UTC_Time_Offset eventually,
via Formatting_Operations.Split with Use_TZ => False?

Thanks,
Florian

[Ada] Crash on misplaced First operation for GNAT iterable type

[Pierre-Marie de Rodat]

This patch improves the handling of an improper declaaration of aspect
First for a GNAT-defined iterable type,

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Ed Schonberg  

gcc/ada/

* sem_util.adb (Get_Actual_Subtype): Function can return type
mark.
(Get_Cursor_Type): Improve recovery and error message on a
misplaced First aspect for an iterable type.

gcc/testsuite/

* gnat.dg/iter4.adb: New testcase.--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -9049,6 +9049,13 @@ package body Sem_Util is
 
  else
 Decl := Build_Actual_Subtype (Typ, N);
+
+--  The call may yield a declaration, or just return the entity
+
+if Decl = Typ then
+   return Typ;
+end if;
+
 Atyp := Defining_Identifier (Decl);
 
 --  If Build_Actual_Subtype generated a new declaration then use it
@@ -9162,6 +9169,9 @@ package body Sem_Util is
   if First_Op = Any_Id then
  Error_Msg_N ("aspect Iterable must specify First operation", Aspect);
  return Any_Type;
+
+  elsif not Analyzed (First_Op) then
+ Analyze (First_Op);
   end if;
 
   Cursor := Any_Type;
@@ -9195,7 +9205,8 @@ package body Sem_Util is
 
   if Cursor = Any_Type then
  Error_Msg_N
-   ("No legal primitive operation First for Iterable type", Aspect);
+   ("primitive operation for Iterable type must appear "
+ & "in the same list of declarations as the type", Aspect);
   end if;
 
   return Cursor;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/iter4.adb
@@ -0,0 +1,36 @@
+--  { dg-do compile }
+
+procedure Iter4 is
+   package Root is
+  type Result is tagged record
+ B : Boolean;
+  end record;
+
+  type T is tagged record
+ I : Integer;
+  end record
+  with Iterable => (First   => Pkg.First, --  { dg-error "primitive operation for Iterable type must appear in the same list of declarations as the type" }
+Next=> Pkg.Next,
+Has_Element => Pkg.Has_Element,
+Element => Pkg.Element);
+
+  package Pkg is
+ function First (Dummy : T) return Natural is (0);
+ function Next (Dummy : T; Cursor : Natural) return Natural is
+   (Cursor + 1);
+ function Has_Element (Value : T; Cursor : Natural) return Boolean is
+   (Cursor <= Value.I);
+ function Element (Dummy : T; Cursor : Natural) return Result is
+   ((B => Cursor mod 2 = 0));
+  end Pkg;
+   end Root;
+
+   package Derived is
+  type T is new Root.T with record
+ C : Character;
+  end record;
+   end Derived;
+
+begin
+   null;
+end;

[Ada] Add "Global => null" contracts to Ada.Calendar routines

[Pierre-Marie de Rodat]

Routines in Ada.Real_Time are already annotated with Global => null
contracts to suppress spurious warnings from the flow analysis in
GNATprove. This patch adds such contracts to Ada.Calendar. No change in
runtime behavior expected.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Piotr Trojanek  

gcc/ada/

* libgnat/a-calend.ads: Add "Global => null" contracts to pure
routines.--- gcc/ada/libgnat/a-calend.ads
+++ gcc/ada/libgnat/a-calend.ads
@@ -61,17 +61,19 @@ is
--  the result will contain all elapsed leap seconds since the start of
--  Ada time until now.
 
-   function Year(Date : Time) return Year_Number;
-   function Month   (Date : Time) return Month_Number;
-   function Day (Date : Time) return Day_Number;
-   function Seconds (Date : Time) return Day_Duration;
+   function Year(Date : Time) return Year_Number  with Global => null;
+   function Month   (Date : Time) return Month_Number with Global => null;
+   function Day (Date : Time) return Day_Number   with Global => null;
+   function Seconds (Date : Time) return Day_Duration with Global => null;
 
procedure Split
  (Date: Time;
   Year: out Year_Number;
   Month   : out Month_Number;
   Day : out Day_Number;
-  Seconds : out Day_Duration);
+  Seconds : out Day_Duration)
+   with
+ Global => null;
--  Break down a time value into its date components set in the current
--  time zone. If Split is called on a time value created using Ada 2005
--  Time_Of in some arbitrary time zone, the input value will always be
@@ -81,7 +83,9 @@ is
  (Year: Year_Number;
   Month   : Month_Number;
   Day : Day_Number;
-  Seconds : Day_Duration := 0.0) return Time;
+  Seconds : Day_Duration := 0.0) return Time
+   with
+ Global => null;
--  GNAT Note: Normally when procedure Split is called on a Time value
--  result of a call to function Time_Of, the out parameters of procedure
--  Split are identical to the in parameters of function Time_Of. However,
@@ -97,19 +101,27 @@ is
--  Seconds may be 14340.0 (3:59:00) instead of 10740.0 (2:59:00 being
--  a time that not exist).
 
-   function "+" (Left : Time; Right : Duration) return Time;
-   function "+" (Left : Duration; Right : Time) return Time;
-   function "-" (Left : Time; Right : Duration) return Time;
-   function "-" (Left : Time; Right : Time) return Duration;
+   function "+" (Left : Time; Right : Duration) return Time
+   with
+ Global => null;
+   function "+" (Left : Duration; Right : Time) return Time
+   with
+ Global => null;
+   function "-" (Left : Time; Right : Duration) return Time
+   with
+ Global => null;
+   function "-" (Left : Time; Right : Time) return Duration
+   with
+ Global => null;
--  The first three functions will raise Time_Error if the resulting time
--  value is less than the start of Ada time in UTC or greater than the
--  end of Ada time in UTC. The last function will raise Time_Error if the
--  resulting difference cannot fit into a duration value.
 
-   function "<"  (Left, Right : Time) return Boolean;
-   function "<=" (Left, Right : Time) return Boolean;
-   function ">"  (Left, Right : Time) return Boolean;
-   function ">=" (Left, Right : Time) return Boolean;
+   function "<"  (Left, Right : Time) return Boolean with Global => null;
+   function "<=" (Left, Right : Time) return Boolean with Global => null;
+   function ">"  (Left, Right : Time) return Boolean with Global => null;
+   function ">=" (Left, Right : Time) return Boolean with Global => null;
 
Time_Error : exception;
 

[Ada] Do not expand code inside ignored ghost bodies

[Pierre-Marie de Rodat]

While ignored ghost code is not compiled into the executable, it may
lead to compilation errors when it makes use of language features
requiring runtime support that is not available in the available runtime
library.  These errors are spurious, as the executable will never call
in these runtime units.

This patch deactivates the expansion of code inside ignored ghost bodies
of subprograms and packages, so that this code is still checked for
possible semantic errors, but it does not force the presence of useless
runtime units.

There is no impact on the executable produced.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Yannick Moy  

gcc/ada/

* sem_ch6.adb (Analyze_Subprogram_Body_Helper): Deactivate
expansion in ignored ghost subprogram body.
* sem_ch7.adb (Analyze_Package_Body_Helper): Deactivate
expansion in ignored ghost package body.

gcc/testsuite/

* gnat.dg/ghost4.adb: New testcase.--- gcc/ada/sem_ch6.adb
+++ gcc/ada/sem_ch6.adb
@@ -3370,6 +3370,7 @@ package body Sem_Ch6 is
 
   Saved_GM   : constant Ghost_Mode_Type := Ghost_Mode;
   Saved_IGR  : constant Node_Id := Ignored_Ghost_Region;
+  Saved_EA   : constant Boolean := Expander_Active;
   Saved_ISMP : constant Boolean :=
  Ignore_SPARK_Mode_Pragmas_In_Instance;
   --  Save the Ghost and SPARK mode-related data to restore on exit
@@ -3610,6 +3611,18 @@ package body Sem_Ch6 is
  end if;
   end if;
 
+  --  Deactivate expansion inside the body of ignored Ghost entities,
+  --  as this code will ultimately be ignored. This avoids requiring the
+  --  presence of run-time units which are not needed. Only do this for
+  --  user entities, as internally generated entitities might still need
+  --  to be expanded (e.g. those generated for types).
+
+  if Present (Ignored_Ghost_Region)
+and then Comes_From_Source (Body_Id)
+  then
+ Expander_Active := False;
+  end if;
+
   --  Previously we scanned the body to look for nested subprograms, and
   --  rejected an inline directive if nested subprograms were present,
   --  because the back-end would generate conflicting symbols for the
@@ -4588,6 +4601,10 @@ package body Sem_Ch6 is
   end if;
 
<>
+  if Present (Ignored_Ghost_Region) then
+ Expander_Active := Saved_EA;
+  end if;
+
   Ignore_SPARK_Mode_Pragmas_In_Instance := Saved_ISMP;
   Restore_Ghost_Region (Saved_GM, Saved_IGR);
end Analyze_Subprogram_Body_Helper;

--- gcc/ada/sem_ch7.adb
+++ gcc/ada/sem_ch7.adb
@@ -669,6 +669,7 @@ package body Sem_Ch7 is
 
   Saved_GM   : constant Ghost_Mode_Type := Ghost_Mode;
   Saved_IGR  : constant Node_Id := Ignored_Ghost_Region;
+  Saved_EA   : constant Boolean := Expander_Active;
   Saved_ISMP : constant Boolean :=
  Ignore_SPARK_Mode_Pragmas_In_Instance;
   --  Save the Ghost and SPARK mode-related data to restore on exit
@@ -780,6 +781,18 @@ package body Sem_Ch7 is
 
   Mark_And_Set_Ghost_Body (N, Spec_Id);
 
+  --  Deactivate expansion inside the body of ignored Ghost entities,
+  --  as this code will ultimately be ignored. This avoids requiring the
+  --  presence of run-time units which are not needed. Only do this for
+  --  user entities, as internally generated entitities might still need
+  --  to be expanded (e.g. those generated for types).
+
+  if Present (Ignored_Ghost_Region)
+and then Comes_From_Source (Body_Id)
+  then
+ Expander_Active := False;
+  end if;
+
   --  If the body completes the initial declaration of a compilation unit
   --  which is subject to pragma Elaboration_Checks, set the model of the
   --  pragma because it applies to all parts of the unit.
@@ -1075,6 +1088,10 @@ package body Sem_Ch7 is
  end if;
   end if;
 
+  if Present (Ignored_Ghost_Region) then
+ Expander_Active := Saved_EA;
+  end if;
+
   Ignore_SPARK_Mode_Pragmas_In_Instance := Saved_ISMP;
   Restore_Ghost_Region (Saved_GM, Saved_IGR);
end Analyze_Package_Body_Helper;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/ghost4.adb
@@ -0,0 +1,15 @@
+pragma Restrictions (No_Secondary_Stack);
+
+procedure Ghost4 is
+
+   procedure Dummy with Ghost is
+  function Slice (S : String) return String is
+ (S (S'First .. S'First + 3));
+
+  X : String := Slice ("hello");
+   begin
+ null;
+   end Dummy;
+begin
+   Dummy;
+end Ghost4;

[Ada] Spurious error with pragma Thread_Local_Storage

[Pierre-Marie de Rodat]

The following patch modifies the checks related to pragma
Thread_Local_Storage to correct a confusion in semantics which led to
spurious errors.


-- Source --


--  pack.ads

package Pack is
   type Arr is array (1 .. 5) of Boolean;

   type Arr_With_Default is array (1 .. 5) of Boolean
 with Default_Component_Value => False;

   type Int is new Integer range 1 .. 5;

   type Int_With_Default is new Integer range 1 .. 5
 with Default_Value => 1;

   protected type Prot_Typ is
  entry E;
   end Prot_Typ;

   type Rec_1 is record
  Comp : Integer;
   end record;

   type Rec_2 is record
  Comp : Int;
   end record;

   type Rec_3 is record
  Comp : Int_With_Default;
   end record;

   task type Task_Typ is
  entry E;
   end Task_Typ;
end Pack;

--  pack.adb

package body Pack is
   function F (Val : Int) return Int is
   begin
  if Val <= 1 then
 return 1;
  else
 return F (Val - 1) * Val;
  end if;
   end F;

   function F (Val : Int_With_Default) return Int_With_Default is
   begin
  if Val <= 1 then
 return 1;
  else
 return F (Val - 1) * Val;
  end if;
   end F;

   function F (Val : Integer) return Integer is
   begin
  if Val <= 1 then
 return 1;
  else
 return F (Val - 1) * Val;
  end if;
   end F;

   protected body Prot_Typ is
  entry E when True is begin null; end E;
   end Prot_Typ;

   task body Task_Typ is
   begin
  accept E;
   end Task_Typ;

   Obj_1 : Arr;  --  OK
   pragma Thread_Local_Storage (Obj_1);

   Obj_2 : Arr := (others => True);  --  OK
   pragma Thread_Local_Storage (Obj_2);

   Obj_3 : Arr := (others => F (2) = Integer (3));   --  ERROR
   pragma Thread_Local_Storage (Obj_3);

   Obj_4 : Arr_With_Default; --  ERROR
   pragma Thread_Local_Storage (Obj_4);

   Obj_5 : Arr_With_Default := (others => True); --  OK
   pragma Thread_Local_Storage (Obj_5);

   Obj_6 : Arr_With_Default := (others => F (2) = Integer (3));  --  ERROR
   pragma Thread_Local_Storage (Obj_6);

   Obj_7 : Integer;  --  OK
   pragma Thread_Local_Storage (Obj_7);

   Obj_8 : Integer := 1; --  OK
   pragma Thread_Local_Storage (Obj_8);

   Obj_9 : Integer := F (2); --  ERROR
   pragma Thread_Local_Storage (Obj_9);

   Obj_10 : Int; --  OK
   pragma Thread_Local_Storage (Obj_10);

   Obj_11 : Int := 1;--  OK
   pragma Thread_Local_Storage (Obj_11);

   Obj_12 : Int := F (2);--  ERROR
   pragma Thread_Local_Storage (Obj_12);

   Obj_13 : Int_With_Default;--  ERROR
   pragma Thread_Local_Storage (Obj_13);

   Obj_14 : Int_With_Default := 1;   --  OK
   pragma Thread_Local_Storage (Obj_14);

   Obj_15 : Int_With_Default := F (2);   --  ERROR
   pragma Thread_Local_Storage (Obj_15);

   Obj_16 : Prot_Typ;--  ERROR
   pragma Thread_Local_Storage (Obj_16);

   Obj_17 : Rec_1;   --  OK
   pragma Thread_Local_Storage (Obj_17);

   Obj_18 : Rec_1 := (others => 1);  --  OK
   pragma Thread_Local_Storage (Obj_18);

   Obj_19 : Rec_1 := (others => F (2));  --  ERROR
   pragma Thread_Local_Storage (Obj_19);

   Obj_20 : Rec_2;   --  OK
   pragma Thread_Local_Storage (Obj_20);

   Obj_21 : Rec_2 := (others => 1);  --  OK
   pragma Thread_Local_Storage (Obj_21);

   Obj_22 : Rec_2 := (others => F (2));  --  ERROR
   pragma Thread_Local_Storage (Obj_22);

   Obj_23 : Rec_3;   --  ERROR
   pragma Thread_Local_Storage (Obj_23);

   Obj_24 : Rec_3 := (others => 1);  --  OK
   pragma Thread_Local_Storage (Obj_24);

   Obj_25 : Rec_3 := (others => F (2));  --  ERROR
   pragma Thread_Local_Storage (Obj_25);

   Obj_26 : Task_Typ;--  ERROR
   pragma Thread_Local_Storage (Obj_26);
end Pack;


-- Compilation and output --


$ gcc -c pack.adb
pack.adb:47:04: Thread_Local_Storage variable "Obj_4" is improperly
  initialized
pack.adb:47:04: only allowed initialization is explicit "null", static
  expression or static aggregate
pack.adb:62:04: Thread_Local_Storage variable "Obj_9" is improperly
  

[Ada] Improve error message when named number passed as global item

[Pierre-Marie de Rodat]

When a named number is used in Global/Depends contracts as global item,
the error message could be confusing to users new to Ada. Now the
message explains that named numbers are not objects.

For instance on the following illegal code snippet:

 $ gcc -c bad_global.ads

 1. package Bad_Global is
 2.
 3.X : constant := 1;
 4.Y : constant := 1.0;
 5.
 6.procedure P with
 7.  Global => (Input => X,
 |
>>> global item must denote object, state or current instance
of concurrent type
>>> named number "X" is not an object

 8. In_Out => Y);
  |
>>> global item must denote object, state or current instance
of concurrent type
>>> named number "Y" is not an object

 9.
10. end Bad_Global;

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Yannick Moy  

gcc/ada/

* sem_prag.adb (Analyze_Global_Item): Refine error message.--- gcc/ada/sem_prag.adb
+++ gcc/ada/sem_prag.adb
@@ -2282,6 +2282,12 @@ package body Sem_Prag is
   SPARK_Msg_N
 ("global item must denote object, state or current "
  & "instance of concurrent type", Item);
+
+  if Ekind (Item_Id) in Named_Kind then
+ SPARK_Msg_NE
+   ("\named number & is not an object", Item, Item);
+  end if;
+
   return;
end if;
 

[Ada] Volatility, validity checks, and System.Aux_DEC

[Pierre-Marie de Rodat]

This patch updates validity checks to prevent the validation of an
by-reference formal parameter because the parameter is not being read in
the process.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Hristian Kirtchev  

gcc/ada/

* checks.adb: Add with and use clauses for Sem_Mech.
(Ensure_Valid): Update the "annoying special case" to include
entry and function calls. Use Get_Called_Entity to obtain the
entry or subprogram being invoked, rather than retrieving it
manually. Parameters passed by reference do not need a validity
check.

gcc/testsuite/

* gnat.dg/valid4.adb, gnat.dg/valid4_pkg.adb,
gnat.dg/valid4_pkg.ads: New testcase.--- gcc/ada/checks.adb
+++ gcc/ada/checks.adb
@@ -50,6 +50,7 @@ with Sem_Ch3;  use Sem_Ch3;
 with Sem_Ch8;  use Sem_Ch8;
 with Sem_Disp; use Sem_Disp;
 with Sem_Eval; use Sem_Eval;
+with Sem_Mech; use Sem_Mech;
 with Sem_Res;  use Sem_Res;
 with Sem_Util; use Sem_Util;
 with Sem_Warn; use Sem_Warn;
@@ -6071,7 +6072,8 @@ package body Checks is
 
   --  An annoying special case. If this is an out parameter of a scalar
   --  type, then the value is not going to be accessed, therefore it is
-  --  inappropriate to do any validity check at the call site.
+  --  inappropriate to do any validity check at the call site. Likewise
+  --  if the parameter is passed by reference.
 
   else
  --  Only need to worry about scalar types
@@ -6097,25 +6099,20 @@ package body Checks is
   P := Parent (N);
end if;
 
-   --  Only need to worry if we are argument of a procedure call
-   --  since functions don't have out parameters. If this is an
-   --  indirect or dispatching call, get signature from the
-   --  subprogram type.
+   --  If this is an indirect or dispatching call, get signature
+   --  from the subprogram type.
 
-   if Nkind (P) = N_Procedure_Call_Statement then
+   if Nkind_In (P, N_Entry_Call_Statement,
+   N_Function_Call,
+   N_Procedure_Call_Statement)
+   then
+  E := Get_Called_Entity (P);
   L := Parameter_Associations (P);
 
-  if Is_Entity_Name (Name (P)) then
- E := Entity (Name (P));
-  else
- pragma Assert (Nkind (Name (P)) = N_Explicit_Dereference);
- E := Etype (Name (P));
-  end if;
-
   --  Only need to worry if there are indeed actuals, and if
-  --  this could be a procedure call, otherwise we cannot get a
-  --  match (either we are not an argument, or the mode of the
-  --  formal is not OUT). This test also filters out the
+  --  this could be a subprogram call, otherwise we cannot get
+  --  a match (either we are not an argument, or the mode of
+  --  the formal is not OUT). This test also filters out the
   --  generic case.
 
   if Is_Non_Empty_List (L) and then Is_Subprogram (E) then
@@ -6126,7 +6123,10 @@ package body Checks is
  F := First_Formal (E);
  A := First (L);
  while Present (F) loop
-if Ekind (F) = E_Out_Parameter and then A = N then
+if A = N
+  and then (Ekind (F) = E_Out_Parameter
+ or else Mechanism (F) = By_Reference)
+then
return;
 end if;
 

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/valid4.adb
@@ -0,0 +1,13 @@
+--  { dg-do run }
+--  { dg-options "-gnatVa" }
+
+with Valid4_Pkg; use Valid4_Pkg;
+
+procedure Valid4 is
+begin
+   Proc (Global);
+
+   if Global then
+  raise Program_Error;
+   end if;
+end Valid4;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/valid4_pkg.adb
@@ -0,0 +1,19 @@
+package body Valid4_Pkg is
+   procedure Inner_Proc (B : in out Boolean);
+   pragma Export_Procedure
+ (Inner_Proc,
+  External=> "Inner_Proc",
+  Parameter_Types => (Boolean),
+  Mechanism   => Reference);
+
+   procedure Inner_Proc (B : in out Boolean) is
+   begin
+  B := True;
+  Global := False;
+   end Inner_Proc;
+
+   procedure Proc (B : in out Boolean) is
+   begin
+  Inner_Proc (B);
+   end Proc;
+end Valid4_Pkg;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/valid4_pkg.ads
@@ -0,0 +1,10 @@
+package Valid4_Pkg is
+   Global : Boolean := False;
+
+   procedure Proc (B : in out Boolean);
+   pragma Export_Procedure
+ (Proc,
+  External=> "Proc",
+  Parameter_Types => (Boolean),
+  Mechanism   => 

[Ada] Fix setting of Has_Predicate flag for aggregate subtypes

[Pierre-Marie de Rodat]

This patch enures that the subtype of an aggregate has the Has_Predicate
flag properly set if the array component has a predicate, including the
case the predicate function for the component has not been constructed
yet.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Ed Schonberg  

gcc/ada/

* sem_aggr.adb (Array_Aggr_Subtype. Resolve_Aggr_Expr): Indicate
that aggregate subtype has a predicate if the component type has
a predicate; do not rely on exisatence of predicate function for
component, in case component is a type no yet frozen, for which
predicate function has not been created yet.--- gcc/ada/sem_aggr.adb
+++ gcc/ada/sem_aggr.adb
@@ -611,6 +611,16 @@ package body Sem_Aggr is
   Set_Is_Constrained (Itype, True);
   Set_Is_Internal(Itype, True);
 
+  if Has_Predicates (Typ) then
+ Set_Has_Predicates (Itype);
+
+ if Present (Predicate_Function (Typ)) then
+Set_Predicate_Function (Itype, Predicate_Function (Typ));
+ else
+Set_Predicated_Parent (Itype, Predicated_Parent (Typ));
+ end if;
+  end if;
+
   --  A simple optimization: purely positional aggregates of static
   --  components should be passed to gigi unexpanded whenever possible, and
   --  regardless of the staticness of the bounds themselves. Subsequent
@@ -1627,7 +1637,7 @@ package body Sem_Aggr is
  --  component assignments. If the expression covers several components
  --  the analysis and the predicate check take place later.
 
- if Present (Predicate_Function (Component_Typ))
+ if Has_Predicates (Component_Typ)
and then Analyzed (Expr)
  then
 Apply_Predicate_Check (Expr, Component_Typ);
@@ -4194,7 +4204,7 @@ package body Sem_Aggr is
  --  because the aggegate might not be expanded into individual
  --  component assignments.
 
- if Present (Predicate_Function (Expr_Type))
+ if Has_Predicates (Expr_Type)
and then Analyzed (Expr)
  then
 Apply_Predicate_Check (Expr, Expr_Type);

[Ada] Plug small loophole with pathological packed array type

[Pierre-Marie de Rodat]

This fixes a crash in gigi on a pathological packed array type, whose
component type is a record type without representation clause or packing
but with a clause that bumps its size to a non-multiple value of the
storage unit.  In this case, the front-end fails to detect that calls
to the packing manpulation routines of the run time are necessary.

The fix doesn't change anything for non-pathological cases, i.e. when
the component type has a representation clause or is packed.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Eric Botcazou  

gcc/ada/

* exp_aggr.adb (Packed_Array_Aggregate_Handled): Bail out for
any non-scalar type as component type of the array.

gcc/testsuite/

* gnat.dg/packed_array.adb, gnat.dg/packed_array.ads,
gnat.dg/packed_array_pkg.ads: New testcase.--- gcc/ada/exp_aggr.adb
+++ gcc/ada/exp_aggr.adb
@@ -7893,9 +7893,7 @@ package body Exp_Aggr is
  return False;
   end if;
 
-  if not Is_Scalar_Type (Component_Type (Typ))
-and then Has_Non_Standard_Rep (Component_Type (Typ))
-  then
+  if not Is_Scalar_Type (Ctyp) then
  return False;
   end if;
 

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/packed_array.adb
@@ -0,0 +1,5 @@
+package body Packed_Array is
+
+  procedure Dummy is null;
+
+end;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/packed_array.ads
@@ -0,0 +1,9 @@
+with Packed_Array_Pkg; use Packed_Array_Pkg;
+
+package Packed_Array is
+
+  C : constant Small_Rec2 := (Lo => 1, Hi => Max, A => (1 => (2, 3)));
+
+  procedure Dummy;
+
+end;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/packed_array_pkg.ads
@@ -0,0 +1,20 @@
+package Packed_Array_Pkg is
+
+  type Rec1 is record
+I : Integer;
+S : Short_Integer;
+  end record;
+  for Rec1'Size use 49;
+
+  type Arr is array (Positive range <>) of Rec1;
+  for Arr'Component_Size use 49;
+
+  type Rec2 (Lo, Hi : Positive) is record
+A : Arr (Lo .. Hi);
+  end record;
+
+  Max : Positive := 1;
+
+  subtype Small_Rec2 is Rec2 (1, Max);
+
+end;

[Ada] gnatbind: ghost code with -gnatQ

[Pierre-Marie de Rodat]

This patch fixes a bug where if a library unit is compiled with -gnatQ,
and that library unit is an ignored Ghost unit, then gnatbind silently
fails.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Bob Duff  

gcc/ada/

* gnat1drv.adb (gnat1drv): Pass the correct Object value when
calling Write_ALI in the case of -gnatQ.
* gnatbind.adb (Gnatbind): Avoid silent failure; give an error
message.--- gcc/ada/gnat1drv.adb
+++ gcc/ada/gnat1drv.adb
@@ -1452,10 +1452,11 @@ begin
  Tree_Gen;
 
  --  Generate ALI file if specially requested, or for missing subunits,
- --  subunits or predefined generic.
+ --  subunits or predefined generic. For ignored ghost code, the object
+ --  file IS generated, so Object should be True.
 
  if Opt.Force_ALI_Tree_File then
-Write_ALI (Object => False);
+Write_ALI (Object => Is_Ignored_Ghost_Unit (Main_Unit_Node));
  end if;
 
  Namet.Finalize;

--- gcc/ada/gnatbind.adb
+++ gcc/ada/gnatbind.adb
@@ -790,6 +790,7 @@ begin
   --  Quit if some file needs compiling
 
   if No_Object_Specified then
+ Error_Msg ("no object specified");
  raise Unrecoverable_Error;
   end if;
 

[Ada] Missing predicate check on declaration with aggregate expression

[Pierre-Marie de Rodat]

This patch adds a missing predicate check on the initial value of an
object whose declaration initializes the object with an aggregate. Such
a declaration is marked No_Initialization to prevent a call to a default
initialization procedure, but the check is needed on the value of the
aggregate.

Executing the following:

   gnatmake -q -gnata pred
   ./pred

must yield:

   raised SYSTEM.ASSERTIONS.ASSERT_FAILURE :
 Dynamic_Predicate failed at root.ads:30


with Root;

procedure Pred is
begin
   null;
end Pred;

package Root with SPARK_Mode is
   type Index_Type is range 1 .. Natural'Last;

   type Element_Type is private;
   Null_Element : constant Element_Type;

   type Foobar_Type is array (Index_Type range <>) of Element_Type
 with Dynamic_Predicate =>
Foobar_Type'First > 0 and Foobar_Type'Length > 0;

   Null_Foobar : constant Foobar_Type;

private
   type Kind_Type is (Kind_Invalid, Kind_Valid);

   type Element_Type (Kind : Kind_Type := Kind_Invalid) is record
  Index1 : Index_Type;

  case Kind is
 when Kind_Valid =>
Index2 : Index_Type;
 when Kind_Invalid =>
null;
  end case;
   end record;

   Null_Element : constant Element_Type := (Kind   => Kind_Invalid,
Index1 => Index_Type'First);

   Null_Foobar : constant Foobar_Type := (1 .. 0 => Null_Element);
end Root;

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Ed Schonberg  

gcc/ada/

* sem_ch3.adb (Analyze_Object_Declaration): Apply
Dynamic_Predicate check to an object of an array type
initialized with an aggregate.--- gcc/ada/sem_ch3.adb
+++ gcc/ada/sem_ch3.adb
@@ -4454,11 +4454,16 @@ package body Sem_Ch3 is
   --  default initialization when we have at least one case of an explicit
   --  default initial value and then this is not an internal declaration
   --  whose initialization comes later (as for an aggregate expansion).
+  --  If expression is an aggregate it may be expanded into assignments
+  --  and the declaration itself is marked with No_Initialization, but
+  --  the predicate still applies.
 
   if not Suppress_Assignment_Checks (N)
 and then Present (Predicate_Function (T))
 and then not Predicates_Ignored (T)
-and then not No_Initialization (N)
+and then
+  (not No_Initialization (N)
+or else (Present (E) and then Nkind (E) = N_Aggregate))
 and then
   (Present (E)
 or else

[Ada] Crash on generic instantiation in ignored Ghost context

[Pierre-Marie de Rodat]

The following patch corrects the freezing of entities to properly
preserve all freeze nodes in case of recursive freezing when the context
is ignored Ghost, and the construct frozen is non-Ghost.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Hristian Kirtchev  

gcc/ada/

* freeze.adb (Add_To_Result): Move the ignored Ghost-specific
handling of freeze nodes to...
(Freeze_Entity): ...here. This ensures that the freeze nodes of
constructs that have recursive freezing are preserved when the
context is ignored Ghost, and the top level construct being
frozen is non-Ghost.

gcc/testsuite/

* gnat.dg/ghost3.adb, gnat.dg/ghost3.ads: New testcase.--- gcc/ada/freeze.adb
+++ gcc/ada/freeze.adb
@@ -2241,29 +2241,7 @@ package body Freeze is
 
   procedure Add_To_Result (Fnod : Node_Id) is
   begin
- --  The Ghost mode of the enclosing context is ignored, while the
- --  entity being frozen is living. Insert the freezing action prior
- --  to the start of the enclosing ignored Ghost region. As a result
- --  the freezeing action will be preserved when the ignored Ghost
- --  context is eliminated. The insertion must take place even when
- --  the context is a spec expression, otherwise "Handling of Default
- --  and Per-Object Expressions" will suppress the insertion, and the
- --  freeze node will be dropped on the floor.
-
- if Saved_GM = Ignore
-   and then Ghost_Mode /= Ignore
-   and then Present (Ignored_Ghost_Region)
- then
-Insert_Action
-  (Assoc_Node   => Ignored_Ghost_Region,
-   Ins_Action   => Fnod,
-   Spec_Expr_OK => True);
-
- --  Otherwise add the freezing action to the result list
-
- else
-Append_New_To (Result, Fnod);
- end if;
+ Append_New_To (Result, Fnod);
   end Add_To_Result;
 
   
@@ -5301,6 +5279,7 @@ package body Freeze is
 
   if Is_Itype (E) and then Is_Record_Type (Scope (E)) then
  Test_E := Scope (E);
+
   elsif Is_Itype (E) and then Present (Underlying_Type (Scope (E)))
 and then Is_Record_Type (Underlying_Type (Scope (E)))
   then
@@ -5582,8 +5561,8 @@ package body Freeze is
  --  Here for other than a subprogram or type
 
  else
---  If entity has a type, and it is not a generic unit, then
---  freeze it first (RM 13.14(10)).
+--  If entity has a type, and it is not a generic unit, then freeze
+--  it first (RM 13.14(10)).
 
 if Present (Etype (E))
   and then Ekind (E) /= E_Generic_Function
@@ -5603,7 +5582,7 @@ package body Freeze is
  and then Has_Delayed_Aspects (E)
then
   Set_Has_Delayed_Aspects (E, False);
-  Set_Has_Delayed_Freeze (E, False);
+  Set_Has_Delayed_Freeze  (E, False);
   Set_Freeze_Node (E, Empty);
end if;
 end if;
@@ -6916,18 +6895,35 @@ package body Freeze is
 
   Check_Debug_Info_Needed (E);
 
-  --  Special handling for subprograms
+  --  If subprogram has address clause then reset Is_Public flag, since we
+  --  do not want the backend to generate external references.
 
-  if Is_Subprogram (E) then
+  if Is_Subprogram (E)
+and then Present (Address_Clause (E))
+and then not Is_Library_Level_Entity (E)
+  then
+ Set_Is_Public (E, False);
+  end if;
 
- --  If subprogram has address clause then reset Is_Public flag, since
- --  we do not want the backend to generate external references.
+  --  The Ghost mode of the enclosing context is ignored, while the
+  --  entity being frozen is living. Insert the freezing action prior
+  --  to the start of the enclosing ignored Ghost region. As a result
+  --  the freezeing action will be preserved when the ignored Ghost
+  --  context is eliminated. The insertion must take place even when
+  --  the context is a spec expression, otherwise "Handling of Default
+  --  and Per-Object Expressions" will suppress the insertion, and the
+  --  freeze node will be dropped on the floor.
+
+  if Saved_GM = Ignore
+and then Ghost_Mode /= Ignore
+and then Present (Ignored_Ghost_Region)
+  then
+ Insert_Actions
+   (Assoc_Node   => Ignored_Ghost_Region,
+Ins_Actions  => Result,
+Spec_Expr_OK => True);
 
- if Present (Address_Clause (E))
-   and then not Is_Library_Level_Entity (E)
- then
-Set_Is_Public (E, False);
- end if;
+ Result := No_List;
   end if;
 
<>

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/ghost3.adb
@@ -0,0 +1,5 @@
+--  { dg-do compile }
+

[Ada] Crash on ignored Ghost expression function

[Pierre-Marie de Rodat]

This patch updates freezing to ensure that freeze nodes are inserted
into the tree when the entity being frozen is non-Ghost, and the context
is an ignored Ghost spec expression.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Hristian Kirtchev  

gcc/ada/

* exp_util.adb (Insert_Action): Add new formal parameter
Spec_Expr_OK.
(Insert_Actions): Add new formal parameter Spec_Expr_OK. Update
all calls to Insert_Actions where relevant. Honour an insertion
from a spec expression context when requested by the caller.
* exp_util.ads (Insert_Action): Add new formal parameter
Spec_Expr_OK.
(Insert_Actions): Add new formal parameter Spec_Expr_OK.
* freeze.adb (Add_To_Result): Force the insertion of the freeze
node even when the context is a spec expression.

gcc/testsuite/

* gnat.dg/ghost2.adb, gnat.dg/ghost2.ads: New testcase.--- gcc/ada/exp_util.adb
+++ gcc/ada/exp_util.adb
@@ -6702,20 +6702,34 @@ package body Exp_Util is
-- Insert_Action --
---
 
-   procedure Insert_Action (Assoc_Node : Node_Id; Ins_Action : Node_Id) is
+   procedure Insert_Action
+ (Assoc_Node   : Node_Id;
+  Ins_Action   : Node_Id;
+  Spec_Expr_OK : Boolean := False)
+   is
begin
   if Present (Ins_Action) then
- Insert_Actions (Assoc_Node, New_List (Ins_Action));
+ Insert_Actions
+   (Assoc_Node   => Assoc_Node,
+Ins_Actions  => New_List (Ins_Action),
+Spec_Expr_OK => Spec_Expr_OK);
   end if;
end Insert_Action;
 
--  Version with check(s) suppressed
 
procedure Insert_Action
- (Assoc_Node : Node_Id; Ins_Action : Node_Id; Suppress : Check_Id)
+ (Assoc_Node   : Node_Id;
+  Ins_Action   : Node_Id;
+  Suppress : Check_Id;
+  Spec_Expr_OK : Boolean := False)
is
begin
-  Insert_Actions (Assoc_Node, New_List (Ins_Action), Suppress);
+  Insert_Actions
+(Assoc_Node   => Assoc_Node,
+ Ins_Actions  => New_List (Ins_Action),
+ Suppress => Suppress,
+ Spec_Expr_OK => Spec_Expr_OK);
end Insert_Action;
 
-
@@ -6734,7 +6748,11 @@ package body Exp_Util is
-- Insert_Actions --

 
-   procedure Insert_Actions (Assoc_Node : Node_Id; Ins_Actions : List_Id) is
+   procedure Insert_Actions
+ (Assoc_Node   : Node_Id;
+  Ins_Actions  : List_Id;
+  Spec_Expr_OK : Boolean := False)
+   is
   N : Node_Id;
   P : Node_Id;
 
@@ -6745,14 +6763,20 @@ package body Exp_Util is
  return;
   end if;
 
+  --  Insert the action when the context is "Handling of Default and Per-
+  --  Object Expressions" only when requested by the caller.
+
+  if Spec_Expr_OK then
+ null;
+
   --  Ignore insert of actions from inside default expression (or other
   --  similar "spec expression") in the special spec-expression analyze
   --  mode. Any insertions at this point have no relevance, since we are
   --  only doing the analyze to freeze the types of any static expressions.
-  --  See section "Handling of Default Expressions" in the spec of package
-  --  Sem for further details.
+  --  See section "Handling of Default and Per-Object Expressions" in the
+  --  spec of package Sem for further details.
 
-  if In_Spec_Expression then
+  elsif In_Spec_Expression then
  return;
   end if;
 
@@ -7429,9 +7453,10 @@ package body Exp_Util is
--  Version with check(s) suppressed
 
procedure Insert_Actions
- (Assoc_Node  : Node_Id;
-  Ins_Actions : List_Id;
-  Suppress: Check_Id)
+ (Assoc_Node   : Node_Id;
+  Ins_Actions  : List_Id;
+  Suppress : Check_Id;
+  Spec_Expr_OK : Boolean := False)
is
begin
   if Suppress = All_Checks then
@@ -7439,7 +7464,7 @@ package body Exp_Util is
 Sva : constant Suppress_Array := Scope_Suppress.Suppress;
  begin
 Scope_Suppress.Suppress := (others => True);
-Insert_Actions (Assoc_Node, Ins_Actions);
+Insert_Actions (Assoc_Node, Ins_Actions, Spec_Expr_OK);
 Scope_Suppress.Suppress := Sva;
  end;
 
@@ -7448,7 +7473,7 @@ package body Exp_Util is
 Svg : constant Boolean := Scope_Suppress.Suppress (Suppress);
  begin
 Scope_Suppress.Suppress (Suppress) := True;
-Insert_Actions (Assoc_Node, Ins_Actions);
+Insert_Actions (Assoc_Node, Ins_Actions, Spec_Expr_OK);
 Scope_Suppress.Suppress (Suppress) := Svg;
  end;
   end if;

--- gcc/ada/exp_util.ads
+++ gcc/ada/exp_util.ads
@@ -89,39 +89,54 @@ package Exp_Util is
--  calls, and this guarantee is preserved for the special cases above.
 
procedure Insert_Action
- (Assoc_Node : Node_Id;
-  Ins_Action : Node_Id);
+ (Assoc_Node   : Node_Id;
+  

[Ada] Crash on compilation unit function that builds in place

[Pierre-Marie de Rodat]

This patch fixes a crash on a function that builds its limited result in
place. Previously this was handled properly only if the function was a
child unit.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Ed Schonberg  

gcc/ada/

* sem_ch3.adb (Build_Itype_Reference): Handle properly an itype
reference created for a function that is a compilation unit, for
example if the function builds in place an object of a limited
type.

gcc/testsuite/

* gnat.dg/bip_cu.adb, gnat.dg/bip_cu_constructor.adb,
gnat.dg/bip_cu_constructor.ads, gnat.dg/bip_cu_t.adb,
gnat.dg/bip_cu_t.ads: New testcase.--- gcc/ada/sem_ch3.adb
+++ gcc/ada/sem_ch3.adb
@@ -10368,12 +10368,13 @@ package body Sem_Ch3 is
  --  If Nod is a library unit entity, then Insert_After won't work,
  --  because Nod is not a member of any list. Therefore, we use
  --  Add_Global_Declaration in this case. This can happen if we have a
- --  build-in-place library function.
+ --  build-in-place library function, child unit or not.
 
  if (Nkind (Nod) in N_Entity and then Is_Compilation_Unit (Nod))
or else
- (Nkind (Nod) = N_Defining_Program_Unit_Name
-   and then Is_Compilation_Unit (Defining_Identifier (Nod)))
+ (Nkind_In (Nod,
+N_Defining_Program_Unit_Name, N_Subprogram_Declaration)
+   and then Is_Compilation_Unit (Defining_Entity (Nod)))
  then
 Add_Global_Declaration (IR);
  else

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/bip_cu.adb
@@ -0,0 +1,10 @@
+--  { dg-do compile }
+
+with BIP_CU_T; use BIP_CU_T;
+with BIP_CU_Constructor;
+
+procedure BIP_CU is
+Value : constant T := BIP_CU_Constructor;
+begin
+null;
+end;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/bip_cu_constructor.adb
@@ -0,0 +1,5 @@
+with BIP_CU_T; use BIP_CU_T;
+function BIP_CU_Constructor return T is
+begin
+   return Make_T (Name => "Rumplestiltskin");
+end BIP_CU_Constructor;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/bip_cu_constructor.ads
@@ -0,0 +1,2 @@
+with BIP_CU_T; use BIP_CU_T;
+function BIP_CU_Constructor return T;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/bip_cu_t.adb
@@ -0,0 +1,8 @@
+package body BIP_CU_T is
+
+   function Make_T (Name : String) return T is
+   begin
+  return (Name => To_Unbounded_String (Name), others => <>);
+   end Make_T;
+
+end BIP_CU_T;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/bip_cu_t.ads
@@ -0,0 +1,10 @@
+with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
+
+package BIP_CU_T is
+   type T is limited private;
+   function Make_T (Name : String) return T;
+private
+   type T is limited record
+  Name : Unbounded_String;
+   end record;
+end BIP_CU_T;

[Ada] Remove vxlink and vxaddr2line from this repository

[Pierre-Marie de Rodat]

Those tools need a dedicated repository as they're VxWorks specific and
not related with the Ada front-end.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Jerome Lambourg  

gcc/ada/

* vxaddr2line.adb, vxlink-bind.adb, vxlink-bind.ads,
vxlink-link.adb, vxlink-link.ads, vxlink-main.adb, vxlink.adb,
vxlink.ads: Remove.
* gcc-interface/Make-lang.in, gcc-interface/Makefile.in: Remove
bits for vxaddr2line.--- gcc/ada/gcc-interface/Make-lang.in
+++ gcc/ada/gcc-interface/Make-lang.in
@@ -675,12 +675,10 @@ regnattools:
 cross-gnattools: force
 	$(MAKE) -C ada $(ADA_TOOLS_FLAGS_TO_PASS) gnattools1-re
 	$(MAKE) -C ada $(ADA_TOOLS_FLAGS_TO_PASS) gnattools2
-	$(MAKE) -C ada $(ADA_TOOLS_FLAGS_TO_PASS) gnattools4
 
 canadian-gnattools: force
 	$(MAKE) -C ada $(ADA_TOOLS_FLAGS_TO_PASS) gnattools1-re
 	$(MAKE) -C ada $(ADA_TOOLS_FLAGS_TO_PASS) gnattools2
-	$(MAKE) -C ada $(ADA_TOOLS_FLAGS_TO_PASS) gnattools4
 
 gnatlib gnatlib-sjlj gnatlib-zcx gnatlib-shared: force
 	$(MAKE) -C ada $(COMMON_FLAGS_TO_PASS)  \
@@ -811,8 +809,6 @@ doc/gnat-style.pdf: ada/gnat-style.texi $(gcc_docdir)/include/fdl.texi
 # gnatlink, gnatls, gnatmake, gnatname, gnatprep, gnatxref, gnatfind,
 # gnatclean).
 # gnatdll is only used on Windows.
-# vxaddr2line is only used for cross VxWorks ports (it calls the underlying
-# cross addr2line).
 ada.install-common:
 	$(MKDIR) $(DESTDIR)$(bindir)
 	-if [ -f gnat1$(exeext) ] ; \
@@ -829,11 +825,6 @@ ada.install-common:
 	  done; \
 	  $(RM) $(DESTDIR)$(bindir)/gnatdll$(exeext); \
 	  $(INSTALL_PROGRAM) gnatdll$(exeext) $(DESTDIR)$(bindir)/gnatdll$(exeext); \
-	  if [ -f vxaddr2line$(exeext) ] ; \
-	  then \
-	$(RM) $(DESTDIR)$(bindir)/vxaddr2line$(exeext); \
-	$(INSTALL_PROGRAM) vxaddr2line$(exeext) $(DESTDIR)$(bindir)/vxaddr2line$(exeext); \
-	  fi ; \
 	fi
 
 #
@@ -859,7 +850,6 @@ ada.uninstall:
 	  -$(RM) $(DESTDIR)$(bindir)/$$install_name; \
 	done
 	-$(RM) $(DESTDIR)$(tooldir)/bin/gnatdll$(exeext)
-	-$(RM) $(DESTDIR)$(tooldir)/bin/vxaddr2line$(exeext)
 
 # Clean hooks:
 # A lot of the ancillary files are deleted by the main makefile.

--- gcc/ada/gcc-interface/Makefile.in
+++ gcc/ada/gcc-interface/Makefile.in
@@ -434,19 +434,6 @@ gnattools2: ../stamp-tools
 	$(MAKE) -C tools -f ../Makefile $(TOOLS_FLAGS_TO_PASS) \
 	  TOOLSCASE=native common-tools $(EXTRA_GNATTOOLS)
 
-# those tools are only built for the cross version
-gnattools4: ../stamp-tools
-ifeq ($(ENABLE_VXADDR2LINE),true)
-	$(MAKE) -C tools -f ../Makefile $(TOOLS_FLAGS_TO_PASS) \
-	  TOOLSCASE=cross top_buildir=../../.. \
-	  ../../vxaddr2line$(exeext)
-endif
-ifeq ($(ENABLE_VXLINK),true)
-	$(MAKE) -C tools -f ../Makefile $(TOOLS_FLAGS_TO_PASS) \
-	  TOOLSCASE=cross top_build=../../.. \
-	  ../../vxlink$(exeext)
-endif
-
 common-tools: ../stamp-tools
 	$(GNATMAKE) -j0 -c -b $(ADA_INCLUDES) \
 	  --GNATBIND="$(GNATBIND)" --GCC="$(CC) $(ALL_ADAFLAGS)" \
@@ -477,18 +464,6 @@ common-tools: ../stamp-tools
 	$(GNATLINK) -v gnatdll -o $@ \
 	  --GCC="$(CC) $(ADA_INCLUDES)" --LINK="$(GCC_LINK)" $(TOOLS_LIBS)
 
-../../vxaddr2line$(exeext): ../stamp-tools
-	$(GNATMAKE) -c  $(ADA_INCLUDES) vxaddr2line --GCC="$(CC) $(ALL_ADAFLAGS)"
-	$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) vxaddr2line
-	$(GNATLINK) -v vxaddr2line -o $@ \
-	  --GCC="$(CC) $(ADA_INCLUDES)" --LINK="$(GCC_LINK)" ../targext.o $(CLIB)
-
-../../vxlink$(exeext): ../stamp-tools
-	$(GNATMAKE) -c  $(ADA_INCLUDES) vxlink-main --GCC="$(CC) $(ALL_ADAFLAGS)"
-	$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) vxlink-main
-	$(GNATLINK) -v vxlink-main -o $@ \
-	  --GCC="$(CC) $(ADA_INCLUDES)" --LINK="$(GCC_LINK)"
-
 gnatmake-re: ../stamp-tools
 	$(GNATMAKE) -j0 $(ADA_INCLUDES) -u sdefault --GCC="$(CC) $(MOST_ADA_FLAGS)"
 	$(GNATMAKE) -j0 -c $(ADA_INCLUDES) gnatmake --GCC="$(CC) $(ALL_ADAFLAGS)"

--- gcc/ada/vxaddr2line.adb
deleted file mode 100644
+++ /dev/null
@@ -1,525 +0,0 @@
---
---  --
--- GNAT COMPILER COMPONENTS --
---  --
---   V X A D D R 2 L I N E  --
---  --
--- B o d y  --
---  --
--- Copyright (C) 2002-2018, AdaCore --
---  --
--- GNAT is free software;  you can  redistribute it  and/or modify it under --
--- terms of the  GNU General Public License as published  by the Free Soft- --
--- ware  Foundation;  either version 3,  or (at your option) any later ver- --
--- sion.  GNAT is distributed in the 

[Ada] Complete implementation of RM C.6(19) clause

[Pierre-Marie de Rodat]

This ensures that the compiler fully implements the C.6(19) clause of
the Ada Reference Manual and gives a warning when the clause does change
the passing mechanism of the affected parameter.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Eric Botcazou  

gcc/ada/

* fe.h (Is_Atomic_Object): Declare.
(Is_Volatile_Object): Likewise.
* gcc-interface/trans.c (atomic_or_volatile_copy_required_p):
New.
(Call_to_gnu): Generate a copy for an actual parameter passed by
reference if the conditions set forth by RM C.6(19) are met and
specificially deal with an atomic actual parameter.

gcc/testsuite/

* gnat.dg/atomic11.adb, gnat.dg/atomic11_pkg1.ads,
gnat.dg/atomic11_pkg2.ads: New testcase.--- gcc/ada/fe.h
+++ gcc/ada/fe.h
@@ -281,13 +281,17 @@ extern Boolean Is_OK_Static_Subtype	(Entity_Id);
 #define Defining_Entity			sem_util__defining_entity
 #define First_Actual			sem_util__first_actual
 #define Next_Actual			sem_util__next_actual
+#define Is_Atomic_Object		sem_util__is_atomic_object
 #define Is_Variable_Size_Record 	sem_util__is_variable_size_record
+#define Is_Volatile_Object		sem_util__is_volatile_object
 #define Requires_Transient_Scope	sem_util__requires_transient_scope
 
 extern Entity_Id Defining_Entity	(Node_Id);
 extern Node_Id First_Actual		(Node_Id);
 extern Node_Id Next_Actual		(Node_Id);
+extern Boolean Is_Atomic_Object 	(Node_Id);
 extern Boolean Is_Variable_Size_Record 	(Entity_Id Id);
+extern Boolean Is_Volatile_Object 	(Node_Id);
 extern Boolean Requires_Transient_Scope	(Entity_Id);
 
 /* sinfo: */

--- gcc/ada/gcc-interface/trans.c
+++ gcc/ada/gcc-interface/trans.c
@@ -4936,6 +4936,35 @@ create_init_temporary (const char *prefix, tree gnu_init, tree *gnu_init_stmt,
   return gnu_temp;
 }
 
+/* Return whether ACTUAL parameter corresponding to FORMAL_TYPE must be passed
+   by copy in a call as per RM C.6(19).  Note that we use the same predicates
+   as in the front-end for RM C.6(12) because it's purely a legality issue.  */
+
+static bool
+atomic_or_volatile_copy_required_p (Node_Id actual, Entity_Id formal_type)
+{
+  /* We should not have a scalar type here because such a type is passed
+ by copy.  But the Interlocked routines in System.Aux_DEC force some
+ of the their scalar parameters to be passed by reference so we need
+ to preserve that if we do not want to break the interface.  */
+  if (Is_Scalar_Type (formal_type))
+return false;
+
+  if (Is_Atomic_Object (actual) && !Is_Atomic (formal_type))
+{
+  post_error ("?atomic actual passed by copy (RM C.6(19))", actual);
+  return true;
+}
+
+  if (Is_Volatile_Object (actual) && !Is_Volatile (formal_type))
+{
+  post_error ("?volatile actual passed by copy (RM C.6(19))", actual);
+  return true;
+}
+
+  return false;
+}
+
 /* Subroutine of gnat_to_gnu to translate gnat_node, either an N_Function_Call
or an N_Procedure_Call_Statement, to a GCC tree, which is returned.
GNU_RESULT_TYPE_P is a pointer to where we should place the result type.
@@ -5150,13 +5179,18 @@ Call_to_gnu (Node_Id gnat_node, tree *gnu_result_type_p, tree gnu_target,
 	  = build_compound_expr (TREE_TYPE (gnu_name), init, gnu_name);
 	}
 
-  /* If we are passing a non-addressable parameter by reference, pass the
-	 address of a copy.  In the In Out or Out case, set up to copy back
-	 out after the call.  */
+  /* If we are passing a non-addressable actual parameter by reference,
+	 pass the address of a copy and, in the In Out or Out case, set up
+	 to copy back after the call.  We also need to do that if the actual
+	 parameter is atomic or volatile but the formal parameter is not.  */
   if (is_by_ref_formal_parm
 	  && (gnu_name_type = gnat_to_gnu_type (Etype (gnat_name)))
-	  && !addressable_p (gnu_name, gnu_name_type))
+	  && (!addressable_p (gnu_name, gnu_name_type)
+	  || (Comes_From_Source (gnat_node)
+		  && atomic_or_volatile_copy_required_p (gnat_actual,
+			 gnat_formal_type
 	{
+	  const bool atomic_p = atomic_access_required_p (gnat_actual, );
 	  tree gnu_orig = gnu_name, gnu_temp, gnu_stmt;
 
 	  /* Do not issue warnings for CONSTRUCTORs since this is not a copy
@@ -5236,6 +5270,8 @@ Call_to_gnu (Node_Id gnat_node, tree *gnu_result_type_p, tree gnu_target,
 	}
 
 	  /* Create an explicit temporary holding the copy.  */
+	  if (atomic_p)
+	gnu_name = build_atomic_load (gnu_name, sync);
 	  gnu_temp
 	= create_init_temporary ("A", gnu_name, _stmt, gnat_actual);
 
@@ -5256,8 +5292,13 @@ Call_to_gnu (Node_Id gnat_node, tree *gnu_result_type_p, tree gnu_target,
 		 (TREE_OPERAND (TREE_OPERAND (gnu_orig, 1), 1)))
 		gnu_orig = TREE_OPERAND (gnu_orig, 2);
 
-	  gnu_stmt
-		= build_binary_op (MODIFY_EXPR, NULL_TREE, gnu_orig, gnu_temp);
+	  if (atomic_p)
+		gnu_stmt
+		  = build_atomic_store (gnu_orig, gnu_temp, sync);
+	  else
+		gnu_stmt
+		  = build_binary_op 

[Ada] Support access types in GNATprove

[Pierre-Marie de Rodat]

SPARK RM has been updated to support access types in SPARK. Part of this
support is that now SPARK RM 3.1 lists access types as having full
default initialization. Now updated.

There is no impact on compilation.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Yannick Moy  

gcc/ada/

* sem_util.adb (Has_Full_Default_Initialization): Consider
access types as having full default initialization.--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -10880,6 +10880,11 @@ package body Sem_Util is
   if Is_Scalar_Type (Typ) then
  return Has_Default_Aspect (Typ);
 
+  --  An access type is fully default initialized by default
+
+  elsif Is_Access_Type (Typ) then
+ return True;
+
   --  An array type is fully default initialized if its element type is
   --  scalar and the array type carries aspect Default_Component_Value or
   --  the element type is fully default initialized.

[Ada] Better error message from GNATprove on illegal switch

[Pierre-Marie de Rodat]

When a compilation switch is wrongly passed to GNATprove without the
leading hyphen, this patch issues a clear error message instead of the
obscure 'usage' message previously displayed.

There is no impact on compilation.

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Yannick Moy  

gcc/ada/

* gnat1drv.adb (Gnat1drv): Issue specific error message in
GNATprove mode when multiple file names on the command line.
* osint.adb, osint.ads (Dump_Command_Line_Source_File_Names):
New procedure to print file names on the command line.--- gcc/ada/gnat1drv.adb
+++ gcc/ada/gnat1drv.adb
@@ -1161,8 +1161,21 @@ begin
   --  gnat1 is invoked from gcc in the normal case.
 
   if Osint.Number_Of_Files /= 1 then
- Usage;
- Write_Eol;
+
+ --  In GNATprove mode, gcc is not called, so we may end up with
+ --  switches wrongly interpreted as source file names when they are
+ --  written by mistake without a starting hyphen. Issue a specific
+ --  error message but do not print the internal 'usage' message.
+
+ if GNATprove_Mode then
+Write_Str ("one of the following is not a valid switch"
+   & " or source file name: ");
+Osint.Dump_Command_Line_Source_File_Names;
+ else
+Usage;
+Write_Eol;
+ end if;
+
  Osint.Fail ("you must provide one source file");
 
   elsif Usage_Requested then

--- gcc/ada/osint.adb
+++ gcc/ada/osint.adb
@@ -787,6 +787,17 @@ package body Osint is
   end if;
end Dir_In_Src_Search_Path;
 
+   -
+   -- Dump_Command_Line_Source_File_Names --
+   -
+
+   procedure Dump_Command_Line_Source_File_Names is
+   begin
+  for J in 1 .. Number_Of_Files loop
+ Write_Str (File_Names (J).all & " ");
+  end loop;
+   end Dump_Command_Line_Source_File_Names;
+

-- Dump_Source_File_Names --


--- gcc/ada/osint.ads
+++ gcc/ada/osint.ads
@@ -508,6 +508,9 @@ package Osint is
--  (i.e. Include_Dir_Default_Prefix). The text is sent to whatever Output
--  is currently using (e.g. standard output or standard error).
 
+   procedure Dump_Command_Line_Source_File_Names;
+   --  Prints out the names of all source files on the command-line
+
---
-- Representation of Library Information --
---

[Ada] Stubs that complete generic subprogram do have a "prior declaration"

[Pierre-Marie de Rodat]

The intuition behind the Is_Subprogram_Stub_Without_Prior_Declaration
utility routine is to detect stubs that act as subprogram declarations
and False on stubs that act as completions. This behaviour is now fixed
for stubs that correspond to generic subprogram declarations.

This patch affects a routine that is only used in GNATprove, so no
frontend test provided. An example where the result changed from True to
False is:

---
-- p.ads --
---

package P is
   generic
   procedure Proc;
end P;

---
-- p.adb --
---

package body P is
   procedure Proc is separate; -- now we return False for this stub
end P;


-- p-proc.adb --


separate (P)
procedure Proc is
begin
   null;
end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2018-12-11  Piotr Trojanek  

gcc/ada/

* sem_util.adb (Is_Subprogram_Stub_Without_Prior_Declaration):
Return False on stubs that complete a generic subprogram.
* sem_util.ads: Update corresponding comment.--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -17471,12 +17471,30 @@ package body Sem_Util is
  (N : Node_Id) return Boolean
is
begin
-  --  A subprogram stub without prior declaration serves as declaration for
-  --  the actual subprogram body. As such, it has an attached defining
-  --  entity of E_[Generic_]Function or E_[Generic_]Procedure.
+  pragma Assert (Nkind (N) = N_Subprogram_Body_Stub);
 
-  return Nkind (N) = N_Subprogram_Body_Stub
-and then Ekind (Defining_Entity (N)) /= E_Subprogram_Body;
+  case Ekind (Defining_Entity (N)) is
+
+ --  A subprogram stub without prior declaration serves as declaration
+ --  for the actual subprogram body. As such, it has an attached
+ --  defining entity of E_Function or E_Procedure.
+
+ when E_Function
+| E_Procedure
+ =>
+return True;
+
+ --  Otherwise, it is completes a [generic] subprogram declaration
+
+ when E_Generic_Function
+| E_Generic_Procedure
+| E_Subprogram_Body
+ =>
+return False;
+
+ when others =>
+raise Program_Error;
+  end case;
end Is_Subprogram_Stub_Without_Prior_Declaration;
 
---

--- gcc/ada/sem_util.ads
+++ gcc/ada/sem_util.ads
@@ -2001,8 +2001,8 @@ package Sem_Util is
 
function Is_Subprogram_Stub_Without_Prior_Declaration
  (N : Node_Id) return Boolean;
-   --  Return True if N is a subprogram stub with no prior subprogram
-   --  declaration.
+   --  Given an N_Subprogram_Body_Stub node N, return True if N is a subprogram
+   --  stub with no prior subprogram declaration.
 
function Is_Suitable_Primitive (Subp_Id : Entity_Id) return Boolean;
--  Determine whether arbitrary subprogram Subp_Id may act as a primitive of