[PATCH] [Microblaze]: PIC Data Text Relative

[Andrew Guirguis]

 Dears,

Kindly find the patch bundle for Microblaze '-mpic-data-text-relative'
feature at the following link:
https://github.com/andrewsadek/microblaze-pic-data-text-rel/tree/pic_data_text_rel/PATCH%20BUNDLE

Description of the feature:
https://github.com/andrewsadek/microblaze-pic-data-text-rel/
blob/pic_data_text_rel/README.md

Bundle includes:
1) Change logs for GCC, binutils
2) GCC Test results and comparison with the original.
3) New Test case (picdtr.c)
4) The Patches (against current heads)

Thanks

-- 

Andrew

Fw: GCC interpretation of C11 atomics (DR 459)

[Ruslan Nikolaev via gcc]

Alexander,
Thank you for your comments. Please see my response below. I definitely do not 
want to fight for or against this change in gcc, but there are definitely 
legitimate concerns to consider.  I think, it would really be good to consider 
this change to make things more compatible (i.e., at least between clang/llvm 
and gcc which can be both used within the same ecosystem). There are real 
practical benefits of having true lock-free double-width operations when 
implementing algorithms that rely on ABA tagging for pointers, and C11 at last 
gives an opportunity to do that without resorting to assembly or 
platform-specific implementations.


> Note that there's more issues to that than just behavior on readonly memory:
> you need to ensure that the whole program, including all static and shared
> libraries, is compiled with -mcx16 (and currently there's no ld.so/ld-level
> support to ensure that), or you'd need to be sure that it's safe to mix code
> compiled with different -mcx16 settings because it never happens to interop
> on wide atomic objects.

Well, if libatomic is already doing it when corresponding CPU feature is 
available (i.e., effectively implementing operations using cmpxchg16b), I do 
not see any problem here. mcx16 implies that you *have* cmpxchg16b, therefore 
other code compiled without -mcx16 flag will go to libatomic. Inside libatomic, 
it will detect that cmpxchg16b *is* available, thus making code compiled with 
and without -mcx16 flag completely compatible on a given system. Or do I miss 
something here?

If you do not have cmpxchg16b, but the program is compiled with the flag, it 
will simply not run (as expected).
 
So, in other words, libatomic should still decide whether you have cmpxchg16b 
or not for cases when -mcx16 is not specified. But if it is specified, 
cmpxchg16b can be generated unconditionally. If you want better compatibility, 
you will not specify the flag. Mix of -mcx16 and mno-cx16 will be, thus, binary 
compatible.

> Note that there's no "load" function in the __sync family, so the original
> concern about operations on readonly memory does not apply.
Yes, but per clarification from WG14/C11, read-only memory should not be a 
concern at all, as this behavior is not specified anyway (regardless of the 
const specifier). Read-modify-write is allowed for atomic_load as long as there 
is no 'visible' change on the value being loaded. In this sense, the bug that 
was filed previously regarding read-only memory accesses and const specifier 
does not seem to be valid.
Additionally, it is really odd and counterintuitive to still provide support 
for (almost) deprecated macros while not giving such an opportunity for newer 
and more advanced functions.

