[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[jan at jki dot io]

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

--- Comment #9 from Jan  ---
I'm using the clear linux gcc version well atleast the patches.
Maybe thats the culprit.
https://clearlinux.org/

But it should be easy to run that in a container.
I reverted some of the patches and rebuild gcc.
I will report if that solved the problem an what patch made the problems.

[Bug libstdc++/85768] [9 Regression] FreeBSD bootstrap fails due to undefined reference to 'backtrace'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

--- Comment #1 from Richard Biener  ---
Hmm, I think we are supposed to use libbacktrace instead?

[Bug target/85769] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2205 for -mcpu=thunderx

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.2

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[jan at jki dot io]

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

--- Comment #4 from Jan  ---
Created attachment 44127
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44127=edit
preproccessed source and gcda

[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type

[glisse at gcc dot gnu.org]

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

--- Comment #22 from Marc Glisse  ---
(In reply to rguent...@suse.de from comment #21)
> Note that in the strict C semantic thing __restrict on
> this isn't valid as the following is valid C++:
> 
> Foo() __restrict
> {
>   Foo *x = this;
>   x->a = 1;
>   this->a = 2;
> ...
> }
> 
> but for C restrict you'd have two pointers with same provenance here.


How is that different from the C

void Foo_const(Foo*const restrict t)
{
  Foo *x = t;
  x->a = 1;
  t->a = 2;
}

, which seems valid to me?

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Richard Biener from comment #2)
> Please attach the preprocessed source.

And profile file (*.gcda) that should be somewhere:
find /var/tmp/portage/pgo/bash -name alias.gcda

[Bug c++/85761] [8/9 Regression] ICE on invalid in rtl with uncaptured constexpr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||7.3.1
   Keywords||accepts-invalid,
   ||ice-on-invalid-code
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1
Summary|ICE on invalid in rtl with  |[8/9 Regression] ICE on
   |uncaptured constexpr|invalid in rtl with
   ||uncaptured constexpr
   Target Milestone|--- |8.2

--- Comment #1 from Richard Biener  ---
Confirmed.  If the code is really invalid then we also accept it without
diagnostic in GCC 7.

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #21 from Xi Ruoyao  ---
I made up a (highly immature) patch in the days.

This "thing" works with simple source code files but I believe there are many
bugs in the patch.

And I suggest to make "weakref" attribute to output ".symver" directive for
arguments with "@" in it.  For e.g.

static void *old_memcpy (void *, void *, size_t)
__attribute__((weakref("memcpy@GLIBC_2.2.5")));

should produce

.symver old_memcpy memcpy@GLIBC_2.2.5

So we can "import" old functions.

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to Jan from comment #9)
> I'm using the clear linux gcc version well atleast the patches.
> Maybe thats the culprit.
> https://clearlinux.org/

I thought you are using Gentoo system?

> 
> But it should be easy to run that in a container.

Can you please help me with that?

> I reverted some of the patches and rebuild gcc.
> I will report if that solved the problem an what patch made the problems.

OK, let's wait then for it.

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #6 from Martin Liška  ---
Hm, it's somehow corrupted profile:

$ cov-dump-8 alias.gcda | head
alias.gcda:data:magic `gcda':version `A81*'
alias.gcda:stamp 1570461131
alias.gcda:  a300: 212:PROGRAM_SUMMARY checksum=0xbcd4b386
alias.gcda:counts=34022, runs=0, sum_all=64330, run_max=3152,
sum_max=3152
alias.gcda:counter histogram:
alias.gcda: 0: num counts=32358, min counter=0, cum_counter=0
alias.gcda: 1: num counts=670, min counter=1, cum_counter=670
alias.gcda: 2: num counts=336, min counter=2, cum_counter=672
alias.gcda: 3: num counts=155, min counter=3, cum_counter=465
alias.gcda: 4: num counts=38, min counter=4, cum_counter=152

we can't have runs=0 :/
Jan is it reproducible? Can you please test adding this option:
-fprofile-update=atomic
?

[Bug c++/85747] suboptimal code without constexpr

[antoshkka at gmail dot com]

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

--- Comment #7 from Antony Polukhin  ---
(In reply to Jakub Jelinek from comment #6)
> IMHO just use constexpr if you care about compile time evaluation
> guarantees, that is what it has been added for.

Fair point. Overcomplicated logic on the frontend does not seem right. But from
my (not experienced) point of view there are some low hanging fruits here.

I assume that frontend uses some kind of `__builtin_constant_p` to distinguish
between constexpr evaluation or not. Adjusting that function slightly could
produce better code out of the box on some optimization levels:

static int generate() {
int a[7] = {3, 7, 4, 2, 8, 0, 1};
static_assert(
__builtin_constant_p(a + 0),
"Immediate usage of variable initialized by constant should be a
constant expression"
);
sort(a + 0, a + 7); // __builtin_constant_p returns `true` => constexpr
call
static_assert(
__builtin_constant_p(a + 0),
"Value after constexpr function call should be a constant"
);
return a[0] + a[6];
}

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[jan at jki dot io]

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

--- Comment #7 from Jan  ---
I added  the option same ICE.

[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de  ---
On Sat, 12 May 2018, glisse at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
> 
> --- Comment #20 from Marc Glisse  ---
> Created attachment 44122
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44122=edit
> untested middle-end patch
> 
> This works on the testcase, I need to add a comment and run it through the
> testsuite.

Looks good.  Note that in the strict C semantic thing __restrict on
this isn't valid as the following is valid C++:

Foo() __restrict
{
  Foo *x = this;
  x->a = 1;
  this->a = 2;
...
}

but for C restrict you'd have two pointers with same provenance here.

The middle-end handles this situation conservatively and thus the
middle-end approach of effectively handling it as restrict is fine.

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #22 from Xi Ruoyao  ---
Created attachment 44126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44126=edit
Patch to add symver attribute, highly experimental, C++ only

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Please attach the preprocessed source.

[Bug middle-end/85751] RFE: option to align code using breakpoint instructions when unreachable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So there's cases where there is no padding - are you suggesting a way to
reliably insert traps at unreachable () points or just taking advantage of
existing padding?

Confirmed.

[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P2
 CC||mjambor at suse dot cz
  Known to work||7.3.1
   Target Milestone|--- |8.2

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[marxin at gcc dot gnu.org]

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

--- Comment #23 from Martin Liška  ---
(In reply to Xi Ruoyao from comment #22)
> Created attachment 44126 [details]
> Patch to add symver attribute, highly experimental, C++ only

That's great you did the prototype. I'll take a look.

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #5 from Martin Liška  ---
(In reply to Jan from comment #4)
> Created attachment 44127 [details]
> preproccessed source and gcda

Thanks, I can reproduce that, so I'm going to debug that.

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Hi Jan.
Interesting ICE. Well I've just tried your set of options for openSUSE package
(where we use PGO). But it works fine.
Can you please provide a bash script that will do the build for me? Would it be
possible to extract from an ebuild package file?

[Bug target/85767] [9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 64-bit mode (not in 32-bit mode)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Liška  ---
Also started with r260045, thus probably dup of PR85756.

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

[Bug target/85756] [9 regression] wrong code at -Os on x86-64-linux-gnu in 32-bit mode

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
*** Bug 85767 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/85758] questionable bitwise folding (missing single use check?)

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
(In reply to Alexander Monakov from comment #0)
> However since m_3 is used, this is more costly. Shouldn't this folding check
> for single use of the intermediate expr? From a quick look, this is probably
> match.pd:/* Fold (X & Y) ^ Y and (X ^ Y) & Y as ~X & Y.  */

Just as a note I'd consider ~X & Y cheaper canonicalization-wise because it
has one unary and one binary op vs two binary ones.

Yes, this is probably a candidate for :s

With the current :s semantics :s should eventually be applied automagically by
genmatch.  Note that given match.pd patterns cannot rely on immediate uses
being up-to-date all this is fragile heuristics anyways...

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
(In reply to Jan from comment #7)
> I added  the option same ICE.

I see. Well would it be possible to provide build steps that will utilize a
gentoo docker container and can help me to reproduce that?

[Bug tree-optimization/85757] tree optimizers fail to fully clean up fixed-size memcpy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||kugan at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
This is the failure to handle non-aliasing stores.  We get it recorded here:

  /* If this is a store, remember it or bail out if we have
 multiple ones (the will be in different CFG parts then).  */
  else if (gimple_vdef (use_stmt))
{
  if (temp)
{
  fail = true;
  BREAK_FROM_IMM_USE_STMT (ui);
}
  temp = use_stmt;
}

but that's necessary for the walking algorithm.  Basically PHI handling was
added for a few ad-hoc cases.

diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index 9220fea7f2e..ab5aa5bb314 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -569,7 +569,8 @@ dse_classify_store (ao_ref *ref, gimple *stmt, gimple
**use_stmt,
 See gcc.c-torture/execute/20051110-*.c.  */
  else if (gimple_code (use_stmt) == GIMPLE_PHI)
{
- if (temp
+ if ((temp
+  && stmt_may_clobber_ref_p_1 (temp, ref))
  /* Make sure we are not in a loop latch block.  */
  || gimple_bb (stmt) == gimple_bb (use_stmt)
  || dominated_by_p (CDI_DOMINATORS,

"solves" half of it.  But the above snipped needs similar treatment for
the case of temp being the PHI.

Basically a more programatical approach of walking the individual paths
into the PHI node is required which, for clarity, should require
refactoring of the walk.  walk_nonaliased_vuses and friends may or may not
be a good copying source.

[Bug target/85769] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2205 for -mcpu=thunderx

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||ktkachov at gcc dot gnu.org,
   ||tnfchris at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Looks to me like r250673.
The
+   fmov\\t%h0, %w1

alternative that was added needs Armv8.2-A, which is not present on
-mcpu=thunderx

[Bug target/85769] New: ICE in extract_constrain_insn, at recog.c:2205 for -mcpu=thunderx

[marxin at gcc dot gnu.org]

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

Bug ID: 85769
   Summary: ICE in extract_constrain_insn, at recog.c:2205 for
-mcpu=thunderx
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: pinskia at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: aarch64-linux-gnu

Following ICEs:

$ aarch64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/f16_mov_immediate_1.c
-mcpu=thunderx
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/f16_mov_immediate_1.c:
In function ‘f4’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/f16_mov_immediate_1.c:38:1:
error: insn does not satisfy its constraints:
 }
 ^
(insn 36 33 40 2 (set (reg:HF 32 v0 [orig:91  ] [91])
(reg:HF 0 x0 [orig:90 _8 ] [90]))
"/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/f16_mov_immediate_1.c":37
51 {*movhf_aarch64}
 (nil))
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/f16_mov_immediate_1.c:38:1:
internal compiler error: in extract_constrain_insn, at recog.c:2205
0x59ac3d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.././../gcc/rtl-error.c:108
0x59ac66 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
.././../gcc/rtl-error.c:118
0xb23c3d extract_constrain_insn(rtx_insn*)
.././../gcc/recog.c:2205
0xa283b7 check_rtl
.././../gcc/lra.c:2156
0xa2db79 lra(_IO_FILE*)
.././../gcc/lra.c:2590
0x9e0d31 do_reload
.././../gcc/ira.c:5465
0x9e0d31 execute
.././../gcc/ira.c:5649

[Bug target/85756] [9 regression] wrong code at -Os on x86-64-linux-gnu in 32-bit mode

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-*-*, i?86-*-*
   Priority|P3  |P1

[Bug c++/85764] [8/9 Regression] bogus ‘this’ was not captured for this lambda function error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |8.2
Summary|bogus ‘this’ was not|[8/9 Regression] bogus
   |captured for this lambda|‘this’ was not captured for
   |function error  |this lambda function error

[Bug c++/85765] [8/9 Regression] Missing SFINAE in default template argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.2

[Bug rtl-optimization/85745] variable with asm register assignment allocated in wrong reg

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
just in case someone runs into the same issue, this would
be the linux patch that Jakub suggested:

commit 20dfb4d2eb648bd947adbb729d963f78df75ffee
Author: Bernd Edlinger 
Date:   Fri May 11 18:51:03 2018 +0200

Fix compilation with gcc-8

diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 74b17d0..dc64fa2 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -220,7 +220,7 @@ extern int __put_user_8(void *, unsigned long long);
({  \
unsigned long __limit = current_thread_info()->addr_limit - 1;
\
const typeof(*(p)) __user *__tmp_p = (p);   \
-   register const typeof(*(p)) __r2 asm("r2") = (x);   \
+   register typeof(*(p)) __r2 asm("r2") = (x); \
register const typeof(*(p)) __user *__p asm("r0") = __tmp_p; \
register unsigned long __l asm("r1") = __limit; \
register int __e asm("r0"); \

[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type

[rguenther at suse dot de]

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

--- Comment #23 from rguenther at suse dot de  ---
On Mon, 14 May 2018, glisse at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
> 
> --- Comment #22 from Marc Glisse  ---
> (In reply to rguent...@suse.de from comment #21)
> > Note that in the strict C semantic thing __restrict on
> > this isn't valid as the following is valid C++:
> > 
> > Foo() __restrict
> > {
> >   Foo *x = this;
> >   x->a = 1;
> >   this->a = 2;
> > ...
> > }
> > 
> > but for C restrict you'd have two pointers with same provenance here.
> 
> 
> How is that different from the C
> 
> void Foo_const(Foo*const restrict t)
> {
>   Foo *x = t;
>   x->a = 1;
>   t->a = 2;
> }
> 
> , which seems valid to me?

it accesses the object pointed-to by the restrict qualified pointer
via an lvalue that is not based on it in my reading of C11 6.7.3.1/3
(though "some" sequence point sounds like that being x = t makes it
valid based on).  Otherwise for restrict to be usable by a compiler
it would need to perform conservative pointer propagation.  Like

void Foo(Foo **x, Foo * restrict t)
{
  *x = t;
  t->a = 1;
  (*x)->a = 2;
}

or with Foo *baz(Foo *);

 Foo *x = baz(t);
 t->a = 1;
 x->a = 2;

if x and t point to the same object my reading of the standard
says thats undefined (GCC of course treats it conservatively instead).

[Bug libstdc++/84118] filesystem::path concat does not accept value_type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Ethan Smith from comment #0)
> As I have read the filesystem TS, I believe concat on path items should have
> an overload following:
> 
> path& operator+=(value_type x);

It does have that overload.

> However, on trying to use 7.2.0 this overload seems not to work correctly.
> 
> https://wandbox.org/permlink/S4DZ3witD15xz0lT

But you're using path::concat(value_type) not path::operator+=(value_type).

> TL;DR it would allow for constructs such as
> .concat(fs::path::preferred_separator)

No it wouldn't, because that uses concat, not operator+=

[Bug libstdc++/85772] New: __gnu_cxx::__versa_string doesn't support C++11 allocators

[redi at gcc dot gnu.org]

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

Bug ID: 85772
   Summary: __gnu_cxx::__versa_string doesn't support C++11
allocators
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This would be useful to support, for people who want a COW string type when
using the cxx11 ABI (so can't use std::string).

[Bug libstdc++/85773] New: Embedded nulls in filesystem::path cause problems

[redi at gcc dot gnu.org]

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

Bug ID: 85773
   Summary: Embedded nulls in filesystem::path cause problems
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
int main()
{
  std::filesystem::create_directories("a/b");
  std::string s("a\0/..", 5);
  for (auto f : std::filesystem::recursive_directory_iterator(s))
  { }
}

$ GCC 8 -std=c++17 null.cc -lstdc++fs
$ ./a.out
terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot increment recursive directory iterator: Too
many open files
Aborted (core dumped)


The problem is that we call opendir(pathname.c_str()) which only reads up to
the null terminator, so we open "a"  but then the pathname for the first
element in the iteration sequence is formed by concatenating "a\0/.." / "b" and
then recursing by calling opendir(path("a\0/../b").c_str()) which opens "a"
again. This keeps looping, opening "a" every time until we reach the ulimit for
open files.

[Bug libstdc++/71301] std::tuple move constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug libstdc++/62119] dangling reference : gslice_array's copy constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
I can't reproduce a segfault but ASan shows the problem:

=
==12423==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000b0
at pc 0x0040276f bp 0x7fff6678eb50 sp 0x7fff6678eb48
READ of size 8 at 0x606000b0 thread T0
#0 0x40276e in std::valarray::size() const
/home/jwakely/gcc/9/include/c++/9.0.0/valarray:938
#1 0x40232f in std::gslice_array::operator=(int const&) const
/home/jwakely/gcc/9/include/c++/9.0.0/bits/gslice_array.h:165
#2 0x401616 in main /tmp/gs.cc:17
#3 0x7f01d4f65f29 in __libc_start_main ../csu/libc-start.c:308
#4 0x401159 in _start (/tmp/a.out+0x401159)

0x606000b0 is located 48 bytes inside of 64-byte region
[0x60600080,0x606000c0)
freed by thread T0 here:
#0 0x7f01d5ccbe78 in operator delete(void*, unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cc:151
#1 0x401b65 in std::gslice::~gslice()
/home/jwakely/gcc/9/include/c++/9.0.0/bits/gslice.h:166
#2 0x40159c in main /tmp/gs.cc:15
#3 0x7f01d4f65f29 in __libc_start_main ../csu/libc-start.c:308

previously allocated by thread T0 here:
#0 0x7f01d5ccaa80 in operator new(unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cc:90
#1 0x401a18 in std::gslice::gslice(unsigned long, std::valarray const&, std::valarray const&)
/home/jwakely/gcc/9/include/c++/9.0.0/bits/gslice.h:155
#2 0x40154e in main /tmp/gs.cc:15
#3 0x7f01d4f65f29 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-use-after-free
/home/jwakely/gcc/9/include/c++/9.0.0/valarray:938 in std::valarray::size() const
Shadow bytes around the buggy address:
  0x0c0c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff8000: fa fa fa fa 00 00 00 00 00 00 00 04 fa fa fa fa
=>0x0c0c7fff8010: fd fd fd fd fd fd[fd]fd fa fa fa fa fa fa fa fa
  0x0c0c7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==12423==ABORTING

[Bug libstdc++/85772] __gnu_cxx::__versa_string doesn't support C++11 allocators

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug libstdc++/85772] __gnu_cxx::__versa_string doesn't support C++11 allocators

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Also review it for noexcept, so that for example the copy constructor is
noexcept when using the COW base:

diff --git a/libstdc++-v3/include/ext/rc_string_base.h
b/libstdc++-v3/include/ext/rc_string_base.h
index 46f189331f7..7e027cf6fb6 100644
--- a/libstdc++-v3/include/ext/rc_string_base.h
+++ b/libstdc++-v3/include/ext/rc_string_base.h
@@ -311,7 +311,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   __rc_string_base(const _Alloc& __a);

-  __rc_string_base(const __rc_string_base& __rcs);
+  __rc_string_base(const __rc_string_base& __rcs) _GLIBCXX_USE_NOEXCEPT;

 #if __cplusplus >= 201103L
   __rc_string_base(__rc_string_base&& __rcs)
diff --git a/libstdc++-v3/include/ext/vstring.h
b/libstdc++-v3/include/ext/vstring.h
index 605311e9a28..8834bdcc36e 100644
--- a/libstdc++-v3/include/ext/vstring.h
+++ b/libstdc++-v3/include/ext/vstring.h
@@ -143,6 +143,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  @param  __str  Source string.
*/
   __versa_string(const __versa_string& __str)
+ 
_GLIBCXX_NOEXCEPT_IF(std::is_nothrow_copy_constructible<__vstring_base>())
   : __vstring_base(__str) { }

 #if __cplusplus >= 201103L

[Bug libstdc++/85771] `std::variant<...>` insanely slow to compile compared to `union` (256 types)

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This should be completely unsurprising, obviously std::variant is different to
a union. The type safety and other features come at a cost, and 2s isn't
insane.

[Bug libstdc++/81263] Work around CWG issue 1558 (guarantee SFINAE when using `void_t`)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
CWG 1558 was implemented in GCC ages ago (though given that you haven't said
what version you're using, maybe it isn't for you).

This is not a library bug though, it's a limitation of void_t and the current
core language.

[Bug sanitizer/85774] New: Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes

[jwyatt at feralinteractive dot com]

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

Bug ID: 85774
   Summary: Incorrect stack-use-after-scope caused by missing
cleanup of shadow bytes
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwyatt at feralinteractive dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

The code:

#include 

void DoSomething(){}

void DoFunc(const std::function& func)
{
func();
}

void Setup()
{
switch (1)
{
case 1:
{
DoFunc([](){});
break;
}
case 2:
{
DoFunc([](){});
break;
}
default:
break;
}

DoSomething();
}

void DemostrateBadPoisoning()
{
DoFunc([](){});
}

int main()
{
Setup();
DemostrateBadPoisoning();
return 0;
}

will cause an AddressSanitizer stack-use-after-scope error in
DemonstrateBadPoisoning. This appears to be because the shadow bytes for the
stack of Setup are not completely zeroed on function exit.

Compiled with: g++ -O0 -g -fsanitize=address -Wall -Wextra

gcc version 8.1.1 20180502 (Red Hat 8.1.1-1) (GCC)

[Bug libstdc++/67011] division by zero in std::exponential_distribution

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
(In reply to Matthias Kretz from comment #3)
> The problem is that (result_type(1) - __aurng()) must never be zero (because
> std::log might raise FE_DIVBYZERO for std::log(0)). If __aurng() is a
> distribution guaranteed to exclude result_type(1) then this works fine.
> AFAIK std::generate_canoncial sometimes generates a 1 (cf.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63176).

PR 63176 is fixed now.

> Also, I'm wondering whether the 1 - rng wouldn't reduce the randomness.
> Consider:
> std::log(numeric_limits::min()) -> -87.3365478515625
> std::log(1.f - nextafter(1.f, 0.f))-> -16.635532379150390625
> IIUC, the effect of log(1 - rng) is that the distance between random values
> from std::exponential_distribution is considerable larger than for log(rng).

Hmm, let's confirm the bug for that, instead of the division-by-zero that
should be fixed.

[Bug libstdc++/85184] Remove __glibcxx_assert uses from std::variant

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug libstdc++/85319] std::char_traits::length does not always function in constexpr context

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 CC||palves at redhat dot com
 Ever confirmed|0   |1

[Bug target/85770] New: [9 Regression] ICE: in lra_eliminate, at lra-eliminations.c:1439 with -march=nano-1000

[zsojka at seznam dot cz]

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

Bug ID: 85770
   Summary: [9 Regression] ICE: in lra_eliminate, at
lra-eliminations.c:1439 with -march=nano-1000
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 44128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44128=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -march=nano-1000 -fnon-call-exceptions
-fno-tree-coalesce-vars testcase.c 
during RTL pass: reload
testcase.c: In function 'foo':
testcase.c:13:1: internal compiler error: in lra_eliminate, at
lra-eliminations.c:1439
 }
 ^
0xba5ed0 lra_eliminate(bool, bool)
/repo/gcc-trunk/gcc/lra-eliminations.c:1439
0xb82de9 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.c:2555
0xb26a19 do_reload
/repo/gcc-trunk/gcc/ira.c:5465
0xb26a19 execute
/repo/gcc-trunk/gcc/ira.c:5649
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-260223-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-260223-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
gcc version 9.0.0 20180514 (experimental) (GCC)

[Bug libstdc++/85773] Embedded nulls in filesystem::path cause problems

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Possible solutions:

1) Detect embedded nulls when constructing paths (and forming them by
concatenation and other modifications). Opinions differ on whether this is
allowed, as filesystem::path objects are purely lexical and can represent
invalid or impossible paths.

2) Check for embedded nulls every time we call an OS function with the NTBS
returned by c_str(). This is tedious and error-prone.

3) Add a workaround to recursive_directory_iterator only.

[Bug libstdc++/72830] istream::seekg should not reset eofbit if -std=c++98

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> No, it's not a bug. The old behaviour was considered a defect in the
> language, and so the fix is applied unconditionally.

Invalid as stated above.

[Bug libstdc++/82452] defines macros for getc and putc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug c++/85775] New: False positive with -Wparentheses

[insertinterestingnamehere at gmail dot com]

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

Bug ID: 85775
   Summary: False positive with -Wparentheses
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: insertinterestingnamehere at gmail dot com
  Target Milestone: ---

g++ 8.1 warns about unnecessary parentheses in some cases where they are
actually needed to designate something as a single argument to a macro. Here's
a minimal example:

#define M(x) x

template 
struct A {
static const volatile char *M(B);
};

template 
const volatile char *M((A::B)) = nullptr;


As it stands, the compiler warns that the double parentheses are unnecessary,
but if they are removed the preprocessor complains that two arguments are being
passed to a macro that only expects one. The only work around, for now, is to
locally disable the warning with pragmas.

[Bug libstdc++/71098] uniform initialization for nested tuples work in c++11/14 mode but should only work >=c++17

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Klaus Rudolph from comment #0)
> uniform initialization for nested std::tuple works in c++11/14 mode but
> should work not before c++17.

Why not?

[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
(In reply to Chip Salzenberg from comment #16)
> Still happening in 7.2

What is?

[Bug libstdc++/81522] c++17/old-abi/cygwin empty stringstream invalid memory access

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Possibly related to PR 82172 (which was due to a binutils bug) but that
apparently only occurs when using LTO.

[Bug libstdc++/85768] [9 Regression] FreeBSD bootstrap fails due to undefined reference to 'backtrace'

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Yes I did suggest that. For now I think we should just disable the use of
backtrace anywhere except GNU/Linux.

[Bug libstdc++/85771] New: `std::variant<...>` insanely slow to compile compared to `union` (256 types)

[vittorio.romeo at outlook dot com]

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

Bug ID: 85771
   Summary: `std::variant<...>` insanely slow to compile compared
to `union` (256 types)
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

Consider the following set of types:

struct Type0 { int x; };
struct Type1 { int x; };
struct Type2 { int x; };
// ...
struct Type253 { int x; };
struct Type254 { int x; };
struct Type255 { int x; };

Now imagine creating both a `std::variant` and a `union` out of them, then
compiling some code that prints out the active alternative with `-O3`:

union MyVariant { Type0 type0; /* ... */; Type255 type255; };
std::variant v;

These are the *compilation time* results I get:

UNION
real0m0.182s
user0m0.104s
sys 0m0.068s

VARIANT
real0m2.259s
user0m1.960s
sys 0m0.280s

I can get similar results on widely different machines (40 core company
development box, my laptop, and an online compiler).

Fully-reproducible live demo on coliru:
http://coliru.stacked-crooked.com/a/65d2ec5f4d7eb1ca

I think that this kind of difference is unacceptable, and `std::variant` types
with a lot of alternatives can occur in realistic use cases. If we want to
promote safety and abstraction over C-style code, the compilation time costs
must be sane.

[Bug libstdc++/62119] dangling reference : gslice_array's copy constructor

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
PR 63314 points out the same problem exists in mask_array and indirect_array.

[Bug libstdc++/63314] valarray mask/indices refers to temporary

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Very similar to PR 62119 which has a complete testcase.

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

[Bug libstdc++/62119] dangling reference : gslice_array's copy constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||helloworld922 at hotmail dot 
com

--- Comment #3 from Jonathan Wakely  ---
*** Bug 63314 has been marked as a duplicate of this bug. ***

[Bug libstdc++/81256] basic_filebuf::close doesn't propagate exceptions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug libstdc++/83891] std::filesystem::path::is_absolute for Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug target/85769] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2205 for -mcpu=thunderx

[tnfchris at gcc dot gnu.org]

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

--- Comment #2 from Tamar Christina  ---
It's not r250673, That was committed 2017-07-28 and a GCC built 2017-08-17
does the correct thing for non-Armv8.2-a. It promotes the fp16 values to 32
bits does the operations and converts them back to fp16.

somewhere along the line something has decided to no longer do this. I can fix
the ICE by adding the missing pattern explicitly, but it should have not
generated this insn to begin with.

[Bug libstdc++/67554] runtime error in valarray (NULL passed to memcpy)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

[Bug libstdc++/82966] node_handle swap fails to compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-14
Version|unknown |7.3.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug sanitizer/85777] [7/8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

--- Comment #1 from Vincent Lefèvre  ---
I've cleaned up the testcase:

int d;
int h(void);
void e(void)
{
  int f[2];
  int g = 0;
  if (d)
g++;
  if (d == 1)
f[g++] = 2;
  (void) (f[0] || (g && h()));
}

Now:

cventin% gcc-snapshot -Werror=uninitialized -Werror=maybe-uninitialized -O2 -c
file.c
file.c: In function 'e':
file.c:11:3: error: 'f[0]' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
   (void) (f[0] || (g && h()));
   ^~~
cc1: some warnings being treated as errors
cventin%

but

cventin% gcc-snapshot -Werror=uninitialized -Werror=maybe-uninitialized -O2 -c
file.c -fsanitize=undefined
cventin%

(no errors).

Note (this may be a separate issue): If I understand correctly, f[0] is
actually *always* used uninitialized in this function. Indeed, f[0] might be
initialized only via "f[g++] = 2;", thus only if d == 1. But in this case, it
is actually f[1] that is initialized.

[Bug libstdc++/67554] runtime error in valarray (NULL passed to memcpy)

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 15:35:06 2018
New Revision: 260229

URL: https://gcc.gnu.org/viewcvs?rev=260229=gcc=rev
Log:
PR libstdc++/67554 Do not pass null pointers to memcpy

PR libstdc++/67554
* include/bits/valarray_array.h (_Array_copy_ctor<_Tp, true>)
(_Array_copier<_Tp, true>): Do not pass null pointers to memcpy.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/valarray_array.h

[Bug libstdc++/82966] node_handle swap fails to compile

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 14:27:54 2018
New Revision: 260226

URL: https://gcc.gnu.org/viewcvs?rev=260226=gcc=rev
Log:
PR libstdc++/82966 fix swapping of node handles

PR libstdc++/82966
* include/bits/node_handle.h (_Node_handle_common::_M_swap): Use value
instead of type.
* testsuite/23_containers/set/modifiers/node_swap.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/set/modifiers/node_swap.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/node_handle.h

[Bug c++/85776] New: ICE when compiling `boost::thread` with `-std=c++11` on mingw-w64

[lh_mouse at 126 dot com]

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

Bug ID: 85776
   Summary: ICE when compiling `boost::thread` with `-std=c++11`
on mingw-w64
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

Created attachment 44129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44129=edit
(though not minimal) testcase

Compiling the attached program using `-std=c++11` with boost 1.66 results in an
ICE:

```
E:\Desktop>g++ -std=c++11 test.cc
In file included from
C:/MinGW/MSYS2/mingw32/include/boost/thread/detail/thread.hpp:23,
 from
C:/MinGW/MSYS2/mingw32/include/boost/thread/thread_only.hpp:22,
 from
C:/MinGW/MSYS2/mingw32/include/boost/thread/thread.hpp:12,
 from C:/MinGW/MSYS2/mingw32/include/boost/thread.hpp:13,
 from test.cc:1:
C:/MinGW/MSYS2/mingw32/include/boost/thread/detail/invoke.hpp: In function
'decltype (*(forward)(boost::detail::invoke::a0).*boost::detail::invoke::f)
boost::detail::invoke(Fp&&, A0&&) [with Fp = void (A::*)(); A0 = A*]':
C:/MinGW/MSYS2/mingw32/include/boost/thread/detail/invoke.hpp:102:43: internal
compiler error: in gimplify_expr, at gimplify.c:12188
 return (*boost::forward(a0)).*f;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```

This is confirmed to be the case on 5.4 (native and cross from Linux) and 8.1.1
(native).


Preprocessing the testcase results in such an enormous file (5+ MiB) that
CReduce has been unable to reduce it at all (it resulted in a `}` only, which
was apparently a bug).

[Bug sanitizer/85777] New: [7/8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

Bug ID: 85777
   Summary: [7/8 Regression] -fsanitize=undefined makes a
-Wmaybe-uninitialized warning disappear
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

On some C files, adding the -fsanitize=undefined option makes a
-Wmaybe-uninitialized warning disappear.

In the past, I reported PR81981, which was fixed for the provided testcase. But
this was just a simplified testcase of tests/turandom.c in MPFR revision 11663,
and the problem still occurs for this revision of MPFR.

I've used creduce with the following test under Debian/unstable in order to
obtain another simplified testcase:


#!/bin/sh

cmd="gcc-snapshot -Werror=uninitialized -Werror=maybe-uninitialized -O2 -c
file.c"
$cmd -fsanitize=undefined && ! $cmd


The obtained file.c file is:


enum { a, b } typedef c;
d;
e() {
  c f[2];
  int g = 0;
  if (d)
g++;
  if (d == b)
f[g++] = 2;
  f[0] || g &();
}


I get the "‘f[0]’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]" error with:
  * gcc-6 -Werror=maybe-uninitialized -O2 -c file.c
  * gcc-6 -Werror=maybe-uninitialized -O2 -c file.c -fsanitize=undefined
  * gcc-7 -Werror=maybe-uninitialized -O2 -c file.c
  * gcc-8 -Werror=maybe-uninitialized -O2 -c file.c
  * gcc-snapshot -Werror=maybe-uninitialized -O2 -c file.c

but not with:
  * gcc-7 -Werror=maybe-uninitialized -O2 -c file.c -fsanitize=undefined
  * gcc-8 -Werror=maybe-uninitialized -O2 -c file.c -fsanitize=undefined
  * gcc-snapshot -Werror=maybe-uninitialized -O2 -c file.c -fsanitize=undefined

FYI, currently under Debian/unstable:
  * gcc-6 (Debian 6.4.0-17) 6.4.0 20180424
  * gcc-7 (Debian 7.3.0-19) 7.3.0
  * gcc-8 (Debian 8.1.0-3) 8.1.0
  * gcc (Debian 20180512-1) 9.0.0 20180512 (experimental) [trunk revision
260194]

[Bug c++/85739] [8/9 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #4 from ensadc at mailnesia dot com ---
struct l { int k; };
template  class b { };
template  class B { using e = int; };
template 
bool operator!=(B, b);

bool bb = (B<::k>() != b<::k>());

also reproduces it.

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Martin Liška  ---
[...]
> According to log file alias support is mission on solaris. Thus following 
> patch
> should fix that by skipping the test:
>
> diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> b/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> index 85531ab1cf3..45525844551 100644
> --- a/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> +++ b/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
> @@ -1,4 +1,5 @@
>  /* { dg-do link } */
> +/* { dg-require-alias "" } */
>  /* { dg-options "-O2 -fdump-ipa-icf -flto -fdump-tree-fixup_cfg4" } */
>  /* { dg-require-effective-target lto } */
>  /* { dg-additional-sources "ipa-icf-38a.c" }*/
>
> Can you please verify that?

The patch doesn't make a difference as Solaris *does* support attribute
alias, even when using as and ld.  However, I noticed that the
unmodified test PASSes when using gas/gld instead, so there is a
toolchain difference that causes this failure.

[Bug target/85756] [9 regression] wrong code at -Os on x86-64-linux-gnu in 32-bit mode

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon May 14 15:53:58 2018
New Revision: 260231

URL: https://gcc.gnu.org/viewcvs?rev=260231=gcc=rev
Log:
PR target/85756
* config/i386/i386.md: Disallow non-commutative arithmetics in
last twpeephole for mem {+,-,&,|,^}= x; mem != 0 after cmpelim
optimization.  Use COMMUTATIVE_ARITH_P test rather than != MINUS
in the peephole2 before it.

testsuite/ChangeLog:

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


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr85756.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/71098] uniform initialization for nested tuples work in c++11/14 mode but should only work >=c++17

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jonathan Wakely  ---
I assume you're referring to the conditionally EXPLICIT constructors. That
fixed a defect and is supported all the way back to C++11, as per our usual
policy.

[Bug target/85769] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2205 for -mcpu=thunderx

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

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

[Bug libstdc++/62196] running time segment fault with valarray

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
abcdefghijklmnopqrstuvwxyz
=
==15899==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200036 at pc 0x004024c5 bp 0x7ffe7350f5f0 sp 0x7ffe7350f5e0
READ of size 1 at 0x60200036 thread T0
#0 0x4024c4 in void std::__valarray_copy(std::_Array, unsigned
long, std::_Array, std::_Array) (/tmp/a.out+0x4024c4)
#1 0x402092 in std::mask_array::operator=(std::valarray const&)
const (/tmp/a.out+0x402092)
#2 0x40154c in main (/tmp/a.out+0x40154c)
#3 0x7f3736481f29 in __libc_start_main (/lib64/libc.so.6+0x20f29)
#4 0x400ef9 in _start (/tmp/a.out+0x400ef9)

0x60200036 is located 0 bytes to the right of 6-byte region
[0x60200030,0x60200036)
allocated by thread T0 here:
#0 0x7f37371e0158 in operator new(unsigned long)
(/lib64/libasan.so.4+0xe0158)
#1 0x40187a in std::__valarray_get_memory(unsigned long)
(/tmp/a.out+0x40187a)
#2 0x402155 in bool* restrict std::__valarray_get_storage(unsigned
long) (/tmp/a.out+0x402155)
#3 0x401a35 in std::valarray::valarray(bool const*, unsigned long)
(/tmp/a.out+0x401a35)
#4 0x4013e8 in main (/tmp/a.out+0x4013e8)
#5 0x7f3736481f29 in __libc_start_main (/lib64/libc.so.6+0x20f29)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/tmp/a.out+0x4024c4) in void
std::__valarray_copy(std::_Array, unsigned long, std::_Array,
std::_Array)
Shadow bytes around the buggy address:
  0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa 06 fa fa fa[06]fa fa fa fa fa fa fa fa fa
  0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==15899==ABORTING

[Bug c++/85731] [8/9 Regression] Inner class method declaration changes meaning of outer template class template method

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Started with r251438

PR c++/81236 - ICE with template-id in generic lambda

* semantics.c (finish_id_expression): Remove special dependent
case.
Avoid some later pieces when dependent.
(finish_qualified_id_expr): Do normal BASELINK handling in a
template.  Always build a SCOPE_REF for a destructor BIT_NOT_EXPR.
(parsing_default_capturing_generic_lambda_in_template): Remove.
* parser.c (cp_parser_postfix_dot_deref_expression): Always give an
error for types that will never be complete.
* mangle.c (write_expression): Add sanity check.
* tree.c (build_qualified_name): Add sanity check.
(cp_walk_subtrees): Walk into the class context of a BASELINK.
* lambda.c (add_capture): Improve diagnostic for generic lambda
capture failure.
* call.c (build_new_method_call_1): Print the right constructor
name.

[Bug c++/85782] New: acc loops with continue statements ICE in c++

[cesar at gcc dot gnu.org]

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

Bug ID: 85782
   Summary: acc loops with continue statements ICE in c++
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cesar at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44130=edit
test.cpp

G++ ICEs when it encounters OpenACC loops that contains continue statements as
demonstrated in the attached test case. Gcc, in contrast, does not suffer from
this defect.

This bug is present in GCC 6, 7, 8 and trunk.

[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I agree that's not an improvement.  Would something like this be better? (at
least until utmp_ent is marked nonstring and GCC taught to suppress the
diagnostic)

  size_t utmpsize = sizeof UT_ID (utmp_ent);
  char *comment = xmalloc (strlen (_("id=")) + utmpsize + 1);

  strcpy (comment, _("id="));
  strncat (comment, UT_ID (utmp_ent), utmpsize);

I'll try to remember to test coreutils with new warnings in the future.

[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 CC||kargl at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Paul,

The ICE can be fixed by checking for a NULL pointer.

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 260235)
+++ gcc/fortran/resolve.c   (working copy)
@@ -12501,7 +12501,7 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
   while (curr_arg != NULL)
 {
   /* Skip implicitly typed dummy args here.  */
- if (curr_arg->sym->attr.implicit_type == 0)
+ if (curr_arg->sym && curr_arg->sym->attr.implicit_type == 0)
if (!gfc_verify_c_interop_param (curr_arg->sym))
  /* If something is found to fail, record the fact so we
 can mark the symbol for the procedure as not being

HOwever, I think we then have an accepts invalid as an alternate
return takes a label.  If I look at gfc_match_formal_arglist in 
decl.c, it looks like your PDT work may have touched the area
that should issue an error.
 81764   dnovillo   if (gfc_match_char ('*') == MATCH_YES)
197389  janus   {
197389  janus sym = NULL;
255311  pault if (!typeparam && !gfc_notify_std (GFC_STD_F95_OBS,
255311  pault"Alternate-return argument at
%C"))
197389  janus   {
197389  janus m = MATCH_ERROR;
197389  janus goto cleanup;
197389  janus   }
255311  pault else if (typeparam)
255311  pault   gfc_error_now ("A parameter name is required at
%C");
197389  janus   }

Do you have any insights?

[Bug target/85756] [9 regression] wrong code at -Os on x86-64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon May 14 20:17:19 2018
New Revision: 260239

URL: https://gcc.gnu.org/viewcvs?rev=260239=gcc=rev
Log:
PR target/85756
* gnat.dg/opt70.adb: New test.
* gnat.dg/opt70_pkg.ad[sb]: New helper.

Added:
trunk/gcc/testsuite/gnat.dg/opt70.adb
trunk/gcc/testsuite/gnat.dg/opt70_pkg.adb
trunk/gcc/testsuite/gnat.dg/opt70_pkg.ads
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source

[eggert at gnu dot org]

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

--- Comment #4 from Paul Eggert  ---
Thanks, that workaround is much better for coreutils, and I installed it here:

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=f6cb50cc991d461f443ea3afc517c9e1e37ef496

[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source

[eggert at gnu dot org]

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

--- Comment #2 from Paul Eggert  ---
Thanks for looking into it. For what it's worth, the practical effect of this
new warning was that I changed that part of coreutils to not use strncat,
causing 3 lines of code to grow to 8 lines. See the end of:

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=9781fcd532f30afe174239a22816a83c40528b27

Another part of coreutils still uses strncat (also correctly). Let's hope GCC
doesn't start warning about it too

[Bug fortran/85779] ICE in gfc_typename, at fortran/misc.c:156

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-14
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
This fixes the problem.  Watch for cut-n-paste corruption of tabs.

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 260235)
+++ gcc/fortran/decl.c  (working copy)
@@ -9961,8 +9975,12 @@ gfc_match_derived_decl (void)

   if (!gensym->attr.generic && gensym->ts.type != BT_UNKNOWN)
 {
-  gfc_error ("Derived type name %qs at %C already has a basic type "
-"of %s", gensym->name, gfc_typename (>ts));
+  if (gensym->ts.u.derived)
+   gfc_error ("Derived type name %qs at %C already has a basic type "
+  "of %s", gensym->name, gfc_typename (>ts));
+  else
+   gfc_error ("Derived type name %qs at %C already has a basic type",
+  gensym->name);
   return MATCH_ERROR;
 }

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

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

--- Comment #6 from Pat Haugen  ---
(In reply to Richard Biener from comment #4)
> I can see what the patch does to this testcase on x86_64 - it enables BB
> vectorization of the first two loops after runrolling.  I don't see anything
> suspicious here on x86_64 and 525.x264_r works fine for me.
> 
> Can you claify whether test, ref or train inputs fail for you?  I tried
> AVX256, AVX128 and plain old SSE sofar without any issue but ref takes some
> time...
> 
> Can you check whether the following reduced file produces the same assembly
> for add4x4_idct as in the complete benchmark?  If so it should be possible to
> generate a runtime testcase from it.  Please attach preprocessed source if
> that doesn't work out.
> 
> Sofar I do suspect we are hitting a latent target issue?
> 
> #include 
> static uint8_t x264_clip_uint8( int x )
> {
>   return x&(~255) ? (-x)>>31 : x;
> }
> void add4x4_idct( uint8_t *p_dst, int16_t dct[16])
> {
>   int16_t d[16];
>   int16_t tmp[16];
>   for( int i = 0; i < 4; i++ )
> {
>   int s02 =  dct[0*4+i] +  dct[2*4+i];
>   int d02 =  dct[0*4+i] -  dct[2*4+i];
>   int s13 =  dct[1*4+i] + (dct[3*4+i]>>1);
>   int d13 = (dct[1*4+i]>>1) -  dct[3*4+i];
>   tmp[i*4+0] = s02 + s13;
>   tmp[i*4+1] = d02 + d13;
>   tmp[i*4+2] = d02 - d13;
>   tmp[i*4+3] = s02 - s13;
> }
>   for( int i = 0; i < 4; i++ )
> {
>   int s02 =  tmp[0*4+i] +  tmp[2*4+i];
>   int d02 =  tmp[0*4+i] -  tmp[2*4+i];
>   int s13 =  tmp[1*4+i] + (tmp[3*4+i]>>1);
>   int d13 = (tmp[1*4+i]>>1) -  tmp[3*4+i];
>   d[0*4+i] = ( s02 + s13 + 32 ) >> 6;
>   d[1*4+i] = ( d02 + d13 + 32 ) >> 6;
>   d[2*4+i] = ( d02 - d13 + 32 ) >> 6;
>   d[3*4+i] = ( s02 - s13 + 32 ) >> 6;
> }
>   for( int y = 0; y < 4; y++ )
> {
>   for( int x = 0; x < 4; x++ )
> p_dst[x] = x264_clip_uint8( p_dst[x] + d[y*4+x] );
>   p_dst += 32;
> }
> }

Yes, that produces similar code, and adding the following to it produces an
executable test that fails at -O3.

void main()
{
  uint8_t dst[128];
  int16_t dct[16];
  int i;

  for (i = 0; i < 16; i++)
dct[i] = i*10 + i;
  for (i = 0; i < 128; i++)
dst[i] = i;

  add4x4_idct(dst, dct);

  if (dst[0] != 14 || dst[1] != 0 || dst[2] != 4 || dst[3] != 2 
  || dst[32] != 28 || dst[33] != 35 || dst[34] != 33 || dst[35] != 35)
abort();

}

Continuing to debug further...

[Bug c++/85783] New: alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

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

Bug ID: 85783
   Summary: alloc-size-larger-than fires incorrectly with new[]
and can't be disabled
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: psmith at gnu dot org
  Target Milestone: ---

Created attachment 44131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44131=edit
sample source file

GCC 8.1.0 / binutils 2.30
GNU/Linux x86_64 with a sysroot of Red Hat EL 6.5.

Recently I started upgrading from GCC 7.3 to GCC 8.1.  I discovered three
locations in my codebase where the alloc-size-larger-than warning is generated.
 It wasn't ever generated with 7.3.  Since I build with -Wall -Werror this
causes compiles to fail.

The first issue is, I wasn't able to find any way to turn off this warning
other than by removing -Wall which seems entirely too severe.  There should be
some way to disable it; maybe by providing -Walloc-size-larger-than=0 or
similar.

I did work around this issue by casting the value given to new[] to type
unsigned int, but that's unpleasant.

Of course removing the false positive would be helpful as well.

I spent quite a while trying to create a small sample; the results are below. 
Most any change to this file appears to cause the warning to go away: for
example I tried to use a simple template I created rather than
std::shared_ptr<>, or even remove that field altogether: no warning.  If I
remove or modify the if-statements in the method significantly, no warning. 
Etc.  I didn't try all changes of course.  Also without optimization it doesn't
warn but with both -O1 and -O2 it does.

Results of compiling the attached file:

  $ x86_64-rh65-linux-gnu-g++ -v -o /tmp/SP.o -c -O2 -Wall -Werror params.cpp
  Using built-in specs.
 
COLLECT_GCC=/work/src/build/x86_64-linux/cc/generic/bin/x86_64-generic-linux-gnu-g++
  Target: x86_64-generic-linux-gnu
  Configured with: /work/src/cc/gcc-8.1.0/configure --disable-nls
--disable-werror --prefix=/work/src/cc/x86_64-linux/final/generic
--host=x86_64-tools-linux-gnu --target=x86_64-generic-linux-gnu
--with-sysroot=/work/src/build/x86_64-linux/sysroot/generic CFLAGS=-O2
CXXFLAGS=-O2 LDFLAGS=-O2 --enable-gold --enable-languages=c,c++
  Thread model: posix
  gcc version 8.1.0 (GCC) 
  COLLECT_GCC_OPTIONS='-m64' '-isystem' '=/usr/include-fixed' '-v' '-o'
'/tmp/SP.o' '-c' '-O2' '-Wall' '-Werror' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 
/work/src/build/x86_64-linux/cc/generic/bin/../libexec/gcc/x86_64-generic-linux-gnu/8.1.0/cc1plus
-quiet -v -iprefix
/work/src/build/x86_64-linux/cc/generic/bin/../lib/gcc/x86_64-generic-linux-gnu/8.1.0/
-isysroot /work/src/build/x86_64-linux/sysroot/rh65 -D_GNU_SOURCE -isystem
=/usr/include-fixed params.cpp -quiet -dumpbase SortParameters.cpp -m64
-mtune=generic -march=x86-64 -auxbase-strip /tmp/SP.o -O2 -Wall -Werror
-version -o /tmp/ccuJobAh.s
  GNU C++14 (GCC) version 8.1.0 (x86_64-generic-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

  GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
  Compiler executable checksum: e2fe942476766bd673c0e36030131141
  In function 'void* operator new [](size_t)',
inlined from 'static Params* Params::buildParams(size_t, Info*)' at
params.cpp:52:47:
  params.cpp:8:21: error: argument 1 value '18446744073709551615' exceeds
maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
   void* p = malloc(size);
 ~~^~
...
  /work/src/build/x86_64-linux/sysroot/rh65/usr/include/stdlib.h: In static
member function 'static Params* Params::buildParams(size_t, Info*)':
  /work/src/build/x86_64-linux/sysroot/rh65/usr/include/stdlib.h:471:14: note:
in a call to allocation function 'void* malloc(size_t)' declared here
   extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
^~
  cc1plus: all warnings being treated as errors

[Bug fortran/85781] ICE in gfc_build_array_ref, at fortran/trans.c:393

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Some variants that are actually compiling :


$ cat z2.f90
subroutine s(x) bind(c)
   use iso_c_binding, only: c_char
   character(kind=c_char), value :: x
   print *, x(1:0)
end


$ cat z3.f90
subroutine s(x)
   use iso_c_binding, only: c_char
   character(kind=c_char), value :: x
   print *, x(2:1)
end

[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)

> HOwever, I think we then have an accepts invalid as an alternate
> return takes a label.  

Whoops, I may have misread the standard.  The label applies to
the actual argument.  A dummy argument of '*' alone signifies
an alternate return, the patch in #1 indeed fixes the issue.

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[jan at jki dot io]

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

--- Comment #12 from Jan  ---
And yes I use a gentoo system. But I'm using the gcc patches from clear linux
but this bug doesn't seem relate to that.

[Bug fortran/85780] New: ICE in resolve_fl_procedure, at fortran/resolve.c:12504

[gs...@t-online.de]

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

Bug ID: 85780
   Summary: ICE in resolve_fl_procedure, at
fortran/resolve.c:12504
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least 4.8 :

$ cat z1.f90
subroutine s(*) bind(c)
end


$ gfortran-9-20180513 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb9f4bf crash_signal
../../gcc/toplev.c:325
0x71bbfd resolve_fl_procedure
../../gcc/fortran/resolve.c:12504
0x71bbfd resolve_symbol
../../gcc/fortran/resolve.c:15157
0x73639b do_traverse_symtree
../../gcc/fortran/symbol.c:4149
0x71cb1a resolve_types
../../gcc/fortran/resolve.c:16456
0x71839c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16570
0x701b6a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x701b6a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[jan at jki dot io]

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

--- Comment #11 from Jan  ---
I can reproduce it with vanilla gcc 8.1.0 no patches applied.

[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-14
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|[8/9 Regression] regression |-Wsizeof-pointer-memaccess
   |with strncat and -Wall in   |for strncat with size of
   |GCC 8   |source
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
(The warning behaves as designed so this is not a regression.  I've changed the
Summary to reflect that.)

The code in the test case is correct and safe, and reflects one of the original
and intended uses of the function.  Unfortunately, due to a poor understanding
of the various string functions[1], many calls to strncat() with either the
size of the source or (to a lesser extent) the size of the destination have
been mistakes that have led to either buffer overflow or inadvertent
truncation.  To avoid these mistakes the recommended way to call the function
is to pass it the amount of space remaining in the destination, e.g., like
so[2]:

  strncat (dst, src, dstsize - strlen (d) - 1);

The warning is designed to help detect these mistakes and encourage this idiom.

Ideally, the warning would detect the safe calls (like the one in the test
case) and avoid triggering for them, but it's not always possible.  In the test
case, it's impossible to detect the length of the destination string at the
point where GCC sees the use of 'sizeof source' in the strncat() call; at the
point where the length is known the fact that the bound is the result of
'sizeof source' has been lost.

Since in the test case strncat() is being used to constrain the copy to avoid
reading past the end of a non-string (i.e., an array of characters not
necessarily terminated by a NUL) I'll see if GCC can be taught to recognize the
attribute in this context to suppress the warning.  Until then (or if
annotating the member isn't an option), the warning can be suppressed either by
a #pragma GCC diagnostic, or by introducing a temporary pointer pointing to the
member array and passing the pointer to strncat, or by introducing a temporary
for the size of the source and passing it to the function as the bound:

  char* __attribute__ ((nonstring)) p = u.ut_user;
  enum { N = sizeof u.ut_user };
  strncat (buf, u.ut_user, N);

[1]
https://www.usenix.org/legacy/event/usenix99/full_papers/millert/millert.pdf
[2]
https://www.us-cert.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncat

[Bug fortran/85779] New: ICE in gfc_typename, at fortran/misc.c:156

[gs...@t-online.de]

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

Bug ID: 85779
   Summary: ICE in gfc_typename, at fortran/misc.c:156
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With invalid code, down to at least 4.8 :


$ cat z1.f90
type(t) function f()
   type f
   end type
end


$ cat z2.f90
type(t) function f() result(z)
   type z
   end type
end


$ gfortran-9-20180513 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb9f4bf crash_signal
../../gcc/toplev.c:325
0x6de45c gfc_typename(gfc_typespec*)
../../gcc/fortran/misc.c:156
0x69d9b6 gfc_match_derived_decl()
../../gcc/fortran/decl.c:9964
0x6f7139 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6fc0b1 match_word
../../gcc/fortran/parse.c:265
0x6fc0b1 decode_specification_statement
../../gcc/fortran/parse.c:265
0x6fc0b1 decode_statement
../../gcc/fortran/parse.c:314
0x6fc754 next_free
../../gcc/fortran/parse.c:1230
0x6fc754 next_statement
../../gcc/fortran/parse.c:1462
0x6fe56c parse_spec
../../gcc/fortran/parse.c:3670
0x700533 parse_progunit
../../gcc/fortran/parse.c:5667
0x701ec1 gfc_parse_file()
../../gcc/fortran/parse.c:6221
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85779] ICE in gfc_typename, at fortran/misc.c:156

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Related :

$ cat z3.f90
class(t) function f()
   type f
   end type
end


$ gfortran-9-20180513 -c z3.f90
f951: internal compiler error: Segmentation fault
0xb9f4bf crash_signal
../../gcc/toplev.c:325
0x6de494 gfc_typename(gfc_typespec*)
../../gcc/fortran/misc.c:159
0x69d9b6 gfc_match_derived_decl()
../../gcc/fortran/decl.c:9964
0x6f7139 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6fb1c5 match_word
../../gcc/fortran/parse.c:569
0x6fb1c5 decode_statement
../../gcc/fortran/parse.c:569
0x6fc754 next_free
../../gcc/fortran/parse.c:1230
0x6fc754 next_statement
../../gcc/fortran/parse.c:1462
0x6fdea0 parse_spec
../../gcc/fortran/parse.c:3870
0x700533 parse_progunit
../../gcc/fortran/parse.c:5667
0x701ec1 gfc_parse_file()
../../gcc/fortran/parse.c:6221
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug libstdc++/81256] basic_filebuf::close doesn't propagate exceptions

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 18:57:45 2018
New Revision: 260236

URL: https://gcc.gnu.org/viewcvs?rev=260236=gcc=rev
Log:
PR libstdc++/81256 fix exception handling in basic_filebuf::close

PR libstdc++/81256
* include/bits/fstream.tcc (basic_filebuf::close): Do not swallow
exceptions from _M_terminate_output().
* include/std/fstream (basic_filebuf::~basic_filebuf): Swallow any
exceptions from close().
* testsuite/27_io/basic_filebuf/close/81256.cc: New.

Added:
trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/close/81256.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/fstream.tcc
trunk/libstdc++-v3/include/std/fstream

[Bug libstdc++/85768] [9 Regression] FreeBSD bootstrap fails due to undefined reference to 'backtrace'

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |fdumont at gcc dot 
gnu.org

--- Comment #3 from François Dumont  ---
I used this function cause it was already being used by the libstdc++ profile
mode so I was expecting it to be quite safe. As profile mode is not used on
bootstrap or in general I guess this problem never show up.

I'll move to libbacktrace with proper checks.

Waiting for the fix shall I revert the change ?

[Bug other/85778] New: unexpected results with -O2, wrong code?

[doko at gcc dot gnu.org]

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

Bug ID: 85778
   Summary: unexpected results with -O2, wrong code?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with GCC 5 and all newer version. Is this wrong-code?

$ cat testcase.c 
#include 
#include 

#define PRINT \
  if (foo == NULL) \
printf("foo in func() is %p, NULL (expected)\n", foo); \
  else \
printf("foo in func() is %p, not NULL (NOT EXPECTED!)\n", foo);

void func(const char *foo) {
  struct stat stat_buf;

  PRINT;
  stat(foo, _buf);
  PRINT;
}

int main() {
  const char *foo = NULL;
  struct stat stat_buf;

  func(NULL);

  PRINT;
  stat(foo, _buf);
  PRINT;
  return 0;
}

$ gcc -O0 testcase.c && ./a.out 
foo in func() is (nil), NULL (expected)
foo in func() is (nil), NULL (expected)
foo in func() is (nil), NULL (expected)
foo in func() is (nil), NULL (expected)
$ gcc -O2 testcase.c && ./a.out 
foo in func() is (nil), NULL (expected)
foo in func() is (nil), not NULL (NOT EXPECTED!)
foo in func() is (nil), NULL (expected)
foo in func() is (nil), NULL (expected)

[Bug other/85778] unexpected results with -O2, wrong code?

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
It depends on if glibc is adding the nonnull attribute to stat or is it GCC. 
Also what does the C (and POSIX) standard says about a null pointer being
passed as the string to stat.

[Bug fortran/85781] New: ICE in gfc_build_array_ref, at fortran/trans.c:393

[gs...@t-online.de]

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

Bug ID: 85781
   Summary: ICE in gfc_build_array_ref, at fortran/trans.c:393
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects also versions down to at least 4.8 :

$ cat z1.f90
subroutine s(x) bind(c)
   use iso_c_binding, only: c_char
   character(kind=c_char), value :: x
   print *, x(2:1)
end


$ gfortran-9-20180513 -c z1.f90
z1.f90:4:0:

print *, x(2:1)

internal compiler error: in gfc_build_array_ref, at fortran/trans.c:393
0x74c15b gfc_build_array_ref(tree_node*, tree_node*, tree_node*, tree_node*)
../../gcc/fortran/trans.c:393
0x7821e5 gfc_conv_substring
../../gcc/fortran/trans-expr.c:2301
0x782524 gfc_conv_variable
../../gcc/fortran/trans-expr.c:2766
0x77f312 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7930
0x785bba gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8022
0x7a5d76 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2585
0x74b647 trans_code
../../gcc/fortran/trans.c:2044
0x7a3827 build_dt
../../gcc/fortran/trans-io.c:2027
0x74b667 trans_code
../../gcc/fortran/trans.c:2016
0x772c49 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x701d40 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x701d40 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

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

--- Comment #7 from Pat Haugen  ---
So the problem is that we're generating a stxvw4x insn to write to memory,
which corrupts the contents due to both endian behavior and element size (since
we're dealing with halfword/uint16_t elements).

Value in vector reg = 0x0002fffc0002fff5000e

stvx/good
(gdb) x/8hx $r1+$r8
0x7fffe490: 0x000e  0xfff5  0x0002  0x  0xfffc  0x0002  0x  0x


stxvw4x/bad
(gdb) x/8hx $r7+$r8
0x7fffe470: 0x  0x  0xfffc  0x0002  0x0002  0x  0x000e  0xfff5

[Bug libstdc++/82966] node_handle swap fails to compile

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 22:22:23 2018
New Revision: 260242

URL: https://gcc.gnu.org/viewcvs?rev=260242=gcc=rev
Log:
PR libstdc++/82966 fix swapping of node handles

PR libstdc++/82966
* include/bits/node_handle.h (_Node_handle_common::_M_swap): Use value
instead of type.
* testsuite/23_containers/set/modifiers/node_swap.cc: New.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/set/modifiers/node_swap.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/node_handle.h

[Bug libstdc++/67554] runtime error in valarray (NULL passed to memcpy)

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon May 14 22:22:27 2018
New Revision: 260243

URL: https://gcc.gnu.org/viewcvs?rev=260243=gcc=rev
Log:
PR libstdc++/67554 Do not pass null pointers to memcpy

PR libstdc++/67554
* include/bits/valarray_array.h (_Array_copy_ctor<_Tp, true>)
(_Array_copier<_Tp, true>): Do not pass null pointers to memcpy.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/valarray_array.h