Re: [PR94092] Re: [RFC] test builtin ratio for loop distribution

2021-05-03 Thread Prathamesh Kulkarni via Gcc-patches
On Tue, 4 May 2021 at 07:30, Alexandre Oliva  wrote:
>
> On May  3, 2021, Richard Biener  wrote:
>
> > On Fri, Apr 30, 2021 at 4:42 PM Jeff Law  wrote:
> >>
> >>
> >> On 4/28/2021 10:26 PM, Alexandre Oliva wrote:
> >> > On Feb 22, 2021, Richard Biener  wrote:
> >> >
> >> >> On Fri, Feb 19, 2021 at 9:08 AM Alexandre Oliva  
> >> >> wrote:
> >> >>> Here's an improved version of the patch.  Regstrapped on
> >> >>> x86_64-linux-gnu, with and without a patchlet that moved multi-pieces
> >> >>> ahead of setmem, and also tested with riscv32-elf.
> >> >>>
> >> >>> Is it ok to install?  Or should it wait for stage1?
> >> >> It generally looks OK but I'd wait for stage1.
> >> > 'k, I've retested the patch now, and it's still working as expected.
> >>
> >> Then I'd go forward with it at this point.
>
> > Yes, it looks good to me as well.
>
> Thanks, I've put it in.
Hi,
This caused the following build error:
../../gcc/gcc/builtins.c:6750:18: error: invalid conversion from
‘rtx_def* (*)(void*, void*, long int, scalar_int_mode)’ to
rtx_def* (*)(void*, long int, scalar_int_mode)’ [-fpermissive]
 6750 |   constfun = builtin_memset_gen_str;

It looks like constfun's prototype had a typo with missing 2nd param for void *.
I committed the fix as obvious in the following commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5fbe6a8e73b52c6ebc28b9111456226c1cda6472

Thanks,
Prathamesh
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 


ctype support for libstdc++ on VxWorks

2021-05-03 Thread Alexandre Oliva


This patch adds ctype and locale support to libstdc++ on vxworks7.
We've been using this for a while internally.  It was tested with
various vx7r2 targets.  Ok to install?


From: Corentin Gay 

for  libstdc++-v3/ChangeLog

* acinclude.m4: Add VxWorks-specific case for the
configuration of ctypes.
* configure: Regenerate.
* config/locale/vxworks/ctype_members.cc: Add VxWorks-specific
version.
* config/os/vxworks/ctype_base.h: Adjust for VxWorks7+.
* config/os/vxworks/ctype_configure_char.cc: Likewise.
* config/os/vxworks/ctype_inline.h: Likewise.
* testsuite/28_regex/traits/char/isctype.cc: Defines
NEWLINE_IN_CLASS_BLANK if the target is VxWorks.
* testsuite/28_regex/traits/wchar_t/isctype.cc: Likewise.
---
 libstdc++-v3/acinclude.m4  |   18 +
 .../config/locale/vxworks/ctype_members.cc |  291 
 libstdc++-v3/config/os/vxworks/ctype_base.h|   27 ++
 .../config/os/vxworks/ctype_configure_char.cc  |   10 +
 libstdc++-v3/config/os/vxworks/ctype_inline.h  |   39 +++
 libstdc++-v3/configure |   19 +
 .../testsuite/28_regex/traits/char/isctype.cc  |1 
 .../testsuite/28_regex/traits/wchar_t/isctype.cc   |1 
 8 files changed, 405 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/config/locale/vxworks/ctype_members.cc

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 7b78e148fbd38..e5d88daac0aa9 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -2391,6 +2391,9 @@ AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [
   darwin*)
enable_clocale_flag=darwin
;;
+  vxworks*)
+   enable_clocale_flag=vxworks
+   ;;
   dragonfly* | freebsd*)
enable_clocale_flag=dragonfly
;;
@@ -2485,7 +2488,22 @@ AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [
   CTIME_CC=config/locale/generic/time_members.cc
   CLOCALE_INTERNAL_H=config/locale/generic/c++locale_internal.h
   ;;
+vxworks)
+  AC_MSG_RESULT(vxworks)
 
+  CLOCALE_H=config/locale/generic/c_locale.h
+  CLOCALE_CC=config/locale/generic/c_locale.cc
+  CCODECVT_CC=config/locale/generic/codecvt_members.cc
+  CCOLLATE_CC=config/locale/generic/collate_members.cc
+  CCTYPE_CC=config/locale/vxworks/ctype_members.cc
+  CMESSAGES_H=config/locale/generic/messages_members.h
+  CMESSAGES_CC=config/locale/generic/messages_members.cc
+  CMONEY_CC=config/locale/generic/monetary_members.cc
+  CNUMERIC_CC=config/locale/generic/numeric_members.cc
+  CTIME_H=config/locale/generic/time_members.h
+  CTIME_CC=config/locale/generic/time_members.cc
+  CLOCALE_INTERNAL_H=config/locale/generic/c++locale_internal.h
+  ;;
 dragonfly)
   AC_MSG_RESULT(dragonfly or freebsd)
 
diff --git a/libstdc++-v3/config/locale/vxworks/ctype_members.cc 
b/libstdc++-v3/config/locale/vxworks/ctype_members.cc
new file mode 100644
index 0..c5f327969b3f5
--- /dev/null
+++ b/libstdc++-v3/config/locale/vxworks/ctype_members.cc
@@ -0,0 +1,291 @@
+// std::ctype implementation details, vxworks specific version -*- C++ -*-
+
+// Copyright (C) 2001-2021 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.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+//
+// ISO C++ 14882: 22.2.1.1.2  ctype virtual functions.
+//
+
+// Written by Benjamin Kosnik 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+  // NB: The other ctype specializations are in src/locale.cc and
+  // various /config/os/* files.
+  ctype_byname::ctype_byname(const char* __s, size_t __refs)
+  : ctype(0, false, __refs)
+  {
+if (std::strcmp(__s, "C") != 0 && std::strcmp(__s, "POSIX") != 0)
+  {
+   this->_S_destroy_c_locale(this->_M_c_locale_ctype);
+   this->_S_create_c_locale(this->_M_c_locale_ctype, __s);
+  }
+  }
+
+  ctype_byname::~ctype_byname()
+  { }
+

restore EH on x86-vx7r2

2021-05-03 Thread Alexandre Oliva


x86-vx7r2 needs svr4_dbx_register_map, but the default in i386/i386.h
was dbx_register_map, partially swapping ebp and esp in unwind info.

i386/vxworks.h had a correct overrider, but it was conditional for
vxworks < 7.  This patch reenables the overrider unconditionally.

Tested on x86_64-linux-gnu with a cross to x86-vx7r2.  Ok to install?


for  gcc/ChangeLog

* config/i386/vxworks.h (DBX_REGISTER_NUMBER): Make it
unconditional.
---
 gcc/config/i386/vxworks.h |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/config/i386/vxworks.h b/gcc/config/i386/vxworks.h
index b3ca224fa1071..ebda7d9d26a34 100644
--- a/gcc/config/i386/vxworks.h
+++ b/gcc/config/i386/vxworks.h
@@ -37,13 +37,6 @@ along with GCC; see the file COPYING3.  If not see
 #define TARGET_SUBTARGET_DEFAULT \
(MASK_80387 | MASK_IEEE_FP | MASK_FLOAT_RETURNS | MASK_VECT8_RETURNS)
 
-/* Provide our target specific DBX_REGISTER_NUMBER.  VxWorks relies on
-   the SVR4 numbering.  */
-
-#undef DBX_REGISTER_NUMBER
-#define DBX_REGISTER_NUMBER(n) \
-  (TARGET_64BIT ? dbx64_register_map[n] : svr4_dbx_register_map[n])
-
 #undef PTRDIFF_TYPE
 #define PTRDIFF_TYPE (TARGET_LP64 ? "long int" : "int")
 
@@ -61,6 +54,13 @@ along with GCC; see the file COPYING3.  If not see
 
 #endif
 
+/* Provide our target specific DBX_REGISTER_NUMBER.  VxWorks relies on
+   the SVR4 numbering.  */
+
+#undef DBX_REGISTER_NUMBER
+#define DBX_REGISTER_NUMBER(n) \
+  (TARGET_64BIT ? dbx64_register_map[n] : svr4_dbx_register_map[n])
+
 /* CPU macro definitions, ordered to account for VxWorks 7 not
supporting CPUs older than PENTIUM4 since SR0650.  */
 


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 


Re: [PR94092] Re: [RFC] test builtin ratio for loop distribution

2021-05-03 Thread Alexandre Oliva
On May  3, 2021, Richard Biener  wrote:

> On Fri, Apr 30, 2021 at 4:42 PM Jeff Law  wrote:
>> 
>> 
>> On 4/28/2021 10:26 PM, Alexandre Oliva wrote:
>> > On Feb 22, 2021, Richard Biener  wrote:
>> >
>> >> On Fri, Feb 19, 2021 at 9:08 AM Alexandre Oliva  wrote:
>> >>> Here's an improved version of the patch.  Regstrapped on
>> >>> x86_64-linux-gnu, with and without a patchlet that moved multi-pieces
>> >>> ahead of setmem, and also tested with riscv32-elf.
>> >>>
>> >>> Is it ok to install?  Or should it wait for stage1?
>> >> It generally looks OK but I'd wait for stage1.
>> > 'k, I've retested the patch now, and it's still working as expected.
>> 
>> Then I'd go forward with it at this point.

> Yes, it looks good to me as well.

Thanks, I've put it in.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 


Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

2021-05-03 Thread Simon Marchi via Gcc-patches
On 2021-05-03 5:51 p.m., Alan Modra wrote:
> I wasn't talking about running configure, I was talking about running
> make.  For example, you configure and make binutils as usual, then
> after making a change to ld/ files, run make in the ld build dir.  I
> don't tend to do that myself but I do run "make check" sometimes in a
> subdir expecting to get the same results in that subdir as if "make
> check" was run from the top level.

Ah yeah, that works just fine.  During my edit-build-cycle, I typically
only "make" in gdb/, or whatever I'm working on at the moment.  It saves
some precious milliseconds!

> But I should have just tried it myself rather than asking.  CC, CPP
> and others are inherited from the top level and appear with -std=gnu99
> in the subdir Makefiles.  So it seems all the AC_PROG_CC in subdir
> configure.ac can stay as they are.

Yes, the top-level passes CC=... and others when it configures the
subdirectories.  The subdirectories remember how they were configures
(in config.status), so that even if a "make" in the subdirectory ends up
re-running configure (because configure changed), the CC value will be
remembered.

Simon


Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

2021-05-03 Thread Alan Modra via Gcc-patches
On Mon, May 03, 2021 at 10:47:15AM -0400, Simon Marchi wrote:
> > Yes, I prefer the configure fix too.  If we state we require C99 in
> > binutils then we ought to be able to use C99..
> > 
> > Nick, does the configure.ac change also need to go in all subdirs, to
> > support people running make in say ld/ rather than running make in the
> > top build dir?
> 
> For GDB, it's not supported to run gdb/configure directly, you need to
> use the top-level configure.  Is it supported from some of the other
> projects in the repo?
> 
> I just tried with ld, it doesn't work since it depends on bfd also being
> built.  I tried with just bfd, it doesn't work (with the default
> configure options at least) because it requires zlib being built.

I wasn't talking about running configure, I was talking about running
make.  For example, you configure and make binutils as usual, then
after making a change to ld/ files, run make in the ld build dir.  I
don't tend to do that myself but I do run "make check" sometimes in a
subdir expecting to get the same results in that subdir as if "make
check" was run from the top level.

But I should have just tried it myself rather than asking.  CC, CPP
and others are inherited from the top level and appear with -std=gnu99
in the subdir Makefiles.  So it seems all the AC_PROG_CC in subdir
configure.ac can stay as they are.

> 
> So if all projects need to go through the top-level configure script
> anyway, and C99 is a baseline for all projects, then having the check
> only in the top-level makes sense to me.  Projects that have more
> specific requirements can have their own checks.  For example, sim/
> requires C11 now.  Unless the C99 check at top-level somehow does not
> play well with the C11 check in sim/?  Like if that would cause CC to be
> set to "gcc -std=gnu99 -std=gnu11" or something like that.
> 
> Simon

-- 
Alan Modra
Australia Development Lab, IBM


[PING][PATCH] define auto_vec copy ctor and assignment (PR 90904)

2021-05-03 Thread Martin Sebor via Gcc-patches

Ping:

https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568901.html

On 4/27/21 9:52 AM, Martin Sebor wrote:

On 4/27/21 8:04 AM, Richard Biener wrote:

On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor  wrote:


On 4/27/21 1:58 AM, Richard Biener wrote:

On Tue, Apr 27, 2021 at 2:46 AM Martin Sebor via Gcc-patches
 wrote:


PR 90904 notes that auto_vec is unsafe to copy and assign because
the class manages its own memory but doesn't define (or delete)
either special function.  Since I first ran into the problem,
auto_vec has grown a move ctor and move assignment from
a dynamically-allocated vec but still no copy ctor or copy
assignment operator.

The attached patch adds the two special functions to auto_vec along
with a few simple tests.  It makes auto_vec safe to use in containers
that expect copyable and assignable element types and passes bootstrap
and regression testing on x86_64-linux.


The question is whether we want such uses to appear since those
can be quite inefficient?  Thus the option is to delete those 
operators?


I would strongly prefer the generic vector class to have the properties
expected of any other generic container: copyable and assignable.  If
we also want another vector type with this restriction I suggest to add
another "noncopyable" type and make that property explicit in its name.
I can submit one in a followup patch if you think we need one.


I'm not sure (and not strictly against the copy and assign).  Looking 
around

I see that vec<> does not do deep copying.  Making auto_vec<> do it
might be surprising (I added the move capability to match how vec<>
is used - as "reference" to a vector)


The vec base classes are special: they have no ctors at all (because
of their use in unions).  That's something we might have to live with
but it's not a model to follow in ordinary containers.

The auto_vec class was introduced to fill the need for a conventional
sequence container with a ctor and dtor.  The missing copy ctor and
assignment operators were an oversight, not a deliberate feature.
This change fixes that oversight.

The revised patch also adds a copy ctor/assignment to the auto_vec
primary template (that's also missing it).  In addition, it adds
a new class called auto_vec_ncopy that disables copying and
assignment as you prefer.  It also disables copying for
the auto_string_vec class.

Martin




Re: [PATCH][_GLIBCXX_DEBUG] libbacktrace integration

2021-05-03 Thread Jonathan Wakely via Gcc-patches

On 03/05/21 22:17 +0200, François Dumont via Libstdc++ wrote:

Is it too early to consider this patch ? Or just lack of time ?


I haven't had time to review it yet, but my general feeling hasn't
changed. I still don't like the idea of executing additional code
after undefined behaviour is detected. I've been convinced by glibc
folk that every bit of code run when the program state is corrupt
increases the risk that it can be exploited by an attacker.





[PATCH, OBVIOUS] testsuite: Fix dg directives order in arm/aarch64 vml[as]_float_not_fused.c

2021-05-03 Thread Christophe Lyon via Gcc-patches
dg-do must come before dg-skip-if, this patch fixes this oversight in
these two tests.

Committed as obvious.

2021-05-03  Christophe Lyon  

gcc/testsuite/
* gcc.target/aarch64/advsimd-intrinsics/vmla_float_not_fused.c:
Fix dg directives order.
* gcc.target/aarch64/advsimd-intrinsics/vmls_float_not_fused.c:
Likewise.
---
 .../gcc.target/aarch64/advsimd-intrinsics/vmla_float_not_fused.c| 2 +-
 .../gcc.target/aarch64/advsimd-intrinsics/vmls_float_not_fused.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmla_float_not_fused.c 
b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmla_float_not_fused.c
index b14b259..18d1767 100644
--- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmla_float_not_fused.c
+++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmla_float_not_fused.c
@@ -1,5 +1,5 @@
-/* { dg-skip-if "" { arm*-*-* } } */
 /* { dg-do compile } */
+/* { dg-skip-if "" { arm*-*-* } } */
 /* { dg-options "-O3" } */
 
 
diff --git 
a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmls_float_not_fused.c 
b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmls_float_not_fused.c
index c6f62c5..6c51d04 100644
--- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmls_float_not_fused.c
+++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmls_float_not_fused.c
@@ -1,5 +1,5 @@
-/* { dg-skip-if "" { arm*-*-* } } */
 /* { dg-do compile } */
+/* { dg-skip-if "" { arm*-*-* } } */
 /* { dg-options "-O3" } */
 
 
-- 
2.7.4



Re: [PATCH][_GLIBCXX_DEBUG] libbacktrace integration

2021-05-03 Thread François Dumont via Gcc-patches

Is it too early to consider this patch ? Or just lack of time ?

Considering the patch I would really appreciate that, if validated, it 
gets in as early as possible in next release.


Thanks,
François

On 24/04/21 3:46 pm, François Dumont wrote:

Hi

    Here is the patch to add backtrace generation on _GLIBCXX_DEBUG 
assertions thanks to libbacktrace.


    In addition to this integration I am also improving the generation 
of the assertion message thanks to the "%.*s" printf format, it avoids 
an intermediate buffer most of the time. I am also removing the "__" 
used for uglification to get a nicer output. I can propose it in a 
dedicated patch if you prefer.


    I am adding GLIBCXX_3.4.30 abi version to properly export the 2 
new weak symbols. Let me know if it isn't necessary.


    libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation thanks to 
libbacktrace


  Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace 
generation on

    _GLIBCXX_DEBUG assertions using libbacktrace.

    * config/abi/pre/gnu.ver: Add GLIBCXX_3.4.30 version and 
new exports.

    * include/debug/formatter.h [_GLIBCXX_DEBUG_BACKTRACE]:
    Include .
    [_GLIBCXX_DEBUG_BACKTRACE && BACKTRACE_SUPPORTED]:
    Include .
    [(!_GLIBCXX_DEBUG_BACKTRACE || !BACKTRACE_SUPPORTED) &&
    _GLIBCXX_USE_C99_STDINT_TR1]: Include .
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (__gnu_debug::__create_backtrace_state): New.
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (__gnu_debug::__render_backtrace): New.
[_GLIBCXX_DEBUG_USE_LIBBACKTRACE](_Error_formatter::_M_print_backtrace):
    New.
[_GLIBCXX_DEBUG_USE_LIBBACKTRACE](_Error_formatter::_M_backtrace_state):
    New.
    (_Error_formatter::_Error_formatter): Outline definition.
    * src/c++11/debug.cc: Include .
    (_Print_func_t): New.
    (print_word): Use '%.*s' format in fprintf to render only 
expected

    number of chars.
    (print_raw(PrintContext&, const char*, ptrdiff_t)): New.
    (print_function(PrintContext&, const char*, 
_Print_func_t)): New.

    (print_type): Use latter.
    (print_string(PrintContext&, const char*, const 
_Parameter*, size_t)):

    Change signature to...
    (print_string(PrintContext&, const char*, ptrdiff_t, const 
_Parameter*,
    size_t)): ...this and adapt. Remove intermediate buffer to 
render input

    string.
    (print_string(PrintContext&, const char*, ptrdiff_t)): New.
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (print_backtrace(void*, uintptr_t, const char*, int, const 
char*)): New.

    (_Error_formatter::_M_error()): Adapt.
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (__gnu_debug::__create_backtrace_state): New, weak symbol.
    [_GLIBCXX_DEBUG_USE_LIBBACKTRACE]
    (__gnu_debug::__render_backtrace): New, weak symbol.
    * testsuite/util/testsuite_abi.cc: Add new symbol version.
    * doc/xml/manual/debug_mode.xml: Document 
_GLIBCXX_DEBUG_BACKTRACE.

    * doc/xml/manual/using.xml: Likewise.

Tested under Linux x86_64.

Ok to commit ?

François





[r12-382 Regression] FAIL: gcc.dg/tree-ssa/ssa-dse-26.c scan-tree-dump-times dse1 "Deleted dead store: y = " 1 on Linux/x86_64

2021-05-03 Thread sunil.k.pandey via Gcc-patches
On Linux/x86_64,

ed3c43224cc4e378dbab066122bc63536ccb1276 is the first bad commit
commit ed3c43224cc4e378dbab066122bc63536ccb1276
Author: Richard Biener 
Date:   Mon May 3 09:17:55 2021 +0200

Perform reverse program order walk for GIMPLE DSE

caused

FAIL: gcc.dg/tree-ssa/ssa-dse-26.c scan-tree-dump-times dse1 "Deleted dead 
store: x = " 1
FAIL: gcc.dg/tree-ssa/ssa-dse-26.c scan-tree-dump-times dse1 "Deleted dead 
store: y = " 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-382/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/ssa-dse-26.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/ssa-dse-26.c 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)


Re: [Patch] OpenMP: Support complex/float in && and || reduction

2021-05-03 Thread Jakub Jelinek via Gcc-patches
On Sat, May 01, 2021 at 01:12:15AM +0200, Tobias Burnus wrote:
> gcc/c/ChangeLog:
> 
>   * c-typeck.c (c_finish_omp_clauses): Accept float + complex for || and 
> &&
>   reductions.
> 
> gcc/cp/ChangeLog:
> 
>   * semantics.c (finish_omp_reduction_clause): Accept float + complex for 
> || and &&
>   reductions.
> 
> gcc/ChangeLog:
> 
>   * omp-low.c (lower_rec_input_clauses, lower_reduction_clauses): Handle 
> && and ||
>   with floating-point and complex arguments.

All the above ChangeLog lines are too long.

> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -6376,6 +6376,11 @@ lower_rec_input_clauses (tree clauses, gimple_seq 
> *ilist, gimple_seq *dlist,
> if (code == MINUS_EXPR)
>   code = PLUS_EXPR;
>  
> +   /* C/C++ permits FP/complex with || and &&.  */
> +   bool is_fp_and_or
> + = ((code == TRUTH_ANDIF_EXPR || code == TRUTH_ORIF_EXPR)
> +&& (FLOAT_TYPE_P (TREE_TYPE (new_var))
> +|| TREE_CODE (TREE_TYPE (new_var)) == COMPLEX_TYPE));

The above line is too long too, please use
   || (TREE_CODE (TREE_TYPE (new_var))
   == COMPLEX_TYPE)));