> You don't mention it directly, so just to make it clear for readers: on 
> systems
> where GNU IFUNC extension is available (i.e. on Glibc), libatomic tries to do
> exactly that: test for cmpxchg16b availability and redirect 128-bit atomics to
> lock-free RMW implementations if so.  (I don't like this solution)

Yes, but libatomic makes things slower due to indirection. Also, it is much 
harder to track what is going on, as there is no guarantee of lock-freedom in 
this case. BTW -- The fact that it currently uses cmpxchg16b if available may 
actually be helpful to switch to the suggested behavior without breaking binary 
compatibility (if I understand everything correctly).

-- Ruslan
   

gcc-8-20180225: recipe for target 'configure-target-libbacktrace' failed

[Siegmar Gross]

Hi,

today I tried to install gcc-8-20180225 with accelerator support
on my "SUSE Linux Enterprise Server 12.3 (x86_64)" with gcc-6.4.0.
I used the following commands to download and build everything.

setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/usr/local/cuda/lib64
setenv CUDA_INC_PATH /usr/local/cuda/include
setenv CUDA_LIB_PATH /usr/local/cuda/lib64
set path = ( ${path} /usr/local/cuda/bin )

git clone https://github.com/MentorEmbedded/nvptx-tools
git clone https://github.com/MentorEmbedded/nvptx-newlib

wget ftp://gcc.gnu.org/pub/gcc/snapshots/LATEST-8/gcc-8-20180225.tar.xz
tar xf gcc-8-20180225.tar.xz
ln -s gcc-8-20180225 gcc-8.0.0
cd gcc-8.0.0
ln -s ../nvptx-newlib/newlib newlib
cd ..

mkdir make_nvptx-tools
cd make_nvptx-tools
../nvptx-tools/configure --prefix=/usr/local/gcc-8.0.0 \
  |& tee log.configure
make |& tee log.make
make install |& tee log.make-install
cd ..

mkdir gcc-8.0.0_build
cd gcc-8.0.0_build
../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0 \
  --target=nvptx-none \
  --enable-as-accelerator-for=x86_64-pc-linux-gnu \
  --with-build-time-tools=/usr/local/gcc-8.0.0/nvptx-none/bin \
  --disable-sjlj-exceptions \
  --with-newlib \
  --enable-newlib-io-long-long \
  --enable-languages=c,c++,fortran,lto \
  |& tee log.configure
make |& tee log.make


Unfortunately, "make" breaks with the following error.

loki gcc-8.0.0_build 137 tail -19 log.make
make[3]: Leaving directory 
'/export2/src/gcc-8.0.0/gcc-8.0.0_build/nvptx-none/libgcc'
make[2]: Leaving directory 
'/export2/src/gcc-8.0.0/gcc-8.0.0_build/nvptx-none/libgcc'
Checking multilib configuration for libbacktrace...
mkdir -p -- nvptx-none/libbacktrace
Configuring in nvptx-none/libbacktrace
configure: creating cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... nvptx-unknown-none
checking target system type... nvptx-unknown-none
checking for nvptx-none-gcc... /export2/src/gcc-8.0.0/gcc-8.0.0_build/./gcc/xgcc -B/export2/src/gcc-8.0.0/gcc-8.0.0_build/./gcc/ 
-B/usr/local/gcc-8.0.0/nvptx-none/bin/ -B/usr/local/gcc-8.0.0/nvptx-none/lib/ -isystem /usr/local/gcc-8.0.0/nvptx-none/include -isystem 
/usr/local/gcc-8.0.0/nvptx-none/sys-include

checking for C compiler default output file name...
configure: error: in 
`/export2/src/gcc-8.0.0/gcc-8.0.0_build/nvptx-none/libbacktrace':
configure: error: C compiler cannot create executables
See `config.log' for more details.
Makefile:11774: recipe for target 'configure-target-libbacktrace' failed
make[1]: *** [configure-target-libbacktrace] Error 1
make[1]: Leaving directory '/export2/src/gcc-8.0.0/gcc-8.0.0_build'
Makefile:883: recipe for target 'all' failed
make: *** [all] Error 2
loki gcc-8.0.0_build 138


I was able to build that part for gcc-7.3.0 with a patched nvptx.c
file with the same commands. I would be grateful, if somebody knows
a solution or can fix the problem. Do you need anything else? Thank
you very much for any help in advance.


Kind regards

Siegmar
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by package-unused configure version-unused, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /export2/src/gcc-8.0.0/gcc-8.0.0/libbacktrace/configure 
--srcdir=../../../gcc-8.0.0/libbacktrace --cache-file=./config.cache 
--enable-multilib --with-cross-host=x86_64-pc-linux-gnu 
--prefix=/usr/local/gcc-8.0.0 --enable-as-accelerator-for=x86_64-pc-linux-gnu 
--with-build-time-tools=/usr/local/gcc-8.0.0/nvptx-none/bin 
--disable-sjlj-exceptions --with-newlib --enable-newlib-io-long-long 
--enable-languages=c,c++,fortran,lto --program-transform-name=s&^& 
--disable-option-checking --with-target-subdir=nvptx-none 
--build=x86_64-pc-linux-gnu --host=nvptx-none --target=nvptx-none

## - ##
## Platform. ##
## - ##

hostname = loki
uname -m = x86_64
uname -r = 4.4.114-94.11-default
uname -s = Linux
uname -v = #1 SMP Thu Feb 1 19:28:26 UTC 2018 (4309ff9)

/usr/bin/uname -p = x86_64
/bin/uname -X = unknown

/bin/arch  = x86_64
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /usr/local/valgrind-3.12.0/bin
PATH: /usr/local/jdk-9/bin
PATH: /usr/local/jdk-9/db/bin
PATH: /usr/local/llvm-5.0/bin
PATH: /usr/local/pgi-2017/linux86-64/2017/bin
PATH: 
/usr/local/intel_xe_2018/compilers_and_libraries_2018.1.163/linux/bin/intel64
PATH: 
/usr/local/intel_xe_2018/compilers_and_libraries_2018.1.163/linux/mpi/intel64/bin
PATH: /opt/solstudio12.6/bin
PATH: /usr/local/gcc-6.4.0/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /sbin
PATH: /usr/sbin
PATH: /bin
PATH: /usr/bin
PATH: /usr/local/hwloc-1.11.5/bin
PATH: /root/Linux/x86_64/bin
PATH: .
PATH: /usr/local/cuda/bin


## --- ##
## Core tests. ##
#

[Bug c/84531] c/c++: bogus warning for functions with different argument lengths but compatible arguments

[siddhesh at gotplt dot org]

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Siddhesh Poyarekar  ---
Yeah that doesn't look good.  I had not done a cpython build; I had started
with a gem5 build (which builds python modules) and only superficially looked
at cpython.

I thought about this over the weekend and agree that silencing the warning will
only hold us back indefinitely.  I'll look at the cpython build a bit closer
and try to fix it there when I have time for it.  Thanks for looking into this.

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

[Siddhesh Poyarekar]

On Saturday 24 February 2018 03:28 AM, Martin Sebor wrote:
> In my mind that would be a perfectly reasonable approach.
> A variation on it might be to leave a new warning disabled
> in the first release, then include it in -Wextra the next
> release, and finally put it in -Wall.
> 
> Unfortunately, in reality this rarely happens.  Most warnings
> stay wherever they land when they're first added and only few
> are ever tightened up.  Most also stay the same for many
> releases.  (IME, it's not a fun or glamorous job to do the
> work it takes to turn on a disabled warning, or to tighten
> up an existing one and deal with the fallout.)

Yeah, I've thought about this a bit over the weekend and I've come to
the conclusion that silencing the warning will only hold us back
indefinitely.  I'll try to fix this in the modules I'm interested in.  I
withdraw this patch for now.

Thanks,
Siddhesh

[Bug c++/81589] Possible False-Positive with decltype

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #6 from Jason Merrill  ---
(In reply to Martin Liška from comment #3)
> I see the same problem (reduced from Chromium package):

Fixed.  I suspect that this doesn't address the original issue because it
mentions GCC 8 failing as well.  To address that we'll need a testcase that
fails with GCC 8.

[Bug c++/84015] [7 Regression] ICE with class template argument deduction

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

C++ PATCH for c++/81589, error with is_trivially_constructible

[Jason Merrill]

Applying this one line from Ville's patch for 80654 fixes the Chromium testcase.

Tested x86_64-pc-linux-gnu, applying to 7 branch.
commit 57b9683f0ce55a410c567fcb2dc365a2cc848d6a
Author: jason 
Date:   Mon Feb 26 06:09:07 2018 +

PR c++/81589 - error with is_trivially_constructible.

* method.c (constructible_expr): Set cp_unevaluated.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-7-branch@257981 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 59ad43f73fe..a2d4c071efa 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1165,6 +1165,7 @@ constructible_expr (tree to, tree from)
 {
   tree ctype = to;
   vec *args = NULL;
+  cp_unevaluated cp_uneval_guard;
   if (TREE_CODE (to) != REFERENCE_TYPE)
to = cp_build_reference_type (to, /*rval*/false);
   tree ob = build_stub_object (to);
diff --git a/gcc/testsuite/g++.dg/ext/is_trivially_constructible6.C 
b/gcc/testsuite/g++.dg/ext/is_trivially_constructible6.C
new file mode 100644
index 000..10a8dfbb8f0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_trivially_constructible6.C
@@ -0,0 +1,10 @@
+// PR c++/81589
+
+template 
+struct z {
+  z() {
+k::error;
+  }
+};
+
+int x = __is_trivially_constructible(z);

[Bug c++/84015] [7 Regression] ICE with class template argument deduction

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon Feb 26 06:09:01 2018
New Revision: 257980

URL: https://gcc.gnu.org/viewcvs?rev=257980=gcc=rev
Log:
PR c++/84015 - ICE with class deduction and auto template parm.

* pt.c (rewrite_template_parm): Use tf_partial in first tsubst.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/class-deduction49.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug c++/81589] Possible False-Positive with decltype

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Mon Feb 26 06:09:07 2018
New Revision: 257981

URL: https://gcc.gnu.org/viewcvs?rev=257981=gcc=rev
Log:
PR c++/81589 - error with is_trivially_constructible.

* method.c (constructible_expr): Set cp_unevaluated.

Added:
   
branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/is_trivially_constructible6.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/method.c

Re: GCC interpretation of C11 atomics (DR 459)

[Alexander Monakov]

Hello,

Although I wouldn't like to fight defending GCC's design change here, let me
offer a couple of corrections/additions so everyone is on the same page:

On Mon, 26 Feb 2018, Ruslan Nikolaev via gcc wrote:
> 
> 1. Not consistent with clang/llvm which completely supports double-width
> atomics for arm32, arm64, x86 and x86-64 making it possible to write portable
> code (w/o specific extensions or assembly code) across all these architectures
> (which is finally possible with C11!).The behavior of clang: if mxc16 is
> specified, cmpxchg16b is generated for x86-64 (without any calls to
> libatomic), otherwise -- redirection to libatomic. For arm64, ldaxp/staxp are
> always generated. In my opinion, this is very logical and non-confusing.

Note that there's more issues to that than just behavior on readonly memory:
you need to ensure that the whole program, including all static and shared
libraries, is compiled with -mcx16 (and currently there's no ld.so/ld-level
support to ensure that), or you'd need to be sure that it's safe to mix code
compiled with different -mcx16 settings because it never happens to interop
on wide atomic objects.

(if you mix -mcx16 and -mno-cx16 code operating on the same 128-bit object,
you get wrong code that will appear to work >99% of the time)

> 3. The behavior is inconsistent even within GCC. Older (and more limited, less
> portable, etc) __sync builtins still use cmpxchg16b directly, newer __atomic
> and C11 -- do not. Moreover, __sync builtins are probably less suitable for
> arm/arm64.

Note that there's no "load" function in the __sync family, so the original
concern about operations on readonly memory does not apply.

> For these reasons, it may be a good idea if GCC folks reconsider past
> decision. And just to clarify: if mcx16 (x86-64) is not specified during
> compilation, it is totally OK to redirect to libatomic, and there make the
> final decision if target CPU supports a given instruction or not. But if it is
> specified, it makes sense for performance reasons and lock-freedom guarantees
> to always generate it directly. 

You don't mention it directly, so just to make it clear for readers: on systems
where GNU IFUNC extension is available (i.e. on Glibc), libatomic tries to do
exactly that: test for cmpxchg16b availability and redirect 128-bit atomics to
lock-free RMW implementations if so.  (I don't like this solution)

Thanks.
Alexander

[Bug target/70490] __atomic_load_n(const __int128 *, ...) generates CMPXCHG16B with no warning

[nruslan_devel at yahoo dot com]

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

Ruslan Nikolaev  changed:

   What|Removed |Added

 CC||nruslan_devel at yahoo dot com

--- Comment #6 from Ruslan Nikolaev  ---
See also Bug 84563

[Bug c++/84461] [8 regression] openjdk-10 fails to build

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jason Merrill  ---
(In reply to Andreas Schwab from comment #2)
> Created attachment 43467 [details]

I can't reproduce the failure with this testcase.

[Bug c/84563] New: GCC interpretation of C11 atomics (DR 459)

[nruslan_devel at yahoo dot com]

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

Bug ID: 84563
   Summary: GCC interpretation of C11 atomics (DR 459)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nruslan_devel at yahoo dot com
  Target Milestone: ---

I know, there are related issues already but decided to open a new issue
because it primarily relates to the interpretation of DR 459 by GCC and
response from C11/WG14.

(I also posted the same on the mailing list.)

I have read multiple bug reports (Bug 84522, Bug 80878, Bug 70490), and a past
decision regarding GCC change to redirect double-width (128-bit) atomics for
x86-64 and arm64 to libatomic. Below I mention major concerns as well as the
response from C11 (WG14) regarding DR 459 which, most likely, triggered this
change in more recent GCC releases in the first place. 

If I understand correctly, the redirection to libatomic was made for 2 reasons:

1. cmpxchg16b is not available on early amd64 processors. (However, mcx16 flag
already specifies that you use CPUs that have this instruction, so it should
not be a concern when the flag is specified.)

2. atomic_load on read-only memory. DR 459 now requires to have 'const'
qualifiers for atomic_load which probably resulted in the interpretation that
read-only memory must be supported. However, per response from C11/WG14 (see
below), it does not seem to be the case at all. Therefore, previously filed Bug
70490 does not seem to be valid.

There are several concerns with current GCC behavior:

1. Not consistent with clang/llvm which completely supports double-width
atomics for arm32, arm64, x86 and x86-64 making it possible to write portable
code (w/o specific extensions or assembly code) across all these architectures
(which is finally possible with C11!).
The behavior of clang: if mxc16 is specified, cmpxchg16b is generated for
x86-64 (without any calls to libatomic), otherwise -- redirection to libatomic.
For arm64, ldaxp/staxp are always generated. In my opinion, this is very
logical and non-confusing.

2. Oftentimes you want to have strict guarantees (by specifying mcx16 flag for
x86-64) that the generated code is lock-free, otherwise it is useless.
Double-width atomics are often used in lock-free algorithms that use tags
(stamps) for pointers to resolve the ABA problem. So, it is very useful to have
corresponding support in the compiler.

3. The behavior is inconsistent even within GCC. Older (and more limited, less
portable, etc) __sync builtins still use cmpxchg16b directly, newer __atomic
and C11 -- do not. Moreover, __sync builtins are probably less suitable for
arm/arm64.

4. atomic_load can be implemented using read-modify-write as it is the only
option for x86-64 and arm64 (see below).

For these reasons, it may be a good idea if GCC folks reconsider past decision.
And just to clarify: if mcx16 (x86-64) is not specified during compilation, it
is totally OK to redirect to libatomic, and there make the final decision if
target CPU supports a given instruction or not. But if it is specified, it
makes sense for performance reasons and lock-freedom guarantees to always
generate it directly.

-- Ruslan

Response from the WG14 (C11) Convener regarding DR 459: (I asked for a
permission to publish this response here.)
-
Ruslan,

 Thank you for your comments.  There is no normative requirement that const
objects be suitable for read-only memory.  An example and a footnote refer to
read-only memory as a way to illustrate a point, but examples and footnotes are
not normative.  The actual nature of read-only memory and how it can be used
are outside the scope of the standard, so there is nothing to prevent
atomic_load from being implemented as a read-modify-write operation.

David
--


My original email:

--

Dear David Keaton,

After reviewing the proposed change DR 459 for C11: http://www.open-std.org/
jtc1/sc22/wg14/www/docs/ summary.htm#dr_459 ,
I identified that adding const qualifier to atomic_load (C11 implements its
without it) may actually be harmful in some cases.

Particularly, for double-width (128-bit) atomics found in x86-64 (cmpxchg16b
instruction), arm64 (ldaxp/staxp instructions), it is currently only possible
to implement atomic_load for 128 bit using corresponding read-modify-write
instructions (i.e., potentially rewriting memory with the same value, but, in
essence, not changing it). But these implementations will not work on read-only
memory. Similar concerns apply to some extent to x86 and arm32 for double-width
(64-bit) atomics. Otherwise, there is no obstacle to implement all C11 atomics
for corresponding types in these architectures. Moreover, a well-known
clang/llvm compiler already implements all 

[Bug c++/84015] [7/8 Regression] ICE with class template argument deduction

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Feb 26 05:05:15 2018
New Revision: 257979

URL: https://gcc.gnu.org/viewcvs?rev=257979=gcc=rev
Log:
PR c++/84015 - ICE with class deduction and auto template parm.

* pt.c (rewrite_template_parm): Use tf_partial in first tsubst.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction49.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

C++ PATCH for c++/84015, ICE with class deduction and auto template parm

[Jason Merrill]

While rewriting the template parameters of a member template
constructor to generate the corresponding deduction guide, we tsubst
the parms twice.  In this bug, on the first pass we ended up lowering
the level of the 'auto' TEMPLATE_TYPE_PARM to 1, so the second pass
blows up.  This is very similar to the situation that I already
introduced tf_partial for, so let's use it here as well.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2b7c1f2a66551ce9462c82d119820b524a83b28e
Author: Jason Merrill 
Date:   Sun Feb 25 21:50:15 2018 -0500

PR c++/84015 - ICE with class deduction and auto template parm.

* pt.c (rewrite_template_parm): Use tf_partial in first tsubst.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 85d1adbbe3c..9cf96e9fbe4 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25596,7 +25596,7 @@ rewrite_template_parm (tree olddecl, unsigned index, 
unsigned level,
  // Substitute ttargs into ttparms to fix references to
  // other template parameters.
  ttparms = tsubst_template_parms_level (ttparms, ttargs,
-complain);
+complain|tf_partial);
  // Now substitute again with args based on tparms, to reduce
  // the level of the ttparms.
  ttargs = current_template_args ();
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction49.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction49.C
new file mode 100644
index 000..086f12ad3c6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction49.C
@@ -0,0 +1,15 @@
+// PR c++/84015
+// { dg-additional-options -std=c++17 }
+
+template 
+struct A { };
+
+template 
+struct B
+{
+  template
+  B(T);
+};
+
+A<42> a;
+B b (a);

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |6.5

--- Comment #17 from kargl at gcc dot gnu.org ---
After several people including have gone down rabbit
holes trying to fix this bug, I have found a patch!

GCC interpretation of C11 atomics (DR 459)

[Ruslan Nikolaev via gcc]

Hi
I have read multiple bug reports (84522, 80878, 70490), and the past decision 
regarding GCC change to redirect double-width (128-bit) atomics for x86-64 and 
arm64 to libatomic. Below I mention major concerns as well as the response from 
C11 (WG14) regarding DR 459 which, most likely, triggered this change in more 
recent GCC releases in the first place. 
If I understand correctly, the redirection to libatomic was made for 2 reasons:
1. cmpxchg16b is not available on early amd64 processors. (However, mcx16 flag 
already specifies that you use CPUs that have this instruction, so it should 
not be a concern when the flag is specified.)
2. atomic_load on read-only memory. DR 459 now requires to have 'const' 
qualifiers for atomic_load which probably resulted in the interpretation that 
read-only memory must be supported. However, per response from C11/WG14 (see 
below), it does not seem to be the case at all. Therefore, previously filed bug 
70490 does not seem to be valid.
There are several concerns with current GCC behavior:

1. Not consistent with clang/llvm which completely supports double-width 
atomics for arm32, arm64, x86 and x86-64 making it possible to write portable 
code (w/o specific extensions or assembly code) across all these architectures 
(which is finally possible with C11!).The behavior of clang: if mxc16 is 
specified, cmpxchg16b is generated for x86-64 (without any calls to libatomic), 
otherwise -- redirection to libatomic. For arm64, ldaxp/staxp are always 
generated. In my opinion, this is very logical and non-confusing.

2. Oftentimes you want to have strict guarantees (by specifying mcx16 flag for 
x86-64) that the generated code is lock-free, otherwise it is useless. 
Double-width atomics are often used in lock-free algorithms that use tags 
(stamps) for pointers to resolve the ABA problem. So, it is very useful to have 
corresponding support in the compiler.

3. The behavior is inconsistent even within GCC. Older (and more limited, less 
portable, etc) __sync builtins still use cmpxchg16b directly, newer __atomic 
and C11 -- do not. Moreover, __sync builtins are probably less suitable for 
arm/arm64.

4. atomic_load can be implemented using read-modify-write as it is the only 
option for x86-64 and arm64 (see below).

For these reasons, it may be a good idea if GCC folks reconsider past decision. 
And just to clarify: if mcx16 (x86-64) is not specified during compilation, it 
is totally OK to redirect to libatomic, and there make the final decision if 
target CPU supports a given instruction or not. But if it is specified, it 
makes sense for performance reasons and lock-freedom guarantees to always 
generate it directly. 

-- Ruslan

Response from the WG14 (C11) Convener regarding DR 459: (I asked for a 
permission to publish this response here.)
Ruslan,

     Thank you for your comments.  There is no normative requirement that const 
objects be suitable for read-only memory.  An example and a footnote refer to 
read-only memory as a way to illustrate a point, but examples and footnotes are 
not normative.  The actual nature of read-only memory and how it can be used 
are outside the scope of the standard, so there is nothing to prevent 
atomic_load from being implemented as a read-modify-write operation.

                                        David
My original email:

Dear David Keaton,
After reviewing the proposed change DR 459 for C11: 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_459 ,I 
identified that adding const qualifier to atomic_load (C11 implements its 
without it) may actually be harmful in some cases.
Particularly, for double-width (128-bit) atomics found in x86-64 (cmpxchg16b 
instruction), arm64 (ldaxp/staxp instructions), it is currently only possible 
to implement atomic_load for 128 bit using corresponding read-modify-write 
instructions (i.e., potentially rewriting memory with the same value, but, in 
essence, not changing it). But these implementations will not work on read-only 
memory. Similar concerns apply to some extent to x86 and arm32 for double-width 
(64-bit) atomics. Otherwise, there is no obstacle to implement all C11 atomics 
for corresponding types in these architectures. Moreover, a well-known 
clang/llvm compiler already implements all double-width operations for x86, 
x86-64, arm32 and arm64 (atomic_load is implemented using corresponding 
read-modify-write instructions). Double-width atomics are often used in data 
structures that need tagging for pointers to avoid the ABA problem (e.g., in 
lock-free stacks and queues).
It is my understanding that C11 aimed to make atomics more or less portable 
across different microarchitectures, while at the same time provide an ability 
for a compiler to optimize code well and utilize all potential of the 
corresponding microarchitecture.
If now it is required to support read-only memory (i.e., const qualifier) for 
atomic_load, 128-bit atomics are likely be impossible to 

[Bug c++/84015] [7/8 Regression] ICE with class template argument deduction

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[patch] better explain $target.h vs $target-protos.h in internals manual

[Sandra Loosemore]

Following up on discussion in gcc@, how does this documentation patch look?

https://gcc.gnu.org/ml/gcc/2018-02/msg00139.html

-Sandra
2018-02-25  Sandra Loosemore  

	gcc/
	* doc/configfiles.texi (Configuration Files): Move info about
	conditionalizing $target-protos.h to...
	* doc/sourcebuild.texi (Back End): Here.  Explain how $target.h
	differs from $target-protos.h.
Index: gcc/doc/configfiles.texi
===
--- gcc/doc/configfiles.texi	(revision 257967)
+++ gcc/doc/configfiles.texi	(working copy)
@@ -59,12 +59,10 @@ machine.
 @item
 @file{tm_p.h}, which includes the header @file{@var{machine}-protos.h}
 that contains prototypes for functions in the target
-@file{@var{machine}.c} file.  The header @file{@var{machine}-protos.h}
-can include prototypes of functions that use rtl and tree data
-structures inside appropriate @code{#ifdef RTX_CODE} and @code{#ifdef
-TREE_CODE} conditional code segements.  The
-@file{@var{machine}-protos.h} is included after the @file{rtl.h}
-and/or @file{tree.h} would have been included.  The @file{tm_p.h} also
+@file{@var{machine}.c} file.  The
+@file{@var{machine}-protos.h} header is included after the @file{rtl.h}
+and/or @file{tree.h} would have been included.
+The @file{tm_p.h} also
 includes the header @file{tm-preds.h} which is generated by
 @file{genpreds} program during the build to define the declarations
 and inline functions for the predicate functions.
Index: gcc/doc/sourcebuild.texi
===
--- gcc/doc/sourcebuild.texi	(revision 257967)
+++ gcc/doc/sourcebuild.texi	(working copy)
@@ -822,6 +822,23 @@ manual needs to be installed as info for
 chapter of this manual.
 @end itemize
 
+The @file{@var{machine}.h} header is included very early in GCC's
+standard sequence of header files, while @file{@var{machine}-protos.h}
+is included late in the sequence.  Thus @file{@var{machine}-protos.h}
+can include declarations referencing types that are not defined when
+@file{@var{machine}.h} is included, specifically including those from
+@file{rtl.h} and @file{tree.h}.  Since both RTL and tree types may not
+be available in every context where @file{@var{machine}-protos.h} is
+included, in this file you should guard declarations using these types
+inside appropriate @code{#ifdef RTX_CODE} or @code{#ifdef TREE_CODE}
+conditional code segments.
+
+If the backend uses shared data structures that require @code{GTY} markers 
+for garbage collection (@pxref{Type Information}), you must declare those
+in @file{@var{machine}.h} rather than @file{@var{machine}-protos.h}.  
+Any definitions required for building libgcc must also go in
+@file{@var{machine}.h}.
+
 GCC uses the macro @code{IN_TARGET_CODE} to distinguish between
 machine-specific @file{.c} and @file{.cc} files and
 machine-independent @file{.c} and @file{.cc} files.  Machine-specific

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[romain.geissler at amadeus dot com]

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

--- Comment #13 from Romain Geissler  ---
Hi,

It looks like that the code in #comment 11 works when you build just with -O2,
but not when you add debug symbols: -O2 -g. Do we have a way to ignore debug
statements when looking for the next statement in the next basic block ?

Cheers,
Romain

[Bug c/84562] New: -faggressive-loop-optimizations makes decisions based on weak data structures

[jnordholz at sect dot tu-berlin.de]

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

Bug ID: 84562
   Summary: -faggressive-loop-optimizations makes decisions based
on weak data structures
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jnordholz at sect dot tu-berlin.de
  Target Milestone: ---

Created attachment 43501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43501=edit
minimal example for both cases (int and array-of-char*)

(Minimal test case attached as source tar.gz, as the problem is inherently
multi-compilation-unit and doesn't involve any headers. Snippets below for
illustration.)

Compiling the following code with -c -O2...

__attribute__((weak)) const int y = 0;

void foo(void) {
for (i = 0; i < y; i++) {
write(2, "X", 1);
}
}

yields an empty foo() even though 'y' is weak (which I consider a bug, as
linking with another unit with a proper symbol 'y' with nonzero value will Do
The Wrong Thing and not even issue a warning - -fsanitize=undefined cannot help
either, as the whole loop is optimized away).

In a similar case, having

__attribute__((weak)) const char *arr[] = { NULL };
[...]
for (i = 0; arr[i]; i++) {

in one unit and overriding 'arr' in another with

const char *arr[] = { "abc", "def", NULL };

causes related problems: this time the loop doesn't disappear completely, so
-fsanitize=undefined complains about illegal array accesses - but I don't
believe this is justified, unless the different implicit array size is illegal
by the C standard; I couldn't find anything on that.

Tested with Debian gcc7 (7.3.0) and gcc8 (8.0.1) on x86_64, thus assigning to
the latest version.

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[law at redhat dot com]

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

--- Comment #30 from Jeffrey A. Law  ---
Just a note.  I'm tracking a separate problem with delay slot filling that
looks like it's related to handling of debug insns.  I doubt it's the same
problem, but if you stumble over it, be aware I'm testing a fix.

[Bug tree-optimization/84561] -Wstrinop-truncation with -O2 depends on strncpy's size type

[romain.geissler at amadeus dot com]

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

--- Comment #1 from Romain Geissler  ---
Note: I am testing with gcc snapshot from 24th February + patch from PR 84468
manually applied (at least I think I did).

[Bug c++/55881] #pragma GCC diagnostic ignored ignored when inlining

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #6 from Martin Sebor  ---
*** Bug 84555 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/84555] middle-end warnings are not ignorable with pragmas when inlined

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
As noted in bug 55881 comment 2, the problem has been known for some time but
it isn't easily fixable.

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

[Bug tree-optimization/84561] New: -Wstrinop-truncation with -O2 depends on strncpy's size type

[romain.geissler at amadeus dot com]

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

Bug ID: 84561
   Summary: -Wstrinop-truncation with -O2 depends on strncpy's
size type
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

There is another -Wformat-truncation that I don't understand with -O2. It looks
like I may or may not get the warning if the inlined size type used in strncpy
is 32 bits or 64 bits, and really can't figure out why that even matters wrt
warnings. Reproducer built with -Wall -Wextra -Werror -O2 on x86_64:

< class String
{
public:
String();

void set(const char* string, size_t len = N)
{
if (len > N)
{
len = N;
}

__builtin_strncpy(_string, string, len);
_string[len] = 0;
}

private:
char _string[N + 1];
};

class A
{
public:
A() {}

void setStringSize_t(const char* string, size_t len)
{
_string.set(string, len);
}

void setStringUnsignedInt(const char* string, unsigned int len)
{
_string.set(string, len);
}
private:
String<3> _string;
};

class B
{
public:
B() {}

A& getA()
{   
return _a;
}

private:
A _a;
};

void f(A& a)
{   
a.setStringUnsignedInt("123", 3); //No warning here.
a.setStringSize_t("123", 3); //No warning here.
}

void f(B& b)
{
b.getA().setStringUnsignedInt("123", 3); // Unexpected warning here.
b.getA().setStringSize_t("123", 3); // No warning here.
}
EOF

I am getting this error/warning:

error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output
truncated before terminating nul copying 3 bytes from a string of the same
length [-Werror=stringop-truncation]
 __builtin_strncpy(_string, string, len);
 ~^~

As you can see, using either "size_t" or "unsigned int" for parameter "len"
seems to influence the gcc warning, despite everything is fully inlined. Is
this expected ?

Cheers,
Romain

[Bug tree-optimization/84555] middle-end warnings are not ignorable with pragmas when inlined

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-26
 CC||msebor at gcc dot gnu.org
Summary|strncpy warnings (and   |middle-end warnings are not
   |friends) are not ignorable  |ignorable with pragmas when
   |with pragmas when inlined   |inlined
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
I can confirm this doesn't work as you would expect.  Unfortunately, the
problem isn't limited to just -Wstringop-truncation but affects many if not all
middle-end warnings.  Here's another example with -Wformat-truncation. 
-Wnonnull has the same problem.

$ cat b.c && gcc -O2 -S -Wall b.c
void g (char *d, unsigned n, const char *s, int i)
{
  __builtin_snprintf (d, n, "%s-%i", s, i);
}

char a[8], b[8];

void h (int i)
{
#pragma GCC diagnostic ignored "-Wformat-truncation"
  g (a, sizeof a, b, i);
}
b.c: In function ‘h’:
b.c:3:33: warning: ‘%i’ directive output may be truncated writing between 1 and
11 bytes into a region of size between 0 and 7 [-Wformat-truncation=]
   __builtin_snprintf (d, n, "%s-%i", s, i);
 ^~
b.c:3:3: note: ‘__builtin_snprintf’ output between 3 and 20 bytes into a
destination of size 8
   __builtin_snprintf (d, n, "%s-%i", s, i);
   ^~~~

[Bug c++/84560] Internal error in std::function with std::memset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-26
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed with 8.0, 7.4, and 6.4 regardless of optimization or similar options.
 I'm not sure what revision introduced the ICE but based on bisection it
doesn't seem the code was ever accepted.  It needs to be reduced to a smaller
test case to tell for sure.

Re: [PATCH] Correct debug for -mcall-ms2sysv-xlogues stubs (PR target/83917, take 2)

[Daniel Santos]

Sorry for the dropping the ball on this and thank you Jakub for stepping in!

I've had a patch set sort-of rotting in my local repo, but I like yours
better.  I think I had gotten hung up on trying to figure out how to
write a test for this, and like you I just tested mine manually in gdb. 
I do have one correction though.


On 02/22/2018 08:56 AM, Jakub Jelinek wrote:
> Hi!
>
> On Sat, Jan 20, 2018 at 06:01:16PM -0600, Daniel Santos wrote:
>> Thanks.  I like the idea of commonizing the macros for consistency.
> Didn't see a progress on this P3 for a while, so I've written this
> version of the patch; no tests though, what I've been using in testing was:
> /* { dg-do compile { target lp64 } } */
> /* { dg-options "-mno-avx -msse2 -mcall-ms2sysv-xlogues -O2" } */
>
> void __attribute__((sysv_abi, noipa))
> foo (void)
> {
> }
>
> static void __attribute__((sysv_abi)) (*volatile foop) () = foo;
>
> void __attribute__((ms_abi, noipa))
> bar (void)
> {
>   foop ();
> }
>
> int
> main ()
> {
>   bar ();
>   return 0;
> }
>
> with/without -fno-omit-frame-pointer, disas bar; b on the tail
> call in there, stepi; bt (which before the patch failed, now works),
> also up; p $rbp to see if %rbp has been properly declared to be saved.
> There is no need to cfi_startproc/cfi_endproc for every single entrypoint in
> there, it is enough if the whole range is covered.  On the other side
> we need the cfi_offset for the frame pointer case, otherwise up; p/x $rbp
> doesn't work properly.
>
> Ok for trunk if it passes bootstrap/regtest on x86_64-linux and i686-linux?
>
> 2018-02-22  Jakub Jelinek  
>
>   PR debug/83917
>   * config/i386/i386-asm.h (PACKAGE_VERSION, PACKAGE_NAME,
>   PACKAGE_STRING, PACKAGE_TARNAME, PACKAGE_URL): Undefine between
>   inclusion of auto-target.h and auto-host.h.
>   (USE_GAS_CFI_DIRECTIVES): Define if not defined already based on
>   __GCC_HAVE_DWARF2_CFI_ASM.
>   (cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset,
>   cfi_def_cfa_register, cfi_def_cfa, cfi_register, cfi_offset, cfi_push,
>   cfi_pop): Define.
>   * config/i386/cygwin.S: Don't include auto-host.h here, just
>   define USE_GAS_CFI_DIRECTIVES to 1 or 0 and include i386-asm.h.
>   (cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset,
>   cfi_def_cfa_register, cfi_register, cfi_push, cfi_pop): Remove.
>   * config/i386/resms64fx.h: Add cfi_* directives.
>   * config/i386/resms64x.h: Likewise.
>
> --- libgcc/config/i386/i386-asm.h.jj  2018-01-03 10:42:56.317763517 +0100
> +++ libgcc/config/i386/i386-asm.h 2018-02-22 15:33:43.812922298 +0100
> @@ -27,8 +27,47 @@ see the files COPYING3 and COPYING.RUNTI
>  #define I386_ASM_H
>  
>  #include "auto-target.h"
> +#undef PACKAGE_VERSION
> +#undef PACKAGE_NAME
> +#undef PACKAGE_STRING
> +#undef PACKAGE_TARNAME
> +#undef PACKAGE_URL

This is a beautiful, temporary(?) fix to an ugly problem!

>  #include "auto-host.h"
>  
> +#ifndef USE_GAS_CFI_DIRECTIVES
> +# ifdef __GCC_HAVE_DWARF2_CFI_ASM
> +#  define USE_GAS_CFI_DIRECTIVES 1
> +# else
> +#  define USE_GAS_CFI_DIRECTIVES 0
> +# endif
> +#endif
> +#if USE_GAS_CFI_DIRECTIVES
> +# define cfi_startproc() .cfi_startproc
> +# define cfi_endproc()   .cfi_endproc
> +# define cfi_adjust_cfa_offset(X).cfi_adjust_cfa_offset X
> +# define cfi_def_cfa_register(X) .cfi_def_cfa_register X
> +# define cfi_def_cfa(R,O).cfi_def_cfa R, O
> +# define cfi_register(D,S)   .cfi_register D, S
> +# define cfi_offset(R,O) .cfi_offset R, O
> +# ifdef __x86_64__
> +#  define cfi_push(X).cfi_adjust_cfa_offset 8; 
> .cfi_rel_offset X, 0
> +#  define cfi_pop(X) .cfi_adjust_cfa_offset -8; .cfi_restore X
> +# else
> +#  define cfi_push(X).cfi_adjust_cfa_offset 4; 
> .cfi_rel_offset X, 0
> +#  define cfi_pop(X) .cfi_adjust_cfa_offset -4; .cfi_restore X
> +# endif
> +#else
> +# define cfi_startproc()
> +# define cfi_endproc()
> +# define cfi_adjust_cfa_offset(X)
> +# define cfi_def_cfa_register(X)
> +# define cfi_def_cfa(R,O)
> +# define cfi_register(D,S)
> +# define cfi_offset(R,O)
> +# define cfi_push(X)
> +# define cfi_pop(X)
> +#endif
> +
>  #define PASTE2(a, b) PASTE2a(a, b)
>  #define PASTE2a(a, b) a ## b
>  
> --- libgcc/config/i386/cygwin.S.jj2018-01-03 10:42:56.309763515 +0100
> +++ libgcc/config/i386/cygwin.S   2018-02-22 15:30:34.597925496 +0100
> @@ -23,31 +23,13 @@
>   * .
>   */
>  
> -#include "auto-host.h"

The following include should be here.

+#include "i386-asm.h"


> -
>  #ifdef HAVE_GAS_CFI_SECTIONS_DIRECTIVE
> +# define USE_GAS_CFI_DIRECTIVES 1
>   .cfi_sections   .debug_frame
> -# define cfi_startproc() .cfi_startproc
> -# define cfi_endproc()   .cfi_endproc
> -# define cfi_adjust_cfa_offset(X).cfi_adjust_cfa_offset X
> -# define cfi_def_cfa_register(X) 

[Bug c++/84559] [6/7/8 Regression] ICE with constexpr and variable-sized array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-25
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisected to r246662 (gcc 7.0.1):

r246662 | jason | 2017-04-03 17:15:36 -0400 (Mon, 03 Apr 2017) | 7 lines

PR sanitizer/79993 - ICE with VLA initialization from string

PR c++/69487 - wrong VLA initialization from string
* init.c (finish_length_check): Split out from build_vec_init.
(build_vec_init): Handle STRING_CST.
* typeck2.c (split_nonconstant_init): Handle STRING_CST.
(digest_init_r): Don't give a STRING_CST VLA type.

[Bug c++/84558] [6/7/8 Regression] ICE with invalid constexpr constructor

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-25
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE was introduced in r234439 (gcc 6.0.0):

r234439 | jakub | 2016-03-23 14:55:38 -0400 (Wed, 23 Mar 2016) | 8 lines

PR c++/70001
* constexpr.c (cxx_eval_vec_init_1): Reuse CONSTRUCTOR initializers
for 1..max even for multi-dimensional arrays.  Call unshare_expr
on it.

Re: [Patch fortran] PR32957 - C/Fortran interoperability and -fdefault-integer-8

[Thomas Koenig]

Hi Dominique,


OK for trunk? back port?


OK for trunk.

The tests were non-conforming before, so this is also a
step in making our testsuite better.

For gcc-7, I'm not sure I would bother, but OK if
you want to do it.

Regards

Thomas

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
Yes, all the relevant tests pass with the patch.  There is no warning for
either the test case in comment #0 or the one in comment #11.  The change from
v1 of the patch is just the addition of test for null to avoid the ICE.

[Patch fortran] PR32957 - C/Fortran interoperability and -fdefault-integer-8

[Dominique d'Humières]

Hi all,

I have noticed a recent interest to fix problems with -fdefault-integer-8. 
Please don’t forget to mark new PRs as blocking pr32770. I have also posted new 
results for the test suite.

I think it is a good time to submit the updated attached patch fixing some 
C/Fortran interoperability in the test suite (the variables exchanged between 
Fortran and C must not be changed by -fdefault-integer-8).

I have this patch in my working tree since a very long time and it has been 
applied before the new tests in pr32770.

OK for trunk? back port?

TIA

Dominique




patch-rega3
Description: Binary data

[Bug c++/84560] Internal error in std::function with std::memset

[zamazan4ik at tut dot by]

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

--- Comment #1 from Alexander Zaitsev  ---
On GCC 7.3.1 for this code I have:


internal compiler error: в expand_expr_real_1, в expr.c:9908
 memset(d[n - 1], 0, sizeof(int));
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccsFhYKj.out file, please attach this to
your bugreport.
gmake[3]: *** [CMakeFiles/test_proj.dir/build.make:63:
CMakeFiles/test_proj.dir/main.cpp.o] Ошибка 1
gmake[2]: *** [CMakeFiles/Makefile2:68: CMakeFiles/test_proj.dir/all] Ошибка 2
gmake[1]: *** [CMakeFiles/Makefile2:80: CMakeFiles/test_proj.dir/rule] Ошибка 2
gmake: *** [Makefile:118: test_proj] Ошибка 2

[Bug c++/84560] New: Internal error in std::function with std::memset

[zamazan4ik at tut dot by]

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

Bug ID: 84560
   Summary: Internal error in std::function with std::memset
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zamazan4ik at tut dot by
  Target Milestone: ---

gcc(trunk) with '-O3 -march=native --std=c++11 -Wall' for this code:


#include 
#include 

using namespace std;

int main() {
int n = 1;
int m = 1;
int d[n][m];
function rec = [&]() {
memset(d[n - 1], 0, sizeof(int));
};
  return 0;
}


generates this:


: In lambda function:
:10:32: error: Local declaration from a different function
 function rec = [&]() {
^
D.34164
:11:16: note: in statement
 memset(d[n - 1], 0, sizeof(int));
^
_2 = (sizetype) D.34164;
:10:32: error: Local declaration from a different function
 function rec = [&]() {
^
D.34164
:11:16: note: in statement
 memset(d[n - 1], 0, sizeof(int));
^
_9 = (sizetype) D.34164;
:10:32: error: Local declaration from a different function
 function rec = [&]() {
^
D.34167
:11:23: note: in statement
 memset(d[n - 1], 0, sizeof(int));
~~~^
_13 = D.34167 /[ex] 4;
during GIMPLE pass: cfg
:10:32: internal compiler error: verify_gimple failed
 function rec = [&]() {
^
mmap: Cannot allocate memory
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Compiler returned: 1


I think Internal error isn't good here.

Clang works fine.

[Bug c++/84559] New: [6/7/8 Regression] ICE with constexpr and variable-sized array

[reichelt at gcc dot gnu.org]

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

Bug ID: 84559
   Summary: [6/7/8 Regression] ICE with constexpr and
variable-sized array
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following (valid?) code snippet triggers an ICE since GCC 7.1.0:

==
void foo(int i)
{
  constexpr char x[i] = "";
}
==

bug.cc: In function 'void foo(int)':
bug.cc:5:25: internal compiler error: in cxx_eval_outermost_constant_expr, at
cp/constexpr.c:4810
   constexpr char x[i] = "";
 ^~
0x5e5bee cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4809
0x859c28 maybe_constant_init_1
../../gcc/gcc/cp/constexpr.c:5145
0x9ebcc2 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/gcc/cp/typeck2.c:833
0x881cda check_initializer
../../gcc/gcc/cp/decl.c:6384
0x899c5c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:7038
0x934e63 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19703
0x93c268 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13044
0x93d078 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12869
0x93daa9 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:12463
0x91c45b cp_parser_statement
../../gcc/gcc/cp/parser.c:10912
0x91d3a0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11261
0x91d477 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11215
0x933bf0 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21756
0x933bf0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21793
0x9344a0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26694
0x9351d4 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26610
0x9351d4 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19482
0x93c268 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13044
0x93d078 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12869
0x940fd2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12767
Please submit a full bug report, [etc.]

The code is accepted by GCC 5 and GCC 6.

gcc-8-20180225 is now available

[gccadmin]

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

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

You'll find:

 gcc-8-20180225.tar.xzComplete GCC

  SHA256=faaa9656b627a05180a57e25a544293115b20c334efe16b4f8ba5600a3ec330a
  SHA1=22692132364fc256746189cb3cd811cd2baf9103

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

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

[Bug c++/84558] New: [6/7/8 Regression] ICE with invalid constexpr constructor

[reichelt at gcc dot gnu.org]

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

Bug ID: 84558
   Summary: [6/7/8 Regression] ICE with invalid constexpr
constructor
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE since GCC 6.1.0.
The code was accepted in GCC 5.x.0 (compiled with "-std=c++1y"):

==
struct A
{
  static int i;
  constexpr A() { i = 0; }
};

struct B
{
  A a[2][1][1];
};

B b;
==

bug.cc:12:3:   in 'constexpr' expansion of 'b.B::B()'
bug.cc:12:3: internal compiler error: Segmentation fault
 B b;
   ^
0xeb1ddf crash_signal
../../gcc/gcc/toplev.c:325
0x8567af contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x8567af cxx_eval_vec_init_1
../../gcc/gcc/cp/constexpr.c:2981
0x852665 cxx_eval_vec_init
../../gcc/gcc/cp/constexpr.c:3011
0x852665 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4535
0x854f1d cxx_eval_store_expression
../../gcc/gcc/cp/constexpr.c:3685
0x8525cf cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4248
0x852b6f cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4552
0x851697 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4296
0x851697 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4296
0x85162d cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4647
0x850aaf cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:1689
0x85164b cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4170
0x856c97 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4819
0x859c28 maybe_constant_init_1
../../gcc/gcc/cp/constexpr.c:5145
0x8cd1ca expand_default_init
../../gcc/gcc/cp/init.c:1901
0x8cd1ca expand_aggr_init_1
../../gcc/gcc/cp/init.c:2004
0x8cd3d9 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/init.c:1744
0x8820ef build_aggr_init_full_exprs
../../gcc/gcc/cp/decl.c:6188
0x8820ef check_initializer
../../gcc/gcc/cp/decl.c:6337
Please submit a full bug report, [etc.]

[Bug fortran/68289] Missing diagnostic pragmas

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED
 CC||tkoenig at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #9 from Thomas Koenig  ---
I've assigned it to myself, with the understanding that
it may take some time before I do anything about this.

So, if anybody wants do do some work already, please go ahead :)

[Bug c++/84557] New: ICE with invalid firstprivate variable

[reichelt at gcc dot gnu.org]

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

Bug ID: 84557
   Summary: ICE with invalid firstprivate variable
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet (compiled with "-fopenmp") 
triggers an ICE since GCC 4.2.0:

=
template struct A {};

void foo()
{
#pragma omp parallel firstprivate (A<0>)
  ;
}
=

bug.cc: In function 'void foo()':
bug.cc:5:36: internal compiler error: in cp_parser_lookup_name, at
cp/parser.c:25974
 #pragma omp parallel firstprivate (A<0>)
^~~~
0x624d80 cp_parser_lookup_name
../../gcc/gcc/cp/parser.c:25974
0x92209a cp_parser_lookup_name_simple
../../gcc/gcc/cp/parser.c:26168
0x92209a cp_parser_omp_var_list_no_open
../../gcc/gcc/cp/parser.c:31342
0x923e5f cp_parser_omp_all_clauses
../../gcc/gcc/cp/parser.c:33723
0x93ebc8 cp_parser_omp_parallel
../../gcc/gcc/cp/parser.c:35652
0x9196bc cp_parser_omp_construct
../../gcc/gcc/cp/parser.c:38094
0x91a207 cp_parser_pragma
../../gcc/gcc/cp/parser.c:38713
0x91c7cc cp_parser_statement
../../gcc/gcc/cp/parser.c:10883
0x91d3a0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11261
0x91d477 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11215
0x933bf0 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21756
0x933bf0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21793
0x9344a0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26694
0x9351d4 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26610
0x9351d4 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19482
0x93c268 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13044
0x93d078 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12869
0x940fd2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12767
0x9413e1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12643
0x9416d4 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4559
Please submit a full bug report, [etc.]

[Bug debug/83917] [8 Regression] with -mcall-ms2sysv-xlogues, stepping into x86 tail-call restore stub gives bad backtrace

[daniel.santos at pobox dot com]

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

--- Comment #5 from Daniel Santos  ---
(In reply to Jakub Jelinek from comment #4)
> Patch posted: http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01294.html

My apologies on dropping the ball here and thanks for picking it up! :)

[Bug c++/84556] New: C++17, lambda, OpenMP simd: sorry, unimplemented: unexpected AST

[bisqwit at iki dot fi]

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

Bug ID: 84556
   Summary: C++17, lambda, OpenMP simd: sorry, unimplemented:
unexpected AST
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

This code generates an AST error when compiled with -std=c++17 -fopenmp.

void foo()
{
auto keymaker = [](void)
{
#pragma omp simd
for(unsigned pos = 0; pos < 4; ++pos)
{
}
};
}

test.cc: In lambda function:
test.cc:9:5: sorry, unimplemented: unexpected AST of kind omp_simd
 };
 ^
test.cc:9: confused by earlier errors, bailing out

Compiling without -fopenmp, or using an earlier standard mode such as
-std=c++14 or -std=c++11, the error is not produced.

Tested on: g++-7 (Debian 7.2.0-19) 7.2.0
Tested on: g++-7 (Debian 7.2.0-18) 7.2.0
Tested on: g++-7.1 (GCC) 7.1.0

Problem does NOT occur on:
g++-6 (Debian 6.4.0-11) 6.4.0 20171206

Problem does NOT occur with #pragma omp parallel for.

[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues

[dominiq at lps dot ens.fr]

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

--- Comment #37 from Dominique d'Humieres  ---
Created attachment 43500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43500=edit
Failures with -fdefault-integer-8 at revision r257969

[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues

[dominiq at lps dot ens.fr]

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

--- Comment #36 from Dominique d'Humieres  ---
New summaries of failures with -fdefault-integer-8 at revision r257969

=== gfortran Summary for unix/-m32/-fdefault-integer-8 ===

# of expected passes41549
# of unexpected failures1357
# of expected failures  56
# of unresolved testcases   183
# of unsupported tests  553


=== gfortran Summary for unix/-m64/-fdefault-integer-8 ===

# of expected passes42229
# of unexpected failures936
# of expected failures  56
# of unresolved testcases   182
# of unsupported tests  432

[v3 PATCH] Implement the missing bits of LWG 2769

[Ville Voutilainen]

Tested partially on Linux-x64, will test with the full suite on Linux-PPC64.
Ok for trunk and the gcc-7 branch? This is theoretically a breaking change
for the branch, but the committee has decided that they don't want
the support for copyable-but-not-movable types.

2018-02-25  Ville Voutilainen  

Implement the missing bits of LWG 2769
* include/std/any (any_cast(const any&)): Add static_assert.
(any_cast(any&)): Likewise.
(any_cast(any&&)): Likewise, and remove the handling
for copyable-but-not-movable type.
* testsuite/20_util/any/misc/any_cast.cc: Adjust.
* testsuite/20_util/any/misc/any_cast_neg.cc: Likewise, and
add new tests.
diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index 466b7ca..e0aba3c 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -455,6 +455,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   static_assert(any::__is_valid_cast<_ValueType>(),
  "Template argument must be a reference or CopyConstructible type");
+  static_assert(is_constructible_v<_ValueType,
+   const _AnyCast<_ValueType>&>,
+ "Template argument must be constructible from a const value.");
   auto __p = any_cast<_AnyCast<_ValueType>>(&__any);
   if (__p)
return static_cast<_ValueType>(*__p);
@@ -478,34 +481,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   static_assert(any::__is_valid_cast<_ValueType>(),
  "Template argument must be a reference or CopyConstructible type");
+  static_assert(is_constructible_v<_ValueType,
+   _AnyCast<_ValueType>&>,
+ "Template argument must be constructible from an lvalue.");
   auto __p = any_cast<_AnyCast<_ValueType>>(&__any);
   if (__p)
return static_cast<_ValueType>(*__p);
   __throw_bad_any_cast();
 }
 
-  template::value
-  || is_lvalue_reference<_ValueType>::value,
-  bool>::type = true>
-inline _ValueType any_cast(any&& __any)
-{
-  static_assert(any::__is_valid_cast<_ValueType>(),
- "Template argument must be a reference or CopyConstructible type");
-  auto __p = any_cast<_AnyCast<_ValueType>>(&__any);
-  if (__p)
-   return static_cast<_ValueType>(*__p);
-  __throw_bad_any_cast();
-}
-
-  template::value
-  && !is_lvalue_reference<_ValueType>::value,
-  bool>::type = false>
+  template
 inline _ValueType any_cast(any&& __any)
 {
   static_assert(any::__is_valid_cast<_ValueType>(),
  "Template argument must be a reference or CopyConstructible type");
+  static_assert(is_constructible_v<_ValueType,
+   _AnyCast<_ValueType>>,
+ "Template argument must be constructible from an rvalue.");
   auto __p = any_cast<_AnyCast<_ValueType>>(&__any);
   if (__p)
return static_cast<_ValueType>(std::move(*__p));
diff --git a/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc 
b/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc
index 45d8b63..37a24d7 100644
--- a/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc
+++ b/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc
@@ -95,15 +95,6 @@ void test03()
   VERIFY(move_count == 1);
   MoveEnabled&& m3 = any_cast(any(m));
   VERIFY(move_count == 1);
-  struct MoveDeleted
-  {
-MoveDeleted(MoveDeleted&&) = delete;
-MoveDeleted() = default;
-MoveDeleted(const MoveDeleted&) = default;
-  };
-  MoveDeleted md;
-  MoveDeleted&& md2 = any_cast(any(std::move(md)));
-  MoveDeleted&& md3 = any_cast(any(std::move(md)));
 }
 
 void test04()
diff --git a/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc 
b/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc
index 50a9a67..08da07d 100644
--- a/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/any/misc/any_cast_neg.cc
@@ -20,11 +20,26 @@
 
 #include 
 
+using std::any;
+using std::any_cast;
+
 void test01()
 {
-  using std::any;
-  using std::any_cast;
-
   const any y(1);
-  any_cast(y); // { dg-error "invalid static_cast" "" { target { *-*-* } 
} 460 }
+  any_cast(y); // { dg-error "invalid static_cast" "" { target { *-*-* } 
} 463 }
+  // { dg-error "Template argument must be constructible from a const value" 
"" { target { *-*-* } } 458 }
+}
+
+void test02()
+{
+  any y(1);
+  any_cast(y);
+  // { dg-error "Template argument must be constructible from an lvalue" "" { 
target { *-*-* } } 484 }
+}
+
+void test03()
+{
+  any y(1);
+  any_cast(std::move(y));  // { dg-error "invalid static_cast" "" { 
target { *-*-* } } 503 }
+  // { dg-error "Template argument must be constructible from an rvalue" "" { 
target { *-*-* } } 498 }
 }

[Bug tree-optimization/84555] strncpy warnings (and friends) are not ignorable with pragmas when inlined

[romain.geissler at amadeus dot com]

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

--- Comment #1 from Romain Geissler  ---
This example emits:

error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output
truncated before terminating nul copying 3 bytes from a string of the same
length [-Werror=stringop-truncation]
 return __builtin_strncpy(dest, source, size);
~^~~~
cc1plus: all warnings being treated as errors


while one would expect that no warning is emitted here.

[Bug tree-optimization/84555] New: strncpy warnings (and friends) are not ignorable with pragmas when inlined

[romain.geissler at amadeus dot com]

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

Bug ID: 84555
   Summary: strncpy warnings (and friends) are not ignorable with
pragmas when inlined
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

I have hit this case today. Let's consider that for any reason, you have a
wrapper around strncpy (and friends). Then it looks like that #pragma diagnotic
that are used around the call site of the wrapper are ignored in -O2 when gcc
does some inlining.

Example (built with -Wall -Werror -Wextra -O2):

<

[Bug bootstrap/84554] New: make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

[kdevel at vogtner dot de]

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

Bug ID: 84554
   Summary: make check: FAIL: tversion: ERROR! The versions of
gmp.h (5.0.5) and libgmp (4.3.1) do not match.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kdevel at vogtner dot de
  Target Milestone: ---