> tree new_vard = new_var;
> if (is_simd && omp_is_reference (var))
>   {
> @@ -6443,8 +6448,23 @@ lower_rec_input_clauses (tree clauses, gimple_seq 
> *ilist, gimple_seq *dlist,
> if (is_simd)
>   {
> tree ref = build_outer_var_ref (var, ctx);
> -
> -   x = build2 (code, TREE_TYPE (ref), ref, new_var);
> +   tree new_var2 = new_var;
> +   if (is_fp_and_or)
> + new_var2 = fold_build2_loc (
> +  clause_loc, NE_EXPR,
> +  integer_type_node, new_var,
> +  build_zero_cst (TREE_TYPE (new_var)));

Formatting, would be nice to avoid the ( at the end of line, e.g.
{
  tree zero = build_zero_cst (TREE_TYPE (new_var));
  new_var2
= fold_build2_loc (clause_loc, NE_EXPR,
   integer_type_node, new_var,
   zero);
}

> +   tree ref2 = ref;
> +   if (is_fp_and_or
> +   && (FLOAT_TYPE_P (TREE_TYPE (ref))
> +   || TREE_CODE (TREE_TYPE (ref))
> +  == COMPLEX_TYPE))

Please wrap the == into ()s.
Though ref should have the same type new_var (or at least a compatible type),
so I don't see the point of the && ... in there and of using two separate
if (is_fp_and_or) blocks.
So
tree new_var2 = new_var;
tree ref2 = ref;
if (is_fp_and_or)
  {
tree zero = ...;
new_var2 = ...
ref2 = ...;
  }

> + ref2 = fold_build2_loc (
> +  clause_loc, NE_EXPR, integer_type_node,
> +  ref, build_zero_cst (TREE_TYPE (ref)));

And try to avoid the ( here too.
Even better would be to split the function a little bit, but that can be
done another day.

> +   x = build2 (code, TREE_TYPE (ref2), ref2, new_var2);
> +   if (new_var2 != new_var)
> + x = fold_convert (TREE_TYPE (new_var), x);
> ref = build_outer_var_ref (var, ctx);
> gimplify_assign (ref, x, dlist);
>   }
> @@ -7384,13 +7404,32 @@ lower_reduction_clauses (tree clauses, gimple_seq 
> *stmt_seqp,
>if (code == MINUS_EXPR)
>  code = PLUS_EXPR;
>  
> +  /* C/C++ permits FP/complex with || and &&.  */
> +  bool is_fp_and_or = ((code == TRUTH_ANDIF_EXPR || code == 
> TRUTH_ORIF_EXPR)
> +&& (FLOAT_TYPE_P (TREE_TYPE (new_var))
> +|| TREE_CODE (TREE_TYPE (new_var))
> +== COMPLEX_TYPE));

Again, ()s around ==.

>if (count == 1)
>   {
> tree addr = build_fold_addr_expr_loc (clause_loc, ref);
>  
> addr = save_expr (addr);
> ref = build1 (INDIRECT_REF, TREE_TYPE (TREE_TYPE (addr)), addr);
> -   x = fold_build2_loc (clause_loc, code, TREE_TYPE (ref), ref, new_var);
> +   tree new_var2 = new_var;
> +   if (is_fp_and_or)
> + new_var2 = fold_build2_loc (clause_loc, NE_EXPR,
> + integer_type_node, new_var,
> + build_zero_cst (TREE_TYPE (new_var)));
> +   tree ref2 = ref;
> +   if (is_fp_and_or
> +   && (FLOAT_TYPE_P (TREE_TYPE (ref))
> +  

Re: [PATCH][openmp, simt] Error out for user-defined reduction

2021-05-03 Thread Jakub Jelinek via Gcc-patches
On Mon, May 03, 2021 at 07:03:24PM +0200, Tom de Vries wrote:
> +  if (sctx->is_simt && !known_eq (sctx->max_vf, 1U))
> + {
> +   tree c = omp_find_clause (gimple_omp_for_clauses (ctx->stmt),
> + OMP_CLAUSE_REDUCTION);
> +   if (c && OMP_CLAUSE_REDUCTION_PLACEHOLDER (c))
> + /* UDR reductions are not supported yet for SIMT, disable SIMT.  */
> + sctx->max_vf = 1;

This isn't sufficient, you could have e.g. 2 reductions, the first non-UDR
one and the second one with UDR.
So it needs to be a for loop like:
  for (tree c = gimple_omp_for_clauses (ctx->stmt); c;
   c = OMP_CLAUSE_CHAIN (c))
if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_REDUCTION
&& OMP_CLAUSE_REDUCTION_PLACEHOLDER (c))
  {
/* UDR reductions are not supported yet for SIMT,
   disable SIMT.  */
sctx->max_vf = 1;
break;
  }
(or with omp_find_clause used in two spots).

Jakub



Re: [PATCH][openmp, simt] Error out for user-defined reduction

2021-05-03 Thread Tom de Vries
On 5/3/21 12:31 PM, Jakub Jelinek wrote:
> On Mon, May 03, 2021 at 12:24:10PM +0200, Tom de Vries wrote:
>> The test-case included in this patch contains this target region:
>> ...
>>   for (int i0 = 0 ; i0 < N0 ; i0++ )
>> counter_N0.i += 1;
>> ...
>>
>> When running with nvptx accelerator, the counter variable is expected to
>> be N0 after the region, but instead is N0 / 32.  The problem is that rather
>> than getting the result for all warp lanes, we get it for just one lane.
>>
>> This is caused by the implementation of SIMT being incomplete.  It handles
>> regular reductions, but appearantly not user-defined reductions.
>>
>> For now, make this explicit by erroring out for nvptx, like this:
>> ...
>> target-44.c: In function 'main':
>> target-44.c:20:9: error: SIMT reduction not fully implemented
>> ...
>>
>> Tested libgomp on x86_64-linux with and without nvptx accelerator.
>>
>> Any comments?
> 
> If you want a workaround, the workaround should be to disable SIMT if
> UDR reductions are seen, rather than erroring out.
> So e.g. in lower_rec_simd_input_clauses for sctx->is_simt if sctx->max_vf
> isn't 1 look for OMP_CLAUSE_REDUCTION with OMP_CLAUSE_REDUCTION_PLACEHOLDER
> and punt (set max_vf = 1) in that case.
> 

Thanks for the review, I've tried to implement this, see patch below.

> The right thing is to implement it properly of course.

Ack, I've taken a look, and for me itd doesn't look like a below-a-day
kind of task, so unfortunately I don't have the time for this right now.

Thanks,
- Tom

[openmp, simt] Disable SIMT for user-defined reduction

The test-case included in this patch contains this target region:
...
  for (int i0 = 0 ; i0 < N0 ; i0++ )
counter_N0.i += 1;
...

When running with nvptx accelerator, the counter variable is expected to
be N0 after the region, but instead is N0 / 32.  The problem is that rather
than getting the result for all warp lanes, we get it for just one lane.

This is caused by the implementation of SIMT being incomplete.  It handles
regular reductions, but appearantly not user-defined reductions.

For now, handle this by disabling SIMT in this case, specifically by setting
sctx->max_vf to 1.

Tested libgomp on x86_64-linux with nvptx accelerator.

gcc/ChangeLog:

2021-05-03  Tom de Vries  

	PR target/100321
	* omp-low.c (lower_rec_input_clauses): Disable SIMT for user-defined
	reduction.

libgomp/ChangeLog:

2021-05-03  Tom de Vries  

	PR target/100321
	* testsuite/libgomp.c/target-44.c: New test.

---
 gcc/omp-low.c   |  8 
 libgomp/testsuite/libgomp.c/target-44.c | 27 +++
 2 files changed, 35 insertions(+)

diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 7b122059c6e..bb8d3188c26 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -4385,6 +4385,14 @@ lower_rec_simd_input_clauses (tree new_var, omp_context *ctx,
 		sctx->max_vf = lower_bound (sctx->max_vf, safe_len);
 	}
 	}
+  if (sctx->is_simt && !known_eq (sctx->max_vf, 1U))
+	{
+	  tree c = omp_find_clause (gimple_omp_for_clauses (ctx->stmt),
+OMP_CLAUSE_REDUCTION);
+	  if (c && OMP_CLAUSE_REDUCTION_PLACEHOLDER (c))
+	/* UDR reductions are not supported yet for SIMT, disable SIMT.  */
+	sctx->max_vf = 1;
+	}
   if (maybe_gt (sctx->max_vf, 1U))
 	{
 	  sctx->idx = create_tmp_var (unsigned_type_node);
diff --git a/libgomp/testsuite/libgomp.c/target-44.c b/libgomp/testsuite/libgomp.c/target-44.c
new file mode 100644
index 000..13e0c757845
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c/target-44.c
@@ -0,0 +1,27 @@
+/* { dg-additional-options "-foffload=-latomic" { target { offload_target_nvptx } } } */
+
+#include 
+
+struct s
+{
+  int i;
+};
+
+#pragma omp declare reduction(+: struct s: omp_out.i += omp_in.i)
+
+int
+main (void)
+{
+  const int N0 = 32768;
+
+  struct s counter_N0 = { 0 };
+#pragma omp target
+#pragma omp for simd reduction(+: counter_N0)
+  for (int i0 = 0 ; i0 < N0 ; i0++ )
+counter_N0.i += 1;
+
+  if (counter_N0.i != N0)
+abort ();
+
+  return 0;
+}


Re: [PATCH] c++: base-clause parsing and implicit 'this' [PR100362]

2021-05-03 Thread Jason Merrill via Gcc-patches

On 5/3/21 12:48 PM, Patrick Palka wrote:

My r11-6815 change to defer access checking when processing a
base-clause removed a pair of pushclass / popclass calls that seemed to
be unnecessary now that we'd also defer access checking while parsing
the base-clause.

But it turns out this makes a difference in the below testcase, where we
have a local class whose base clause implicitly uses the 'this' of the
enclosing class.  Before r11-6815, while parsing the base-clause of the
local class, maybe_resolve_dummy would fail to resolve the dummy 'this'
object because the current scope would be the local class.  Now, since
the current scope is the lambda, maybe_resolve_dummy succeeds and
returns the 'this' for the enclosing class Qux.  Later, during deferred
instantiation of the local class, we get confused trying to resolve the
access of 'a_' through this non-dummy 'this'.

So this patch just reinstates the calls to pushclass / popclass that
were removed in r11-6815.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?


OK for trunk and 11.2.


gcc/cp/ChangeLog:

PR c++/100362
* parser.c (cp_parser_class_head): Reinstate calls to pushclass
and popclass during parsing of the base-clause that were
removed in r11-6815.

gcc/testsuite/ChangeLog:

PR c++/100362
* g++.dg/cpp1y/lambda-generic-100362.C: New test.
---
  gcc/cp/parser.c   |  8 +-
  .../g++.dg/cpp1y/lambda-generic-100362.C  | 25 +++
  2 files changed, 32 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-100362.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index e1b1617da68..28752611b34 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -25683,7 +25683,13 @@ cp_parser_class_head (cp_parser* parser,
   until the entire list has been seen, as per [class.access.general].  */
push_deferring_access_checks (dk_deferred);
if (cp_lexer_next_token_is (parser->lexer, CPP_COLON))
-bases = cp_parser_base_clause (parser);
+{
+  if (type)
+   pushclass (type);
+  bases = cp_parser_base_clause (parser);
+  if (type)
+   popclass ();
+}
else
  bases = NULL_TREE;
  
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-100362.C b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-100362.C

new file mode 100644
index 000..283c2c9477e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-100362.C
@@ -0,0 +1,25 @@
+// PR c++/100362
+// { dg-do compile { target c++14 } }
+
+template 
+struct Qux {
+  struct A { } a_;
+  A f();
+
+  void AsyncOp() {
+[](auto) {
+  struct local : decltype(a_) {};
+  local ptr;
+}(0);
+
+[](auto) {
+  struct local : decltype(f()) {};
+  local ptr;
+}(0);
+  }
+};
+
+void corge() {
+  Qux qux;
+  qux.AsyncOp();
+}





[PATCH] c++: base-clause parsing and implicit 'this' [PR100362]

2021-05-03 Thread Patrick Palka via Gcc-patches
My r11-6815 change to defer access checking when processing a
base-clause removed a pair of pushclass / popclass calls that seemed to
be unnecessary now that we'd also defer access checking while parsing
the base-clause.

But it turns out this makes a difference in the below testcase, where we
have a local class whose base clause implicitly uses the 'this' of the
enclosing class.  Before r11-6815, while parsing the base-clause of the
local class, maybe_resolve_dummy would fail to resolve the dummy 'this'
object because the current scope would be the local class.  Now, since
the current scope is the lambda, maybe_resolve_dummy succeeds and
returns the 'this' for the enclosing class Qux.  Later, during deferred
instantiation of the local class, we get confused trying to resolve the
access of 'a_' through this non-dummy 'this'.

So this patch just reinstates the calls to pushclass / popclass that
were removed in r11-6815.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?

gcc/cp/ChangeLog:

PR c++/100362
* parser.c (cp_parser_class_head): Reinstate calls to pushclass
and popclass during parsing of the base-clause that were
removed in r11-6815.

gcc/testsuite/ChangeLog:

PR c++/100362
* g++.dg/cpp1y/lambda-generic-100362.C: New test.
---
 gcc/cp/parser.c   |  8 +-
 .../g++.dg/cpp1y/lambda-generic-100362.C  | 25 +++
 2 files changed, 32 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-100362.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index e1b1617da68..28752611b34 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -25683,7 +25683,13 @@ cp_parser_class_head (cp_parser* parser,
  until the entire list has been seen, as per [class.access.general].  */
   push_deferring_access_checks (dk_deferred);
   if (cp_lexer_next_token_is (parser->lexer, CPP_COLON))
-bases = cp_parser_base_clause (parser);
+{
+  if (type)
+   pushclass (type);
+  bases = cp_parser_base_clause (parser);
+  if (type)
+   popclass ();
+}
   else
 bases = NULL_TREE;
 
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-100362.C 
b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-100362.C
new file mode 100644
index 000..283c2c9477e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-100362.C
@@ -0,0 +1,25 @@
+// PR c++/100362
+// { dg-do compile { target c++14 } }
+
+template 
+struct Qux {
+  struct A { } a_;
+  A f();
+
+  void AsyncOp() {
+[](auto) {
+  struct local : decltype(a_) {};
+  local ptr;
+}(0);
+
+[](auto) {
+  struct local : decltype(f()) {};
+  local ptr;
+}(0);
+  }
+};
+
+void corge() {
+  Qux qux;
+  qux.AsyncOp();
+}
-- 
2.31.1.442.g7e39198978



[PATCH] libstdc++: Fix wrong thread waking on notify [PR100334]

2021-05-03 Thread Thomas Rodgers
From: Thomas Rodgers 

This should also be backported to gcc-11

libstdc++/ChangeLog:
* include/bits/atomic_wait.h (__waiter::_M_do_wait_v): loop
until observe value change.
(__waiter_base::_M_laundered): New member.
(__watier_base::_M_notify): Check _M_laundered to determine
whether to wake one or all.
(__detail::__atomic_compare): Do not implicitly convert
result of __buildtin_memcpmp to bool,
(__waiter_base::_S_do_spin_v): Adjust predicate.
* testsuite/29_atomics/atomic/wait_notify/100334.cc: New
test.
---
 libstdc++-v3/include/bits/atomic_wait.h   | 20 +++-
 .../29_atomics/atomic/wait_notify/100334.cc   | 94 +++
 2 files changed, 109 insertions(+), 5 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/100334.cc

diff --git a/libstdc++-v3/include/bits/atomic_wait.h 
b/libstdc++-v3/include/bits/atomic_wait.h
index 984ed70f16c..528e4868410 100644
--- a/libstdc++-v3/include/bits/atomic_wait.h
+++ b/libstdc++-v3/include/bits/atomic_wait.h
@@ -181,11 +181,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return false;
   }
 
+// return true if equal
 template
   bool __atomic_compare(const _Tp& __a, const _Tp& __b)
   {
// TODO make this do the correct padding bit ignoring comparison
-   return __builtin_memcmp(&__a, &__b, sizeof(_Tp)) != 0;
+   return __builtin_memcmp(&__a, &__b, sizeof(_Tp)) == 0;
   }
 
 struct __waiter_pool_base
@@ -277,6 +278,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
__waiter_type& _M_w;
__platform_wait_t* _M_addr;
+   bool _M_laundered;
 
template
  static __platform_wait_t*
@@ -300,6 +302,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  explicit __waiter_base(const _Up* __addr) noexcept
: _M_w(_S_for(__addr))
, _M_addr(_S_wait_addr(__addr, &_M_w._M_ver))
+   , _M_laundered(!__platform_wait_uses_type<_Up>)
  {
  }
 
@@ -308,7 +311,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  if (_M_addr == &_M_w._M_ver)
__atomic_fetch_add(_M_addr, 1, __ATOMIC_ACQ_REL);
- _M_w._M_notify(_M_addr, __all, __bare);
+ _M_w._M_notify(_M_addr,
+(_M_laundered ? true : __all),
+__bare);
}
 
template)
  {
@@ -387,7 +392,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__platform_wait_t __val;
if (__base_type::_M_do_spin_v(__old, __vfn, __val))
  return;
-   __base_type::_M_w._M_do_wait(__base_type::_M_addr, __val);
+
+   do
+ {
+   __base_type::_M_w._M_do_wait(__base_type::_M_addr, __val);
+ }
+   while (__detail::__atomic_compare(__old, __vfn()));
  }
 
template
@@ -452,7 +462,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 __atomic_notify_address(const _Tp* __addr, bool __all) noexcept
 {
   __detail::__bare_wait __w(__addr);
-  __w._M_notify(__all, true);
+  __w._M_notify(__all);
 }
 
   // This call is to be used by atomic types which track contention externally
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/100334.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/100334.cc
new file mode 100644
index 000..3e63eca42fa
--- /dev/null
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/100334.cc
@@ -0,0 +1,94 @@
+// { dg-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+// { dg-require-gthreads "" }
+// { dg-additional-options "-pthread" { target pthread } }
+// { dg-add-options libatomic }
+
+// Copyright (C) 2021 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
+// .
+
+#include 
+#include 
+
+#include 
+
+template 
+struct atomics_sharing_same_waiter
+{
+   std::atomic tmp[49 * 4] = {};
+   std::atomic* a[4] = {
+  { [0] },
+  { [16 * 4] },
+  { [32 * 4] },
+  { [48 * 4] }
+   };
+};
+
+constexpr unsigned key(void * a)
+{
+  constexpr uintptr_t ct = 16;
+  return (uintptr_t(a) >> 2) % ct;
+}
+
+int
+main()
+{
+  // all atomic share the same waiter
+//  atomics_sharing_same_waiter atomics;
+  atomics_sharing_same_waiter atomics;
+  for (auto& atom : atomics.a)
+  {
+

Re: [PATCH] tree-ssa-dse: Fix up go.test/test/fixedbugs/issue16095.go miscompilation [PR100382]

2021-05-03 Thread Ian Lance Taylor
Jakub Jelinek  writes:

> The new DCE code inside of tree DSE removes in -fnon-call-exceptions
> go code a load from NULL pointer the testcase relies on throwing an
> exception and so the test hangs.
>
> The following patch just repeats a check that e.g. tree-ssa-dce.c
> uses to prevent this.

Thanks for tracking this down.

Ian


Re: [PATCH] c++: Fix ICE with invalid requires-expression [PR100055]

2021-05-03 Thread Jason Merrill via Gcc-patches

On 4/28/21 4:55 PM, Marek Polacek wrote:

This fixes a crash on invalid requires-expression: in this test,
current_template_parms is null so accessing TEMPLATE_PARMS_CONSTRAINTS
is going to fail.  So don't crash, but make sure we've complained
already.

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


OK.


gcc/cp/ChangeLog:

PR c++/100055
* decl.c (grokfndecl): Check current_template_parms.

gcc/testsuite/ChangeLog:

PR c++/100055
* g++.dg/concepts/diagnostic18.C: New test.
---
  gcc/cp/decl.c| 9 -
  gcc/testsuite/g++.dg/concepts/diagnostic18.C | 7 +++
  2 files changed, 15 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic18.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 60dc2bf182d..1437457241e 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -9702,7 +9702,14 @@ grokfndecl (tree ctype,
  && (processing_template_decl
  > template_class_depth (ctx)));
if (memtmpl)
-tmpl_reqs = TEMPLATE_PARMS_CONSTRAINTS (current_template_parms);
+   {
+ if (!current_template_parms)
+   /* If there are no template parameters, something must have
+  gone wrong.  */
+   gcc_assert (seen_error ());
+ else
+   tmpl_reqs = TEMPLATE_PARMS_CONSTRAINTS (current_template_parms);
+   }
tree ci = build_constraints (tmpl_reqs, decl_reqs);
if (concept_p && ci)
  {
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic18.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic18.C
new file mode 100644
index 000..79f371b8092
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic18.C
@@ -0,0 +1,7 @@
+// PR c++/100055
+// { dg-do compile { target concepts } }
+
+void foo(auto&& arg) requires({}); // { dg-error "statement-expressions are not 
allowed|braced-groups" }
+
+template  requires ([]{}()); // { dg-error "expected unqualified-id" 
}
+auto f() requires ([]{}());

base-commit: c99f3747131377956e3bd8e393911c959ef5ff34





Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

2021-05-03 Thread Tom Tromey
> "Simon" == Simon Marchi via Gcc-patches  writes:

Simon> For GDB, it's not supported to run gdb/configure directly, you need to
Simon> use the top-level configure.  Is it supported from some of the other
Simon> projects in the repo?

It can be done sometimes but I think it isn't really a scenario worth
worrying about.  Normally this kind of thing is only doable for sources
that are already independent of the top-level configury -- drop-in stuff
like gmp or libiconv, or roots of the tree like libiberty and gnulib.

Simon> I just tried with ld, it doesn't work since it depends on bfd also being
Simon> built.  I tried with just bfd, it doesn't work (with the default
Simon> configure options at least) because it requires zlib being built.

Yeah, most of the things that are "really" in-tree have dependencies and
can't be built independently of the rest.

Tom


Re: [PATCH] c++: mark_used and ADL with template-id [PR100344]

2021-05-03 Thread Jason Merrill via Gcc-patches

On 4/30/21 2:53 PM, Patrick Palka wrote:

My r11-295 patch for PR68942 didn't consider that the callee of an
ADL-eligible function call can be a TEMPLATE_ID_EXPR, and we don't want
to disable mark_used when substituting into the template arguments of
this TEMPLATE_ID_EXPR because the arguments are clearly used regardless
of the outcome of ADL.  In the first testcase below, this oversight
causes us to trip over the assert in build_call_a for 'find_index()'
because the function no longer gets its TREE_USED bit set from mark_used.

So this patch restricts the original patch to disable mark_used only
when the callee is a FUNCTION_DECL, which seems to be the only case
that matters for PR68942.  For instance, in the second testcase below we
already don't mark_used the deleted function specialization even before
r11-295.

Bootstrap and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?


OK.


gcc/cp/ChangeLog:

PR c++/68942
PR c++/100344
* pt.c (tsubst_copy_and_build) : Set tf_conv
only when the callee is a FUNCTION_DECL.

gcc/testsuite/ChangeLog:

PR c++/68942
PR c++/100344
* g++.dg/template/call8.C: New test.
* g++.dg/template/koenig12a.C: New test.
---
  gcc/cp/pt.c   | 12 +++-
  gcc/testsuite/g++.dg/template/call8.C | 14 ++
  gcc/testsuite/g++.dg/template/koenig12a.C | 16 
  3 files changed, 37 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/template/call8.C
  create mode 100644 gcc/testsuite/g++.dg/template/koenig12a.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4e9b40f2164..c17407f3012 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -20232,11 +20232,13 @@ tsubst_copy_and_build (tree t,
  /* Avoid error about taking the address of a constructor.  */
  function = TREE_OPERAND (function, 0);
  
-	/* When KOENIG_P, we don't want to mark_used the callee before

-  augmenting the overload set via ADL, so during this initial
-  substitution we disable mark_used by setting tf_conv (68942).  */
-   function = tsubst_copy_and_build (function, args,
- complain | (koenig_p * tf_conv),
+   tsubst_flags_t subcomplain = complain;
+   if (koenig_p && TREE_CODE (function) == FUNCTION_DECL)
+ /* When KOENIG_P, we don't want to mark_used the callee before
+augmenting the overload set via ADL, so during this initial
+substitution we disable mark_used by setting tf_conv (68942).  
*/
+ subcomplain |= tf_conv;
+   function = tsubst_copy_and_build (function, args, subcomplain,
  in_decl,
  !qualified_p,
  integral_constant_expression_p);
diff --git a/gcc/testsuite/g++.dg/template/call8.C 
b/gcc/testsuite/g++.dg/template/call8.C
new file mode 100644
index 000..04609dd508d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/call8.C
@@ -0,0 +1,14 @@
+// PR c++/100344
+// { dg-do compile { target c++11 } }
+
+template  constexpr int find_index() { return 1; }
+
+template  void foo(T);
+
+template  void get(T v) {
+  foo()>(v);
+}
+
+int main() {
+  get(0);
+}
diff --git a/gcc/testsuite/g++.dg/template/koenig12a.C 
b/gcc/testsuite/g++.dg/template/koenig12a.C
new file mode 100644
index 000..96b98b9403f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/koenig12a.C
@@ -0,0 +1,16 @@
+// PR c++/68942
+// { dg-do compile { target c++11 } }
+// A template-id analogue of koenig12.C.
+
+template  void foo(...) = delete;
+
+template  void lookup(T t) { foo<0>(t); }
+
+namespace N {
+ struct A { };
+ template  int foo(A);
+}
+
+int main() {
+  lookup(N::A{});
+}





Re: [PATCH] c++: Remove GCC12 FIXME for DR1312

2021-05-03 Thread Jason Merrill via Gcc-patches

On 4/28/21 9:53 PM, Marek Polacek wrote:

This patch removes a FIXME I left for myself for GCC 12, along with
adjusting the relevant test.

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


OK.


gcc/cp/ChangeLog:

DR 1312
* constexpr.c (cxx_eval_constant_expression): Don't check
integer_zerop.

gcc/testsuite/ChangeLog:

DR 1312
* g++.dg/cpp0x/constexpr-cast2.C: Remove XFAILs.
---
  gcc/cp/constexpr.c   | 3 +--
  gcc/testsuite/g++.dg/cpp0x/constexpr-cast2.C | 6 +++---
  2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index fa7eaed945a..64112ff88c5 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -6747,8 +6747,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
/* [expr.const]: a conversion from type cv void* to a pointer-to-object
   type cannot be part of a core constant expression as a resolution to
   DR 1312.  */
-   if (integer_zerop (op) /* FIXME: Remove in GCC 12.  */
-   && TYPE_PTROB_P (type)
+   if (TYPE_PTROB_P (type)
&& TYPE_PTR_P (TREE_TYPE (op))
&& VOID_TYPE_P (TREE_TYPE (TREE_TYPE (op)))
/* Inside a call to std::construct_at or to
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-cast2.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-cast2.C
index 7c37f6a3f5a..b79e8a90131 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-cast2.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-cast2.C
@@ -6,11 +6,11 @@ static int i;
  constexpr void *vp0 = nullptr;
  constexpr void *vpi = 
  constexpr int *p1 = (int *) vp0; // { dg-error "cast from .void\\*. is not 
allowed" }
-constexpr int *p2 = (int *) vpi; // { dg-error "cast from .void\\*. is not allowed" 
"integer_zerop" { xfail *-*-* } }
+constexpr int *p2 = (int *) vpi; // { dg-error "cast from .void\\*. is not 
allowed" }
  constexpr int *p3 = static_cast(vp0); // { dg-error "cast from .void\\*. is 
not allowed" }
-constexpr int *p4 = static_cast(vpi); // { dg-error "cast from .void\\*. is not 
allowed" "integer_zerop" { xfail *-*-* } }
+constexpr int *p4 = static_cast(vpi); // { dg-error "cast from .void\\*. is 
not allowed" }
  constexpr void *p5 = vp0;
  constexpr void *p6 = vpi;
  
  constexpr int *pi = 

-constexpr bool b = ((int *)(void *) pi == pi); // { dg-error "cast from .void\\*. is not 
allowed" "integer_zerop" { xfail *-*-* } }
+constexpr bool b = ((int *)(void *) pi == pi); // { dg-error "cast from .void\\*. 
is not allowed" }

base-commit: e4aefface2a0e34d84b85844b11652eb28f2cf0c





Re: [Ping, Patch, Fortran, Update 2] PR98301 Re: RANDOM_INIT() and coarray Fortran

2021-05-03 Thread Steve Kargl via Gcc-patches
On Mon, May 03, 2021 at 11:21:10AM +0200, Andre Vehreschild wrote:
> Ping!
> 
> Ok for trunk?
> 
> I have looked at other patches, but none was patching any location I have
> worked on previously. Therefore I can't return the favor of reviewing any
> currently open patches and have to ask for volunteers here.
> 
> - Andre
> 

I doubt I'm allowed to approve a patch, where I wrote a portion
of it.  However, if no one else steps forward in the next day 
or two, then I think you should commit.

-- 
Steve


[PATCH 2/2] testsuite: Fix Wattributes test cases for s390 and add new test

2021-05-03 Thread Robin Dapp via Gcc-patches
Following up, this patch removes the s390-specific check for the warning 
and adds a new test.


Is it OK after the common-code changes are in?

Regards
 Robin

--

gcc/testsuite/ChangeLog:

* c-c++-common/Wattributes.c: Remove s390-specific case and new 
test.

* gcc.dg/Wattributes-6.c: Dito.
>From 0bfe8dff9190862e514e735053d50ea2426dbde7 Mon Sep 17 00:00:00 2001
From: Robin Dapp 
Date: Tue, 16 Mar 2021 11:52:32 +0100
Subject: [PATCH 2/2] testsuite: Fix Wattributes test cases for s390 and add
 new test.

There are several FAILs because we have an s390-specific check for a
warning which is not necessary anymore.  Remove it.

Add a new test case that expects a warning about conflicting function
alignment.  This would fail on s390 before but most likely on other
targets as well so it can be a target-independent test.
---
 gcc/testsuite/c-c++-common/Wattributes.c |  3 +--
 gcc/testsuite/gcc.dg/Wattributes-6.c | 15 +--
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/Wattributes.c b/gcc/testsuite/c-c++-common/Wattributes.c
index 4ad90441b4d..3f89594f100 100644
--- a/gcc/testsuite/c-c++-common/Wattributes.c
+++ b/gcc/testsuite/c-c++-common/Wattributes.c
@@ -401,8 +401,7 @@ inline int ATTR ((warn_unused_result))
 finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .warn_unused_result. because it conflicts with attribute .noreturn." } */
 
 inline int ATTR ((aligned (4)))
-  finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .aligned \\(4\\). because it conflicts with attribute .aligned \\(8\\)." "" { target { ! { hppa*64*-*-* s390*-*-* } } } } */
-/* { dg-error "alignment for '.*finline_hot_noret_align.*' must be at least 8" "" { target s390*-*-* } .-1 } */
+  finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .aligned \\(4\\). because it conflicts with attribute .aligned \\(8\\)." "" { target { ! { hppa*64*-*-* } } } } */
 
 inline int ATTR ((aligned (8)))
 finline_hot_noret_align (int);
diff --git a/gcc/testsuite/gcc.dg/Wattributes-6.c b/gcc/testsuite/gcc.dg/Wattributes-6.c
index 4ba59bf2806..8460a7dede8 100644
--- a/gcc/testsuite/gcc.dg/Wattributes-6.c
+++ b/gcc/testsuite/gcc.dg/Wattributes-6.c
@@ -401,8 +401,7 @@ inline int ATTR ((warn_unused_result))
 finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .warn_unused_result. because it conflicts with attribute .noreturn." } */
 
 inline int ATTR ((aligned (4)))
-  finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .aligned \\(4\\). because it conflicts with attribute .aligned \\(8\\)." "" { target { ! { hppa*64*-*-* s390*-*-* } } } } */
-/* { dg-error "alignment for 'finline_hot_noret_align' must be at least 8" "" { target s390*-*-* } .-1 } */
+  finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .aligned \\(4\\). because it conflicts with attribute .aligned \\(8\\)." "" { target { ! { hppa*64*-*-* } } } } */
 
 inline int ATTR ((aligned (8)))
 finline_hot_noret_align (int);
@@ -416,6 +415,18 @@ inline int ATTR ((noreturn))
 finline_hot_noret_align (int i) { (void) __builtin_abort (); }
 
 
+/* Expect a warning about conflicting alignment but without
+   other declarations inbetween.  */
+inline int ATTR ((aligned (32)))
+finline_align (int);
+
+inline int ATTR ((aligned (4)))
+  finline_align (int);  /* { dg-warning "ignoring attribute .aligned \\(4\\). because it conflicts with attribute .aligned \\(32\\)." "" } */
+
+inline int ATTR ((noreturn))
+finline_align (int i) { (void) __builtin_abort (); }
+
+
 /* Exercise variable attributes.  */
 
 extern int ATTR ((common))
-- 
2.23.0



Re: [patch] Reuse non-gimple_reg variable for inlining

2021-05-03 Thread Eric Botcazou
> Hmm, instead of (ab-)using debug_map can we instead use sth like setting
> TREE_VISITED on the argument decl (not the value - it might be passed
> multiple tiimes)?  IIRC TREE_VISITED state is undetermined thus we can
> clear it at the start of setup_one_parameter and set it when we want to
> avoid the clobber and then test for this later?
> 
> In the end I'd even find using a new bitmap to record parameter decl UIDs
> cleaner ... (I'm not sure if we not end up doing tree walks that might
> clobber TREE_VISITED here).

I tried TREE_VISITED and other similar kludges but this broke in weird ways so
reusing debug_map was probably the best of them.  Less kludgy version attached
though, before switching to a dedicated bitmap indeed.


* tree-inline.c (insert_debug_decl_map): Insert unconditionally.
(copy_debug_stmt): Minor tweak.
(setup_one_parameter): Do not create a variable if the value is either
a read-only DECL or a non-addressable local variable in the caller.
(expand_call_inline): Do not generate a CLOBBER for these values.

-- 
Eric Botcazoudiff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 1dcb31c0267..57d3b6ff6de 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -152,21 +152,11 @@ insert_decl_map (copy_body_data *id, tree key, tree value)
 id->decl_map->put (value, value);
 }
 
-/* Insert a tree->tree mapping for ID.  This is only used for
-   variables.  */
+/* Insert a tree->tree mapping for ID.  This is only used for parameters.   */
 
 static void
 insert_debug_decl_map (copy_body_data *id, tree key, tree value)
 {
-  if (!gimple_in_ssa_p (id->src_cfun))
-return;
-
-  if (!opt_for_fn (id->dst_fn, flag_var_tracking_assignments))
-return;
-
-  if (!target_for_debug_bind (key))
-return;
-
   gcc_assert (TREE_CODE (key) == PARM_DECL);
   gcc_assert (VAR_P (value));
 
@@ -3190,7 +3180,8 @@ copy_debug_stmt (gdebug *stmt, copy_body_data *id)
   else
 gcc_unreachable ();
 
-  if (TREE_CODE (t) == PARM_DECL && id->debug_map
+  if (TREE_CODE (t) == PARM_DECL
+  && id->debug_map
   && (n = id->debug_map->get (t)))
 {
   gcc_assert (VAR_P (*n));
@@ -3460,16 +3451,18 @@ setup_one_parameter (copy_body_data *id, tree p, tree value, tree fn,
  value.  */
   if (TREE_READONLY (p)
   && !TREE_ADDRESSABLE (p)
-  && value && !TREE_SIDE_EFFECTS (value)
+  && value
+  && !TREE_SIDE_EFFECTS (value)
   && !def)
 {
-  /* We may produce non-gimple trees by adding NOPs or introduce
-	 invalid sharing when operand is not really constant.
-	 It is not big deal to prohibit constant propagation here as
-	 we will constant propagate in DOM1 pass anyway.  */
-  if (is_gimple_min_invariant (value)
-	  && useless_type_conversion_p (TREE_TYPE (p),
-		 TREE_TYPE (value))
+  /* We may produce non-gimple trees by adding NOPs or introduce invalid
+	 sharing when the value is not constant or DECL.  And we need to make
+	 sure that it cannot be modified from another path in the callee.  */
+  if ((is_gimple_min_invariant (value)
+	   || (DECL_P (value) && TREE_READONLY (value))
+	   || (auto_var_in_fn_p (value, id->src_fn)
+	   && !TREE_ADDRESSABLE (value)))
+	  && useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value))
 	  /* We have to be very careful about ADDR_EXPR.  Make sure
 	 the base variable isn't a local variable of the inlined
 	 function, e.g., when doing recursive inlining, direct or
@@ -5128,8 +5121,13 @@ expand_call_inline (basic_block bb, gimple *stmt, copy_body_data *id,
 for (tree p = DECL_ARGUMENTS (id->src_fn); p; p = DECL_CHAIN (p))
   if (!TREE_THIS_VOLATILE (p))
 	{
+	  /* The value associated with P is a local temporary only if
+	 there is no value associated with P in the debug map.  */
 	  tree *varp = id->decl_map->get (p);
-	  if (varp && VAR_P (*varp) && !is_gimple_reg (*varp))
+	  if (varp
+	  && VAR_P (*varp)
+	  && !is_gimple_reg (*varp)
+	  && !(id->debug_map && id->debug_map->get (p)))
 	{
 	  tree clobber = build_clobber (TREE_TYPE (*varp));
 	  gimple *clobber_stmt;


Minor testsuite fix for cr16 and xstormy16 targets

2021-05-03 Thread Jeff Law via Gcc-patches


Richi's recent work twiddles dse1's actions for these targets. This 
patch just updates the expected output.  I'll keep an eye on other 
targets as their results trickle in.



Committed to the trunk,


Jeff

commit 4d8a13cad842e7822fa29d0aa93799033a0f7847
Author: Jeff Law 
Date:   Mon May 3 07:50:22 2021 -0700

Fix test results on cr16 and xstormy16

gcc/testsuite
* gcc.dg/tree-ssa/ssa-dse-26.c: Update expected output for
cr16 and xstormy16 targets

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
index 271e666f265..1321fec308e 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
@@ -31,8 +31,8 @@ constraint_equal (struct constraint a, struct constraint b)
 }
 
 /* Most targets should be using this test.  */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: x = " 1 "dse1" { 
target { ! { tic6x-*-* mmix-knuth-mmixware } } } } } */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: y = " 1 "dse1" { 
target { ! { tic6x-*-* mmix-knuth-mmixware } } } } } */
+/* { dg-final { scan-tree-dump-times "Deleted dead store: x = " 1 "dse1" { 
target { ! { tic6x-*-* mmix-knuth-mmixware cr16*-*-* xstormy16-*-*-* } } } } } 
*/
+/* { dg-final { scan-tree-dump-times "Deleted dead store: y = " 1 "dse1" { 
target { ! { tic6x-*-* mmix-knuth-mmixware cr16*-*-* xstormy16-*-*-* } } } } } 
*/
 
 /* The c6x port generates significantly different gimple which
changes the SRA and DSE decisions.   Verify we remove all
@@ -42,3 +42,6 @@ constraint_equal (struct constraint a, struct constraint b)
 /* { dg-final { scan-tree-dump-times "Deleted dead store: x::. = " 1 "dse1" { 
target mmix-knuth-mmixware } } } */
 /* { dg-final { scan-tree-dump-times "Deleted dead store: y::. = " 1 "dse1" { 
target mmix-knuth-mmixware } } } */
 
+/* And more special cases
+/* { dg-final { scan-tree-dump-times "Deleted dead store: x = " 2 "dse1" { 
target cr16*-*-* xstormy16-*-*-*} } } */
+/* { dg-final { scan-tree-dump-times "Deleted dead store: y = " 2 "dse1" { 
target cr16*-*-* xstormy16-*-*-*} } } */


[PATCH 1/2] c-family: Copy DECL_USER_ALIGN even if DECL_ALIGN is similar.

2021-05-03 Thread Robin Dapp via Gcc-patches

Hi,

on s390 a warning test fails:

inline int ATTR ((cold, aligned (8)))
finline_hot_noret_align (int);

inline int ATTR ((warn_unused_result))
finline_hot_noret_align (int);

inline int ATTR ((aligned (4)))
  finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute 
.aligned \\(4\\). because it conflicts with attribute .aligned \\(8\\)."


This test actually uncovered two problems.  First, on s390 the default 
function alignment is 8 bytes.  When the second decl above is merged 
with the first one, DECL_USER_ALIGN is only copied if DECL_ALIGN (old) > 
DECL_ALIGN (new).  Subsequently, when merging the third decl, no warning 
is emitted since DECL_USER_ALIGN is unset.


This patch also copies DECL_USER_ALIGN if DECL_ALIGN (old) == DECL_ALIGN 
(new) && DECL_USER_ALIGN (olddecl) != DECL_USER_ALIGN (newdecl)).



Then, while going through the related files I also noticed that we emit 
a wrong warning for:


inline int ATTR ((aligned (32)))
finline_align (int);

inline int ATTR ((aligned (4)))
  finline_align (int);  /* { dg-warning "ignoring attribute .aligned 
\\(4\\). because it conflicts with attribute .aligned \\(32\\)." "" } */


What we emit is

warning: ignoring attribute ‘aligned (4)’ because it conflicts with 
attribute ‘aligned (8)’ [-Wattributes].


This is due to the short circuit evaluation in c-attribs.c:

   && ((curalign = DECL_ALIGN (decl)) > bitalign
   || ((lastalign = DECL_ALIGN (last_decl)) > bitalign)))

where lastalign is only initialized when curalign > bitalign.  On s390 
this is not the case and lastalign is used zero-initialized in the 
following code.


On top, the following condition
  else if (!warn_if_not_aligned_p
  && TREE_CODE (decl) == FUNCTION_DECL
  && DECL_ALIGN (decl) > bitalign)

seems to be fully covered by
else if (TREE_CODE (decl) == FUNCTION_DECL
   && ((curalign = DECL_ALIGN (decl)) > bitalign
   || ((lastalign = DECL_ALIGN (last_decl)) > bitalign)))

and so is essentially dead. I therefore removed it as there does not 
seem to be a test anywhere for the error message ( "alignment for %q+D 
was previously specified as %d and may not be decreased") either.


Bootstrapped and regtested on s390, ppc64 and amd64.
Is it OK?

Regards
 Robin

--

gcc/c-family/ChangeLog:

* c-attribs.c (common_handle_aligned_attribute): Re-init 
lastalign and remove case.


gcc/c/ChangeLog:

* c-decl.c (merge_decls): Copy DECL_USER_ALIGN even for similar 
DECL_ALIGN.


gcc/cp/ChangeLog:

* decl.c (duplicate_decls): Dito.
>From f3a9f8b9bd1e28c23f2efcdb061959852a91deb6 Mon Sep 17 00:00:00 2001
From: Robin Dapp 
Date: Tue, 20 Apr 2021 10:51:18 +0200
Subject: [PATCH 1/2] c-family: Copy DECL_USER_ALIGN even if DECL_ALIGN is
 similar.

When re-declaring a function with differing attributes DECL_USER_ALIGN
is usually not merged/copied when DECL_ALIGN is similar.  On s390 this
will cause a warning message not to be shown.  Similarly, a note is not
shown when we short-circuit an alignment initialization in
common_handle_aligned_attribute ().

Fix this by copying DECL_USER_ALIGN even if DECL_ALIGN is similar as
well as reinitializing the short-circuited initialization.
---
 gcc/c-family/c-attribs.c | 23 ---
 gcc/c/c-decl.c   |  3 +++
 gcc/cp/decl.c|  5 +
 3 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index c1f652d1dc9..d132b6fd3b6 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -2317,6 +2317,10 @@ common_handle_aligned_attribute (tree *node, tree name, tree args, int flags,
 	   && ((curalign = DECL_ALIGN (decl)) > bitalign
 	   || ((lastalign = DECL_ALIGN (last_decl)) > bitalign)))
 {
+  /* Re-init lastalign in case we short-circuit the condition,
+	 i.e.  curalign > bitalign.  */
+  lastalign = DECL_ALIGN (last_decl);
+
   /* Either a prior attribute on the same declaration or one
 	 on a prior declaration of the same function specifies
 	 stricter alignment than this attribute.  */
@@ -2366,25 +2370,6 @@ common_handle_aligned_attribute (tree *node, tree name, tree args, int flags,
   This formally comes from the c++11 specification but we are
   doing it for the GNU attribute syntax as well.  */
 *no_add_attrs = true;
-  else if (!warn_if_not_aligned_p
-	   && TREE_CODE (decl) == FUNCTION_DECL
-	   && DECL_ALIGN (decl) > bitalign)
-{
-  /* Don't warn for function alignment here if warn_if_not_aligned_p
-	 is true.  It will be warned about later.  */
-  if (DECL_USER_ALIGN (decl))
-	{
-	  /* Only reject attempts to relax/override an alignment
-	 explicitly specified previously and accept declarations
-	 that appear to relax the implicit function alignment for
-	 the target.  Both increasing and increasing the alignment
-	 set by -falign-functions setting is permitted.  */
-	  error ("alignment for %q+D was 

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

2021-05-03 Thread Simon Marchi via Gcc-patches
> Yes, I prefer the configure fix too.  If we state we require C99 in
> binutils then we ought to be able to use C99..
> 
> Nick, does the configure.ac change also need to go in all subdirs, to
> support people running make in say ld/ rather than running make in the
> top build dir?

For GDB, it's not supported to run gdb/configure directly, you need to
use the top-level configure.  Is it supported from some of the other
projects in the repo?

I just tried with ld, it doesn't work since it depends on bfd also being
built.  I tried with just bfd, it doesn't work (with the default
configure options at least) because it requires zlib being built.

So if all projects need to go through the top-level configure script
anyway, and C99 is a baseline for all projects, then having the check
only in the top-level makes sense to me.  Projects that have more
specific requirements can have their own checks.  For example, sim/
requires C11 now.  Unless the C99 check at top-level somehow does not
play well with the C11 check in sim/?  Like if that would cause CC to be
set to "gcc -std=gnu99 -std=gnu11" or something like that.

Simon


Re: [PATCH] Avoid DSE/DCE of pure call that throws

2021-05-03 Thread Richard Biener
On Mon, 3 May 2021, Michael Matz wrote:

> Hello,
> 
> On Mon, 3 May 2021, Jan Hubicka wrote:
> 
> > > (it should not abort).  The documentation of 'pure' must be read
> > > as that 'pure' is not valid for 'foo' since throwing an exception
> > > is obviously an observable effect on the state of the program
> > > (in particular for the testcase at hand).  But for example
> > > IPA pure const does not cause us to infer nothrow on pure
> > > declared functions and the C++ program
> > > 
> > > ...
> > > 
> > > So - what is it?  Are pure functions allowed to throw or not?
> > 
> > I was one adding pure functions and it was really intended to be same
> > thing as const+reading memory.  So does const function throw or not?
> 
> I really want to say that const/pure and throw are mutually exclusive.  
> But in reality they are orthogonal, so a const function may throw.  (It 
> certainly can in C++).
> 
> This is because while we implement exceptions with memory state, that 
> state in not accessible to the application.  Exceptions could for instance 
> also be implemented via return type extension.  And then, as long as other 
> guarantees of const or pure functions are adhered to (same input -> same 
> output), throwing an exception from a const function would be completely 
> natural.  E.g. if a const function, given a specific set of arguments, 
> always throws the same value that would still allow to CSE two calls to it 
> in a row, and it would still allow to assume that no reachable memory was 
> changed by that call.
> 
> So, I think const and pure functions may validly throw (but then must 
> always do so given the same inputs).

I've filed PR100394 since it appearantly never worked (for C++).

Richard.

> 
> Ciao,
> Michael.
> 
> 
> > Internally we definitly want to make this separate - with symbol
> > summaries it is now reasonably easy to do.  I was thinking of doing
> > similar summary as modref handles to pass down separate info tracked by
> > pure-const patch rather than trying to re-synthetize it to rather random
> > attributes we have now...
> > 
> > Honza
> > > 
> > > 2021-05-03  Richard Biener  
> > > 
> > >   * calls.c (expand_call): Preserve possibly throwing calls.
> > >   * cfgexpand.c (expand_call_stmt): When a call can throw signal
> > >   RTL expansion there are side-effects.
> > >   * tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Simplify.
> > >   * tree-ssa-dse.c (pass_dse::execute): Preserve exceptions unless
> > >   -fdelete-dead-exceptions.
> > > 
> > >   * g++.dg/tree-ssa/pr100382.C: New testcase.
> > > ---
> > >  gcc/calls.c  |  1 +
> > >  gcc/cfgexpand.c  |  5 -
> > >  gcc/testsuite/g++.dg/tree-ssa/pr100382.C | 25 
> > >  gcc/tree-ssa-dce.c   | 21 +++-
> > >  gcc/tree-ssa-dse.c   |  3 ++-
> > >  5 files changed, 35 insertions(+), 20 deletions(-)
> > >  create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> > > 
> > > diff --git a/gcc/calls.c b/gcc/calls.c
> > > index 883d08ba5f2..f3da1839dc5 100644
> > > --- a/gcc/calls.c
> > > +++ b/gcc/calls.c
> > > @@ -3808,6 +3808,7 @@ expand_call (tree exp, rtx target, int ignore)
> > >   side-effects.  */
> > >if ((flags & (ECF_CONST | ECF_PURE))
> > >&& (!(flags & ECF_LOOPING_CONST_OR_PURE))
> > > +  && (flags & ECF_NOTHROW)
> > >&& (ignore || target == const0_rtx
> > > || TYPE_MODE (rettype) == VOIDmode))
> > >  {
> > > diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> > > index a6b48d3e48f..556a0b22ed6 100644
> > > --- a/gcc/cfgexpand.c
> > > +++ b/gcc/cfgexpand.c
> > > @@ -2795,7 +2795,10 @@ expand_call_stmt (gcall *stmt)
> > >CALL_EXPR_ARG (exp, i) = arg;
> > >  }
> > >  
> > > -  if (gimple_has_side_effects (stmt))
> > > +  if (gimple_has_side_effects (stmt)
> > > +  /* ???  Downstream in expand_expr_real_1 we assume that expressions
> > > +  w/o side-effects do not throw so work around this here.  */
> > > +  || stmt_could_throw_p (cfun, stmt))
> > >  TREE_SIDE_EFFECTS (exp) = 1;
> > >  
> > >if (gimple_call_nothrow_p (stmt))
> > > diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr100382.C 
> > > b/gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> > > new file mode 100644
> > > index 000..b9948d3034a
> > > --- /dev/null
> > > +++ b/gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> > > @@ -0,0 +1,25 @@
> > > +// { dg-do run }
> > > +// { dg-options "-O2" }
> > > +
> > > +int x, y;
> > > +int __attribute__((pure,noinline)) foo () { if (x) throw; return y; }
> > > +
> > > +int __attribute__((noinline)) bar()
> > > +{
> > > +  int a[2];
> > > +  x = 1;
> > > +  try {
> > > +int res = foo ();
> > > +a[0] = res;
> > > +  } catch (...) {
> > > +  return 0;
> > > +  }
> > > +  return 1;
> > > +}
> > > +
> > > +int main()
> > > +{
> > > +  if (bar ())
> > > +__builtin_abort ();
> > > +  return 0;
> > > +}
> > > diff --git 

Re: [PATCH] Avoid DSE/DCE of pure call that throws

2021-05-03 Thread Michael Matz
Hello,

On Mon, 3 May 2021, Jan Hubicka wrote:

> > (it should not abort).  The documentation of 'pure' must be read
> > as that 'pure' is not valid for 'foo' since throwing an exception
> > is obviously an observable effect on the state of the program
> > (in particular for the testcase at hand).  But for example
> > IPA pure const does not cause us to infer nothrow on pure
> > declared functions and the C++ program
> > 
> > ...
> > 
> > So - what is it?  Are pure functions allowed to throw or not?
> 
> I was one adding pure functions and it was really intended to be same
> thing as const+reading memory.  So does const function throw or not?

I really want to say that const/pure and throw are mutually exclusive.  
But in reality they are orthogonal, so a const function may throw.  (It 
certainly can in C++).

This is because while we implement exceptions with memory state, that 
state in not accessible to the application.  Exceptions could for instance 
also be implemented via return type extension.  And then, as long as other 
guarantees of const or pure functions are adhered to (same input -> same 
output), throwing an exception from a const function would be completely 
natural.  E.g. if a const function, given a specific set of arguments, 
always throws the same value that would still allow to CSE two calls to it 
in a row, and it would still allow to assume that no reachable memory was 
changed by that call.

So, I think const and pure functions may validly throw (but then must 
always do so given the same inputs).


Ciao,
Michael.


> Internally we definitly want to make this separate - with symbol
> summaries it is now reasonably easy to do.  I was thinking of doing
> similar summary as modref handles to pass down separate info tracked by
> pure-const patch rather than trying to re-synthetize it to rather random
> attributes we have now...
> 
> Honza
> > 
> > 2021-05-03  Richard Biener  
> > 
> > * calls.c (expand_call): Preserve possibly throwing calls.
> > * cfgexpand.c (expand_call_stmt): When a call can throw signal
> > RTL expansion there are side-effects.
> > * tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Simplify.
> > * tree-ssa-dse.c (pass_dse::execute): Preserve exceptions unless
> > -fdelete-dead-exceptions.
> > 
> > * g++.dg/tree-ssa/pr100382.C: New testcase.
> > ---
> >  gcc/calls.c  |  1 +
> >  gcc/cfgexpand.c  |  5 -
> >  gcc/testsuite/g++.dg/tree-ssa/pr100382.C | 25 
> >  gcc/tree-ssa-dce.c   | 21 +++-
> >  gcc/tree-ssa-dse.c   |  3 ++-
> >  5 files changed, 35 insertions(+), 20 deletions(-)
> >  create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> > 
> > diff --git a/gcc/calls.c b/gcc/calls.c
> > index 883d08ba5f2..f3da1839dc5 100644
> > --- a/gcc/calls.c
> > +++ b/gcc/calls.c
> > @@ -3808,6 +3808,7 @@ expand_call (tree exp, rtx target, int ignore)
> >   side-effects.  */
> >if ((flags & (ECF_CONST | ECF_PURE))
> >&& (!(flags & ECF_LOOPING_CONST_OR_PURE))
> > +  && (flags & ECF_NOTHROW)
> >&& (ignore || target == const0_rtx
> >   || TYPE_MODE (rettype) == VOIDmode))
> >  {
> > diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> > index a6b48d3e48f..556a0b22ed6 100644
> > --- a/gcc/cfgexpand.c
> > +++ b/gcc/cfgexpand.c
> > @@ -2795,7 +2795,10 @@ expand_call_stmt (gcall *stmt)
> >CALL_EXPR_ARG (exp, i) = arg;
> >  }
> >  
> > -  if (gimple_has_side_effects (stmt))
> > +  if (gimple_has_side_effects (stmt)
> > +  /* ???  Downstream in expand_expr_real_1 we assume that expressions
> > +w/o side-effects do not throw so work around this here.  */
> > +  || stmt_could_throw_p (cfun, stmt))
> >  TREE_SIDE_EFFECTS (exp) = 1;
> >  
> >if (gimple_call_nothrow_p (stmt))
> > diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr100382.C 
> > b/gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> > new file mode 100644
> > index 000..b9948d3034a
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> > @@ -0,0 +1,25 @@
> > +// { dg-do run }
> > +// { dg-options "-O2" }
> > +
> > +int x, y;
> > +int __attribute__((pure,noinline)) foo () { if (x) throw; return y; }
> > +
> > +int __attribute__((noinline)) bar()
> > +{
> > +  int a[2];
> > +  x = 1;
> > +  try {
> > +int res = foo ();
> > +a[0] = res;
> > +  } catch (...) {
> > +  return 0;
> > +  }
> > +  return 1;
> > +}
> > +
> > +int main()
> > +{
> > +  if (bar ())
> > +__builtin_abort ();
> > +  return 0;
> > +}
> > diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
> > index 096cfc8721d..ff0389af36f 100644
> > --- a/gcc/tree-ssa-dce.c
> > +++ b/gcc/tree-ssa-dce.c
> > @@ -250,14 +250,6 @@ mark_stmt_if_obviously_necessary (gimple *stmt, bool 
> > aggressive)
> > && DECL_IS_REPLACEABLE_OPERATOR_NEW_P (callee))
> >   return;
> >  
> > -   /* Most, but not all function 

Re: [PATCH] Avoid DSE/DCE of pure call that throws

2021-05-03 Thread Richard Biener
On Mon, 3 May 2021, Eric Botcazou wrote:

> > So - what is it?  Are pure functions allowed to throw or not?
> 
> We keep going back to this every N years and I'm not sure why...  In Ada the 
> answer is definitely yes, we have entire library units marked Pure and thus 
> containing bunch of pure functions but they can throw like any other function.

OK, so then we definitely have all the latent issues I paper over with
the patch and that isn't even enough.

Do you have extra fixes in your tree or does -fnon-call-exceptions
somehow magically paper over the issue?

I suppose if the C or C++ frontends like to have pure/const attributed
functions not throw they could mark functions accordingly themselves.

Which also means, the Ada functions are DECL_PURE_P but not 'pure'
according to the extend.texi documentation of the user-visible
attribute?  That said, I think if my C++ testcase is valid then we
should amend this documentation (or if not then as well, to not
re-iterate this every N years).  Do you agree?

Thanks,
Richard.


Re: [PATCH] Avoid DSE/DCE of pure call that throws

2021-05-03 Thread Eric Botcazou
> So - what is it?  Are pure functions allowed to throw or not?

We keep going back to this every N years and I'm not sure why...  In Ada the 
answer is definitely yes, we have entire library units marked Pure and thus 
containing bunch of pure functions but they can throw like any other function.

-- 
Eric Botcazou




Re: [PATCH] Avoid DSE/DCE of pure call that throws

2021-05-03 Thread Richard Biener
On Mon, 3 May 2021, Jan Hubicka wrote:

> > note that if you wrap foo () into another noinline
> > wrap_foo () { foo (); return 1; } function then we need to make
> > sure to not DCE this call either even though it only throws
> > externally.  Now the question is whether this testcase is valid
> > (it should not abort).  The documentation of 'pure' must be read
> > as that 'pure' is not valid for 'foo' since throwing an exception
> > is obviously an observable effect on the state of the program
> > (in particular for the testcase at hand).  But for example
> > IPA pure const does not cause us to infer nothrow on pure
> > declared functions and the C++ program
> > 
> > extern int __attribute__((pure)) foo();
> > int bar()
> > {
> >   try
> > {
> >   return foo ();
> > }
> >   catch (...)
> > {
> >   return -1;
> > }
> > }
> > 
> > is compiled with full EH in place. (clang elides all of it, btw)
> > 
> > The set of changes below do not succeed in it passing but at least
> > the throwing call prevails but somehow EH info is hosed and you'll
> > get
> > 
> > > ./pr100382.exe
> > terminate called without an active exception
> > Aborted (core dumped)
> > 
> > So - what is it?  Are pure functions allowed to throw or not?
> 
> I was one adding pure functions and it was really intended to be same
> thing as const+reading memory.  So does const function throw or not?
> Internally we definitly want to make this separate - with symbol
> summaries it is now reasonably easy to do.  I was thinking of doing
> similar summary as modref handles to pass down separate info tracked by
> pure-const patch rather than trying to re-synthetize it to rather random
> attributes we have now...

Yes, we handle 'const' as throwing (well, we don't optimize it as
not throwing...).  But since 'const' is a subset of 'pure' functions
if pure functions cannot throw then const functions can not either.

extern int __attribute__((const)) foo();
int bar()
{
  try
{
  return foo ();
}
  catch (...)
{
  return -1;
}
}

has EH emitted as well.

Richard.

> Honza
> > 
> > 2021-05-03  Richard Biener  
> > 
> > * calls.c (expand_call): Preserve possibly throwing calls.
> > * cfgexpand.c (expand_call_stmt): When a call can throw signal
> > RTL expansion there are side-effects.
> > * tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Simplify.
> > * tree-ssa-dse.c (pass_dse::execute): Preserve exceptions unless
> > -fdelete-dead-exceptions.
> > 
> > * g++.dg/tree-ssa/pr100382.C: New testcase.
> > ---
> >  gcc/calls.c  |  1 +
> >  gcc/cfgexpand.c  |  5 -
> >  gcc/testsuite/g++.dg/tree-ssa/pr100382.C | 25 
> >  gcc/tree-ssa-dce.c   | 21 +++-
> >  gcc/tree-ssa-dse.c   |  3 ++-
> >  5 files changed, 35 insertions(+), 20 deletions(-)
> >  create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> > 
> > diff --git a/gcc/calls.c b/gcc/calls.c
> > index 883d08ba5f2..f3da1839dc5 100644
> > --- a/gcc/calls.c
> > +++ b/gcc/calls.c
> > @@ -3808,6 +3808,7 @@ expand_call (tree exp, rtx target, int ignore)
> >   side-effects.  */
> >if ((flags & (ECF_CONST | ECF_PURE))
> >&& (!(flags & ECF_LOOPING_CONST_OR_PURE))
> > +  && (flags & ECF_NOTHROW)
> >&& (ignore || target == const0_rtx
> >   || TYPE_MODE (rettype) == VOIDmode))
> >  {
> > diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> > index a6b48d3e48f..556a0b22ed6 100644
> > --- a/gcc/cfgexpand.c
> > +++ b/gcc/cfgexpand.c
> > @@ -2795,7 +2795,10 @@ expand_call_stmt (gcall *stmt)
> >CALL_EXPR_ARG (exp, i) = arg;
> >  }
> >  
> > -  if (gimple_has_side_effects (stmt))
> > +  if (gimple_has_side_effects (stmt)
> > +  /* ???  Downstream in expand_expr_real_1 we assume that expressions
> > +w/o side-effects do not throw so work around this here.  */
> > +  || stmt_could_throw_p (cfun, stmt))
> >  TREE_SIDE_EFFECTS (exp) = 1;
> >  
> >if (gimple_call_nothrow_p (stmt))
> > diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr100382.C 
> > b/gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> > new file mode 100644
> > index 000..b9948d3034a
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> > @@ -0,0 +1,25 @@
> > +// { dg-do run }
> > +// { dg-options "-O2" }
> > +
> > +int x, y;
> > +int __attribute__((pure,noinline)) foo () { if (x) throw; return y; }
> > +
> > +int __attribute__((noinline)) bar()
> > +{
> > +  int a[2];
> > +  x = 1;
> > +  try {
> > +int res = foo ();
> > +a[0] = res;
> > +  } catch (...) {
> > +  return 0;
> > +  }
> > +  return 1;
> > +}
> > +
> > +int main()
> > +{
> > +  if (bar ())
> > +__builtin_abort ();
> > +  return 0;
> > +}
> > diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
> > index 096cfc8721d..ff0389af36f 100644
> > --- a/gcc/tree-ssa-dce.c
> > +++ b/gcc/tree-ssa-dce.c
> > @@ 

Re: [committed][nvptx] Set -misa=sm_35 by default

2021-05-03 Thread Tom de Vries
On 3/23/21 9:04 AM, Thomas Schwinge wrote:
> From eac0d3458f38cd5bb4c930b2887a547b64b046ef Mon Sep 17 00:00:00 2001
> From: Thomas Schwinge 
> Date: Wed, 13 Jan 2021 09:04:47 +0100
> Subject: [PATCH] [nvptx] Let nvptx-as figure out the target architecture
>  [PR97348]
> 
> ... now that it has been enhanced to do so.
> 
> This is a follow-up to PR97348 commit 383400a6078d75bbfa1216c9af2c37f7e88740c9
> "[nvptx] Set -misa=sm_35 by default".
> 
>   gcc/
>   PR target/97348
>   * config/nvptx/nvptx.h (ASM_SPEC): Don't set.
>   * config/nvptx/nvptx.opt (misa): Adjust comment.
> ---
>  gcc/config/nvptx/nvptx.h   | 5 -
>  gcc/config/nvptx/nvptx.opt | 1 -
>  2 files changed, 6 deletions(-)
> 
> diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
> index 2451703e77f..1a61e6207f6 100644
> --- a/gcc/config/nvptx/nvptx.h
> +++ b/gcc/config/nvptx/nvptx.h
> @@ -29,11 +29,6 @@
>  
>  #define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
>  
> -/* Default needs to be in sync with default for misa in nvptx.opt.
> -   We add a default here to work around a hard-coded sm_30 default in
> -   nvptx-as.  */
> -#define ASM_SPEC "%{misa=*:-m %*; :-m sm_35}"
> -
>  #define TARGET_CPU_CPP_BUILTINS()\
>do \
>  {\
> diff --git a/gcc/config/nvptx/nvptx.opt b/gcc/config/nvptx/nvptx.opt
> index 51363e4e276..cf7f9022663 100644
> --- a/gcc/config/nvptx/nvptx.opt
> +++ b/gcc/config/nvptx/nvptx.opt
> @@ -61,7 +61,6 @@ Enum(ptx_isa) String(sm_30) Value(PTX_ISA_SM30)
>  EnumValue
>  Enum(ptx_isa) String(sm_35) Value(PTX_ISA_SM35)
>  
> -; Default needs to be in sync with default in ASM_SPEC in nvptx.h.
>  misa=
>  Target RejectNegative ToLower Joined Enum(ptx_isa) Var(ptx_isa_option) 
> Init(PTX_ISA_SM35)
>  Specify the version of the ptx ISA to use.
> -- 2.17.1

Hi Thomas,

Sorry for the delay.  LGTM, please apply.

Thanks,
- Tom


Re: [PATCH] Avoid DSE/DCE of pure call that throws

2021-05-03 Thread Jan Hubicka
> note that if you wrap foo () into another noinline
> wrap_foo () { foo (); return 1; } function then we need to make
> sure to not DCE this call either even though it only throws
> externally.  Now the question is whether this testcase is valid
> (it should not abort).  The documentation of 'pure' must be read
> as that 'pure' is not valid for 'foo' since throwing an exception
> is obviously an observable effect on the state of the program
> (in particular for the testcase at hand).  But for example
> IPA pure const does not cause us to infer nothrow on pure
> declared functions and the C++ program
> 
> extern int __attribute__((pure)) foo();
> int bar()
> {
>   try
> {
>   return foo ();
> }
>   catch (...)
> {
>   return -1;
> }
> }
> 
> is compiled with full EH in place. (clang elides all of it, btw)
> 
> The set of changes below do not succeed in it passing but at least
> the throwing call prevails but somehow EH info is hosed and you'll
> get
> 
> > ./pr100382.exe
> terminate called without an active exception
> Aborted (core dumped)
> 
> So - what is it?  Are pure functions allowed to throw or not?

I was one adding pure functions and it was really intended to be same
thing as const+reading memory.  So does const function throw or not?
Internally we definitly want to make this separate - with symbol
summaries it is now reasonably easy to do.  I was thinking of doing
similar summary as modref handles to pass down separate info tracked by
pure-const patch rather than trying to re-synthetize it to rather random
attributes we have now...

Honza
> 
> 2021-05-03  Richard Biener  
> 
>   * calls.c (expand_call): Preserve possibly throwing calls.
>   * cfgexpand.c (expand_call_stmt): When a call can throw signal
>   RTL expansion there are side-effects.
>   * tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Simplify.
>   * tree-ssa-dse.c (pass_dse::execute): Preserve exceptions unless
>   -fdelete-dead-exceptions.
> 
>   * g++.dg/tree-ssa/pr100382.C: New testcase.
> ---
>  gcc/calls.c  |  1 +
>  gcc/cfgexpand.c  |  5 -
>  gcc/testsuite/g++.dg/tree-ssa/pr100382.C | 25 
>  gcc/tree-ssa-dce.c   | 21 +++-
>  gcc/tree-ssa-dse.c   |  3 ++-
>  5 files changed, 35 insertions(+), 20 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> 
> diff --git a/gcc/calls.c b/gcc/calls.c
> index 883d08ba5f2..f3da1839dc5 100644
> --- a/gcc/calls.c
> +++ b/gcc/calls.c
> @@ -3808,6 +3808,7 @@ expand_call (tree exp, rtx target, int ignore)
>   side-effects.  */
>if ((flags & (ECF_CONST | ECF_PURE))
>&& (!(flags & ECF_LOOPING_CONST_OR_PURE))
> +  && (flags & ECF_NOTHROW)
>&& (ignore || target == const0_rtx
> || TYPE_MODE (rettype) == VOIDmode))
>  {
> diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> index a6b48d3e48f..556a0b22ed6 100644
> --- a/gcc/cfgexpand.c
> +++ b/gcc/cfgexpand.c
> @@ -2795,7 +2795,10 @@ expand_call_stmt (gcall *stmt)
>CALL_EXPR_ARG (exp, i) = arg;
>  }
>  
> -  if (gimple_has_side_effects (stmt))
> +  if (gimple_has_side_effects (stmt)
> +  /* ???  Downstream in expand_expr_real_1 we assume that expressions
> +  w/o side-effects do not throw so work around this here.  */
> +  || stmt_could_throw_p (cfun, stmt))
>  TREE_SIDE_EFFECTS (exp) = 1;
>  
>if (gimple_call_nothrow_p (stmt))
> diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr100382.C 
> b/gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> new file mode 100644
> index 000..b9948d3034a
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/tree-ssa/pr100382.C
> @@ -0,0 +1,25 @@
> +// { dg-do run }
> +// { dg-options "-O2" }
> +
> +int x, y;
> +int __attribute__((pure,noinline)) foo () { if (x) throw; return y; }
> +
> +int __attribute__((noinline)) bar()
> +{
> +  int a[2];
> +  x = 1;
> +  try {
> +int res = foo ();
> +a[0] = res;
> +  } catch (...) {
> +  return 0;
> +  }
> +  return 1;
> +}
> +
> +int main()
> +{
> +  if (bar ())
> +__builtin_abort ();
> +  return 0;
> +}
> diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
> index 096cfc8721d..ff0389af36f 100644
> --- a/gcc/tree-ssa-dce.c
> +++ b/gcc/tree-ssa-dce.c
> @@ -250,14 +250,6 @@ mark_stmt_if_obviously_necessary (gimple *stmt, bool 
> aggressive)
>   && DECL_IS_REPLACEABLE_OPERATOR_NEW_P (callee))
> return;
>  
> - /* Most, but not all function calls are required.  Function calls that
> -produce no result and have no side effects (i.e. const pure
> -functions) are unnecessary.  */
> - if (gimple_has_side_effects (stmt))
> -   {
> - mark_stmt_necessary (stmt, true);
> - return;
> -   }
>   /* IFN_GOACC_LOOP calls are necessary in that they are used to
>  represent parameter (i.e. step, bound) of a lowered OpenACC
>  

[PATCH] Avoid DSE/DCE of pure call that throws

2021-05-03 Thread Richard Biener
There is -fdelete-dead-exceptions now and we're tracking
nothrow and const/pure bits separately and I do remember that
const or pure does _not_ imply nothrow.

Now, in the light of the PR100382 fix which added a
stmt_unremovable_because_of_non_call_eh_p guard to DSEs "DCE"
I wondered how -fdelete-dead-exceptions applies to calls and
whether stmt_unremovable_because_of_non_call_eh_p doing

  return (fun->can_throw_non_call_exceptions
  && !fun->can_delete_dead_exceptions
  && stmt_could_throw_p (fun, stmt));

really should conditionalize itself on
fun->can_throw_non_call_exceptions.  In fact DCE happily elides
pure function calls that throw without a LHS (probably a
consistency bug).  The following testcase shows this:

int x, y;
int __attribute__((pure,noinline)) foo () { if (x) throw; return y; }

int main()
{
  int a[2];
  x = 1;
  try {
int res = foo ();
a[0] = res;
  } catch (...) {
  return 0;
  }
  return 1;
}

note that if you wrap foo () into another noinline
wrap_foo () { foo (); return 1; } function then we need to make
sure to not DCE this call either even though it only throws
externally.  Now the question is whether this testcase is valid
(it should not abort).  The documentation of 'pure' must be read
as that 'pure' is not valid for 'foo' since throwing an exception
is obviously an observable effect on the state of the program
(in particular for the testcase at hand).  But for example
IPA pure const does not cause us to infer nothrow on pure
declared functions and the C++ program

extern int __attribute__((pure)) foo();
int bar()
{
  try
{
  return foo ();
}
  catch (...)
{
  return -1;
}
}

is compiled with full EH in place. (clang elides all of it, btw)

The set of changes below do not succeed in it passing but at least
the throwing call prevails but somehow EH info is hosed and you'll
get

> ./pr100382.exe
terminate called without an active exception
Aborted (core dumped)

So - what is it?  Are pure functions allowed to throw or not?

2021-05-03  Richard Biener  

* calls.c (expand_call): Preserve possibly throwing calls.
* cfgexpand.c (expand_call_stmt): When a call can throw signal
RTL expansion there are side-effects.
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Simplify.
* tree-ssa-dse.c (pass_dse::execute): Preserve exceptions unless
-fdelete-dead-exceptions.

* g++.dg/tree-ssa/pr100382.C: New testcase.
---
 gcc/calls.c  |  1 +
 gcc/cfgexpand.c  |  5 -
 gcc/testsuite/g++.dg/tree-ssa/pr100382.C | 25 
 gcc/tree-ssa-dce.c   | 21 +++-
 gcc/tree-ssa-dse.c   |  3 ++-
 5 files changed, 35 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr100382.C

diff --git a/gcc/calls.c b/gcc/calls.c
index 883d08ba5f2..f3da1839dc5 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -3808,6 +3808,7 @@ expand_call (tree exp, rtx target, int ignore)
  side-effects.  */
   if ((flags & (ECF_CONST | ECF_PURE))
   && (!(flags & ECF_LOOPING_CONST_OR_PURE))
+  && (flags & ECF_NOTHROW)
   && (ignore || target == const0_rtx
  || TYPE_MODE (rettype) == VOIDmode))
 {
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index a6b48d3e48f..556a0b22ed6 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -2795,7 +2795,10 @@ expand_call_stmt (gcall *stmt)
   CALL_EXPR_ARG (exp, i) = arg;
 }
 
-  if (gimple_has_side_effects (stmt))
+  if (gimple_has_side_effects (stmt)
+  /* ???  Downstream in expand_expr_real_1 we assume that expressions
+w/o side-effects do not throw so work around this here.  */
+  || stmt_could_throw_p (cfun, stmt))
 TREE_SIDE_EFFECTS (exp) = 1;
 
   if (gimple_call_nothrow_p (stmt))
diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr100382.C 
b/gcc/testsuite/g++.dg/tree-ssa/pr100382.C
new file mode 100644
index 000..b9948d3034a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr100382.C
@@ -0,0 +1,25 @@
+// { dg-do run }
+// { dg-options "-O2" }
+
+int x, y;
+int __attribute__((pure,noinline)) foo () { if (x) throw; return y; }
+
+int __attribute__((noinline)) bar()
+{
+  int a[2];
+  x = 1;
+  try {
+int res = foo ();
+a[0] = res;
+  } catch (...) {
+  return 0;
+  }
+  return 1;
+}
+
+int main()
+{
+  if (bar ())
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index 096cfc8721d..ff0389af36f 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -250,14 +250,6 @@ mark_stmt_if_obviously_necessary (gimple *stmt, bool 
aggressive)
&& DECL_IS_REPLACEABLE_OPERATOR_NEW_P (callee))
  return;
 
-   /* Most, but not all function calls are required.  Function calls that
-  produce no result and have no side effects (i.e. const pure
-  functions) are unnecessary.  */
-   if 

[PATCH] Improve PHI handling in DSE

2021-05-03 Thread Richard Biener
This improves handling of PHI defs when walking uses in
dse_classify_store to track two PHI defs.  This happens
when there are CFG merges and one PHI feeds into another.
If we decide to want more then using a sbitmap for this might be
the way to go.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

2021-05-03  Richard Biener  

* tree-ssa-dse.c (dse_classify_store): Track two PHI defs.

* gcc.dg/tree-ssa/ssa-dse-42.c: New testcase.
* gcc.dg/pr81192.c: Disable DSE.
---
 gcc/testsuite/gcc.dg/pr81192.c |  4 +++-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-42.c | 20 +++
 gcc/tree-ssa-dse.c | 23 +-
 3 files changed, 37 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-42.c

diff --git a/gcc/testsuite/gcc.dg/pr81192.c b/gcc/testsuite/gcc.dg/pr81192.c
index 71bbc13a0e9..6cab6056558 100644
--- a/gcc/testsuite/gcc.dg/pr81192.c
+++ b/gcc/testsuite/gcc.dg/pr81192.c
@@ -1,4 +1,4 @@
-/* { dg-options "-Os -fdump-tree-pre-details -fdisable-tree-evrp" } */
+/* { dg-options "-Os -fdump-tree-pre-details -fdisable-tree-evrp 
-fno-tree-dse" } */
 
 /* Disable tree-evrp because the new version of evrp sees
  :
@@ -16,6 +16,8 @@ produces
   # iftmp.2_12 = PHI <2147483647(3), iftmp.2_11(4)> 
 which causes the situation being tested to dissapear before we get to PRE.  */
 
+/* Likewise disable DSE which also elides the tail merging "opportunity".  */
+
 #if __SIZEOF_INT__ == 2
 #define unsigned __UINT32_TYPE__
 #define int __INT32_TYPE__
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-42.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-42.c
new file mode 100644
index 000..34108c83828
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-42.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-dse1" } */
+
+int a[2];
+void foo(int i, int k, int j)
+{
+  a[0] = i;
+  if (k)
+a[0] = a[i] + k;
+  else
+{
+  if (j)
+a[1] = 1;
+  a[0] = a[i] + 3;
+}
+  a[0] = 0;
+}
+
+/* The last stores to a[0] and a[1] remain.  */
+/* { dg-final { scan-tree-dump-times " = " 2 "dse1" } } */
diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index e0a944c704a..dfa6d314727 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -799,7 +799,8 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
return DSE_STORE_LIVE;
 
   auto_vec defs;
-  gimple *phi_def = NULL;
+  gimple *first_phi_def = NULL;
+  gimple *last_phi_def = NULL;
   FOR_EACH_IMM_USE_STMT (use_stmt, ui, defvar)
{
  /* Limit stmt walking.  */
@@ -825,7 +826,9 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
 SSA_NAME_VERSION (PHI_RESULT (use_stmt
{
  defs.safe_push (use_stmt);
- phi_def = use_stmt;
+ if (!first_phi_def)
+   first_phi_def = use_stmt;
+ last_phi_def = use_stmt;
}
}
  /* If the statement is a use the store is not dead.  */
@@ -889,6 +892,8 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
  gimple *def = defs[i];
  gimple *use_stmt;
  use_operand_p use_p;
+ tree vdef = (gimple_code (def) == GIMPLE_PHI
+  ? gimple_phi_result (def) : gimple_vdef (def));
  /* If the path to check starts with a kill we do not need to
 process it further.
 ???  With byte tracking we need only kill the bytes currently
@@ -901,8 +906,7 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
}
  /* If the path ends here we do not need to process it further.
 This for example happens with calls to noreturn functions.  */
- else if (gimple_code (def) != GIMPLE_PHI
-  && has_zero_uses (gimple_vdef (def)))
+ else if (has_zero_uses (vdef))
{
  /* But if the store is to global memory it is definitely
 not dead.  */
@@ -912,12 +916,13 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
}
  /* In addition to kills we can remove defs whose only use
 is another def in defs.  That can only ever be PHIs of which
-we track a single for simplicity reasons (we fail for multiple
-PHIs anyways).  We can also ignore defs that feed only into
+we track two for simplicity reasons, the first and last in
+{first,last}_phi_def (we fail for multiple PHIs anyways).
+We can also ignore defs that feed only into
 already visited PHIs.  */
- else if (gimple_code (def) != GIMPLE_PHI
-  && single_imm_use (gimple_vdef (def), _p, _stmt)
-  && (use_stmt == phi_def
+ else if (single_imm_use (vdef, _p, _stmt)
+  && (use_stmt == first_phi_def
+  || use_stmt == 

Re: [PATCH] split loop for NE condition.

2021-05-03 Thread Richard Biener
On Thu, 29 Apr 2021, Jiufu Guo wrote:

> When there is the possibility that overflow may happen on the loop index,
> a few optimizations would not happen. For example code:
> 
> foo (int *a, int *b, unsigned k, unsigned n)
> {
>   while (++k != n)
> a[k] = b[k]  + 1;
> }
> 
> For this code, if "l > n", overflow may happen.  if "l < n" at begining,
> it could be optimized (e.g. vectorization).
> 
> We can split the loop into two loops:
> 
>   while (++k > n)
> a[k] = b[k]  + 1;
>   while (l++ < n)
> a[k] = b[k]  + 1;
> 
> then for the second loop, it could be optimized.
> 
> This patch is spltting this kind of small loop to achieve better performance.
> 
> Bootstrap and regtest pass on ppc64le.  Is this ok for trunk?

Do you have any statistics on how often this splits a loop during
bootstrap (use --with-build-config=bootstrap-O3)?  Or alternatively
on SPEC?

Actual comments on the patch inline.

> Thanks!
> 
> Jiufu Guo.
> 
> gcc/ChangeLog:
> 
> 2021-04-29  Jiufu Guo  
> 
>   * params.opt (max-insns-ne-cond-split): New.
>   * tree-ssa-loop-split.c (connect_loop_phis): Add new param.
>   (get_ne_cond_branch): New function.
>   (split_ne_loop): New function.
>   (split_loop_on_ne_cond): New function.
>   (tree_ssa_split_loops): Use split_loop_on_ne_cond.
>   
> gcc/testsuite/ChangeLog:
> 2021-04-29  Jiufu Guo  
> 
>   * gcc.dg/loop-split1.c: New test.
> 
> ---
>  gcc/params.opt |   4 +
>  gcc/testsuite/gcc.dg/loop-split1.c |  28 
>  gcc/tree-ssa-loop-split.c  | 219 -
>  3 files changed, 247 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/loop-split1.c
> 
> diff --git a/gcc/params.opt b/gcc/params.opt
> index 2e4cbdd7a71..900b59b5136 100644
> --- a/gcc/params.opt
> +++ b/gcc/params.opt
> @@ -766,6 +766,10 @@ Min. ratio of insns to prefetches to enable prefetching 
> for a loop with an unkno
>  Common Joined UInteger Var(param_min_loop_cond_split_prob) Init(30) 
> IntegerRange(0, 100) Param Optimization
>  The minimum threshold for probability of semi-invariant condition statement 
> to trigger loop split.
>  
> +-param=max-insns-ne-cond-split=
> +Common Joined UInteger Var(param_max_insn_ne_cond_split) Init(64) Param 
> Optimization
> +The maximum threshold for insnstructions number of a loop with ne condition 
> to split.
> +
>  -param=min-nondebug-insn-uid=
>  Common Joined UInteger Var(param_min_nondebug_insn_uid) Param
>  The minimum UID to be used for a nondebug insn.
> diff --git a/gcc/testsuite/gcc.dg/loop-split1.c 
> b/gcc/testsuite/gcc.dg/loop-split1.c
> new file mode 100644
> index 000..4c466aa9f54
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/loop-split1.c
> @@ -0,0 +1,28 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fsplit-loops -fdump-tree-lsplit-details" } */
> +
> +void
> +foo (int *a, int *b, unsigned l, unsigned n)
> +{
> +  while (++l != n)
> +a[l] = b[l]  + 1;
> +}
> +
> +void
> +foo1 (int *a, int *b, unsigned l, unsigned n)
> +{
> +  while (l++ != n)
> +a[l] = b[l]  + 1;
> +}
> +
> +unsigned
> +foo2 (char *a, char *b, unsigned l, unsigned n)
> +{
> +  while (++l != n)
> +if (a[l] != b[l])
> +  break;
> +
> +  return l;
> +}
> +
> +/* { dg-final { scan-tree-dump-times "Loop split" 3 "lsplit" } } */
> diff --git a/gcc/tree-ssa-loop-split.c b/gcc/tree-ssa-loop-split.c
> index b80b6a75e62..a6d28078e5e 100644
> --- a/gcc/tree-ssa-loop-split.c
> +++ b/gcc/tree-ssa-loop-split.c
> @@ -41,6 +41,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "cfghooks.h"
>  #include "gimple-fold.h"
>  #include "gimplify-me.h"
> +#include "tree-ssa-loop-ivopts.h"
>  
>  /* This file implements two kinds of loop splitting.
>  
> @@ -233,7 +234,8 @@ easy_exit_values (class loop *loop)
> this.  The loops need to fulfill easy_exit_values().  */
>  
>  static void
> -connect_loop_phis (class loop *loop1, class loop *loop2, edge new_e)
> +connect_loop_phis (class loop *loop1, class loop *loop2, edge new_e,
> +bool use_prev = false)
>  {
>basic_block rest = loop_preheader_edge (loop2)->src;
>gcc_assert (new_e->dest == rest);
> @@ -248,13 +250,14 @@ connect_loop_phis (class loop *loop1, class loop 
> *loop2, edge new_e)
> !gsi_end_p (psi_first);
> gsi_next (_first), gsi_next (_second))
>  {
> -  tree init, next, new_init;
> +  tree init, next, new_init, prev;
>use_operand_p op;
>gphi *phi_first = psi_first.phi ();
>gphi *phi_second = psi_second.phi ();
>  
>init = PHI_ARG_DEF_FROM_EDGE (phi_first, firste);
>next = PHI_ARG_DEF_FROM_EDGE (phi_first, firstn);
> +  prev = PHI_RESULT (phi_first);
>op = PHI_ARG_DEF_PTR_FROM_EDGE (phi_second, seconde);
>gcc_assert (operand_equal_for_phi_arg_p (init, USE_FROM_PTR (op)));
>  
> @@ -279,7 +282,7 @@ connect_loop_phis (class loop *loop1, class loop *loop2, 
> edge new_e)
>  
>gphi 

Re: [PATCH v2] Add line debug info for virtual thunks [PR97937]

2021-05-03 Thread Richard Biener
On Thu, 29 Apr 2021, Bernd Edlinger wrote:

> Hi!
> 
> 
> I've re-based and re-tested this patch on current trunk.
> Otherwise the patch is unchanged, from the previous v2 version.
> 
> This patch is fixing two issues with functions where we
> do not have proper debug info:
> 
> 1. Functions without line-numbers at all, are excluded from
> the CU's address range in the debug info.  This makes the
> debugger not display any line numbers but instead the debugger
> steps into assembler.
> 
> 2. Functions with a declaration line number show this line
> number instead of a completely unrelated line-number from a
> different function that was emitted before the current one.
> 
> So, since we are again in stage 1:
> Is it OK for trunk?

Overall it looks good to me but I'm not familiar with the code
and thus maybe unable to spot obvious downsides.

So - OK unless you hear concerns by others in a day or two.

Thanks,
Richard.

> 
> Thanks
> Bernd.
> 
> 
> On 1/13/21 3:59 PM, Bernd Edlinger wrote:
> > Hi,
> > 
> > this is a new improved version of my patch.
> > The previous patch had two defects:
> > It failed with -ffunction-section.  Although
> > the line info was emitted, that was not working
> > since the debug_ranges did not contain the
> > thunk.
> > And secondly it failed to address the case of
> > functions without any source line information.
> > 
> > The new pattch addresses both cases, of DECL_IGNORED_P
> > functions:
> > 
> > In the case of virtual thunks we emit the line
> > number from the declaration.
> > Other than the previous version this patch
> > also explicitly adds the virtual thunk to the
> > debug_ranges and debug_aranges.  If that is not
> > done, the debugger does not recognize the line
> > table for these functions.
> > 
> > But if that location info is unavailable,
> > the function is explicitly removed from the
> > debug_ranges and debug_aranges.  That has
> > the same effect as a theoretical .noloc assembler
> > directive.
> > 
> > 
> > Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> > Is it OK for trunk?
> > 
> > 
> > Thanks
> > Bernd.
> > 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)


Re: [patch] Reuse non-gimple_reg variable for inlining

2021-05-03 Thread Richard Biener via Gcc-patches
On Mon, May 3, 2021 at 11:02 AM Eric Botcazou  wrote:
>
> Hi,
>
> when a call to a function is inlined and takes a parameter whose type is not
> gimple_reg, a variable is created in the caller to hold a copy of the argument
> passed in the call with the following comment:
>
>   /* We may produce non-gimple trees by adding NOPs or introduce
>  invalid sharing when operand is not really constant.
>  It is not big deal to prohibit constant propagation here as
>  we will constant propagate in DOM1 pass anyway.  *
>
> Of course the second sentence of the comment does not apply to non-gimple_reg
> values, unless they get SRAed later, because we do not do constant propagation
> for them.  This for example prevents two identical calls to a pure function
> from being merged in the attached Ada testcase.
>
> Therefore the attached patch attempts to reuse a read-only or non-addressable
> local DECL of the caller, the hitch being that expand_call_inline needs to be
> prevented from creating a CLOBBER for the cases where it ends uo being reused.
>
> Tested on x86-64/Linux, OK for the mainline?

Hmm, instead of (ab-)using debug_map can we instead use sth like setting
TREE_VISITED on the argument decl (not the value - it might be passed
multiple tiimes)?  IIRC TREE_VISITED state is undetermined thus we can
clear it at the start of setup_one_parameter and set it when we want to avoid
the clobber and then test for this later?

In the end I'd even find using a new bitmap to record parameter decl UIDs
cleaner ... (I'm not sure if we not end up doing tree walks that might clobber
TREE_VISITED here).

Otherwise looks OK.

Thanks,
Richard.

>
> 2021-05-03  Eric Botcazou  
>
> * tree-inline.c (setup_one_parameter): Do not create a variable if the
> value is either a read-only DECL or a non-addressable local variable.
> Register the variable thus reused instead of creating a new one.
> (expand_call_inline): Do not generate a CLOBBER for these variables.
>
>
> 2021-05-03  Eric Botcazou  
>
> * gnat.dg/opt94.adb: New test.
> * gnat.dg/opt94_pkg.ads, opt94.adb: New helper.
>
> --
> Eric Botcazou


Re: [PATCH v2] IBM Z: Handle hard registers in s390_md_asm_adjust()

2021-05-03 Thread Ilya Leoshkevich via Gcc-patches
On Fri, 2021-04-30 at 08:49 +0200, Andreas Krebbel wrote:
> On 4/28/21 3:48 AM, Ilya Leoshkevich wrote:
> > Bootstrapped and regtested on s390x-redhat-linux.  Tested with
> > valgrind
> > too (PR 100278 is now fixed).  Ok for master?
> > 
> > v1:
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568771.html
> > v1 -> v2: Use the UNSPEC pattern, which is less efficient, but is
> > more
> >   on the "obviously correct" side than gen_raw_SUBREG().
> > 
> > 
> > 
> > gen_fprx2_to_tf() and gen_tf_to_fprx2() cannot handle hard
> > registers,
> > since the subregs they create do not pass validation.  Change
> > s390_md_asm_adjust() to manually copy between hard VRs and FPRs
> > instead
> > of using these two functions.
> > 
> > gcc/ChangeLog:
> > 
> > PR target/100217
> > * config/s390/s390.c (s390_hard_fp_reg_p): New function.
> > (s390_md_asm_adjust): Handle hard registers.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR target/100217
> > * gcc.target/s390/vector/long-double-asm-in-out-hard-fp-
> > reg.c: New test.
> > * gcc.target/s390/vector/long-double-asm-inout-hard-fp-
> > reg.c: New test.
> 
> Ok. Thanks!
> 
> Andreas

Thanks!

I forgot to ask: ok for gcc-11 branch?



Re: [PATCH v2 0/2] OpenRISC support for cmodel=large

2021-05-03 Thread Giulio Benetti

Hi Stafford, All,

I've backported this patchset for Buildroot to versions:
- 9.3.0
- 10.3.0

Does it make sense to send them? I don't know if those version will have 
minor versions where these backported patches can be applied.


Best regards
--
Giulio Benetti
Benetti Engineering sas

On 5/1/21 11:11 PM, Stafford Horne wrote:

Changes from v1:
  - Added patch to enabled cmodle=large on crtstuff

This series fixes some bugs found when linking large binaries, both in buildroot
and glibc testing.

Stafford Horne (2):
   or1k: Add mcmodel option to handle large GOTs
   or1k: Use cmodel=large when building crtstuff

  gcc/config/or1k/or1k-opts.h   | 30 ++
  gcc/config/or1k/or1k.c| 11 +--
  gcc/config/or1k/or1k.h|  7 +++
  gcc/config/or1k/or1k.opt  | 19 +++
  gcc/doc/invoke.texi   | 12 +++-
  libgcc/config.host|  4 ++--
  libgcc/config/or1k/t-crtstuff |  2 ++
  7 files changed, 80 insertions(+), 5 deletions(-)
  create mode 100644 gcc/config/or1k/or1k-opts.h
  create mode 100644 libgcc/config/or1k/t-crtstuff



Re: [PATCH][openmp, simt] Error out for user-defined reduction

2021-05-03 Thread Jakub Jelinek via Gcc-patches
On Mon, May 03, 2021 at 12:24:10PM +0200, Tom de Vries wrote:
> The test-case included in this patch contains this target region:
> ...
>   for (int i0 = 0 ; i0 < N0 ; i0++ )
> counter_N0.i += 1;
> ...
> 
> When running with nvptx accelerator, the counter variable is expected to
> be N0 after the region, but instead is N0 / 32.  The problem is that rather
> than getting the result for all warp lanes, we get it for just one lane.
> 
> This is caused by the implementation of SIMT being incomplete.  It handles
> regular reductions, but appearantly not user-defined reductions.
> 
> For now, make this explicit by erroring out for nvptx, like this:
> ...
> target-44.c: In function 'main':
> target-44.c:20:9: error: SIMT reduction not fully implemented
> ...
> 
> Tested libgomp on x86_64-linux with and without nvptx accelerator.
> 
> Any comments?

If you want a workaround, the workaround should be to disable SIMT if
UDR reductions are seen, rather than erroring out.
So e.g. in lower_rec_simd_input_clauses for sctx->is_simt if sctx->max_vf
isn't 1 look for OMP_CLAUSE_REDUCTION with OMP_CLAUSE_REDUCTION_PLACEHOLDER
and punt (set max_vf = 1) in that case.

The right thing is to implement it properly of course.

Jakub



[PATCH][openmp, simt] Error out for user-defined reduction

2021-05-03 Thread Tom de Vries
Hi,

The test-case included in this patch contains this target region:
...
  for (int i0 = 0 ; i0 < N0 ; i0++ )
counter_N0.i += 1;
...

When running with nvptx accelerator, the counter variable is expected to
be N0 after the region, but instead is N0 / 32.  The problem is that rather
than getting the result for all warp lanes, we get it for just one lane.

This is caused by the implementation of SIMT being incomplete.  It handles
regular reductions, but appearantly not user-defined reductions.

For now, make this explicit by erroring out for nvptx, like this:
...
target-44.c: In function 'main':
target-44.c:20:9: error: SIMT reduction not fully implemented
...

Tested libgomp on x86_64-linux with and without nvptx accelerator.

Any comments?

Thanks,
- Tom

[openmp, simt] Error out for user-defined reduction

gcc/ChangeLog:

2021-05-03  Tom de Vries  

PR target/100321
* omp-low.c (lower_rec_input_clauses): Error out for user-defined 
reduction
for SIMT.

libgomp/ChangeLog:

2021-05-03  Tom de Vries  

PR target/100321
* testsuite/libgomp.c/target-44.c: New test.

---
 gcc/omp-low.c   |  2 ++
 libgomp/testsuite/libgomp.c/target-44.c | 28 
 2 files changed, 30 insertions(+)

diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 7b122059c6e..0f122857a3a 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -6005,6 +6005,8 @@ lower_rec_input_clauses (tree clauses, gimple_seq *ilist, 
gimple_seq *dlist,
  tree placeholder = OMP_CLAUSE_REDUCTION_PLACEHOLDER (c);
  gimple *tseq;
  tree ptype = TREE_TYPE (placeholder);
+ if (sctx.is_simt)
+   error ("SIMT reduction not fully implemented");
  if (cond)
{
  x = error_mark_node;
diff --git a/libgomp/testsuite/libgomp.c/target-44.c 
b/libgomp/testsuite/libgomp.c/target-44.c
new file mode 100644
index 000..497931cd14c
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c/target-44.c
@@ -0,0 +1,28 @@
+/* { dg-do link { target { offload_target_nvptx } } } */
+/* { dg-additional-options "-foffload=-latomic" { target { 
offload_target_nvptx } } } */
+/* { dg-error "SIMT reduction not fully implemented" "" { target { 
offload_target_nvptx } } 0 }  */
+#include 
+
+struct s
+{
+  int i;
+};
+
+#pragma omp declare reduction(+: struct s: omp_out.i += omp_in.i)
+
+int
+main (void)
+{
+  const int N0 = 32768;
+
+  struct s counter_N0 = { 0 };
+#pragma omp target
+#pragma omp for simd reduction(+: counter_N0)
+  for (int i0 = 0 ; i0 < N0 ; i0++ )
+counter_N0.i += 1;
+
+  if (counter_N0.i != N0)
+abort ();
+
+  return 0;
+}


[PATCH] Perform reverse program order walk for GIMPLE DSE

2021-05-03 Thread Richard Biener
The following changes the post-dominator domwalk done by GIMPLE DSE
to a reverse program order walk.  This enables 2% more stmts do be
DSEd during bootstrap and in particular for testcases like the one
added where it is important to visit post dominators in a particular
order.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

2021-05-03  Richard Biener  

* tree-ssa-dse.c: Do not include domwalk.h but cfganal.h.
(dse_dom_walker): Remove.
(dse_dom_walker::dse_optimize_stmt): Rename...
(dse_optimize_stmt): ... to this, pass in live_bytes sbitmap.
(dse_dom_walker::before_dom_children): Inline ...
(pass_dse::execute): ... here.  Perform a reverse program
order walk.

* gcc.dg/tree-ssa/ssa-dse-41.c: New testcase.
---
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-41.c |  16 ++
 gcc/tree-ssa-dse.c | 182 +
 2 files changed, 91 insertions(+), 107 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-41.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-41.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-41.c
new file mode 100644
index 000..9128eea1035
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-41.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-dse1" } */
+
+int a[2];
+void foo(int i, int k)
+{
+  a[0] = i;
+  if (k)
+a[0] = a[i] + k;
+  else
+a[0] = a[i] + 3;
+  a[0] = 0;
+}
+
+/* Only the last store remains.  */
+/* { dg-final { scan-tree-dump-times " = " 1 "dse1" } } */
diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index 76929fa03c7..e0a944c704a 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -31,7 +31,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple-iterator.h"
 #include "tree-cfg.h"
 #include "tree-dfa.h"
-#include "domwalk.h"
 #include "tree-cfgcleanup.h"
 #include "alias.h"
 #include "tree-ssa-loop.h"
@@ -40,6 +39,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple-fold.h"
 #include "gimplify.h"
 #include "tree-eh.h"
+#include "cfganal.h"
 
 /* This file implements dead store elimination.
 
@@ -958,31 +958,6 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
 }
 
 
-class dse_dom_walker : public dom_walker
-{
-public:
-  dse_dom_walker (cdi_direction direction)
-: dom_walker (direction),
-m_live_bytes (param_dse_max_object_size),
-m_byte_tracking_enabled (false),
-m_need_cfg_cleanup (false) {}
-
-  virtual edge before_dom_children (basic_block);
-  unsigned todo () const;
-
-private:
-  auto_sbitmap m_live_bytes;
-  bool m_byte_tracking_enabled;
-  bool m_need_cfg_cleanup;
-  void dse_optimize_stmt (gimple_stmt_iterator *);
-};
-
-unsigned
-dse_dom_walker::todo () const
-{
-  return m_need_cfg_cleanup ? TODO_cleanup_cfg : 0;
-}
-
 /* Delete a dead call at GSI, which is mem* call of some kind.  */
 static void
 delete_dead_or_redundant_call (gimple_stmt_iterator *gsi, const char *type)
@@ -1054,8 +1029,8 @@ delete_dead_or_redundant_assignment (gimple_stmt_iterator 
*gsi, const char *type
is used precisely once by a later store to the same location which
post dominates the first store, then the first store is dead.  */
 
-void
-dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator *gsi)
+static void
+dse_optimize_stmt (gimple_stmt_iterator *gsi, sbitmap live_bytes)
 {
   gimple *stmt = gsi_stmt (*gsi);
 
@@ -1104,17 +1079,17 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator 
*gsi)
  dse_optimize_redundant_stores (stmt);
 
enum dse_store_status store_status;
-   m_byte_tracking_enabled
- = setup_live_bytes_from_ref (, m_live_bytes);
+   bool byte_tracking_enabled
+ = setup_live_bytes_from_ref (, live_bytes);
store_status = dse_classify_store (, stmt,
-  m_byte_tracking_enabled,
-  m_live_bytes);
+  byte_tracking_enabled,
+  live_bytes);
if (store_status == DSE_STORE_LIVE)
  return;
 
if (store_status == DSE_STORE_MAYBE_PARTIAL_DEAD)
  {
-   maybe_trim_memstar_call (, m_live_bytes, stmt);
+   maybe_trim_memstar_call (, live_bytes, stmt);
return;
  }
 
@@ -1150,18 +1125,18 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator 
*gsi)
;
   else
{
- m_byte_tracking_enabled
-   = setup_live_bytes_from_ref (, m_live_bytes);
+ bool byte_tracking_enabled
+   = setup_live_bytes_from_ref (, live_bytes);
  enum dse_store_status store_status;
  store_status = dse_classify_store (, stmt,
-m_byte_tracking_enabled,
-m_live_bytes, 

Re: [PATCH] tree-ssa-dse: Fix up go.test/test/fixedbugs/issue16095.go miscompilation [PR100382]

2021-05-03 Thread Richard Biener
On Mon, 3 May 2021, Jakub Jelinek wrote:

> Hi!
> 
> The new DCE code inside of tree DSE removes in -fnon-call-exceptions
> go code a load from NULL pointer the testcase relies on throwing an
> exception and so the test hangs.
> 
> The following patch just repeats a check that e.g. tree-ssa-dce.c
> uses to prevent this.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

> 2021-05-03  Jakub Jelinek  
> 
>   PR tree-optimization/100382
>   * tree-ssa-dse.c: Include tree-eh.h.
>   (dse_dom_walker::before_dom_children): Don't remove stmts if
>   stmt_unremovable_because_of_non_call_eh_p is true.
> 
> --- gcc/tree-ssa-dse.c.jj 2021-05-02 16:25:43.636266833 +0200
> +++ gcc/tree-ssa-dse.c2021-05-02 19:42:53.451320031 +0200
> @@ -39,6 +39,7 @@ along with GCC; see the file COPYING3.
>  #include "builtins.h"
>  #include "gimple-fold.h"
>  #include "gimplify.h"
> +#include "tree-eh.h"
>  
>  /* This file implements dead store elimination.
>  
> @@ -1193,7 +1194,8 @@ dse_dom_walker::before_dom_children (bas
> /* When we remove dead stores make sure to also delete trivially
>dead SSA defs.  */
> if (has_zero_uses (DEF_FROM_PTR (def_p))
> -   && !gimple_has_side_effects (stmt))
> +   && !gimple_has_side_effects (stmt)
> +   && !stmt_unremovable_because_of_non_call_eh_p (cfun, stmt))
>   {
> if (dump_file && (dump_flags & TDF_DETAILS))
>   {
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)


[Ada] Replace calls to RTE with Is_RTE where possible

2021-05-03 Thread Pierre-Marie de Rodat
Replace expression of the form "X = RTE (...)" with "Is_RTE (X, ...)",
which avoids loading of the unit where the ... entity is defined. In
particular, a sequence of RTE_Available and RTE load the target unit
where Is_RTE doesn't.

This patch is primarily a code cleanup, but it also avoids unnecessary
loading of Ada.Tags in few cases.

The only context where replacing RTE with Is_RTE isn't really needed is
pragma Assert (X = RTE (...)), because we expect the equality to hold,
but this patch replaces such calls to RTE as well, for consistency.

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

gcc/ada/

* checks.adb, exp_aggr.adb, exp_attr.adb, exp_ch6.adb,
exp_disp.adb, exp_imgv.adb, exp_util.adb, sem_attr.adb,
sem_ch13.adb, sem_ch8.adb, sem_eval.adb, sem_scil.adb,
sem_util.adb: Replace calls to RTE with Is_RTE.diff --git a/gcc/ada/checks.adb b/gcc/ada/checks.adb
--- a/gcc/ada/checks.adb
+++ b/gcc/ada/checks.adb
@@ -552,9 +552,7 @@ package body Checks is
 
   if Tagged_Type_Expansion
 and then Present (Etype (P))
-and then RTU_Loaded (Ada_Tags)
-and then RTE_Available (RE_Offset_To_Top_Ptr)
-and then Etype (P) = RTE (RE_Offset_To_Top_Ptr)
+and then Is_RTE (Etype (P), RE_Offset_To_Top_Ptr)
   then
  return;
   end if;


diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -8678,30 +8678,25 @@ package body Exp_Aggr is
begin
   return Building_Static_Dispatch_Tables
 and then Tagged_Type_Expansion
-and then RTU_Loaded (Ada_Tags)
 
  --  Avoid circularity when rebuilding the compiler
 
-and then Cunit_Entity (Get_Source_Unit (N)) /= RTU_Entity (Ada_Tags)
-and then (Typ = RTE (RE_Dispatch_Table_Wrapper)
+and then not Is_RTU (Cunit_Entity (Get_Source_Unit (N)), Ada_Tags)
+and then (Is_RTE (Typ, RE_Dispatch_Table_Wrapper)
 or else
-  Typ = RTE (RE_Address_Array)
+  Is_RTE (Typ, RE_Address_Array)
 or else
-  Typ = RTE (RE_Type_Specific_Data)
+  Is_RTE (Typ, RE_Type_Specific_Data)
 or else
-  Typ = RTE (RE_Tag_Table)
+  Is_RTE (Typ, RE_Tag_Table)
 or else
-  (RTE_Available (RE_Object_Specific_Data)
- and then Typ = RTE (RE_Object_Specific_Data))
+  Is_RTE (Typ, RE_Object_Specific_Data)
 or else
-  (RTE_Available (RE_Interface_Data)
- and then Typ = RTE (RE_Interface_Data))
+  Is_RTE (Typ, RE_Interface_Data)
 or else
-  (RTE_Available (RE_Interfaces_Array)
- and then Typ = RTE (RE_Interfaces_Array))
+  Is_RTE (Typ, RE_Interfaces_Array)
 or else
-  (RTE_Available (RE_Interface_Data_Element)
- and then Typ = RTE (RE_Interface_Data_Element)));
+  Is_RTE (Typ, RE_Interface_Data_Element));
end Is_Static_Dispatch_Table_Aggregate;
 
-


diff --git a/gcc/ada/exp_attr.adb b/gcc/ada/exp_attr.adb
--- a/gcc/ada/exp_attr.adb
+++ b/gcc/ada/exp_attr.adb
@@ -2150,7 +2150,7 @@ package body Exp_Attr is
--  the node with the type imposed by the context.
 
if Nkind (Parent (N)) = N_Unchecked_Type_Conversion
- and then Etype (Parent (N)) = RTE (RE_Prim_Ptr)
+ and then Is_RTE (Etype (Parent (N)), RE_Prim_Ptr)
then
   Set_Etype (N, RTE (RE_Prim_Ptr));
 


diff --git a/gcc/ada/exp_ch6.adb b/gcc/ada/exp_ch6.adb
--- a/gcc/ada/exp_ch6.adb
+++ b/gcc/ada/exp_ch6.adb
@@ -10010,8 +10010,6 @@ package body Exp_Ch6 is
  elsif Nkind (Expr) = N_Function_Call
and then Nkind (Name (Expr)) in N_Has_Entity
and then Present (Entity (Name (Expr)))
-   and then RTU_Loaded (Ada_Tags)
-   and then RTE_Available (RE_Displace)
and then Is_RTE (Entity (Name (Expr)), RE_Displace)
  then
 Has_Pointer_Displacement := True;


diff --git a/gcc/ada/exp_disp.adb b/gcc/ada/exp_disp.adb
--- a/gcc/ada/exp_disp.adb
+++ b/gcc/ada/exp_disp.adb
@@ -161,9 +161,8 @@ package body Exp_Disp is
   --  This capability of dispatching directly by tag is also needed by the
   --  implementation of AI-260 (for the generic dispatching constructors).
 
-  if Ctrl_Typ = RTE (RE_Tag)
-or else (RTE_Available (RE_Interface_Tag)
-  and then Ctrl_Typ = RTE (RE_Interface_Tag))
+  if Is_RTE (Ctrl_Typ, RE_Tag)
+or else Is_RTE (Ctrl_Typ, RE_Interface_Tag)
   then
  CW_Typ := Class_Wide_Type (Find_Dispatching_Type (Subp));
 
@@ -527,8 +526,7 @@ package body Exp_Disp is
  

[Ada] Refine type of a counter object from Int to Nat

2021-05-03 Thread Pierre-Marie de Rodat
A local counter objects that are initialized with 0 and only incremented
now have type Nat instead of Int. Code cleanup; semantics is unaffected.

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

gcc/ada/

* exp_ch7.adb (Build_Finalize_Statements): Refine type of a
local counter variable.
* exp_dist.adb (Append_Record_Traversal): Refine type of Counter
parameter.
(Add_Process_Element): Likewise.
(Build_From_Any_Call): Refine type of a local counter variable.
(Build_From_Any_Function): Likewise.
(Build_To_Any_Function): Likewise.
(FA_Rec_Add_Process_Element): Likewise.
(TA_Append_Record_Traversal): Likewise.
(TA_Rec_Add_Process_Element): Likewise.diff --git a/gcc/ada/exp_ch7.adb b/gcc/ada/exp_ch7.adb
--- a/gcc/ada/exp_ch7.adb
+++ b/gcc/ada/exp_ch7.adb
@@ -8225,7 +8225,7 @@ package body Exp_Ch7 is
  Loc : constant Source_Ptr := Sloc (Typ);
  Typ_Def : constant Node_Id:= Type_Definition (Parent (Typ));
 
- Counter: Int := 0;
+ Counter: Nat := 0;
  Finalizer_Data : Finalization_Exception_Data;
 
  function Process_Component_List_For_Finalize


diff --git a/gcc/ada/exp_dist.adb b/gcc/ada/exp_dist.adb
--- a/gcc/ada/exp_dist.adb
+++ b/gcc/ada/exp_dist.adb
@@ -8261,7 +8261,7 @@ package body Exp_Dist is
 with procedure Add_Process_Element
   (Stmts : List_Id;
Container : Node_Or_Entity_Id;
-   Counter   : in out Int;
+   Counter   : in out Nat;
Rec   : Entity_Id;
Field : Node_Id);
 --  Rec is the instance of the record type, or Empty.
@@ -8272,7 +8272,7 @@ package body Exp_Dist is
(Stmts : List_Id;
 Clist : Node_Id;
 Container : Node_Or_Entity_Id;
-Counter   : in out Int);
+Counter   : in out Nat);
  --  Process component list Clist. Individual fields are passed
  --  to Field_Processing. Each variant part is also processed.
  --  Container is the outer Any (for From_Any/To_Any),
@@ -8286,7 +8286,7 @@ package body Exp_Dist is
(Stmts : List_Id;
 Clist : Node_Id;
 Container : Node_Or_Entity_Id;
-Counter   : in out Int)
+Counter   : in out Nat)
  is
 CI : List_Id;
 VP : Node_Id;
@@ -8674,7 +8674,7 @@ package body Exp_Dist is
  Rdef  : constant Node_Id :=
Type_Definition
  (Declaration_Node (Typ));
- Component_Counter : Int := 0;
+ Component_Counter : Nat := 0;
 
  --  The returned object
 
@@ -8685,7 +8685,7 @@ package body Exp_Dist is
  procedure FA_Rec_Add_Process_Element
(Stmts   : List_Id;
 Any : Entity_Id;
-Counter : in out Int;
+Counter : in out Nat;
 Rec : Entity_Id;
 Field   : Node_Id);
 
@@ -8701,7 +8701,7 @@ package body Exp_Dist is
  procedure FA_Rec_Add_Process_Element
(Stmts   : List_Id;
 Any : Entity_Id;
-Counter : in out Int;
+Counter : in out Nat;
 Rec : Entity_Id;
 Field   : Node_Id)
  is
@@ -8735,7 +8735,7 @@ package body Exp_Dist is
 
declare
   Variant: Node_Id;
-  Struct_Counter : Int := 0;
+  Struct_Counter : Nat := 0;
 
   Block_Decls : constant List_Id := New_List;
   Block_Stmts : constant List_Id := New_List;
@@ -9540,13 +9540,13 @@ package body Exp_Dist is
  Disc : Entity_Id := Empty;
  Rdef : constant Node_Id :=
   Type_Definition (Declaration_Node (Typ));
- Counter  : Int := 0;
+ Counter  : Nat := 0;
  Elements : constant List_Id := New_List;
 
  procedure TA_Rec_Add_Process_Element
(Stmts : List_Id;
 Container : Node_Or_Entity_Id;
-Counter   : in out Int;
+Counter   : in out Nat;
 Rec   : Entity_Id;
 Field : Node_Id);
  --  Processing routine for traversal below
@@ -9563,7 +9563,7 @@ package body Exp_Dist is
  procedure 

[Ada] Ada.Strings.Unbounded.Aux.Set_String

2021-05-03 Thread Pierre-Marie de Rodat
The current version of Set_String is no longer used and not very useful
and even unsafe with the introduction of a-stunau__shared.adb.

Replace it with a more useful and safer version taking a callback to set
the string.

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

gcc/ada/

* libgnat/a-stunau.ads, libgnat/a-stunau.adb,
libgnat/a-stunau__shared.adb (Set_String): Remove old version,
replace by a new version taking a callback to set the string.diff --git a/gcc/ada/libgnat/a-stunau.adb b/gcc/ada/libgnat/a-stunau.adb
--- a/gcc/ada/libgnat/a-stunau.adb
+++ b/gcc/ada/libgnat/a-stunau.adb
@@ -52,11 +52,17 @@ package body Ada.Strings.Unbounded.Aux is
-- Set_String --

 
-   procedure Set_String (UP : in out Unbounded_String; S : String_Access) is
+   procedure Set_String
+ (U  : out Unbounded_String;
+  Length : Positive;
+  Set: not null access procedure (S : out String))
+   is
+  Old : String_Access := U.Reference;
begin
-  Finalize (UP);
-  UP.Reference := S;
-  UP.Last := UP.Reference'Length;
+  U.Last := Length;
+  U.Reference := new String (1 .. Length);
+  Set (U.Reference.all);
+  Free (Old);
end Set_String;
 
 end Ada.Strings.Unbounded.Aux;


diff --git a/gcc/ada/libgnat/a-stunau.ads b/gcc/ada/libgnat/a-stunau.ads
--- a/gcc/ada/libgnat/a-stunau.ads
+++ b/gcc/ada/libgnat/a-stunau.ads
@@ -56,22 +56,24 @@ package Ada.Strings.Unbounded.Aux is
   S : out Big_String_Access;
   L : out Natural);
pragma Inline (Get_String);
-   --  This procedure returns the internal string pointer used in the
-   --  representation of an unbounded string as well as the actual current
-   --  length (which may be less than S.all'Length because in general there
-   --  can be extra space assigned). The characters of this string may be
-   --  not be modified via the returned pointer,  and are valid only as
-   --  long as the original unbounded string is not accessed or modified.
+   --  Return the internal string pointer used in the representation of an
+   --  unbounded string as well as the actual current length (which may be less
+   --  than S.all'Length because in general there can be extra space assigned).
+   --  The characters of this string may be not be modified via the returned
+   --  pointer, and are valid only as long as the original unbounded string is
+   --  not accessed or modified.
--
--  This procedure is much more efficient than the use of To_String
--  since it avoids the need to copy the string. The lower bound of the
--  referenced string returned by this call is always one, so the actual
--  string data is always accessible as S (1 .. L).
 
-   procedure Set_String (UP : in out Unbounded_String; S : String_Access);
+   procedure Set_String
+ (U  : out Unbounded_String;
+  Length : Positive;
+  Set: not null access procedure (S : out String));
pragma Inline (Set_String);
-   --  This version of Set_Unbounded_String takes a string access value, rather
-   --  than a string. The lower bound of the string value is required to be
-   --  one, and this requirement is not checked.
+   --  Create an unbounded string U with the given Length, using Set to fill
+   --  the contents of U.
 
 end Ada.Strings.Unbounded.Aux;


diff --git a/gcc/ada/libgnat/a-stunau__shared.adb b/gcc/ada/libgnat/a-stunau__shared.adb
--- a/gcc/ada/libgnat/a-stunau__shared.adb
+++ b/gcc/ada/libgnat/a-stunau__shared.adb
@@ -51,12 +51,30 @@ package body Ada.Strings.Unbounded.Aux is
-- Set_String --

 
-   procedure Set_String (UP : in out Unbounded_String; S : String_Access) is
-  X : String_Access := S;
-
+   procedure Set_String
+ (U  : out Unbounded_String;
+  Length : Positive;
+  Set: not null access procedure (S : out String))
+   is
+  TR : constant Shared_String_Access := U.Reference;
+  DR : Shared_String_Access;
begin
-  Set_Unbounded_String (UP, S.all);
-  Free (X);
+  --  Try to reuse existing shared string
+
+  if Can_Be_Reused (TR, Length) then
+ Reference (TR);
+ DR := TR;
+
+  --  Otherwise allocate new shared string
+
+  else
+ DR := Allocate (Length);
+ U.Reference := DR;
+  end if;
+
+  Set (DR.Data (1 .. Length));
+  DR.Last := Length;
+  Unreference (TR);
end Set_String;
 
 end Ada.Strings.Unbounded.Aux;




[Ada] Remove unused initial values in expansion of distributed calls

2021-05-03 Thread Pierre-Marie de Rodat
Default initialization of a local Fname variable was never used. Code
cleanup only; semantics is unaffected.

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

gcc/ada/

* exp_dist.adb (Build_From_Any_Call): Remove initial value for
Fnam; fix style.
(Build_To_Any_Call): Remove initial value for Fnam.
(Build_TypeCode_Call): Likewise.diff --git a/gcc/ada/exp_dist.adb b/gcc/ada/exp_dist.adb
--- a/gcc/ada/exp_dist.adb
+++ b/gcc/ada/exp_dist.adb
@@ -8444,9 +8444,9 @@ package body Exp_Dist is
  is
 Loc : constant Source_Ptr := Sloc (N);
 
-U_Type : Entity_Id  := Underlying_Type (Typ);
+U_Type : Entity_Id := Underlying_Type (Typ);
 
-Fnam: Entity_Id := Empty;
+Fnam: Entity_Id;
 Lib_RE  : RE_Id := RE_Null;
 Result  : Node_Id;
 
@@ -8516,7 +8516,7 @@ package body Exp_Dist is
 --  Integer types
 
 elsif U_Type = RTE (RE_Integer_8) then
-  Lib_RE := RE_FA_I8;
+   Lib_RE := RE_FA_I8;
 
 elsif U_Type = RTE (RE_Integer_16) then
Lib_RE := RE_FA_I16;
@@ -9243,7 +9243,7 @@ package body Exp_Dist is
 Typ: Entity_Id := Etype (N);
 U_Type : Entity_Id;
 C_Type : Entity_Id;
-Fnam   : Entity_Id := Empty;
+Fnam   : Entity_Id;
 Lib_RE : RE_Id := RE_Null;
 
  begin
@@ -10101,7 +10101,7 @@ package body Exp_Dist is
 --  The full view, if Typ is private; the completion,
 --  if Typ is incomplete.
 
-Fnam   : Entity_Id := Empty;
+Fnam   : Entity_Id;
 Lib_RE : RE_Id := RE_Null;
 Expr   : Node_Id;
 




[Ada] Remove leading and trailing spaces in error messages

2021-05-03 Thread Pierre-Marie de Rodat
Remove trailing space in calls to Error_Msg_N routines. Cleanup only.

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

gcc/ada/

* exp_disp.adb, sem_aggr.adb, sem_cat.adb, sem_ch10.adb,
sem_ch12.adb, sem_ch3.adb, sem_ch4.adb, sem_ch5.adb,
sem_ch6.adb, sem_ch8.adb, sem_ch9.adb, sem_prag.adb,
sem_res.adb: Remove extra leading and trailing space in error
messages.diff --git a/gcc/ada/exp_disp.adb b/gcc/ada/exp_disp.adb
--- a/gcc/ada/exp_disp.adb
+++ b/gcc/ada/exp_disp.adb
@@ -4011,7 +4011,7 @@ package body Exp_Disp is
Error_Msg_NE
  ("\which is a component of untagged type& in the profile "
   & "of primitive & of type % that is frozen by the "
-  & "declaration ", N, Typ);
+  & "declaration", N, Typ);
 end if;
  end if;
   end Check_Premature_Freezing;


diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -4743,7 +4743,7 @@ package body Sem_Aggr is
  then
 Error_Msg_NE
   ("aggregate not available for type& whose ancestor "
-   & "has unknown discriminants ", N, Typ);
+   & "has unknown discriminants", N, Typ);
  end if;
 
  if Has_Unknown_Discriminants (Typ)


diff --git a/gcc/ada/sem_cat.adb b/gcc/ada/sem_cat.adb
--- a/gcc/ada/sem_cat.adb
+++ b/gcc/ada/sem_cat.adb
@@ -275,7 +275,7 @@ package body Sem_Cat is
and then Is_Preelaborated (Depended_Entity)
  then
 Error_Msg_NE
-  ("<

[Ada] Error message on invalid prefixed procedure call

2021-05-03 Thread Pierre-Marie de Rodat
When the prefix of a call denotes an overloaded primitive operation, all
possible interpretations are analyzed to determine the intended one. If
all of them fail, then if the All_Errors flag is on all interpretations
are analyzed anew to indicate why each one is illegal. If All_Errors is
not set then only one interpretation is reanalyzed, which in rare cases
will fail to provide a meaningful error message. This patch adds the
required message and prevents the construction of an invalid tree.

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

gcc/ada/

* sem_ch4.adb (Try_Object_Operation): When a prefixed call is
overloaded and illegal, and the All_Errors flag is off, generate
an error message if the re-analysis of some candidate
interpretation fails to produce one.diff --git a/gcc/ada/sem_ch4.adb b/gcc/ada/sem_ch4.adb
--- a/gcc/ada/sem_ch4.adb
+++ b/gcc/ada/sem_ch4.adb
@@ -10215,6 +10215,16 @@ package body Sem_Ch4 is
Report => True,
Success=> Success,
Skip_First => True);
+
+--  The error may hot have been reported yet for overloaded
+--  prefixed calls, depending on the non-matching candidate,
+--  in which case provide a concise error now.
+
+if Serious_Errors_Detected = 0 then
+   Error_Msg_NE
+ ("cannot resolve prefixed call to primitive operation of&",
+   N, Entity (Prefix (N)));
+end if;
  end if;
 
  --  No need for further errors




[Ada] Fix attributes Version and Body_Version for concurrent units

2021-05-03 Thread Pierre-Marie de Rodat
Attributes Version and Body_Version can be prefixed by program units,
which include protected units and task units. Those attributes were
wrongly accepted when prefixed by protected subtype, task subtype and by
any object of a concurrent type.

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

gcc/ada/

* sem_attr.adb (Check_Program_Unit): Fix references to
Concurrent_Kind and Is_Concurrent_Type; avoid repeated calls to
Entity.diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb
--- a/gcc/ada/sem_attr.adb
+++ b/gcc/ada/sem_attr.adb
@@ -2298,16 +2298,15 @@ package body Sem_Attr is
   begin
  if Is_Entity_Name (P) then
 declare
-   K : constant Entity_Kind := Ekind (Entity (P));
-   T : constant Entity_Id   := Etype (Entity (P));
-
+   E : constant Entity_Id := Entity (P);
 begin
-   if K in Concurrent_Kind
- | Entry_Kind
- | Generic_Unit_Kind
- | Subprogram_Kind
- | E_Package
- or else (K = E_Variable and then Is_Concurrent_Type (T))
+   if Ekind (E) in E_Protected_Type
+ | E_Task_Type
+ | Entry_Kind
+ | Generic_Unit_Kind
+ | Subprogram_Kind
+ | E_Package
+ or else Is_Single_Concurrent_Object (E)
then
   return;
end if;




[Ada] Allow attributes Version and Body_Version prefixed by entries

2021-05-03 Thread Pierre-Marie de Rodat
Prefix of attributes Version and Body_Version denotes any program unit,
including protected entries, which were wrongly rejected this context.

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

gcc/ada/

* sem_attr.adb (Check_Program_Unit): Replace tests for Task_Kind
and Protected_Kind with a collective test for Concurrent_Kind;
likewise, replace calls to Is_Task_Type and Is_Protected_Type
with a collective call to Is_Concurrent_Type; simplify into a
single membership test; add missing Entry_Kind alternative.diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb
--- a/gcc/ada/sem_attr.adb
+++ b/gcc/ada/sem_attr.adb
@@ -2302,16 +2302,12 @@ package body Sem_Attr is
T : constant Entity_Id   := Etype (Entity (P));
 
 begin
-   if K in Subprogram_Kind
- or else K in Task_Kind
- or else K in Protected_Kind
- or else K = E_Package
- or else K in Generic_Unit_Kind
- or else (K = E_Variable
-and then
-  (Is_Task_Type (T)
- or else
-   Is_Protected_Type (T)))
+   if K in Concurrent_Kind
+ | Entry_Kind
+ | Generic_Unit_Kind
+ | Subprogram_Kind
+ | E_Package
+ or else (K = E_Variable and then Is_Concurrent_Type (T))
then
   return;
end if;




[Ada] Rename package instead of each routine

2021-05-03 Thread Pierre-Marie de Rodat
Package GNAT.Case_Util contained routines renamed from System.Case_Util.
Few routines were missed. Renames entire package instead of renaming
each routine separately.

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

gcc/ada/

* libgnat/g-casuti.adb: Replace with "pragma No_Body".
* libgnat/g-casuti.ads: Replace with a package renaming.diff --git a/gcc/ada/libgnat/g-casuti.adb b/gcc/ada/libgnat/g-casuti.adb
--- a/gcc/ada/libgnat/g-casuti.adb
+++ b/gcc/ada/libgnat/g-casuti.adb
@@ -29,10 +29,8 @@
 --  --
 --
 
---  This is a dummy body, required because if we remove the body we have
---  bootstrap path problems (this unit used to have a body, and if we do not
---  supply a dummy body, the old incorrect body is picked up during the
---  bootstrap process.
+--  This package does not require a body, since it is a package renaming. We
+--  provide a dummy file containing a No_Body pragma so that previous versions
+--  of the body (which did exist) will not interfere.
 
-package body GNAT.Case_Util is
-end GNAT.Case_Util;
+pragma No_Body;


diff --git a/gcc/ada/libgnat/g-casuti.ads b/gcc/ada/libgnat/g-casuti.ads
--- a/gcc/ada/libgnat/g-casuti.ads
+++ b/gcc/ada/libgnat/g-casuti.ads
@@ -40,38 +40,4 @@
 
 with System.Case_Util;
 
-package GNAT.Case_Util is
-   pragma Pure;
-   pragma Elaborate_Body;
-   --  The elaborate body is because we have a dummy body to deal with
-   --  bootstrap path problems (we used to have a real body, and now we don't
-   --  need it any more, but the bootstrap requires that we have a dummy body,
-   --  since otherwise the old body gets picked up.
-
-   --  Note: all the following functions handle the full Latin-1 set
-
-   function To_Upper (A : Character) return Character
- renames System.Case_Util.To_Upper;
-   --  Converts A to upper case if it is a lower case letter, otherwise
-   --  returns the input argument unchanged.
-
-   procedure To_Upper (A : in out String)
- renames System.Case_Util.To_Upper;
-   --  Folds all characters of string A to upper case
-
-   function To_Lower (A : Character) return Character
- renames System.Case_Util.To_Lower;
-   --  Converts A to lower case if it is an upper case letter, otherwise
-   --  returns the input argument unchanged.
-
-   procedure To_Lower (A : in out String)
- renames System.Case_Util.To_Lower;
-   --  Folds all characters of string A to lower case
-
-   procedure To_Mixed (A : in out String)
- renames System.Case_Util.To_Mixed;
-   --  Converts A to mixed case (i.e. lower case, except for initial
-   --  character and any character after an underscore, which are
-   --  converted to upper case.
-
-end GNAT.Case_Util;
+package GNAT.Case_Util renames System.Case_Util;




[Ada] Fix calls to Error_Msg_NE instead of Error_Msg_N

2021-05-03 Thread Pierre-Marie de Rodat
Replace calls to Error_Msg_NE whose Msg parameters have no insertion
characters corresponding to the E parameter with equivalent but simpler
calls to Error_Msg_N. Code cleanup; behaviour is unaffected.

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

gcc/ada/

* freeze.adb (Freeze_Profile): Replace Error_Msg_NE with
Error_Msg_N; change to continuation message.
* sem_cat.adb, sem_ch10.adb, sem_ch12.adb, sem_ch5.adb: Replace
calls to Error_Msg_NE with calls to Error_Msg_N.diff --git a/gcc/ada/freeze.adb b/gcc/ada/freeze.adb
--- a/gcc/ada/freeze.adb
+++ b/gcc/ada/freeze.adb
@@ -3749,8 +3749,8 @@ package body Freeze is
 
Error_Msg_NE ("?x?type of argument& is unconstrained array",
   Warn_Node, Formal);
-   Error_Msg_NE ("?x?foreign caller must pass bounds explicitly",
-  Warn_Node, Formal);
+   Error_Msg_N ("\?x?foreign caller must pass bounds explicitly",
+  Warn_Node);
Error_Msg_Qual_Level := 0;
 end if;
 


diff --git a/gcc/ada/sem_cat.adb b/gcc/ada/sem_cat.adb
--- a/gcc/ada/sem_cat.adb
+++ b/gcc/ada/sem_cat.adb
@@ -296,18 +296,16 @@ package body Sem_Cat is
  --  Add further explanation for Pure/Preelaborate common cases
 
  if Unit_Category = Pure then
-Error_Msg_NE
-  ("\<= Ada_95
   then
- Error_Msg_NE
+ Error_Msg_N
("subtypes of actual discriminants must match formal",
-Actual, Gen_T);
+Actual);
  Abandon_Instantiation (Actual);
   end if;
 


diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb
--- a/gcc/ada/sem_ch5.adb
+++ b/gcc/ada/sem_ch5.adb
@@ -2037,8 +2037,8 @@ package body Sem_Ch5 is
 then
null;
 else
-   Error_Msg_NE
- ("container type does not support reverse iteration", N, Typ);
+   Error_Msg_N
+ ("container type does not support reverse iteration", N);
 end if;
  end if;
   end Check_Reverse_Iteration;




[Ada] Spurious warning about premature use of selected component

2021-05-03 Thread Pierre-Marie de Rodat
Compiler emits a warning on a selected component that is an actual in a
function call, when the enclosing object has no explicit initialization
and no discriminants, but the component type itself has partial
initialization.  Such a warning should be suppressed.

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

gcc/ada/

* sem_warn.adb (Check_References): Do not emit warning on a
selected component when enclosing type has no discriminant and
type of component has partial initialization.diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb
--- a/gcc/ada/sem_warn.adb
+++ b/gcc/ada/sem_warn.adb
@@ -1523,6 +1523,17 @@ package body Sem_Warn is
 --  uninitialized component to get a better message.
 
  elsif Nkind (Parent (UR)) = N_Selected_Component then
+--  Suppress possibly superfluous warning if component
+--  is known to exist and is partially initialized.
+
+if not Has_Discriminants (Etype (E1))
+  and then
+Is_Partially_Initialized_Type
+  (Etype (Parent (UR)), False)
+then
+   goto Continue;
+end if;
+
 Error_Msg_Node_2 := Selector_Name (Parent (UR));
 
 if not Comes_From_Source (Parent (UR)) then




[Ada] Remove confusing warning on type export

2021-05-03 Thread Pierre-Marie de Rodat
"exporting" a type may seem useless but is actually useful to set its
convention and sometimes its external name.

So simply remove this warning.

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

gcc/ada/

* sem_prag.adb (Set_Exported): Do not warn on exporting a type.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -10934,10 +10934,6 @@ package body Sem_Prag is
 end if;
  end if;
 
- if Warn_On_Export_Import and then Is_Type (E) then
-Error_Msg_NE ("exporting a type has no effect?x?", Arg, E);
- end if;
-
  if Warn_On_Export_Import and Inside_A_Generic then
 Error_Msg_NE
   ("all instances of& will have the same external name?x?",




[Ada] Expansion in _postconditions confusing CodePeer

2021-05-03 Thread Pierre-Marie de Rodat
This patch fixes an issue in the compiler whereby extra flags and tests
added to the internally generated _postconditions procedure confused and
caused issues with CodePeer due to it treating the procedure as coming
from source.

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

gcc/ada/

* contracts.adb (Build_Postconditions_Procedure): Remove
internally generated if statement used to control finalization
actions.
* exp_ch6.adb (Add_Return, Expand_Non_Function_Return,
Expand_Simple_Function_Return): Add if statement around
_postconditions to control finalization.
* exp_ch7.adb (Build_Finalizer): Likewise.
* sem_prag.adb (Find_Related_Declaration_Or_Body): Add case to
handle Context itself being a handled sequence of statements.diff --git a/gcc/ada/contracts.adb b/gcc/ada/contracts.adb
--- a/gcc/ada/contracts.adb
+++ b/gcc/ada/contracts.adb
@@ -2367,6 +2367,10 @@ package body Contracts is
  --  postconditions until finalization has been performed when cleanup
  --  actions are present.
 
+ --  NOTE: This flag could be made into a predicate since we should be
+ --  able at compile time to recognize when finalization and cleanup
+ --  actions occur, but in practice this is not possible ???
+
  --  Generate:
  --
  --Postcond_Enabled : Boolean := True;
@@ -2405,16 +2409,16 @@ package body Contracts is
  --  the postconditions: this would cause confusing debug info to be
  --  produced, interfering with coverage-analysis tools.
 
- --  Also, wrap the postcondition checks in a conditional which can be
- --  used to delay their evaluation when clean-up actions are present.
+ --  NOTE: Coverage-analysis and static-analysis tools rely on the
+ --  postconditions procedure being free of internally generated code
+ --  since some of these tools, like CodePeer, treat _postconditions
+ --  as original source.
 
  --  Generate:
  --
  --procedure _postconditions is
  --begin
- --   if Postcond_Enabled and then Return_Success_For_Postcond then
- --  [Stmts];
- --   end if;
+ --   [Stmts];
  --end;
 
  Proc_Bod :=
@@ -2425,19 +2429,7 @@ package body Contracts is
  Handled_Statement_Sequence =>
Make_Handled_Sequence_Of_Statements (Loc,
  End_Label  => Make_Identifier (Loc, Chars (Proc_Id)),
- Statements => New_List (
-   Make_If_Statement (Loc,
- Condition  =>
-   Make_And_Then (Loc,
- Left_Opnd  =>
-   New_Occurrence_Of
- (Defining_Identifier
-   (Postcond_Enabled_Decl), Loc),
- Right_Opnd =>
-   New_Occurrence_Of
- (Defining_Identifier
-   (Return_Success_Decl), Loc)),
-  Then_Statements => Stmts;
+ Statements => Stmts));
  Insert_After_And_Analyze (Last_Decl, Proc_Bod);
 
   end Build_Postconditions_Procedure;


diff --git a/gcc/ada/exp_ch6.adb b/gcc/ada/exp_ch6.adb
--- a/gcc/ada/exp_ch6.adb
+++ b/gcc/ada/exp_ch6.adb
@@ -6246,7 +6246,8 @@ package body Exp_Ch6 is
 --  has contract assertions that need to be verified on exit.
 
 --  Also, mark the successful return to signal that postconditions
---  need to be evaluated when finalization occurs.
+--  need to be evaluated when finalization occurs by setting
+--  Return_Success_For_Postcond to be True.
 
 if Ekind (Spec_Id) = E_Procedure
   and then Present (Postconditions_Proc (Spec_Id))
@@ -6254,19 +6255,30 @@ package body Exp_Ch6 is
--  Generate:
--
--Return_Success_For_Postcond := True;
-   --_postconditions;
+   --if Postcond_Enabled then
+   --   _postconditions;
+   --end if;
 
Insert_Action (Stmt,
  Make_Assignment_Statement (Loc,
Name   =>
  New_Occurrence_Of
-  (Get_Return_Success_For_Postcond (Spec_Id), Loc),
+   (Get_Return_Success_For_Postcond (Spec_Id), Loc),
Expression => New_Occurrence_Of (Standard_True, Loc)));
 
+   --  Wrap the call to _postconditions within a test of the
+   --  Postcond_Enabled flag to delay postcondition evaluation
+   --  until after finalization when required.
+
Insert_Action (Stmt,
- Make_Procedure_Call_Statement (Loc,
-   Name =>
-

[Ada] No_Implicit_Loops restriction and pragma Assert

2021-05-03 Thread Pierre-Marie de Rodat
When using e.g. pragma Assert (X'Initialized) combined with pragma
Restrictions (No_Implicit_Loops), a violation is flagged when assertions
are disabled, which is undesirable. Fixed by recognizing simple forms of
dead paths used by pragma Assert when assertions are disabled.

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

gcc/ada/

* tbuild.adb (Make_Implicit_Loop_Statement): Disable restriction
checking on dead paths.diff --git a/gcc/ada/tbuild.adb b/gcc/ada/tbuild.adb
--- a/gcc/ada/tbuild.adb
+++ b/gcc/ada/tbuild.adb
@@ -35,6 +35,7 @@ with Opt;  use Opt;
 with Restrict; use Restrict;
 with Rident;   use Rident;
 with Sem_Aux;  use Sem_Aux;
+with Sem_Util; use Sem_Util;
 with Snames;   use Snames;
 with Stand;use Stand;
 with Stringt;  use Stringt;
@@ -348,14 +349,42 @@ package body Tbuild is
   Has_Created_Identifier : Boolean := False;
   End_Label  : Node_Id := Empty) return Node_Id
is
-   begin
-  Check_Restriction (No_Implicit_Loops, Node);
+  P  : Node_Id;
+  Check_Restrictions : Boolean := True;
+   begin
+  --  Do not check restrictions if the implicit loop statement is part
+  --  of a dead branch: False and then ...
+  --  This will occur in particular as part of the expansion of pragma
+  --  Assert when assertions are disabled.
+
+  P := Parent (Node);
+  while Present (P) loop
+ if Nkind (P) = N_And_Then then
+if Nkind (Left_Opnd (P)) = N_Identifier
+  and then Entity (Left_Opnd (P)) = Standard_False
+then
+   Check_Restrictions := False;
+   exit;
+end if;
 
-  if Present (Iteration_Scheme)
-and then Nkind (Iteration_Scheme) /= N_Iterator_Specification
-and then Present (Condition (Iteration_Scheme))
-  then
- Check_Restriction (No_Implicit_Conditionals, Node);
+ --  Prevent the search from going too far
+
+ elsif Is_Body_Or_Package_Declaration (P) then
+exit;
+ end if;
+
+ P := Parent (P);
+  end loop;
+
+  if Check_Restrictions then
+ Check_Restriction (No_Implicit_Loops, Node);
+
+ if Present (Iteration_Scheme)
+   and then Nkind (Iteration_Scheme) /= N_Iterator_Specification
+   and then Present (Condition (Iteration_Scheme))
+ then
+Check_Restriction (No_Implicit_Conditionals, Node);
+ end if;
   end if;
 
   return Make_Loop_Statement (Sloc (Node),




[Ada] Crash on aggregate in function call in object declaration

2021-05-03 Thread Pierre-Marie de Rodat
Compiler aborts on an aggregate with limited components, when the
aggregate is a formal in a function call that is the right-hand side of
an assignment, possibly coming from an object declaration.

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

gcc/ada/

* exp_aggr.adb (Expand_Array_Aggregate): If the parent node of
the aggregate is a subprogram call there is no target in which
to build the aggregate, and it has to be expanded into component
assignments.diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -5700,7 +5700,7 @@ package body Exp_Aggr is
   function Safe_Left_Hand_Side (N : Node_Id) return Boolean;
   --  In addition to Maybe_In_Place_OK, in order for an aggregate to be
   --  built directly into the target of the assignment it must be free
-  --  of side effects.
+  --  of side effects. N is the LHS of an assignment.
 
   
   -- Build_Constrained_Type --
@@ -6661,9 +6661,13 @@ package body Exp_Aggr is
  Set_Expansion_Delayed (N);
  return;
 
-  --  In the remaining cases the aggregate is the RHS of an assignment
+  --  In the remaining cases the aggregate appears in the RHS of an
+  --  assignment, which may be part of the expansion of an object
+  --  delaration. If the aggregate is an actual in a call, itself
+  --  possibly in a RHS, building it in the target is not possible.
 
   elsif Maybe_In_Place_OK
+and then Nkind (Parent_Node) not in N_Subprogram_Call
 and then Safe_Left_Hand_Side (Name (Parent_Node))
   then
  Tmp := Name (Parent_Node);




[Ada] Spurious warning on postcondition and result

2021-05-03 Thread Pierre-Marie de Rodat
When a function has "in out" parameters and a postcondition which does
not reference 'Result, a potentially spurious warning is emitted. The
necessary logic was actually already there in
Sem_Util.Check_Result_And_Post_State but was using a local
Has_In_Out_Parameter function instead of using simply
Einfo.Has_Out_Or_In_Out_Parameter.

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

gcc/ada/

* sem_util.adb (Check_Result_And_Post_State): Replace custom
Has_In_Out_Parameter with existing Has_Out_Or_In_Out_Parameter
flag which corresponds exactly to what we need.diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -4701,10 +4701,6 @@ package body Sem_Util is
   --  and post-state. Prag is a [refined] postcondition or a contract-cases
   --  pragma. Result_Seen is set when the pragma mentions attribute 'Result
 
-  function Has_In_Out_Parameter (Subp_Id : Entity_Id) return Boolean;
-  --  Determine whether subprogram Subp_Id contains at least one IN OUT
-  --  formal parameter.
-
   ---
   -- Check_Result_And_Post_State_In_Pragma --
   ---
@@ -5093,28 +5089,6 @@ package body Sem_Util is
  end if;
   end Check_Result_And_Post_State_In_Pragma;
 
-  --
-  -- Has_In_Out_Parameter --
-  --
-
-  function Has_In_Out_Parameter (Subp_Id : Entity_Id) return Boolean is
- Formal : Entity_Id;
-
-  begin
- --  Traverse the formals looking for an IN OUT parameter
-
- Formal := First_Formal (Subp_Id);
- while Present (Formal) loop
-if Ekind (Formal) = E_In_Out_Parameter then
-   return True;
-end if;
-
-Next_Formal (Formal);
- end loop;
-
- return False;
-  end Has_In_Out_Parameter;
-
   --  Local variables
 
   Items: constant Node_Id := Contract (Subp_Id);
@@ -5194,10 +5168,10 @@ package body Sem_Util is
  null;
 
   --  Regardless of whether the function has postconditions or contract
-  --  cases, or whether they mention attribute 'Result, an IN OUT formal
+  --  cases, or whether they mention attribute 'Result, an [IN] OUT formal
   --  parameter is always treated as a result.
 
-  elsif Has_In_Out_Parameter (Spec_Id) then
+  elsif Has_Out_Or_In_Out_Parameter (Spec_Id) then
  null;
 
   --  The function has both a postcondition and contract cases and they do




[Ada] Spurious accessibility error on call in return statement

2021-05-03 Thread Pierre-Marie de Rodat
This patch fixes an issue in the compiler whereby a spurious
accessibility error regarding actuals for explicitly aliased formals in
a function call within a return statement gets triggered during
compilation when the return type of the function call in question has
implicit dereference specified.

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

gcc/ada/

* sem_util.adb (In_Return_Value): Modified to detect when
implicit dereference is specified on the return type of a
function call within the expression being checked.diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -14329,6 +14329,17 @@ package body Sem_Util is
 when N_Function_Call =>
if not In_Function_Call then
   In_Function_Call := True;
+
+  --  When the function return type has implicit dereference
+  --  specified we know it cannot directly contribute to the
+  --  return value.
+
+  if Present (Etype (Par))
+and then Has_Implicit_Dereference
+   (Get_Full_View (Etype (Par)))
+  then
+ return False;
+  end if;
else
   return False;
end if;




Re: [Ping, Patch, Fortran, Update 2] PR98301 Re: RANDOM_INIT() and coarray Fortran

2021-05-03 Thread Andre Vehreschild via Gcc-patches
Ping!

Ok for trunk?

I have looked at other patches, but none was patching any location I have
worked on previously. Therefore I can't return the favor of reviewing any
currently open patches and have to ask for volunteers here.

- Andre

On Mon, 26 Apr 2021 12:36:36 +0200
Andre Vehreschild via Fortran  wrote:

> Hi Steve, hi all,
>
> I agree.  The cas-things have been removed (I will put the patch for them into
> the pr98301 ticket, so safe them), streamlining the patch a bit more.
>
> Bootstraped and regtested ok on x86_64-linux/f33. Ok for trunk?
>
> Regards,
>   Andre
>
> Steve Kargl  
>
> PR fortran/98301 - random_init() is broken
>
> Correct implementation of random_init() when -fcoarray=lib is given.
>
> gcc/fortran/ChangeLog:
>
>   PR fortran/98301
>   * trans-decl.c (gfc_build_builtin_function_decls): Move decl.
>   * trans-intrinsic.c (conv_intrinsic_random_init): Use bool for
>   lib-call of caf_random_init instead of logical (4-byte).
>   * trans.h: Add tree var for random_init.
>
> libgfortran/ChangeLog:
>
>   PR fortran/98302
>   * caf/libcaf.h (_gfortran_caf_random_init): New function.
>   * caf/single.c (_gfortran_caf_random_init): New function.
>   * gfortran.map: Added fndecl.
>   * intrinsics/random_init.f90: Implement random_init.
>
>
>
> On Sun, 25 Apr 2021 13:03:34 -0700
> Steve Kargl  wrote:
>
> > Andre,
> >
> > The patch looks fine to me.  I wonder, however, if we should
> > comment out all of the shared memory stuff, i.e., the _cas_
> > stuff.  I don't know when Thomas/Nicolas will merge their
> > work-in-progress.
> >
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de


--
Andre Vehreschild * Email: vehre ad gmx dot de


Re: [PATCH] [PR91400] build only one __cpu_model variable

2021-05-03 Thread Ivan Sorokin via Gcc-patches

As GCC 11 is released and the development of GCC 12 begins I would like
to send this patch again.

It is basically unchanged since the previous submission in February. The 
only change I made is fixing formatting by adding a space after gcc_assert.


Please note, that the original author of the code no longer actively 
contribute to GCC, so he is unlikely to review this patch. It would be 
great if someone else takes a look at it.


On 03.05.2021 11:39, Ivan Sorokin wrote:

Prior to this commit GCC -O2 generated quite bad code for this
function:

bool f()
{
 return __builtin_cpu_supports("popcnt")
 && __builtin_cpu_supports("ssse3");
}

f:
 movl__cpu_model+12(%rip), %eax
 xorl%r8d, %r8d
 testb   $4, %al
 je  .L1
 shrl$6, %eax
 movl%eax, %r8d
 andl$1, %r8d
.L1:
 movl%r8d, %eax
 ret

The problem was caused by the fact that internally every invocation
of __builtin_cpu_supports built a new variable __cpu_model and a new
type __processor_model. Because of this GIMPLE level optimizers
weren't able to CSE the loads of __cpu_model and optimize
bit-operations properly.

This commit fixes the problem by caching created __cpu_model
variable and __processor_model type. Now the GCC -O2 generates:

f:
 movl__cpu_model+12(%rip), %eax
 andl$68, %eax
 cmpl$68, %eax
 sete%al
 ret

gcc/ChangeLog:

PR target/91400
* config/i386/i386-builtins.c (fold_builtin_cpu): Extract
building of __cpu_model and __processor_model into new
function.
* config/i386/i386-builtins.c (init_cpu_model_var): New.
Cache creation of __cpu_model and __processor_model.

gcc/testsuite/Changelog:

PR target/91400
* gcc.target/i386/pr91400.c: New.
---
  gcc/config/i386/i386-builtins.c | 27 ++---
  gcc/testsuite/gcc.target/i386/pr91400.c | 11 ++
  2 files changed, 31 insertions(+), 7 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/i386/pr91400.c

diff --git a/gcc/config/i386/i386-builtins.c b/gcc/config/i386/i386-builtins.c
index b66911082ab..b7d9dd18b03 100644
--- a/gcc/config/i386/i386-builtins.c
+++ b/gcc/config/i386/i386-builtins.c
@@ -2103,6 +2103,25 @@ make_var_decl (tree type, const char *name)
return new_decl;
  }
  
+static GTY(()) tree __cpu_model_var;

+static GTY(()) tree __processor_model_type;
+
+static void
+init_cpu_model_var()
+{
+  if (__cpu_model_var != NULL_TREE)
+{
+  gcc_assert (__processor_model_type != NULL_TREE);
+  return;
+}
+
+  __processor_model_type = build_processor_model_struct ();
+  __cpu_model_var = make_var_decl (__processor_model_type,
+  "__cpu_model");
+
+  varpool_node::add (__cpu_model_var);
+}
+
  /* FNDECL is a __builtin_cpu_is or a __builtin_cpu_supports call that is 
folded
 into an integer defined in libgcc/config/i386/cpuinfo.c */
  
@@ -2114,13 +2133,7 @@ fold_builtin_cpu (tree fndecl, tree *args)

  = (enum ix86_builtins) DECL_MD_FUNCTION_CODE (fndecl);
tree param_string_cst = NULL;
  
-  tree __processor_model_type = build_processor_model_struct ();

-  tree __cpu_model_var = make_var_decl (__processor_model_type,
-   "__cpu_model");
-
-
-  varpool_node::add (__cpu_model_var);
-
+  init_cpu_model_var ();
gcc_assert ((args != NULL) && (*args != NULL));
  
param_string_cst = *args;

diff --git a/gcc/testsuite/gcc.target/i386/pr91400.c 
b/gcc/testsuite/gcc.target/i386/pr91400.c
new file mode 100644
index 000..e8b7d9285f9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr91400.c
@@ -0,0 +1,11 @@
+/* PR target/91400 */
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-times "andl" 1 } } */
+/* { dg-final { scan-assembler-times "68" 2 } } */
+/* { dg-final { scan-assembler-not "je" } } */
+
+_Bool f()
+{
+return __builtin_cpu_supports("popcnt") && __builtin_cpu_supports("ssse3");
+}





Re: [PATCH V7 4/7] CTF/BTF debug formats

2021-05-03 Thread Richard Biener
On Fri, 30 Apr 2021, David Faust wrote:

> 
> On 4/30/21 9:11 AM, Jose E. Marchesi via Gcc-patches wrote:
> > 
> >>> For a moment, for the sake of this question, if we establish that CTF/BTF
> >>> generation always feeds off DWARF DIEs (so there is no need to access
> >>> type/decl tree nodes), what will it take to keep LTO support while keeping
> >>> ctf_debug_finalize in dwarf2out_finish ?
> >>
> >> I don't think it's possible without major surgery.  Now, it looks like
> >> you want to emit .ctf at the LTO compile stage and BTF at the LTRANS
> >> stage.  Note you do not have access to the CTF data produced at the
> >> LTRANS stage.  What DWARF has access to is pointers (symbol name + offset)
> >> to the early DWARF generated DIEs for GCCs tree decls from what it
> >> adds DW_AT_abstract_origin references and then amending those entities
> >> with furthr DWARF attributes.
> >>
> >> Now, the "major surgery" could for example entail streaming the CTF
> >> data you produce from compile through WPA to the LTRANS stage.  Or
> >> alternatively simply reading it from the compile time produced objects
> >> by means of the DWARF DIE references.  I don't know what kind of (if any)
> >> references you need to produce from BTF to the CTF data (I suppose they
> >> might share indexes into a same symbol table...).
> > 
> > I am thinking, given that we have both "early DWARF" and "late DWARF",
> > we may want to have three init/fini hooks for debug formats instead of
> > two:
> > 
> > DEBUG_FORMAT_initialize   (called in dwarf2out_early_finish)
> > 
> > [... traverse early DWARF (DEBUG_FORMAT_do_die) ...]
> > 
> > DEBUG_FORMAT_early_finish (called in dwarf2out_early_finish)
> > DEBUG_FORMAT_finish   (called in dwarf2out_finish)
> > 
> > Note that CTF and BTF share the ctfc internal data structure (which is
> > built from traversing the early DWARF) but these are otherwise distinct
> > debug formats: CTF can be completely emitted in ctf_early_finish,
> > whereas BTF needs additional information that is only available in
> > ctf_finish.)
> > 
> 
> I like this idea.
> 
> As Indu mentioned, the change to writing CTF/BTF in dwarf2out_finish
> rather than dwar2out_early_finish is motivated purely by the needs of BPF.
> 
> Specifically, it is to support BPF Compile Once - Run Everywhere (BPF
> CO-RE). The BPF backend needs BTF information to generate CO-RE
> 'relocation' records, and it needs to add to the BTF string table. The
> relocation records themselves are placed in a .BTF.ext section, but
> refer to BTF records by ID.
> 
> Note that CO-RE only comes into play when generating BTF information for
> a BPF target. Otherwise, the BTF information can also be emitted in
> early_finish. That is, BTF is effectively "late DWARF" ONLY for the BPF
> target. Of course, this is also the usual use case for BTF.
> 
> I do not have much experience with LTO. I am still trying to digest the
> LTO section of the manual. But from what what I do understand, and what
> is discussed here, I think the following may work:
> 
> 1. Always emit CTF in early_finish. There is no reason to delay it. This
> simplifies both LTO and non-LTO cases.
> 
> 2. For non-BPF targets, emit BTF in early_finish as well.
> 
> 3. For non-LTO + BTF + BPF, emit BTF in in (late) finish, to support
> generating CO-RE information in the BPF backend.
> 
> 4. For LTO + BTF + BPF, either emit BTF in early_finish then read it
> back later, or stream it through WPA to LTRANS stage. I am not sure
> exactly what this streaming means. In either case, end up with enough
> information at LTRANS stage to re-emit the BTF, now with CO-RE information.
> 
> Does the above make any sense? Is this overly complicated?

So DWARF would likely emit BTF early and amend it late with the CO-RE
information.  Whatever exactly CO-RE is - I'm assuming it's backend
stuff like DWARF location expressions.

Note when emitting CTF/BTF early there's still the issue of
fat objects, but as said, eventually the "early" CTF/BTF can be
literally shared.  Of course the "fat" part would have the CO-RE
stuff emitted at compile-time and the "lto" part at link time.

I suppose we might want to introduce a target hook that says
whether a target supports fat LTO objects or not, side-stepping
this issue.

Richard.

> Thank you very much Richard for the review, and for raising this LTO
> discussion.
> 
> David
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)


[PATCH] tree-ssa-dse: Fix up go.test/test/fixedbugs/issue16095.go miscompilation [PR100382]

2021-05-03 Thread Jakub Jelinek via Gcc-patches
Hi!

The new DCE code inside of tree DSE removes in -fnon-call-exceptions
go code a load from NULL pointer the testcase relies on throwing an
exception and so the test hangs.

The following patch just repeats a check that e.g. tree-ssa-dce.c
uses to prevent this.

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

2021-05-03  Jakub Jelinek  

PR tree-optimization/100382
* tree-ssa-dse.c: Include tree-eh.h.
(dse_dom_walker::before_dom_children): Don't remove stmts if
stmt_unremovable_because_of_non_call_eh_p is true.

--- gcc/tree-ssa-dse.c.jj   2021-05-02 16:25:43.636266833 +0200
+++ gcc/tree-ssa-dse.c  2021-05-02 19:42:53.451320031 +0200
@@ -39,6 +39,7 @@ along with GCC; see the file COPYING3.
 #include "builtins.h"
 #include "gimple-fold.h"
 #include "gimplify.h"
+#include "tree-eh.h"
 
 /* This file implements dead store elimination.
 
@@ -1193,7 +1194,8 @@ dse_dom_walker::before_dom_children (bas
  /* When we remove dead stores make sure to also delete trivially
 dead SSA defs.  */
  if (has_zero_uses (DEF_FROM_PTR (def_p))
- && !gimple_has_side_effects (stmt))
+ && !gimple_has_side_effects (stmt)
+ && !stmt_unremovable_because_of_non_call_eh_p (cfun, stmt))
{
  if (dump_file && (dump_flags & TDF_DETAILS))
{

Jakub



Re: [PR94092] Re: [RFC] test builtin ratio for loop distribution

2021-05-03 Thread Richard Biener via Gcc-patches
On Fri, Apr 30, 2021 at 4:42 PM Jeff Law  wrote:
>
>
> On 4/28/2021 10:26 PM, Alexandre Oliva wrote:
> > On Feb 22, 2021, Richard Biener  wrote:
> >
> >> On Fri, Feb 19, 2021 at 9:08 AM Alexandre Oliva  wrote:
> >>> Here's an improved version of the patch.  Regstrapped on
> >>> x86_64-linux-gnu, with and without a patchlet that moved multi-pieces
> >>> ahead of setmem, and also tested with riscv32-elf.
> >>>
> >>> Is it ok to install?  Or should it wait for stage1?
> >> It generally looks OK but I'd wait for stage1.
> > 'k, I've retested the patch now, and it's still working as expected.
>
> Then I'd go forward with it at this point.

Yes, it looks good to me as well.

Thanks,
Richard.

>
>
> >
> > I've dropped references to PR94092, since it's a different issue.
>
> ACK.  Note I just put a patch into pr94092 that may be of interest.  In
> simplest terms it tries to use REGNO_POINTER_ALIGN to increase the
> alignment of MEMs.  We'd been using it internally for a bit before we
> went a slightly different direction.  Feel free to use it if it's helpful.
>
>
> jeff
>


[PATCH] [PR91400] build only one __cpu_model variable

2021-05-03 Thread Ivan Sorokin via Gcc-patches
Prior to this commit GCC -O2 generated quite bad code for this
function:

bool f()
{
return __builtin_cpu_supports("popcnt")
&& __builtin_cpu_supports("ssse3");
}

f:
movl__cpu_model+12(%rip), %eax
xorl%r8d, %r8d
testb   $4, %al
je  .L1
shrl$6, %eax
movl%eax, %r8d
andl$1, %r8d
.L1:
movl%r8d, %eax
ret

The problem was caused by the fact that internally every invocation
of __builtin_cpu_supports built a new variable __cpu_model and a new
type __processor_model. Because of this GIMPLE level optimizers
weren't able to CSE the loads of __cpu_model and optimize
bit-operations properly.

This commit fixes the problem by caching created __cpu_model
variable and __processor_model type. Now the GCC -O2 generates:

f:
movl__cpu_model+12(%rip), %eax
andl$68, %eax
cmpl$68, %eax
sete%al
ret

gcc/ChangeLog:

PR target/91400
* config/i386/i386-builtins.c (fold_builtin_cpu): Extract
building of __cpu_model and __processor_model into new
function.
* config/i386/i386-builtins.c (init_cpu_model_var): New.
Cache creation of __cpu_model and __processor_model.

gcc/testsuite/Changelog:

PR target/91400
* gcc.target/i386/pr91400.c: New.
---
 gcc/config/i386/i386-builtins.c | 27 ++---
 gcc/testsuite/gcc.target/i386/pr91400.c | 11 ++
 2 files changed, 31 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr91400.c

diff --git a/gcc/config/i386/i386-builtins.c b/gcc/config/i386/i386-builtins.c
index b66911082ab..b7d9dd18b03 100644
--- a/gcc/config/i386/i386-builtins.c
+++ b/gcc/config/i386/i386-builtins.c
@@ -2103,6 +2103,25 @@ make_var_decl (tree type, const char *name)
   return new_decl;
 }
 
+static GTY(()) tree __cpu_model_var;
+static GTY(()) tree __processor_model_type;
+
+static void
+init_cpu_model_var()
+{
+  if (__cpu_model_var != NULL_TREE)
+{
+  gcc_assert (__processor_model_type != NULL_TREE);
+  return;
+}
+
+  __processor_model_type = build_processor_model_struct ();
+  __cpu_model_var = make_var_decl (__processor_model_type,
+  "__cpu_model");
+
+  varpool_node::add (__cpu_model_var);
+}
+
 /* FNDECL is a __builtin_cpu_is or a __builtin_cpu_supports call that is folded
into an integer defined in libgcc/config/i386/cpuinfo.c */
 
@@ -2114,13 +2133,7 @@ fold_builtin_cpu (tree fndecl, tree *args)
 = (enum ix86_builtins) DECL_MD_FUNCTION_CODE (fndecl);
   tree param_string_cst = NULL;
 
-  tree __processor_model_type = build_processor_model_struct ();
-  tree __cpu_model_var = make_var_decl (__processor_model_type,
-   "__cpu_model");
-
-
-  varpool_node::add (__cpu_model_var);
-
+  init_cpu_model_var ();
   gcc_assert ((args != NULL) && (*args != NULL));
 
   param_string_cst = *args;
diff --git a/gcc/testsuite/gcc.target/i386/pr91400.c 
b/gcc/testsuite/gcc.target/i386/pr91400.c
new file mode 100644
index 000..e8b7d9285f9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr91400.c
@@ -0,0 +1,11 @@
+/* PR target/91400 */
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-times "andl" 1 } } */
+/* { dg-final { scan-assembler-times "68" 2 } } */
+/* { dg-final { scan-assembler-not "je" } } */
+
+_Bool f()
+{
+return __builtin_cpu_supports("popcnt") && __builtin_cpu_supports("ssse3");
+}
-- 
2.25.1



Re: [patch] Fix libiberty link failure in LTO mode

2021-05-03 Thread Richard Biener via Gcc-patches
On Mon, May 3, 2021 at 9:58 AM Eric Botcazou  wrote:
>
> Hi,
>
> the patch for libiberty itself I posted is not sufficient to link the library
> for MinGW platforms in LTO mode, as there is another link failures for stpcpy.
> The symbol is both referenced by libiberty's pex-win32.c and provided by
> libiberty's stpcpy.c so it needs to have a linkage to be resolved in LTO mode.
>
> Tested on x86-64/Linux, x86-64/Windows and x86/Windows, OK for the mainline?

OK.

Richard.

>
> 2021-05-03  Eric Botcazou  
>
> * builtins.c (builtin_with_linkage_p): Return true for stp[n]cpy.
> * symtab.c (symtab_node::output_to_lto_symbol_table_p): Tidy up.
>
> --
> Eric Botcazou


Re: [libiberty] Make test for variables more robust

2021-05-03 Thread Richard Biener via Gcc-patches
On Mon, May 3, 2021 at 9:51 AM Eric Botcazou  wrote:
>
> Hi,
>
> the test for the presence of variables (really symbols) does not work when you
> add -Ox -flto to CFLAGS:
>
>   for v in $vars; do
> AC_MSG_CHECKING([for $v])
> AC_CACHE_VAL(libiberty_cv_var_$v,
>   [AC_LINK_IFELSE([AC_LANG_PROGRAM([[int *p;]],[[extern int $v []; p =
> $v;]])],
>   [eval "libiberty_cv_var_$v=yes"],
>   [eval "libiberty_cv_var_$v=no"])])
> if eval "test \"`echo '$libiberty_cv_var_'$v`\" = yes"; then
>   AC_MSG_RESULT(yes)
>   n=HAVE_`echo $v | tr 'abcdefghijklmnopqrstuvwxyz'
> 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
>   AC_DEFINE_UNQUOTED($n)
> else
>   AC_MSG_RESULT(no)
> fi
>   done
>
> because the assignment to 'p' is optimized away by LTO.  This is visible on
> MinGW platforms in the form of a link failure for sys_siglist.
>
> Tested on x86-64/Linux, x86-64/Windows and x86/Windows, OK for the mainline?

OK.

>
> 2021-05-03  Eric Botcazou  
>
> * configure.ac: Make test for variables more robust.
> * configure: Regenerate.
>
> --
> Eric Botcazou


Re: PING^1 [PATCH 1/2] GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs

2021-05-03 Thread Richard Biener via Gcc-patches
On Sun, May 2, 2021 at 3:27 PM H.J. Lu  wrote:
>
> On Tue, Mar 23, 2021 at 3:39 PM H.J. Lu  wrote:
> >
> > Check if host supports multi-byte NOPs before enabling CET on host.
> >
> > config/
> >
> > PR binutils/27397
> > * cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-byte
> > NOPs.
> >
> > libiberty/
> >
> > PR binutils/27397
> > * configure: Regenerated.
> > ---
> >  config/cet.m4   | 19 ---
> >  libiberty/configure | 29 +
> >  2 files changed, 45 insertions(+), 3 deletions(-)
> >
> > diff --git a/config/cet.m4 b/config/cet.m4
> > index c67fb4f35b6..7718be1afe8 100644
> > --- a/config/cet.m4
> > +++ b/config/cet.m4
> > @@ -130,6 +130,18 @@ fi
> >  if test x$may_have_cet = xyes; then
> >if test x$cross_compiling = xno; then
> >  AC_TRY_RUN([
> > +int
> > +main ()
> > +{
> > +  asm ("endbr32");
> > +  return 0;
> > +}
> > +],
> > +[have_multi_byte_nop=yes],
> > +[have_multi_byte_nop=no])
> > +have_cet=no
> > +if test x$have_multi_byte_nop = xyes; then
> > +  AC_TRY_RUN([
> >  static void
> >  foo (void)
> >  {
> > @@ -155,9 +167,10 @@ main ()
> >bar ();
> >return 0;
> >  }
> > -],
> > -[have_cet=no],
> > -[have_cet=yes])
> > +  ],
> > +  [have_cet=no],
> > +  [have_cet=yes])
> > +fi
> >  if test x$enable_cet = xno -a x$have_cet = xyes; then
> >AC_MSG_ERROR([Intel CET must be enabled on Intel CET enabled host])
> >  fi
> > diff --git a/libiberty/configure b/libiberty/configure
> > index 2ea7c119809..fc0c953dd1a 100755
> > --- a/libiberty/configure
> > +++ b/libiberty/configure
> > @@ -5396,6 +5396,34 @@ else
> >cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> >  /* end confdefs.h.  */
> >
> > +int
> > +main ()
> > +{
> > +  asm ("endbr32");
> > +  return 0;
> > +}
> > +
> > +_ACEOF
> > +if ac_fn_c_try_run "$LINENO"; then :
> > +  have_multi_byte_nop=yes
> > +else
> > +  have_multi_byte_nop=no
> > +fi
> > +rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
> > +  conftest.$ac_objext conftest.beam conftest.$ac_ext
> > +fi
> > +
> > +have_cet=no
> > +if test x$have_multi_byte_nop = xyes; then
> > +  if test "$cross_compiling" = yes; then :
> > +  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
> > +$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
> > +as_fn_error $? "cannot run test program while cross compiling
> > +See \`config.log' for more details" "$LINENO" 5; }
> > +else
> > +  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> > +/* end confdefs.h.  */
> > +
> >  static void
> >  foo (void)
> >  {
> > @@ -5432,6 +5460,7 @@ rm -f core *.core core.conftest.* gmon.out bb.out 
> > conftest$ac_exeext \
> >conftest.$ac_objext conftest.beam conftest.$ac_ext
> >  fi
> >
> > +fi
> >  if test x$enable_cet = xno -a x$have_cet = xyes; then
> >as_fn_error $? "Intel CET must be enabled on Intel CET enabled host" 
> > "$LINENO" 5
> >  fi
> > --
> > 2.30.2
> >
>
> This patch has been checked into binutils, which also fixes:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703
>
> Any objections to sync cet.m4 with binutils next week?

I think syncing is fine at any point.

> --
> H.J.


Re: [PATCH 02/12] Allow generating pseudo register with specific alignment

2021-05-03 Thread Richard Biener via Gcc-patches
On Fri, Apr 30, 2021 at 8:30 PM Richard Sandiford via Gcc-patches
 wrote:
>
> "H.J. Lu via Gcc-patches"  writes:
> > On Fri, Apr 30, 2021 at 5:49 AM H.J. Lu  wrote:
> >>
> >> On Fri, Apr 30, 2021 at 5:42 AM Richard Sandiford
> >>  wrote:
> >> >
> >> > "H.J. Lu via Gcc-patches"  writes:
> >> > > On Fri, Apr 30, 2021 at 2:06 AM Richard Sandiford
> >> > >  wrote:
> >> > >>
> >> > >> "H.J. Lu via Gcc-patches"  writes:
> >> > >> > gen_reg_rtx tracks stack alignment needed for pseudo registers so 
> >> > >> > that
> >> > >> > associated hard registers can be properly spilled onto stack.  But 
> >> > >> > there
> >> > >> > are cases where associated hard registers will never be spilled onto
> >> > >> > stack.  gen_reg_rtx is changed to take an argument for register 
> >> > >> > alignment
> >> > >> > so that stack realignment can be avoided when not needed.
> >> > >>
> >> > >> How is it guaranteed that they will never be spilled though?
> >> > >> I don't think that that guarantee exists for any kind of pseudo,
> >> > >> except perhaps for the temporary pseudos that the RA creates to
> >> > >> replace (match_scratch …)es.
> >> > >>
> >> > >
> >> > > The caller of creating pseudo registers with specific alignment must
> >> > > guarantee that they will never be spilled.   I am only using it in
> >> > >
> >> > >   /* Make operand1 a register if it isn't already.  */
> >> > >   if (can_create_pseudo_p ()
> >> > >   && !register_operand (op0, mode)
> >> > >   && !register_operand (op1, mode))
> >> > > {
> >> > >   /* NB: Don't increase stack alignment requirement when forcing
> >> > >  operand1 into a pseudo register to copy data from one memory
> >> > >  location to another since it doesn't require a spill.  */
> >> > >   emit_move_insn (op0,
> >> > >   force_reg (GET_MODE (op0), op1,
> >> > >  (UNITS_PER_WORD * BITS_PER_UNIT)));
> >> > >   return;
> >> > > }
> >> > >
> >> > > for vector moves.  RA shouldn't spill it.
> >> >
> >> > But this is the point: it's a case of hoping that the RA won't spill it,
> >> > rather than having a guarantee that it won't.
> >> >
> >> > Even if the moves start out adjacent, they could be separated by later
> >> > RTL optimisations, particularly scheduling.  (I realise pre-RA scheduling
> >> > isn't enabled by default for x86, but it can still be enabled 
> >> > explicitly.)
> >> > Or if the same data is being copied to two locations, we might reuse
> >> > values loaded by the first copy for the second copy as well.
> >
> > There are cases where pseudo vector registers are created as pure
> > temporary registers in the backend and they shouldn't ever be spilled
> > to stack.   They will be spilled to stack only if there are other 
> > non-temporary
> > vector register usage in which case stack will be properly re-aligned.
> > Caller of creating pseudo registers with specific alignment guarantees
> > that they are used only as pure temporary registers.
>
> I don't think there's really a distinct category of pure temporary
> registers though.  The things I mentioned above can happen for any
> kind of pseudo register.

I wonder if for the cases HJ thinks of it is appropriate to use hardregs?
Do we generally handle those well?  That is, are they again subject
to be allocated by RA when no longer live?

Richard.

> Thanks,
> Richard


[patch] Reuse non-gimple_reg variable for inlining

2021-05-03 Thread Eric Botcazou
Hi,

when a call to a function is inlined and takes a parameter whose type is not
gimple_reg, a variable is created in the caller to hold a copy of the argument
passed in the call with the following comment:

  /* We may produce non-gimple trees by adding NOPs or introduce
 invalid sharing when operand is not really constant.
 It is not big deal to prohibit constant propagation here as
 we will constant propagate in DOM1 pass anyway.  *

Of course the second sentence of the comment does not apply to non-gimple_reg
values, unless they get SRAed later, because we do not do constant propagation
for them.  This for example prevents two identical calls to a pure function
from being merged in the attached Ada testcase.

Therefore the attached patch attempts to reuse a read-only or non-addressable
local DECL of the caller, the hitch being that expand_call_inline needs to be
prevented from creating a CLOBBER for the cases where it ends uo being reused.

Tested on x86-64/Linux, OK for the mainline?


2021-05-03  Eric Botcazou  

* tree-inline.c (setup_one_parameter): Do not create a variable if the
value is either a read-only DECL or a non-addressable local variable.
Register the variable thus reused instead of creating a new one.
(expand_call_inline): Do not generate a CLOBBER for these variables.


2021-05-03  Eric Botcazou  

* gnat.dg/opt94.adb: New test.
* gnat.dg/opt94_pkg.ads, opt94.adb: New helper.

-- 
Eric Botcazoudiff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 1dcb31c0267..a05093ab829 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -3460,16 +3460,18 @@ setup_one_parameter (copy_body_data *id, tree p, tree value, tree fn,
  value.  */
   if (TREE_READONLY (p)
   && !TREE_ADDRESSABLE (p)
-  && value && !TREE_SIDE_EFFECTS (value)
+  && value
+  && !TREE_SIDE_EFFECTS (value)
   && !def)
 {
-  /* We may produce non-gimple trees by adding NOPs or introduce
-	 invalid sharing when operand is not really constant.
-	 It is not big deal to prohibit constant propagation here as
-	 we will constant propagate in DOM1 pass anyway.  */
-  if (is_gimple_min_invariant (value)
-	  && useless_type_conversion_p (TREE_TYPE (p),
-		 TREE_TYPE (value))
+  /* We may produce non-gimple trees by adding NOPs or introduce invalid
+	 sharing when the value is not constant or DECL.  And we need to make
+	 sure that it cannot be modified from another path in the callee.  */
+  if ((is_gimple_min_invariant (value)
+	   || (DECL_P (value) && TREE_READONLY (value))
+	   || (auto_var_in_fn_p (value, id->src_fn)
+	   && !TREE_ADDRESSABLE (value)))
+	  && useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value))
 	  /* We have to be very careful about ADDR_EXPR.  Make sure
 	 the base variable isn't a local variable of the inlined
 	 function, e.g., when doing recursive inlining, direct or
@@ -3478,6 +3480,13 @@ setup_one_parameter (copy_body_data *id, tree p, tree value, tree fn,
 	  && ! self_inlining_addr_expr (value, fn))
 	{
 	  insert_decl_map (id, p, value);
+	  /* Prevent expand_call_inline from creating a CLOBBER for it.  */
+	  if (VAR_P (value) & !is_gimple_reg (value))
+	{
+	  if (!id->debug_map)
+		id->debug_map = new hash_map;
+	  id->debug_map->put (value, value);
+	}
 	  insert_debug_decl_map (id, p, var);
 	  return insert_init_debug_bind (id, bb, var, value, NULL);
 	}
@@ -5129,7 +5138,10 @@ expand_call_inline (basic_block bb, gimple *stmt, copy_body_data *id,
   if (!TREE_THIS_VOLATILE (p))
 	{
 	  tree *varp = id->decl_map->get (p);
-	  if (varp && VAR_P (*varp) && !is_gimple_reg (*varp))
+	  if (varp
+	  && VAR_P (*varp)
+	  && !is_gimple_reg (*varp)
+	  && !(id->debug_map && id->debug_map->get (*varp)))
 	{
 	  tree clobber = build_clobber (TREE_TYPE (*varp));
 	  gimple *clobber_stmt;
-- { dg-do compile }
-- { dg-options "-O -gnatn -fdump-tree-optimized" }

with Opt94_Pkg; use Opt94_Pkg;

function Opt94 (S : String) return Integer is
  A : constant String := Get;

begin
  if Valid_Result (A) then
return Result (A);
  else
return -1;
  end if;
end;

-- { dg-final { scan-tree-dump-times "worker" 1 "optimized" } }
package body Opt94_Pkg is

  function Worker (S : String) return Integer;
  pragma Pure_Function (Worker);

  function Valid_Result (S : String) return Boolean is
  begin
return Worker (S) > 0;
  end;

  function Result (S : String) return Integer is
R : constant Integer := Worker (S);
  begin
if R > 0 then
  return R;
else
  raise Program_Error;
end if;
  end;

  function Worker (S : String) return Integer is
  begin
return Character'Pos (S (1));
  end;

  function Get return String is
  begin
return "";
  end;

end Opt94_Pkg;
package Opt94_Pkg is

  function Valid_Result (S : String) return Boolean;
  pragma Inline (Valid_Result);

  function Result (S : String) 

OpenMP – patches pending review

2021-05-03 Thread Tobias Burnus

Outstanding but submitted patches:

* [Patch] OpenMP/Fortran: Handle polymorphic scalars in data-sharing 
FIRSTPRIVATE [PR86470]
(March 10, 2021)
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566529.html

* [Patch] OpenMP: Fix combined-target handling for lastprivate/reduction/linear 
[PR99928]
(April 9, 2021)
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567838.html


For completeness:

* [Patch] OpenMP: Support complex/float in && and || reduction
(last Friday)
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569362.html

[to-do by me, i.e. pending some post-review fixes by me and then re-submission:
 * [Patch] OpenMP: Add iterator support to Fortran's depend; add affinity clause
 https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568820.html ]

Thanks,

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf


[patch] Fix libiberty link failure in LTO mode

2021-05-03 Thread Eric Botcazou
Hi,

the patch for libiberty itself I posted is not sufficient to link the library 
for MinGW platforms in LTO mode, as there is another link failures for stpcpy.
The symbol is both referenced by libiberty's pex-win32.c and provided by 
libiberty's stpcpy.c so it needs to have a linkage to be resolved in LTO mode.

Tested on x86-64/Linux, x86-64/Windows and x86/Windows, OK for the mainline?


2021-05-03  Eric Botcazou  

* builtins.c (builtin_with_linkage_p): Return true for stp[n]cpy.
* symtab.c (symtab_node::output_to_lto_symbol_table_p): Tidy up.

-- 
Eric Botcazoudiff --git a/gcc/builtins.c b/gcc/builtins.c
index 2d6bf4a65b4..b1d0f6a551f 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -14310,8 +14310,8 @@ target_char_cst_p (tree t, char *p)
 }
 
 /* Return true if the builtin DECL is implemented in a standard library.
-   Otherwise returns false which doesn't guarantee it is not (thus the list of
-   handled builtins below may be incomplete).  */
+   Otherwise return false which doesn't guarantee it is not (thus the list
+   of handled builtins below may be incomplete).  */
 
 bool
 builtin_with_linkage_p (tree decl)
@@ -14390,6 +14390,14 @@ builtin_with_linkage_p (tree decl)
   CASE_FLT_FN (BUILT_IN_TRUNC):
   CASE_FLT_FN_FLOATN_NX (BUILT_IN_TRUNC):
 	return true;
+
+  case BUILT_IN_STPCPY:
+  case BUILT_IN_STPNCPY:
+	/* stpcpy is both referenced in libiberty's pex-win32.c and provided
+	   by libiberty's stpcpy.c for MinGW targets so we need to return true
+	   in order to be able to build libiberty in LTO mode for them.  */
+	return true;
+
   default:
 	break;
 }
diff --git a/gcc/symtab.c b/gcc/symtab.c
index 2135b34ce27..8c4cb70b015 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -2526,10 +2526,7 @@ symtab_node::output_to_lto_symbol_table_p (void)
 	 in libraries so make sure to output references into the symbol table to
 	 make those libraries referenced.  Note this is incomplete handling for
 	 now and only covers math functions.  */
-  if (builtin_with_linkage_p (decl))
-	return true;
-  else
-	return false;
+  return builtin_with_linkage_p (decl);
 }
 
   /* We have real symbol that should be in symbol table.  However try to trim


[libiberty] Make test for variables more robust

2021-05-03 Thread Eric Botcazou
Hi,

the test for the presence of variables (really symbols) does not work when you 
add -Ox -flto to CFLAGS:

  for v in $vars; do
AC_MSG_CHECKING([for $v])
AC_CACHE_VAL(libiberty_cv_var_$v,
  [AC_LINK_IFELSE([AC_LANG_PROGRAM([[int *p;]],[[extern int $v []; p = 
$v;]])],
  [eval "libiberty_cv_var_$v=yes"],
  [eval "libiberty_cv_var_$v=no"])])
if eval "test \"`echo '$libiberty_cv_var_'$v`\" = yes"; then
  AC_MSG_RESULT(yes)
  n=HAVE_`echo $v | tr 'abcdefghijklmnopqrstuvwxyz' 
'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
  AC_DEFINE_UNQUOTED($n)
else
  AC_MSG_RESULT(no)
fi
  done

because the assignment to 'p' is optimized away by LTO.  This is visible on 
MinGW platforms in the form of a link failure for sys_siglist.

Tested on x86-64/Linux, x86-64/Windows and x86/Windows, OK for the mainline?


2021-05-03  Eric Botcazou  

* configure.ac: Make test for variables more robust.
* configure: Regenerate.

-- 
Eric Botcazoudiff --git a/libiberty/configure.ac b/libiberty/configure.ac
index ad952963971..3c03f24d368 100644
--- a/libiberty/configure.ac
+++ b/libiberty/configure.ac
@@ -665,7 +665,7 @@ if test -z "${setobjs}"; then
   for v in $vars; do
 AC_MSG_CHECKING([for $v])
 AC_CACHE_VAL(libiberty_cv_var_$v,
-  [AC_LINK_IFELSE([AC_LANG_PROGRAM([[int *p;]],[[extern int $v []; p = $v;]])],
+  [AC_LINK_IFELSE([AC_LANG_PROGRAM([[extern int $v [];]],[[if ($v [0]) return 1;]])],
 		  [eval "libiberty_cv_var_$v=yes"],
 		  [eval "libiberty_cv_var_$v=no"])])
 if eval "test \"`echo '$libiberty_cv_var_'$v`\" = yes"; then


Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

2021-05-03 Thread Alan Modra via Gcc-patches
On Fri, Apr 30, 2021 at 03:48:00PM -0600, Jeff Law via Gcc-patches wrote:
> 
> On 4/30/2021 12:36 PM, Simon Marchi via Gcc-patches wrote:
> > On 2021-04-26 7:32 a.m., Nick Clifton via Gdb-patches wrote:> Hi Guys,
> > >Given that gcc, gdb and now binutils are all now requiring C99 as a
> > >minimum version of C, are there any objections to updating
> > >configure.ac to reflect this ?
> > > 
> > > Cheers
> > >Nick
> > > 
> > > diff --git a/configure.ac b/configure.ac
> > > index a721316d07b..59b4194fb24 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -1278,7 +1278,7 @@ else
> > > WINDMC_FOR_BUILD="\$(WINDMC)"
> > >   fi
> > > 
> > > -AC_PROG_CC
> > > +AC_PROG_CC_C99
> > >   AC_PROG_CXX
> > > 
> > >   # We must set the default linker to the linker used by gcc for the 
> > > correct
> > Hi Nick,
> > 
> > I think this fix is obvious enough, I encourage you to push it, that
> > will fix the build failure many people get in opcodes/ppc-dis.c.  We'll
> > just remove the line later when we upgrade to Autoconf 2.71, as simple
> > as that.  For now we use 2.69.  If that matters, you have my OK for the
> > GDB side of things.
> 
> That works for me.  I'd just sent Alan the trivial patch to make ppc-dis.c
> compile again with C89, but if we're going to update configure.ac
> appropriately, then it wouldn't be needed.

Yes, I prefer the configure fix too.  If we state we require C99 in
binutils then we ought to be able to use C99..

Nick, does the configure.ac change also need to go in all subdirs, to
support people running make in say ld/ rather than running make in the
top build dir?

-- 
Alan Modra
Australia Development Lab, IBM