OS: centos 6.9 (X86_64)
expect: installed
dejagnu: NOT installed

N=3
langs=ada,c,c++,fortran,go,objc,obj-c++

tar xf $src/gcc-7.3.0.tar.xz
cd gcc-7.3.0
tar xfj $src/gmp-5.0.5.tar.bz2
mv gmp-5.0.5 gmp
tar xfz $src/mpc-1.0.1.tar.gz
mv mpc-1.0.1 mpc
tar xfj $src/mpfr-3.1.5.tar.bz2
mv mpfr-3.1.5 mpfr
tar xfj $src/isl-0.18.tar.bz2
mv isl-0.18 isl
cd ..
mkdir gcc-objdir
cd gcc-objdir
../gcc-7.3.0/configure --prefix=$inst --enable-languages=$langs

make -j$N bootstrap
make check

RESULT:

make[4]: Entering directory `/.../bld-7.3.0/gcc-objdir/mpfr/tests'
make[5]: Entering directory `/.../bld-7.3.0/gcc-objdir/mpfr/tests'
FAIL: tversion   
PASS: tinternals
PASS: tinits

:

PASS: tzeta 
PASS: tzeta_ui

Testsuite summary for MPFR 3.1.5 

# TOTAL: 160
# PASS:  158
# SKIP:  1
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log

make[5]: *** [test-suite.log] Fehler 1
make[5]: Leaving directory `/bld-7.3.0/gcc-objdir/mpfr/tests'
make[4]: *** [check-TESTS] Fehler 2
make[4]: Leaving directory `/.../bld-7.3.0/gcc-objdir/mpfr/tests'
make[3]: *** [check-am] Fehler 2
make[3]: Leaving directory `/.../bld-7.3.0/gcc-objdir/mpfr/tests'
make[2]: *** [check-recursive] Fehler 1
make[2]: Leaving directory `/.../bld-7.3.0/gcc-objdir/mpfr'
make[1]: *** [check-mpfr] Fehler 2
make[1]: Leaving directory `/.../bld-7.3.0/gcc-objdir'
make: *** [do-check] Fehler 2


test-suite.log
--

==
   MPFR 3.1.5: tests/test-suite.log
==

# TOTAL: 160
# PASS:  158
# SKIP:  1
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tversion
==

ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.
The possible causes are:
  * A bad configuration in your include/library search paths.
  * An inconsistency in the include/library search paths of
your development environment; an example:
  http://gcc.gnu.org/ml/gcc-help/2010-11/msg00359.html
  * GMP has been upgraded after the first "make check".
In such a case, try again after a "make clean".
  * A new or non-standard version naming is used in GMP.
In this case, a patch may already be available on the 
MPFR web site.  Otherwise please report the problem.
In the first two cases, this may lead to errors, in particular with MPFR.
If some other tests fail, please solve that problem first.
FAIL tversion (exit status: 1)

SKIP: tget_set_d64
==

SKIP tget_set_d64 (exit status: 77)

[PATCH] rs6000: Warn for deprecated options

[Segher Boessenkool]

Some command-line options have been deprecated for a long time.  This
patch adds a warning for them, so that we can remove them in GCC 9
without surprising any users.


Segher


2018-02-25  Segher Boessenkool  

* config/rs6000/rs6000.opt (mvrsave=no, mvrsave=yes, isel=no,
isel=yes): Warn for these deprecated options.

---
 gcc/config/rs6000/rs6000.opt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.opt b/gcc/config/rs6000/rs6000.opt
index 97419ae..28c6081 100644
--- a/gcc/config/rs6000/rs6000.opt
+++ b/gcc/config/rs6000/rs6000.opt
@@ -322,11 +322,11 @@ Target Report Var(TARGET_ALTIVEC_VRSAVE) Save
 Generate VRSAVE instructions when generating AltiVec code.
 
 mvrsave=no
-Target RejectNegative Alias(mvrsave) NegativeAlias
+Target RejectNegative Alias(mvrsave) NegativeAlias Warn(%<-mvrsave=no%> is 
deprecated; use %<-mno-vrsave%> instead)
 Deprecated option.  Use -mno-vrsave instead.
 
 mvrsave=yes
-Target RejectNegative Alias(mvrsave)
+Target RejectNegative Alias(mvrsave) Warn(%<-mvrsave=yes%> is deprecated; use 
%<-mvrsave%> instead)
 Deprecated option.  Use -mvrsave instead.
 
 mblock-move-inline-limit=
@@ -350,11 +350,11 @@ Target Report Mask(ISEL) Var(rs6000_isa_flags)
 Generate isel instructions.
 
 misel=no
-Target RejectNegative Alias(misel) NegativeAlias
+Target RejectNegative Alias(misel) NegativeAlias Warn(%<-misel=no%> is 
deprecated; use %<-mno-isel%> instead)
 Deprecated option.  Use -mno-isel instead.
 
 misel=yes
-Target RejectNegative Alias(misel)
+Target RejectNegative Alias(misel) Warn(%<-misel=yes%> is deprecated; use 
%<-misel%> instead)
 Deprecated option.  Use -misel instead.
 
 mdebug=
-- 
1.8.3.1

[Bug c/84553] New: -rdynamic generates TEXTREL relocations on ia64

[slyfox at inbox dot ru]

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

Bug ID: 84553
   Summary: -rdynamic generates TEXTREL relocations on ia64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

This is a trimmed-down version of gcc compiling itself with TEXTRELs on ia64:
https://bugs.gentoo.org/566118

Minimal reproducer:

  // cat lto-lang.c 
  struct a {
int (*b)(void);
int c;
  };
  int d(void) {}
  const struct a e = { , 0, };

  int main(){}
$ LANG=C ia64-unknown-linux-gnu-gcc -O0 -no-pie -fno-PIE lto-lang.c -o
lto-lang -Wl,-z,text -rdynamic
/usr/libexec/gcc/ia64-unknown-linux-gnu/ld: read-only segment has dynamic
relocations.
collect2: error: ld returned 1 exit status

Used version:
binutils-2.30 (older 2.29 is also affected), gcc-HEAD (older 6.4.0 is also
affected)

I'm not sure who exactly is at fault here: gcc or binutils.

What happens here is:
  'const struct e' (with .text pointer) is placed into '.rodata' by gcc and
later is merged into '.text'.

What I suspect should happen:
  'const struct e' (with .text pointer) is placed into '.data.rel.ro' by gcc
and later is merged into '.data'?

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[romain.geissler at amadeus dot com]

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

--- Comment #11 from Romain Geissler  ---
Hi,

Indeed this version of the patch doesn't have any segv. However it seems that
it doesn't fix anymore the initial bug report. Does it actually passes the new
tests you introduced in your patch ?

Unless I am mistaken (I am pretty sure I have applied the patch), the following
code extracted from your tests still emit a warning with -O2

a, q->a, sizeof p->a - 1);/* { dg-bogus
"\\\[-Wstringop-truncation" } */

  p->a[sizeof p->a - 1] = 0;
}
EOF

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[ebotcazou at gcc dot gnu.org]

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

--- Comment #29 from Eric Botcazou  ---
> Never mind, it seems that gcc 5.5 is doing that as hazard_nowell. I will run
> some more tests.

Yes, the nops are preexisting and counter-measures for pipeline hazards, but I
don't know the MIPS port enough to say much more than that.

[Bug fortran/68289] Missing diagnostic pragmas

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
From  pr64273:

Tobias Burnus 2014-12-11 16:29:56 UTC

Follow up to PR44054 and PR53552. See also related bugs PR28662, PR62226,
PR53934.

There are two possibilities, either to use a real
  #pragma warning
or to make it more Fortran-like and use
  !GCC$ warning directive

See PR44054 and PR53552.

Dominique d'Humieres 2014-12-11 16:40:45 UTC

> There are two possibilities, either to use a real
>   #pragma warning
> or to make it more Fortran-like and use
>   !GCC$ warning directive


Yuck!-(I think there are a lot of really more important things to do. In any
case choose the latter).

[Bug fortran/64273] Add support for "#pragma warning" or "!GCC$ warning directive"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Mark as duplicate of pr68289.

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

[Bug fortran/68289] Missing diagnostic pragmas

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #7 from Dominique d'Humieres  ---
*** Bug 64273 has been marked as a duplicate of this bug. ***

[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-25
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Let me take a look tomorrow.

[Bug fortran/84546] [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #3)
> > This is a rather old regression, r247548 already has it.
> 
> The change occurred between revisions r241509 (2016-10-25,OK) and r241635
> (2016-10-27, STOP), r241528 (pr72770)?

r241528 fails, r241527 does not, so rr241528 it is.

Re: $target.h vs $target-protos.h

[Georg-Johann Lay]

Sandra Loosemore schrieb:
The internals manual says that a backend for $target should have 
$target.h and $target-protos.h files, but doesn't say what the 
difference between them is or what belongs in which file.  Current 
practice seems to be a mix of


(1) $target.h contains macro definitions and $target-protos.h contains 
extern declarations.


(2) $target.h defines the external interface to the backend (the macros 
documented in the internals manual) and $target-protos.h contains things 
shared between $target.c and the various .md files.


But some generic source files include $target.h only and some source 
files include both, which wouldn't be true if either of the above models 
applied.  So is there some other logical way to explain the difference 
and what goes where?


IIRC, one difference is scanning for GTY markers used to tag ggc roots: 
$target.h is scanned whereas $target-protos.h is not (and AFAIR adding 
$target-protos.h in config.gcc to the files being scanned pops up other 
problems). Hence when you have a target-specific GTYed structure that's 
shared by several back-end modules, you'd add the struct definition to 
$target.h (If only one module needs such objects, then you'd add the 
type definition to, say, $target.c which is scanned — or can be rendered 
to a scanned one by adjusting config.gcc).


The bulk of code is not GTYed, of course, and from my experience the 
usage of the mentioned files is like you summarized: $target-protos.h is 
usually a blob of prototypes used internally to communicate within a 
back-end, whereas $target.h "defines" the backend part that's not yet 
hookized, e.g. the TARGET_ macros that define (initializers for) 
register classes etc.


And the usage in libgcc might be different: $target.h is used in libgcc 
(which is the reason for why $target.h might need runtime library 
exceptions, cf. PR61152: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152#c0 ) Ideally, all 
information needed by libgcc and other target libraries would be shipped 
by built-in macros, but such complete separation from compiler sources 
from libgcc sources is not yet complete to the best of my knowledge. 
$target-protos.h (via tm_p.h), however, is not used by libgcc.


Johann

The thing that got me thinking about this is looking at a new port 
originally written by a customer, where it seems like there is too much 
stuff in $target.h.  Then I started chasing it down


- FUNCTION_BOUNDARY depends on which arch variant is being compiled for

- Its expansion references some internal target data structures and 
enumerators to look up that info


- The default definition of TARGET_PTRMEMFUNC_VBIT_LOCATION uses 
FUNCTION_BOUNDARY


- ipa-prop.c uses TARGET_PTRMEMFUNC_VBIT_LOCATION but doesn't include 
$target-protos.h


- tree.c also uses FUNCTION_BOUNDARY directly without including 
$target-protos.h


- Probably there are many other target macros that potentially have 
similar issues


- Presumably this means everything referenced in the expansion of any 
target macro in $target.h also needs to be declared in $target.h and not 
depend on $target-protos.h also being included at the point of use.


So what is the purpose of having a separate $target-protos.h?

-Sandra the confused

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[nbd at nbd dot name]

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

--- Comment #28 from Felix Fietkau  ---
Never mind, it seems that gcc 5.5 is doing that as well. I will run some more
tests.

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[nbd at nbd dot name]

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

--- Comment #27 from Felix Fietkau  ---
On the original test case, it generates this code:

00400690 :
  400690:   8c830008lw  v1,8(a0)
  400694:   24020001li  v0,1
  400698:   10620011beq v1,v0,4006e0 
  40069c:   nop
  4006a0:   8c83lw  v1,0(a0)
  4006a4:   nop
  4006a8:   28630002sltiv1,v1,2
  4006ac:   106abeqzv1,4006d8 
  4006b0:   nop
  4006b4:   8c82000clw  v0,12(a0)
  4006b8:   nop
  4006bc:   8c42lw  v0,0(v0)
  4006c0:   nop
  4006c4:   00a2182bsltuv1,a1,v0
  4006c8:   1467bnezv1,4006e8 
  4006cc:   nop
  4006d0:   0045102bsltuv0,v0,a1
  4006d4:   00021023neguv0,v0
  4006d8:   03e8jr  ra
  4006dc:   nop
  4006e0:   03e8jr  ra
  4006e4:   2402li  v0,-1
  4006e8:   03e8jr  ra
  4006ec:   24020001li  v0,1

It looks to me like it's generating lots of useless nop instructions after lw

[Bug c++/84461] [8 regression] openjdk-10 fails to build

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |8.0
   Severity|normal  |critical

[Bug target/84522] GCC does not generate cmpxchg16b when mcx16 is used

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Andrew Pinski  ---
Dup of bug 80878.

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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||nruslan_devel at yahoo dot com

--- Comment #10 from Andrew Pinski  ---
*** Bug 84522 has been marked as a duplicate of this bug. ***

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #43497|0   |1
is obsolete||

--- Comment #26 from Eric Botcazou  ---
Created attachment 43499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43499=edit
Second tentative fix

Adjusted for second testcase but still to be tested.

[Bug target/84547] Suboptimal code for masked shifts (ARM64)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||aarch64*-*
   Severity|normal  |enhancement

[Bug tree-optimization/84552] [8 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
   Target Milestone|--- |8.0

[Bug target/45996] -falign-functions=X does not work

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
Most targets check if -falign-* is already set before messing with it at -Os.

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[ebotcazou at gcc dot gnu.org]

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

--- Comment #25 from Eric Botcazou  ---
> /var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/
> reorg.c:3895
> 
> Line 1787 in reorg.c is this piece of code:
> if (REG_NOTE_KIND (link) != REG_DEAD
> || !REG_P (XEXP (link, 0)))
>   continue;

Weird, this looks like some ill-formed REG_DEAD note.  I'll try to reproduce on
SPARC tomorrow.

[Bug tree-optimization/84552] New: [8 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon

[asolokha at gmx dot com]

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

Bug ID: 84552
   Summary: [8 Regression] Compile time hog w/ -O2
-floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre
-fno-tree-loop-ivcanon
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20180218 snapshot (r257797) takes indefinite time to compile the
following snippet w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre
-fno-tree-loop-ivcanon:

int cx;

int
e6 (int pj, int xe)
{
  for (cx = 0; cx < 2; ++cx)
while (xe < 1)
  {
for (cx = 0; cx < 2; ++cx)
  pj *= 2;

if (cx != 0)
  goto o3;

++xe;
  }

 o3:
  return pj;
}

% timeout 5 gcc-8.0.0-alpha20180218 -O2 -floop-nest-optimize
-fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon -c v8gjilr7.c
zsh: exit 124   timeout 5 gcc-8.0.0-alpha20180218 -O2 -floop-nest-optimize
-fno-tree-copy-pro

Two outstanding entries captured by perf top:

  61.24%  cc1   [.] degenerate_phi_result
  38.49%  cc1   [.] follow_copies_to_constant

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[nbd at nbd dot name]

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

--- Comment #24 from Felix Fietkau  ---
Created attachment 43498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43498=edit
Test case for internal compiler error (musl source file)´

When I test it with a patched gcc 7.3.x, I get this error on compiling remquo.c
from musl with: -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc
-fno-caller-saves -fno-plt -msoft-float

remquo.c: In function 'remquo':
remquo.c:82:1: internal compiler error: Segmentation fault
 }
 ^
0x9dd06f crash_signal
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/toplev.c:337
0x9797f8 fix_reg_dead_note
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:1787
0x97e409 relax_delay_slots
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3231
0x97e409 dbr_schedule
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3723
0x97e409 rest_of_handle_delay_slots
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3864
0x97e409 execute
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3895

Line 1787 in reorg.c is this piece of code:
if (REG_NOTE_KIND (link) != REG_DEAD
|| !REG_P (XEXP (link, 0)))
  continue;

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

--- Comment #14 from kargl at gcc dot gnu.org ---
Fixed of 6-branch, 7-branch, and trunk.
Thanks for bug reports.

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

--- Comment #13 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #11)
> > *** Bug 69420 has been marked as a duplicate of this bug. ***
> 
> Yes, but what about pr69419?

What about it?  It is unrelated.

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

--- Comment #12 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Feb 25 17:32:36 2018
New Revision: 257974

URL: https://gcc.gnu.org/viewcvs?rev=257974=gcc=rev
Log:
2018-02-25  Steven G. Kargl  

PR fortran/83633
* decl.c (variable_decl): Check that an explicit-shape-array with
nonconstant bounds is allowed.

2018-02-25  Steven G. Kargl  

PR fortran/83633
* gfortran.dg/explicit_shape_1.f90: New test.
* gfortran.dg/automatic_module_variable.f90: Update regex.
* gfortran.dg/bad_automatic_objects_1.f90: Ditto.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/explicit_shape_1.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
   
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/automatic_module_variable.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/bad_automatic_objects_1.f90

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> *** Bug 69420 has been marked as a duplicate of this bug. ***

Yes, but what about pr69419?

[Bug fortran/69420] ICE: tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:5618

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
This is essentially a duplicate of 83633 where much more
detail is given for the fix.  Mark it as dup even though
this PR came first.

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

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #10 from kargl at gcc dot gnu.org ---
*** Bug 69420 has been marked as a duplicate of this bug. ***

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Feb 25 17:08:51 2018
New Revision: 257972

URL: https://gcc.gnu.org/viewcvs?rev=257972=gcc=rev
Log:
2018-02-25  Steven G. Kargl  

PR fortran/83633
* decl.c (variable_decl): Check that an explicit-shape-array with
nonconstant bounds is allowed.

2018-02-25  Steven G. Kargl  

PR fortran/83633
* gfortran.dg/explicit_shape_1.f90: New test.
* gfortran.dg/automatic_module_variable.f90: Update regex.
* gfortran.dg/bad_automatic_objects_1.f90: Ditto.
* gfortran.dg/constant_shape.f90: Ditto.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/explicit_shape_1.f90
Modified:
branches/gcc-7-branch/gcc/fortran/decl.c
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/automatic_module_variable.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/bad_automatic_objects_1.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/constant_shape.f90

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[ebotcazou at gcc dot gnu.org]

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

--- Comment #23 from Eric Botcazou  ---
Created attachment 43497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43497=edit
Tentative fix

To be tested.

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Feb 25 16:50:50 2018
New Revision: 257971

URL: https://gcc.gnu.org/viewcvs?rev=257971=gcc=rev
Log:
2018-02-25  Steven G. Kargl  

PR fortran/83633
* decl.c (variable_decl): Check that an explicit-shape-array with
nonconstant bounds is allowed.

2018-02-25  Steven G. Kargl  

PR fortran/83633
* gfortran.dg/explicit_shape_1.f90: New test.
* gfortran.dg/automatic_module_variable.f90: Update regex.
* gfortran.dg/bad_automatic_objects_1.f90: Ditto.
* gfortran.dg/constant_shape.f90: Ditto.
* gfortran.dg/dec_structure_23.f90: Ditto.
* gfortran.dg/pr78240.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/explicit_shape_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/automatic_module_variable.f90
trunk/gcc/testsuite/gfortran.dg/bad_automatic_objects_1.f90
trunk/gcc/testsuite/gfortran.dg/constant_shape.f90
trunk/gcc/testsuite/gfortran.dg/dec_structure_23.f90
trunk/gcc/testsuite/gfortran.dg/pr78240.f90

[Bug c++/84434] [8 Regression] internal compiler error: tree check: expected var_decl or field_decl or function_decl or type_decl or template_decl, have using_decl in build_deduction_guide, at cp/pt.c

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||nathan at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

[Bug fortran/84523] [8 Regression] Runtime crash deallocating allocatable array within derived type

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
For the record:

> Caused by revision r257065.

> Quite why this testcase worked before revision r257065 I cannot for the life
> of me understand.

Actually I think this was exposed by r257065 but caused by r251949.

The following variant is OK with r251946

program gfcbug148
  implicit none
  type t_spot
real, allocatable :: vm(:,:,:)
  end type t_spot
  type t_rowcol
integer   :: nh
type(t_spot), pointer :: spots(:) =>NULL()
  end type t_rowcol
  type(t_rowcol)  :: col
  call construct (col, 80)
  call destruct  (col)
  print *, "OK"
  !
contains
  !
  subroutine construct (rc, nh)
type(t_rowcol) ,intent(out) :: rc   ! row or column to set
integer,intent(in)  :: nh   ! number of spots in a row
rc% nh = nh
allocate (rc% spots (nh))
  end subroutine construct
  !
  subroutine destruct (rc)
type(t_rowcol) ,intent(inout) :: rc   ! row or column to free
integer :: k
if (associated (rc% spots)) then
  print *, "### destruct: size(rc% spots)=", size(rc% spots)
  if (size(rc% spots) > 1) then
print *, "### destruct: allocated (vm) =", allocated(rc%spots(1)%vm)
  end if
  print *, size(rc% spots)
  do k=1, size(rc% spots)
print *, k, allocated (rc% spots(k)% vm)
  end do
  print *, "before deallocate"
endif
nullify (rc% spots)
  end subroutine destruct
end program gfcbug148

but gives with r251980

 ### destruct: size(rc% spots)=  80
 ### destruct: allocated (vm) = F
  80
   1 F

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

when compiled with -fsanitize=undefined.

[Bug target/70713] msp430 interrupt attribute prevents overriding weak symbols

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Eric Gallager  ---
(In reply to Joe Seymour from comment #5)
> Thanks for chasing.
> 
> From my point of view, yes the committed patch makes all the changes
> required for this bug to be considered resolved, however I don't have
> permission to make those changes myself.
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00758.html
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00767.html

OK, closing as FIXED then.

[Bug fortran/84546] [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P4
 CC||vehre at gcc dot gnu.org
  Known to work||6.4.0
  Known to fail||7.3.0, 8.0

--- Comment #3 from Dominique d'Humieres  ---
> This is a rather old regression, r247548 already has it.

The change occurred between revisions r241509 (2016-10-25,OK) and r241635
(2016-10-27, STOP), r241528 (pr72770)?

[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154

[dimhen at gmail dot com]

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

--- Comment #1 from Dmitry G. Dyachenko  ---
r257859 build w/o --enable-checking=extra FAIL too

[Bug testsuite/70516] Regtesting acats hangs on x86_64-apple-darwin15.4

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Dominique d'Humieres  ---
> AFAICT this seems related to the current state of my system, thus I am 
> removing
> the regression marker and setting the status to SUSPENDED (allow me for
> some time before closing this PR as INVALID).

Closing as INVALID.

[Bug c++/84551] New: [8 Regression] [concepts] Compiler options "-O -g" cause valid code to be rejected

[reichelt at gcc dot gnu.org]

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

Bug ID: 84551
   Summary: [8 Regression] [concepts] Compiler options "-O -g"
cause valid code to be rejected
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet (compiled with "-fconcepts -g -O")
is wrongly rejected and triggers an ICE on trunk:

===
template concept bool C() { return true; }

template