[Bug c/80685] -Wnonnull-compare warns based on builtin declaration

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Use -fno-builtins if you don't want gcc to assumes things about functions.

[Bug c/80685] -Wnonnull-compare warns based on builtin declaration

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
The c standard says null pointer for strncat is undefined.

[Bug c/80685] New: -Wnonnull-compare warns based on builtin declaration

[coypu at sdf dot org]

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

Bug ID: 80685
   Summary: -Wnonnull-compare warns based on builtin declaration
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

Hi, I'm building a libc.

It doesn't use __attribute__((nonnull)) anywhere in stdio.h and other headers,
instead asserts in a convoluted way that the arguments aren't NULL.

Building with gcc -Werror -Wall etc. I get lots of warnings about these NULL
checks:

/usr/src/lib/libc/../../common/lib/libc/string/strncat.c: In function
'strncat':
/usr/src/lib/libc/../../common/lib/libc/string/strncat.c:63:2: error: nonnull
argument 'dst' compared to NULL [-Werror=nonnull-compare]
  _DIAGASSERT(dst != NULL);
  ^

I believe that warning may be bogus, feel free to close if you disagree.

[Bug bootstrap/80677] LIMITS_H_TEST is wrong

[helmut at subdivi dot de]

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

--- Comment #2 from Helmut Grohne  ---
(In reply to jos...@codesourcery.com from comment #1)
> Well, if headers move then configure (and related) tests that look at them 
> will need updating.  See how gcc/configure.ac looks in $target_header_dir 
> to identify the glibc version and various other configuration, for 
> example.

As far as I understand it, gcc's build system takes care to consult
$(build_tooldir)/sys-include. Debian's packaging of gcc takes care to populate
it reasonably.

I have performed a fair number of builds of gcc with glibc's headers moved now
and cannot confirm the projected behavior. At present, it looks like fixing
LIMITS_H_TEST is the remaining piece to the puzzle.

[Bug middle-end/80669] [8 Regression] Bad -Wstringop-overflow warnings for stpncpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00575.html

[Bug translation/80280] Missing closing quote (%>) c/semantics.c and c/c-typeck.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Fixed and enhanced -Wformat implementation committed 247778.

[Bug translation/80280] Missing closing quote (%>) c/semantics.c and c/c-typeck.c

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Tue May  9 02:47:14 2017
New Revision: 247778

URL: https://gcc.gnu.org/viewcvs?rev=247778=gcc=rev
Log:
PR translation/80280 - Missing closing quote (%>) c/semantics.c and
c/c-typeck.c

gcc/c-family/ChangeLog:

PR translation/80280
* c-format.h (struct format_flag_spec): Add new member.
(T89_T): New macro.
* c-format.c (local_tree_type_node): New global.
(printf_flag_specs, asm_fprintf_flag_spec): Initialize new data.
(gcc_diag_flag_specs, scanf_flag_specs, strftime_flag_specs): Ditto.
(strfmon_flag_specs): Likewise.
(gcc_diag_char_table, gcc_cdiag_char_table): Split up specifiers
with distinct quoting properties.
(gcc_tdiag_char_table, gcc_cxxdiag_char_table): Same.
(flag_chars_t::validate): Add argument and handle bad quoting.
(check_format_info_main): Handle quoting problems.
(init_dynamic_diag_info): Simplify.

gcc/testsuite/ChangeLog:

PR translation/80280
* gcc.dg/format/gcc_diag-10.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/format/gcc_diag-10.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/c-family/c-format.h
trunk/gcc/testsuite/ChangeLog

[Bug go/64238] ICE in get_partitioning_class, at symtab.c:1775

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor  ---
This appears to work in GCC 7.  At least, I can see a crash when using GCC 6,
but I don't see a crash when using revision 246286.  Which revision are you
using for the crash you see?

I'm afraid that I do not have the time to track down a failure in GCC 5 or 6 if
it is working on trunk.

[Bug target/80101] ICE in store_data_bypass_p, at recog.c:3737

[kelvin at gcc dot gnu.org]

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

--- Comment #2 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Tue May  9 01:15:46 2017
New Revision: 24

URL: https://gcc.gnu.org/viewcvs?rev=24=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2017-05-08  Kelvin Nilsen  

PR target/80101
* gcc.target/powerpc/pr80101-1.c: New test.


gcc/ChangeLog:

2017-05-08  Kelvin Nilsen  

PR target/80101
* config/rs6000/power6.md: Replace store_data_bypass_p calls with
rs6000_store_data_bypass_p in seven define_bypass directives and
in several comments.
* config/rs6000/rs6000-protos.h: Add prototype for
rs6000_store_data_bypass_p function.
* config/rs6000/rs6000.c (rs6000_store_data_bypass_p): New
function implements slightly different (rs6000-specific) semantics
than store_data_bypass_p, returning false rather than aborting
with assertion error when arguments do not satisfy the
requirements of store data bypass.
(rs6000_adjust_cost): Replace six calls of store_data_bypass_p with
rs6000_store_data_bypass_p.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr80101-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/power6.md
trunk/gcc/config/rs6000/rs6000-protos.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/80684] New: poor error message and fix-it hint for a function with an argument of undeclared type

[msebor at gcc dot gnu.org]

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

Bug ID: 80684
   Summary: poor error message and fix-it hint for a function with
an argument of undeclared type
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

G++ issues the following confusing error messages for a function declaration
involving the undeclared type string (where std::string from  was meant
but the header was not included).  The suggested alternative only makes things
worse.

$ cat y.C && gcc -S -Wall -Wextra -Wpedantic y.C
void f (string);

y.C:1:15: error: variable or field ‘f’ declared void
 void f (string);
   ^
y.C:1:9: error: ‘string’ was not declared in this scope
 void f (string);
 ^~
y.C:1:9: note: suggested alternative: ‘struct’
 void f (string);
 ^~
 struct

In contrast, clang simply prints the much clearer:

y.C:1:9: error: unknown type name 'string'

[Bug c++/68905] [DR496] __is_trivially_copyable returns True for volatile class types.

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Eric Fiselier  ---
DR 496 has been superseded by DR2094 which requires the behavior GCC currently
has:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2094

Closing as INVALID.

[Bug rtl-optimization/80358] [7 Regression] ICE (cc1 killed) building glib with -O3 on powerpc64le-linux-gnu

[acsawdey at gcc dot gnu.org]

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

--- Comment #4 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue May  9 00:03:35 2017
New Revision: 247772

URL: https://gcc.gnu.org/viewcvs?rev=247772=gcc=rev
Log:
2017-05-08  Aaron Sawdey  

Backport from trunk
PR target/80358
* config/rs6000/rs6000.c (expand_block_compare): Fix boundary check.


Modified:
branches/ibm/gcc-6-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-6-branch/gcc/config/rs6000/rs6000.c

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Bernd Paysan from comment #11)
> My guess.  He mentions that he's not a lone wolf coder, and since he didn't
> understand why mt_allocator was active, I guessed that a coworker had
> enabled it ;-).  There's no trace at all of ext/mt_allocator in the source
> code on github, but in a crappy project, you never know if they build from
> the sources they released to github.

Yeah I checked that too.

> However, with the CPP/CXX change of the environment variable: The minimal
> GCC version that builds this project is GCC 4.9... or clang 3.9, which it
> prefers to use on build if both gcc and clang are available.  So it can't
> use a too old libstdc++.

In which case using GLIBCXX_FORCE_NEW means they are intentionally switching to
a custom allocator in production without testing if it works, and then blaming
libstdc++. Or they're linking to some 3rd party library build with an ancient
libstdc++. Or setting the env var was just voodoo and didn't change anything in
libstdc++.

So I still see nothing close to a useful bug report, and I've wasted several
hours that could have been spent fixing real bugs in the current codebase.

[Bug c++/80683] New: Exceptions don't propagate through default member initializer

[majerech.o at gmail dot com]

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

Bug ID: 80683
   Summary: Exceptions don't propagate through default member
initializer
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: majerech.o at gmail dot com
  Target Milestone: ---

Testcase:

#include 
#include 

struct bar {
  bar() {
throw std::runtime_error{"foo"};
  }
};

struct foo {
  bar b{};
};

int
main() try {
  foo f;
} catch (std::runtime_error& e) {
  std::cerr << e.what() << '\n';
}

Running this results in terminate being called:

terminate called after throwing an instance of 'std::runtime_error'
  what():  foo

I would very much expect this code to work – i.e. the exception should be
caught in main. This code does work on Clang 3.9.1 and I couldn't find any
reason in the standard for why the exception shouldn't be allowed to propagate.

Stepping through the code in GDB reveals that after throwing, the call-stack
unwinds all the way to foo's constructor and goes to std::terminate from there,
as if foo::foo() were noexcept.

Changing foo to

struct foo {
  bar b;
};

makes the bug go away. I.e. it only happens when a default member initializer
is used.

I've reproduced this on GCC 6.3.1 and GCC 8.0.0 20170507.

[Bug c++/80682] New: __is_trivially_constructible(void, int) returns true.

[eric at efcs dot ca]

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

Bug ID: 80682
   Summary: __is_trivially_constructible(void, int) returns true.
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Reproducer:

// g++ -std=c++11 -fsyntax-only
static_assert(!__is_trivially_constructible(void, int), "");

This seems blatantly incorrect.

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[bernd at net2o dot de]

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

--- Comment #11 from Bernd Paysan  ---
(In reply to Jonathan Wakely from comment #10)
> > which he need to disable first
> > (after a coworker had enabled it somewhere in the source code):
> 
> Where did you get that information? The blog post says nothing about a
> coworker enabling mt_allocator, it strongly implies that the mt allocator
> pooling is on by default and is why libstdc++ is "broken".

My guess.  He mentions that he's not a lone wolf coder, and since he didn't
understand why mt_allocator was active, I guessed that a coworker had enabled
it ;-).  There's no trace at all of ext/mt_allocator in the source code on
github, but in a crappy project, you never know if they build from the sources
they released to github.

However, with the CPP/CXX change of the environment variable: The minimal GCC
version that builds this project is GCC 4.9... or clang 3.9, which it prefers
to use on build if both gcc and clang are available.  So it can't use a too old
libstdc++.

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Bernd Paysan from comment #9)
> (In reply to Jonathan Wakely from comment #2)
> > "I dropped in jemalloc and ran the test. CPU usage dropped but otherwise
> > this had no effect."
> > 
> > i.e. jemalloc was not proposed as a solution.
> 
> That's the first attempt, before he discovered that there is another
> allocator (likely mt_alloc) lurking inside,

There is nothing "lurking inside", the author is deeply mistaken that anything
sits between operator new and the C library. The history of operator new can be
seen at
https://gcc.gnu.org/git/?p=gcc.git;a=history;f=libstdc%2B%2B-v3/libsupc%2B%2B/new_op.cc;h=1c19d4477668242eea1803b76e2638fbd699fe92;hb=HEAD
and has been largely unchanged since October 6, 2000.

> which he need to disable first
> (after a coworker had enabled it somewhere in the source code):

Where did you get that information? The blog post says nothing about a coworker
enabling mt_allocator, it strongly implies that the mt allocator pooling is on
by default and is why libstdc++ is "broken".

> "It turns out that there is a somewhat convoluted way to disable it
> globally: set the environment variable "GLIBCPP_FORCE_NEW". After doing
> this, CPU use increased slightly but memory use stabilized. Recalling
> jemalloc I now once again tried sticking it under the controller in place of
> glibc's malloc and both CPU load and memory use dropped to substantially
> less than either stock configuration. More importantly everything became
> stable once again."

Yes I was too busy facepalming by the time I got to the end to notice the
second reference to jemalloc.

> If the "GLIBCPP_FORCE_NEW" is not a typo, we can nail down the version he
> used to somewhere at least 14 years old (because the environment variable is
> now called GLIBCXX_FORCE_NEW).

Right, so unsupported and unmaintained. We're not interested in bug reports for
GCC 3.x or 4.x releases.

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[bernd at net2o dot de]

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

--- Comment #9 from Bernd Paysan  ---
(In reply to Jonathan Wakely from comment #2)
> "I dropped in jemalloc and ran the test. CPU usage dropped but otherwise
> this had no effect."
> 
> i.e. jemalloc was not proposed as a solution.

That's the first attempt, before he discovered that there is another allocator
(likely mt_alloc) lurking inside, which he need to disable first (after a
coworker had enabled it somewhere in the source code):

"It turns out that there is a somewhat convoluted way to disable it globally:
set the environment variable "GLIBCPP_FORCE_NEW". After doing this, CPU use
increased slightly but memory use stabilized. Recalling jemalloc I now once
again tried sticking it under the controller in place of glibc's malloc and
both CPU load and memory use dropped to substantially less than either stock
configuration. More importantly everything became stable once again."

If the "GLIBCPP_FORCE_NEW" is not a typo, we can nail down the version he used
to somewhere at least 14 years old (because the environment variable is now
called GLIBCXX_FORCE_NEW).

[Bug c++/80681] New: missing -Wuninitialized for const or reference member of a private base class

[msebor at gcc dot gnu.org]

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

Bug ID: 80681
   Summary: missing -Wuninitialized for const or reference member
of a private base class
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

G++ issues -Wuninitialized for uninitialized private const data or reference
members of classes with no constructors because there is no other way to
initialize them.

However, G++ neglects to issue the same warning when an uninitialized public
const data or reference member is defined in a base class that is privately
derived by a class without constructors, even though such a member also cannot
be initialized.

In addition, the C++ warning is not entirely correctly documented.  The manual
states that:

  In C++, warn if a non-static reference or non-static const member appears in
a class without constructors. 

However, G++ only issues the warning when the member is inaccessible (private
or protected).


$ cat y.C && gcc -S -Wall -Wextra y.C
struct A1 { private: const int i; };// warning, good

struct B1 { const int j; }; // no warning, good

struct C1: private B1 { };  // bug: missing warning


struct A2 { private: const int  };   // warning, good

struct B2 { const int  };// no warning, good

struct C2: private B2 { };  // bug: missing warning

y.C:1:32: warning: non-static const member ‘const int A1::i’ in class without a
constructor [-Wuninitialized]
 struct A1 { private: const int i; };// warning, good
^
y.C:8:33: warning: non-static reference ‘const int& A2::i’ in class without a
constructor [-Wuninitialized]
 struct A2 { private: const int  };   // warning, good
 ^

[Bug tree-optimization/80680] New: dead code elimination fails to remove unreferenced function

[zmahler at openmailbox dot org]

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

Bug ID: 80680
   Summary: dead code elimination fails to remove unreferenced
function
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zmahler at openmailbox dot org
  Target Milestone: ---

With the following code, gcc will produce code for yes() even though it is not
referenced anymore after optimization.
Less problematic but probably related is that the call to no() is surprisingly
not inlined,
and the size of the code in the optimized away branch seems to have an
influence on that.

#include 

static inline void yes(void) { puts("yes"); }
static inline void no(void) { puts("no"); }

static inline void test(int v)
{
if (v & 1) {
printf("%d%d%d%d%d%d%d%d%d%d", 1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
}
(v ? yes : no)();
}

int main(void) { test(0); }

00400430 :
  400430:   48 83 ec 08 subrsp,0x8
  400434:   e8 07 01 00 00  call   400540 
  400439:   31 c0   xoreax,eax
  40043b:   48 83 c4 08 addrsp,0x8
  40043f:   c3  ret

00400540 :
  400540:   bf e4 05 40 00  movedi,0x4005e4
  400545:   e9 d6 fe ff ff  jmp400420 
  40054a:   66 0f 1f 44 00 00   nopWORD PTR [rax+rax*1+0x0]

00400550 :
  400550:   bf e7 05 40 00  movedi,0x4005e7
  400555:   e9 c6 fe ff ff  jmp400420 
  40055a:   66 0f 1f 44 00 00   nopWORD PTR [rax+rax*1+0x0]

$ gcc --version
gcc (SUSE Linux) 6.3.1 20170202 [gcc-6-branch revision 245119]

[Bug bootstrap/80677] LIMITS_H_TEST is wrong

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
On Mon, 8 May 2017, helmut at subdivi dot de wrote:

> False negatives: Debian is about to further multiarch. That involves moving
> libc headers from /usr/include to /usr/include/$(DEB_HOST_MULTIARCH) as libc
> headers can differ for different libc implementations (glibc/musl/uclibc). 
> Thus
> the test will wrongly fail even for libcs that provide a limits.h.

Well, if headers move then configure (and related) tests that look at them 
will need updating.  See how gcc/configure.ac looks in $target_header_dir 
to identify the glibc version and various other configuration, for 
example.

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle  ---
I wonder if we should back port this as well since the bug can have a serious
performance hit without it. ?

[Bug c/80428] Incorrect -Wunused-const-variable= instance

[tom.rini at gmail dot com]

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

Tom Rini  changed:

   What|Removed |Added

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

--- Comment #2 from Tom Rini  ---
OK, digging into this quite hard I found that indeed, during SPL builds for
U-Boot, the code in question (or rather, the functions that use it) are never
referenced, but only some times do we generate the warning, and in other times
we do not.  In all cases (again, for U-Boot) we use
-fdata-sections/-ffunction-sections/--gc-sections and discard.

In sum, there is a bug here in that the compiler should have been issuing this
warning in a lot more cases, but I do not have the time / expertise to generate
a stand-alone testcase.  As I was reporting this as a warning when it shouldn't
warn, but it turns out to be warning when it should be warning (and _not_
warning when it _should_ be warning), I'm movinv this to resolved/invalid.

[Bug target/69868] vec_perm built-in is not handled by swap optimization on powerpc64le

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Author: wschmidt
Date: Mon May  8 21:03:45 2017
New Revision: 247759

URL: https://gcc.gnu.org/viewcvs?rev=247759=gcc=rev
Log:
[gcc]

2016-05-08  Bill Schmidt  

Backport from mainline
PR target/69868 + swap optimization backports
* config/rs6000/rs6000.c (swap_web_entry): Enlarge
special_handling bitfield.
(special_handling_values): Add SH_XXPERMDI, SH_CONCAT, SH_VPERM,
and SH_VPERM_COMP.
(const_load_sequence_p): New.
(load_comp_mask_p): New.
(v2df_reduction_p): New.
(rtx_is_swappable_p): Perform special handling for XXPERMDI and
for reductions.
(insn_is_swappable_p): Perform special handling for VEC_CONCAT,
V2DF reductions, and various permutes.
(adjust_xxpermdi): New.
(adjust_concat): New.
(find_swapped_load_and_const_vector): New.
(replace_const_vector_in_load): New.
(adjust_vperm): New.
(adjust_vperm_comp): New.
(handle_special_swappables): Call adjust_xxpermdi, adjust_concat,
adjust_vperm, and adjust_vperm_comp.
(replace_swap_with_copy): Allow vector NOT operations to also be
replaced by copies.
(dump_swap_insn_table): Handle new special handling values.

[gcc/testsuite]

2016-05-08  Bill Schmidt  

Backport from mainline
PR target/69868 + swap optimization backports
* gcc.target/powerpc/swaps-p8-20.c: New.
* gcc.target/powerpc/swaps-p8-23.c: New.
* gcc.target/powerpc/swaps-p8-24.c: New.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/swaps-p8-23.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/swaps-p8-24.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/80679] call of overloaded is ambiguous

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-08
 Ever confirmed|0   |1

[Bug translation/80280] Missing closing quote (%>) c/semantics.c and c/c-typeck.c

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Mon May  8 20:50:24 2017
New Revision: 247758

URL: https://gcc.gnu.org/viewcvs?rev=247758=gcc=rev
Log:
gcc/ChangeLog:

PR translation/80280
* config/sol2-c.c (solaris_pragma_align): Correct quoting.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sol2-c.c

[Bug c++/80679] New: call of overloaded is ambiguous

[thomas.sanchz at gmail dot com]

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

Bug ID: 80679
   Summary: call of overloaded is ambiguous
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.sanchz at gmail dot com
  Target Milestone: ---

Hi,
First reported there https://github.com/mapbox/jni.hpp/pull/17
The following code is compiling fine on clang but fails on g++


template 
class Method {};

template 
void Call(const Method&, const Args&... args) {}

template 
void Call(const Method&, const Args&... args) {}

int main() {
Call(Method(), int());
}


Cheers,

[Bug libstdc++/80676] basic_stringbuf does not use initial capacity of SSO string

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-08
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The fix is trivial:

--- a/libstdc++-v3/include/std/sstream
+++ b/libstdc++-v3/include/std/sstream
@@ -99,7 +99,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   explicit
   basic_stringbuf(ios_base::openmode __mode = ios_base::in |
ios_base::out)
   : __streambuf_type(), _M_mode(__mode), _M_string()
-  { }
+  {
+#if _GLIBCXX_USE_CXX11_ABI
+   _M_stringbuf_init(__mode);
+#endif
+  }

   /**
*  @brief  Starts with an existing string buffer.

There was no point calling _M_stringbuf_init for the COW string, because
immediately after construction there was no buffer to use. With an SSO string
that isn't true.

[Bug c++/80178] Class with deleted copy and move constructors uses wrong argument passing ABI

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon May  8 19:08:07 2017
New Revision: 247757

URL: https://gcc.gnu.org/viewcvs?rev=247757=gcc=rev
Log:
PR c++/80178 - parameter passing for uncopyable classes

* tree.c (type_has_nontrivial_copy_init): True for classes with only
deleted copy/move ctors.
(remember_deleted_copy, maybe_warn_parm_abi): New.
* decl.c (require_complete_types_for_parms, check_function_type):
Call maybe_warn_parm_abi.
* call.c (convert_for_arg_passing, build_cxx_call): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/abi/invisiref1.C
trunk/gcc/testsuite/g++.dg/abi/invisiref1a.C
Modified:
trunk/gcc/common.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/tree.c

[Bug tree-optimization/80647] vectorized loop crashes from wrongly assuming 16 byte alignment

[yzhang1985 at gmail dot com]

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

--- Comment #2 from Yale Zhang  ---
Very interesting case. First, I didn't know unaligned loads were undefined
behavior on x86.

ICC 17 doesn't vectorize the loop probably because the destination and source
of the memmove() alias.

But apparently GCC knows how to vectorize memmove(). In this function, the
destination always comes before the source, so it's trivial to vectorize.
Vectorizing the case where destination > source is harder, and I wonder if GCC
can do that.


This is some legacy code from > 10 years ago. Manually vectorizing the
memmove() was too smart for modern compilers.

But the solution is simple. I'll just use the other simple, fallback
implementation used on unknown platforms. It's still vectorizable though.

thanks Andrew.

[Bug other/80678] New: g++.dg/cpp1y/constexpr-79681-2.C fails with ICE starting with r247678

[seurer at gcc dot gnu.org]

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

Bug ID: 80678
   Summary: g++.dg/cpp1y/constexpr-79681-2.C fails with ICE
starting with r247678
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

The backported test g++.dg/cpp1y/constexpr-79681-2.C fails with an ICE on
powerpcle:

spawn /home/seurer/gcc/build/gcc-6/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-6/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-6/gcc/testsuite/g++.dg/cpp1y/constexpr-79681-2.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-6/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-6/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-6/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-6/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-6/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++14 -O2 -S -o constexpr-79681-2.s
/home/seurer/gcc/gcc-6/gcc/testsuite/g++.dg/cpp1y/constexpr-79681-2.C:38:20:  
in constexpr expansion of 'foo()'
/home/seurer/gcc/gcc-6/gcc/testsuite/g++.dg/cpp1y/constexpr-79681-2.C:38:26:
internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2363
0x1036f2db cxx_eval_bit_field_ref
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:2363
0x1036f2db cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:4003
0x1037091b cxx_eval_binary_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:1835
0x1036e553 cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3960
0x1037091b cxx_eval_binary_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:1835
0x1036e553 cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3960
0x1037091b cxx_eval_binary_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:1835
0x1036e553 cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3960
0x103703db cxx_eval_store_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3296
0x1036db3b cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3780
0x1036dddf cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3792
0x1037196b cxx_eval_statement_list
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3504
0x1036db0b cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:4129
0x1036dc13 cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:4184
0x1036c85f cxx_eval_call_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:1546
0x1036e5b3 cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3702
0x1036929b cxx_eval_outermost_constant_expr
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:4292
0x10371d03 maybe_constant_value_1
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:4486
0x10371d03 maybe_constant_value(tree_node*, tree_node*)
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:4510
0x10356fcb cp_fold
/home/seurer/gcc/gcc-6/gcc/cp/cp-gimplify.c:2261
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-6/gcc/testsuite/g++.dg/cpp1y/constexpr-79681-2.C:38:20:  
in constexpr expansion of 'foo()'
/home/seurer/gcc/gcc-6/gcc/testsuite/g++.dg/cpp1y/constexpr-79681-2.C:38:26:
internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2363
0x1036f2db cxx_eval_bit_field_ref
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:2363
0x1036f2db cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:4003
0x1037091b cxx_eval_binary_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:1835
0x1036e553 cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3960
0x1037091b cxx_eval_binary_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:1835
0x1036e553 cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3960
0x1037091b cxx_eval_binary_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:1835
0x1036e553 cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3960
0x103703db cxx_eval_store_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3296
0x1036db3b cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3780
0x1036dddf cxx_eval_constant_expression
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3792
0x1037196b cxx_eval_statement_list
/home/seurer/gcc/gcc-6/gcc/cp/constexpr.c:3504
0x1036db0b 

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[tkoenig at gcc dot gnu.org]

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

--- Comment #14 from Thomas Koenig  ---
Author: tkoenig
Date: Mon May  8 18:22:44 2017
New Revision: 247755

URL: https://gcc.gnu.org/viewcvs?rev=247755=gcc=rev
Log:
2017-05-08  Thomas Koenig  

PR fortran/79930
* frontend-passes.c (matmul_to_var_expr): New function,
add prototype.
(matmul_to_var_code):  Likewise.
(optimize_namespace):  Use them from gfc_code_walker.

2017-05-08  Thomas Koenig  

PR fortran/79930
* gfortran.dg/inline_transpose_1.f90:  Add
-finline-matmul-limit=0 to options.
* gfortran.dg/matmul_5.f90:  Likewise.
* gfortran.dg/vect/vect-8.f90: Likewise.
* gfortran.dg/inline_matmul_14.f90:  New test.
* gfortran.dg/inline_matmul_15.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/inline_matmul_14.f90
trunk/gcc/testsuite/gfortran.dg/inline_matmul_15.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/inline_transpose_1.f90
trunk/gcc/testsuite/gfortran.dg/matmul_5.f90
trunk/gcc/testsuite/gfortran.dg/vect/vect-8.f90

[Bug debug/80646] [5/6/7 Regression] wrong type info for extern inline function when compiling Emacs

[eggert at gnu dot org]

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

--- Comment #3 from Paul Eggert  ---
(In reply to Richard Biener from comment #1)

> So I start to belive this is a gdb bug.

Thanks, I filed a GDB bug report here:

https://sourceware.org/bugzilla/show_bug.cgi?id=21473

[Bug c/80677] New: LIMITS_H_TEST is wrong

[helmut at subdivi dot de]

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

Bug ID: 80677
   Summary: LIMITS_H_TEST is wrong
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helmut at subdivi dot de
  Target Milestone: ---

LIMITS_H_TEST is a Makefile variable defined in gcc/Makefile.in, that
determines how to generate its own limits.h, in particular whether to use
limitx.h and limity.h. The test simply tests whether
$(BUILD_SYSTEM_HEADER_DIR)/limits.h exists and for most practical purposes this
tests whether /usr/include/limits.h exists.

When the build and target architectures equal, this is fine. When they don't
bad things happen.

False positives: When building on a typical GNU/Linux system for a baremetal
target, the test indicates wrongly indicates success.

False negatives: Debian is about to further multiarch. That involves moving
libc headers from /usr/include to /usr/include/$(DEB_HOST_MULTIARCH) as libc
headers can differ for different libc implementations (glibc/musl/uclibc). Thus
the test will wrongly fail even for libcs that provide a limits.h.

It seems that the false positive is present since ages and nobody ever noticed.
Thus it probably is harmless.

The false negative generates a limits.h that disagrees on MB_LEN_MAX with glibc
and breaks builds. (# error "Assumed value of MB_LEN_MAX wrong" when including
 after )

Thus I propose setting "LIMITS_H_TEST = :" (i.e. always assuming limits.h
presence) as an improved heuristic. I also tried invoking $(GCC_FOR_TARGET) -E
to check for limits.h presence, but since configure.ac overwrites the
GCC_FOR_TARGET defined in gcc/Makefile.in, the required -isystem flags are
missing and it has no chance of finding the header.

[Bug libstdc++/80676] New: basic_stringbuf does not use initial capacity of SSO string

[redi at gcc dot gnu.org]

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

Bug ID: 80676
   Summary: basic_stringbuf does not use initial capacity of SSO
string
   Product: gcc
   Version: 8.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: ---

The following prints "overflow":

#include 
#include 

struct SB : std::stringbuf
{
  int_type overflow(int_type c) override
  {
std::cout << "overflow\n";
return std::stringbuf::overflow(c);
  }
};

int main()
{
  SB sb;
  std::ostringstream s;
  s.std::ios::rdbuf();
  s.put('a');
}

The call to the virtual function should not be necessary when using the new
ABI, because the SSO string has an initial non-zero capacity. The stringbuf
could use it.

[Bug libfortran/80602] Reduce stack usage for blocked matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Mon May  8 17:56:13 2017
New Revision: 247753

URL: https://gcc.gnu.org/viewcvs?rev=247753=gcc=rev
Log:
2017-05-08  Thomas Koenig  

PR fortran/80602
* m4/matmul_internal.m4:  'matmul_name`:  Change
t1 to a VLA of the required size.
* generated/matmul_c10.c: Regenerated.
* generated/matmul_c16.c: Regenerated.
* generated/matmul_c4.c: Regenerated.
* generated/matmul_c8.c: Regenerated.
* generated/matmul_i1.c: Regenerated.
* generated/matmul_i16.c: Regenerated.
* generated/matmul_i2.c: Regenerated.
* generated/matmul_i4.c: Regenerated.
* generated/matmul_i8.c: Regenerated.
* generated/matmul_r10.c: Regenerated.
* generated/matmul_r16.c: Regenerated.
* generated/matmul_r4.c: Regenerated.
* generated/matmul_r8.c: Regenerated.

2017-05-08  Thomas Koenig  

PR fortran/80602
* gfortran.dg/matmul_15.f90:  New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/matmul_15.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.in
trunk/libgfortran/generated/matmul_c10.c
trunk/libgfortran/generated/matmul_c16.c
trunk/libgfortran/generated/matmul_c4.c
trunk/libgfortran/generated/matmul_c8.c
trunk/libgfortran/generated/matmul_i1.c
trunk/libgfortran/generated/matmul_i16.c
trunk/libgfortran/generated/matmul_i2.c
trunk/libgfortran/generated/matmul_i4.c
trunk/libgfortran/generated/matmul_i8.c
trunk/libgfortran/generated/matmul_r10.c
trunk/libgfortran/generated/matmul_r16.c
trunk/libgfortran/generated/matmul_r4.c
trunk/libgfortran/generated/matmul_r8.c
trunk/libgfortran/m4/matmul_internal.m4

[Bug middle-end/35412] Correctness with -ftrapv depended on libcall notes

[r030t1 at gmail dot com]

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

R0b0t1  changed:

   What|Removed |Added

 CC||r030t1 at gmail dot com

--- Comment #9 from R0b0t1  ---
Please fix. Per the documentation available `-fsantize=undefined` provides some
of the missing functionality but does not allow the program's flow to be
altered.

[Bug fortran/80668] wrong error message with -finit-derived

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

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

[Bug libstdc++/80675] New: Incorrect implementation of LWG 2534

[redi at gcc dot gnu.org]

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

Bug ID: 80675
   Summary: Incorrect implementation of LWG 2534
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

struct X { };

std::ostream& operator<<(std::ostream& os, const X&) { return os; }

struct O : std::ostream { };

void operator<<(O&, X) = delete;

int main()
{
  O{} << X{};
}

This should compile, because the operator<<(basic_ostream&&, const T&)
overload should be chosen by overload resolution.

However we implement the "os << t is valid" constrain using the wrong type, as
we do it on the derived type, not after conversion to basic_ostream.

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

Bug 68600 Summary: Inlined MATMUL is too slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/37131] inline matmul for small matrix sizes

[jvdelisle at gcc dot gnu.org]

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

Bug 68600 Summary: Inlined MATMUL is too slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/68600] Inlined MATMUL is too slow.

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #16 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #15)
> I think that with the current status, where
> we have -finline-matmul-limit=30 by default, we
> can close this bug.
> 
> Agreed?

Yes, this can be closed.

[Bug fortran/80674] New: trunk/gcc/fortran/trans-stmt.c:2578]: (style) Redundant condition

[dcb314 at hotmail dot com]

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

Bug ID: 80674
   Summary: trunk/gcc/fortran/trans-stmt.c:2578]: (style)
Redundant condition
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk/gcc/fortran/trans-stmt.c:2578]: (style) Redundant condition: cp->low. '!A
|| (A && B)' is equivalent to '!A || B'

Source code is

  if (!cp->low
  || (cp->low
  && mpz_cmp (cp->low->value.integer,
  cp->high->value.integer) != 0))

[Bug target/80672] gcc/config/sh/sh.c:716: prefer compare to find.

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Unrelated issue in the same file:

trunk/gcc/config/sh/sh.c:10817]: (style) Expression is always false because
'else if' condition matches previous condition at line 10803.

  else if (scratch0 != scratch1)
{
  else if (scratch0 != scratch1)
{

[Bug bootstrap/80673] New: sparcv9-solaris2.11 bootstrap error: cannot convert ‘format_std_version {enum}’ to ‘const char*’ in initialization

[msebor at gcc dot gnu.org]

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

Bug ID: 80673
   Summary: sparcv9-solaris2.11 bootstrap error: cannot convert
‘format_std_version {enum}’ to ‘const char*’ in
initialization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

A cross-build of the sparcv9-solaris2.11 target on a x86_64-linux host fails
with the following error and shows the warnings below.

/src/gcc/80280/gcc/config/sol2-c.c:46:1: error: cannot convert
‘format_std_version {enum}’ to ‘const char*’ in initialization
 };
 ^
/src/gcc/80280/gcc/config/sol2-c.c:46:1: warning: missing initializer for
member ‘format_flag_spec::std’ [-Wmissing-field-initializers]
/src/gcc/80280/gcc/config/sol2-c.c:46:1: error: cannot convert
‘format_std_version {enum}’ to ‘const char*’ in initialization
/src/gcc/80280/gcc/config/sol2-c.c:46:1: warning: missing initializer for
member ‘format_flag_spec::std’ [-Wmissing-field-initializers]
/src/gcc/80280/gcc/config/sol2-c.c:46:1: error: cannot convert
‘format_std_version {enum}’ to ‘const char*’ in initialization
/src/gcc/80280/gcc/config/sol2-c.c:46:1: warning: missing initializer for
member ‘format_flag_spec::std’ [-Wmissing-field-initializers]
/src/gcc/80280/gcc/config/sol2-c.c: In function ‘void
solaris_pragma_align(cpp_reader*)’:
/src/gcc/80280/gcc/config/sol2-c.c:116:24: warning: ‘D’ conversion used
unquoted [-Wformat=]
"%D, ignoring", decl);
^
/src/gcc/80280/gcc/config/t-sol2:21: recipe for target 'sol2-c.o' failed
make[2]: *** [sol2-c.o] Error 1

[Bug libstdc++/80624] char_traits::eof() doesn't meet requirements

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Some more examples of misbehaviour caused by eof() being a valid character:

#include 
#include 

int main()
{
 std::basic_ostringstream s;
 s.put(u'\u');
 assert( s.str().length() == 1 );
}

a.out: ex.cc:8: int main(): Assertion `s.str().length() == 1' failed.
Aborted (core dumped)


#include 

int main()
{
 std::basic_ostringstream s(u"foo");
 s.exceptions(std::ios_base::badbit);
 s.put(u'\u');
}

terminate called after throwing an instance of 'std::ios_base::failure'
 what():  basic_ios::clear
Aborted (core dumped)


#include 
#include 

int main()
{
  const char16_t  = u'\u';
  std::basic_istringstream s(u"\uoo");
  s.exceptions(std::ios_base::eofbit);
  assert( s.rdbuf()->in_avail() > 1 );
  auto c = s.get();
}

terminate called after throwing an instance of 'std::ios_base::failure'
  what():  basic_ios::clear
Aborted (core dumped)

[Bug target/80672] New: gcc/config/sh/sh.c:716: prefer compare to find.

[dcb314 at hotmail dot com]

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

Bug ID: 80672
   Summary: gcc/config/sh/sh.c:716: prefer compare to find.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk/gcc/config/sh/sh.c:716]: (performance) Inefficient usage of
string::find() in condition; string::compare() would be faster.

Source code is

  else if (tokens[i].find ("gbr-offset=") == 0)

[Bug target/80671] New: config/aarch64/cortex-a57-fma-steering.c:416: bad statement order ?

[dcb314 at hotmail dot com]

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

Bug ID: 80671
   Summary: config/aarch64/cortex-a57-fma-steering.c:416: bad
statement order ?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk/gcc/config/aarch64/cortex-a57-fma-steering.c:416]: (error) Dereferencing
'other_forest' after it is deallocated / released

Source code is

  delete other_forest;

  this->m_nb_nodes += other_forest->m_nb_nodes;

Somewhat unwise to delete something then use it.
Maybe other way around would be better.

[Bug c++/80670] Member specialization of alias declaration from different namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-05-08
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Please read https://gcc.gnu.org/bugs/ and provide a testcase as requested.

[Bug fortran/80668] wrong error message with -finit-derived

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-08
 CC||foreese at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
AFAICT this has been introduced with the option (r239489). The manual says

These options do not initialize

* allocatable arrays
* variables that appear in an EQUIVALENCE statement.

This should probably apply to POINTERS.

[Bug c++/80670] New: Member specialization of alias declaration from different namespace

[om_g++bugs at keywallet dot com]

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

Bug ID: 80670
   Summary: Member specialization of alias declaration from
different namespace
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: om_g++bugs at keywallet dot com
  Target Milestone: ---

Name aliases with using-declaration are not treated equivalently to
typedef-name. Please refer to:

http://stackoverflow.com/questions/43787462/member-specialization-of-alias-declaration-in-different-namespaces/43792468

for complete investigation.

[Bug fortran/80666] character length parameter fails if declaration order incorrect

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-05-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Why do you think this a bug in gfortran?

The code compiles if you remove 'implicit none'. With it you have to define
'keylen' before using it, as in you second test.

[Bug middle-end/80669] [8 Regression] Bad -Wstringop-overflow warnings for stpncpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
The bug is expand_builtin_stpncpy working too hard (and not entirely correctly)
to compute the size of the source sequence.  It should leave it to the
check_sizes function which already does this work and does it right, like
strncpy does.  Let me fix that today.

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Bernd Paysan from comment #0)
> The documentation of mt_allocator is at least somewhat misleading:
> 
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/mt_allocator_impl.html
> 
> "Notes about deallocation. This allocator does not explicitly release
> memory."
> 
> Well, it does add freed memory to its freelists and reuse it.  It's just not
> giving back unused memory to the OS.

I've made a tweak to that text which should clarify things.

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> Using the default configuration GLIBCPP_FORCE_NEW has not made any
> difference to std::allocator since 2005 when r106665 was committed, changing
> the default back to the allocator based on new/delete.

In fact that's when the default allocator was switched to new_allocator, but
that used GLIBCXX_FORCE_NEW.

The older GLIBCPP_FORCE_NEW env var hasn't made a difference since r68958 in
2003.

[Bug fortran/80645] [8 regression] FAIL: gfortran.dg/elemental_subroutine_3.f90 -O1 (test for excess errors)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80545

--- Comment #3 from Martin Sebor  ---
The Fortran warnings will be suppressed once a fix for bug 80545 has been
implemented (and the warning enabled only for the C family of languages). 
Unfortunately, the patch I submitted for it doesn't work quite the way it needs
to and I haven't yet found a way to make it do what I want.

That said, I'll look into the latent bug Richard mentions.

[Bug middle-end/80669] [8 Regression] Bad -Wstringop-overflow warnings for stpncpy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-08
 CC||msebor at gcc dot gnu.org
Version|7.0 |8.0
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Using the default configuration GLIBCPP_FORCE_NEW has not made any difference
to std::allocator since 2005 when r106665 was committed, changing the default
back to the allocator based on new/delete.

So if GLIBCPP_FORCE_NEW made a difference then the blog post seems to be about
GCC 3.4 or something of that age, and a bug report about ancient history is
useless.

[Bug c++/80667] [c++1z] ice segfault on partial specialization with non-type template parameter

[ed at catmur dot co.uk]

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

--- Comment #1 from Ed Catmur  ---
note: the rationale for using std::integral_constant rather than a T non-type
argument is CWG 1315.

Clang rejects in -std=c++1z:

:22:63: error: ambiguous partial specializations of 'Impl >'
Impl> foo()
  ^
:13:8: note: partial specialization matches [with T = unsigned char,
MaxValue = '\x00']
struct Impl>
   ^
:18:8: note: partial specialization matches [with T = unsigned char]
struct Impl>
   ^
1 error generated.

In -std=c++14 gcc and clang both accept, and agree on using the latter partial
specialization.

I'm not clear whether the code should be rejected in -std=c++1z, or why the
behavior of the compilers is any different.  Performing the transformation in
temp.class.order, gcc rejects as ambiguous in -std=c++14, and ICEs in
-std=c++1z; clang rejects as ambiguous in -std=c++14, and selects the *former*
specialization in -std=c++1z.

[Bug middle-end/80669] New: [8 Regression] Bad -Wstringop-overflow warnings for stpncpy

[jsm28 at gcc dot gnu.org]

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

Bug ID: 80669
   Summary: [8 Regression] Bad -Wstringop-overflow warnings for
stpncpy
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

The following code (compiled with -Wall, on x86_64, trunk revision 247733)
produces a bogus warning (causing the glibc testsuite build to fail):

char buf[100];
void
f (void)
{
  __builtin_stpncpy (buf, "foo", 4);
}

t.c: In function 'f':
t.c:5:3: warning: '__builtin_stpncpy' reading 4 bytes from a region of size 3
[-Wstringop-overflow=]
   __builtin_stpncpy (buf, "foo", 4);
   ^

The region being read actually has four bytes, not three; it's NUL-terminated. 
And since it's NUL-terminated, any size argument to stpncpy, up to the size of
the destination buffer, would be OK, just as with strncpy; it only makes sense
to diagnose a read buffer overrun for strncpy or stpncpy if the source buffer
has no NUL bytes and the size is too big for it.  In any case, the same
warnings should be given for both strncpy and stpncpy, which means not warning
for this test case (just as a corresponding test with strncpy does not warn).

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Feel free to try to reproduce it or try to contact them. When we have a
reproducer, or even a valgrind report, then a bug report might be useful. Until
then it's not useful. "I read blog that said there's a bug" is not a bug
report.

[Bug fortran/80668] New: wrong error message with -finit-derived

[valeryweber at hotmail dot com]

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

Bug ID: 80668
   Summary: wrong error message with -finit-derived
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com
  Target Milestone: ---

Dear All

The following code is producing wrong error message with -finit-derived

thanks
v


MODULE pw_hfx
  IMPLICIT NONE
  TYPE :: dist_t
 INTEGER :: TYPE,nblks_loc,nblks
 INTEGER,DIMENSION(:),POINTER :: dist
  END TYPE dist_t

CONTAINS

  SUBROUTINE hfx_new()
TYPE(dist_t) :: dist
CALL release_dist(dist)
  END SUBROUTINE hfx_new

  SUBROUTINE release_dist(dist)
TYPE(dist_t) :: dist
  END SUBROUTINE release_dist
END MODULE pw_hfx


gfortran-trunk -c  -finit-derived -finit-integer=1234567890
-finit-logical=false -finit-real=snan  pw_hfx.mod.F90 
pw_hfx.mod.F90:5:41:

  INTEGER,DIMENSION(:),POINTER :: dist
 1
Error: The element in the structure constructor at (1), for pointer component
‘dist’ should be a POINTER or a TARGET
pw_hfx.mod.F90:5:41:

  INTEGER,DIMENSION(:),POINTER :: dist
 1
Error: Pointer initialization target at (1) must have the SAVE attribute

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[bernd at net2o dot de]

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

--- Comment #4 from Bernd Paysan  ---
So we close that without having tried to reproduce it?  I would have put it
into "needinfo" mode, and ask that blog poster to actually fill in the gaps,
like "which version of libstdc++", "did you use the default allocator" and
such.  I lack the information to reproduce it, either.

If he doesn't want to cooperate, we can close it as "worksforme".

[Bug c++/80664] Destructor not called upon exception while initializing a vector

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
NEW doesn't mean it's recent, it means it's been confirmed. If it hadn't been
confirmed it would be UNCONFIRMED.

[Bug c++/80662] libstdc++ basic_string casting oddity

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Reduced thanks to K-ballo:

extern "C" int puts(const char*);

template
void operator<<(C&&, T const&) { puts("non-member"); }

struct my_stream {
template 
void operator<<(T&&) { puts("member"); }
};

int main()
{
my_stream{} << "hello world";
}

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Jonathan Wakely  ---
The blog post links to an unofficial copy of the libstdc++ documentation from
2004, which would explain the bogus claims about libstdc++ allocation policies.

I'm going to close this, as I don't feel like wasting time on it. The ZeroTier
blog post is simply misinformed and misleading and has no useful information.

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-05-08
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
(In reply to Bernd Paysan from comment #0)
> This not very friendly blog entry contains a report of a memory leak in
> libstdc++ ("worst bug of my entire career"):
> 
> https://www.zerotier.com/blog/2017-05-05-theleak.shtml
> 
> Including a not very easy way to reproduce it (by installing their software
> and stress-testing it).  Apparently he didn't file a bug report here.

No, and that blog post is full of incorrect statements like "libstdc++
"helpfully" adds its own memory allocator layer between you and the C library.
This one implements its own caching and pooling, and searching around the web
yields many examples of people complaining about it."

That's simply not true. In the default configuration of libstdc++,
std::allocator uses new/delete and which just call malloc/free. There's no
caching and pooling at all.


> Solution proposed there: link against jemalloc (it's under BSDL),
> performance goes up, memory consumption stays low, i.e. neither use glibc's
> "too slow" malloc() nor use libstdc++'s memory allocator (still slower than
> jemalloc).

No, that's not what it says:

"I dropped in jemalloc and ran the test. CPU usage dropped but otherwise this
had no effect."

i.e. jemalloc was not proposed as a solution.

> Due to #1, we don't even know how many people are affected by the bug. 

What bug?

[Bug c++/80667] New: [c++1z] ice segfault on partial specialization with non-type template parameter

[mathias at gaunard dot com]

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

Bug ID: 80667
   Summary: [c++1z] ice segfault on partial specialization with
non-type template parameter
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathias at gaunard dot com
  Target Milestone: ---

Building the following code with std=c++1z

#include 

template
struct traits
{
static constexpr T const_min = 0;
};

template 
class Impl;

template
struct Impl>
{
};

template
struct Impl>
{
};

Impl> foo()
{
return {};
}

gives

test.cpp: In function ‘Impl > foo()’:
test.cpp:22:67: internal compiler error: Segmentation fault
 Impl> foo()
   ^
0xb118ef crash_signal
../../gcc-src/gcc/toplev.c:337
0x61b925 unify
../../gcc-src/gcc/cp/pt.c:20292
0x61c8d1 unify
../../gcc-src/gcc/cp/pt.c:20573
0x61c319 unify
../../gcc-src/gcc/cp/pt.c:20764
0x61c4d7 unify
../../gcc-src/gcc/cp/pt.c:20843
0x61c319 unify
../../gcc-src/gcc/cp/pt.c:20764
0x61d971 get_partial_spec_bindings
../../gcc-src/gcc/cp/pt.c:21561
0x61db83 more_specialized_partial_spec
../../gcc-src/gcc/cp/pt.c:21436
0x61ddd9 most_specialized_partial_spec
../../gcc-src/gcc/cp/pt.c:21856
0x62e66b instantiate_class_template_1
../../gcc-src/gcc/cp/pt.c:10230
0x62e66b instantiate_class_template(tree_node*)
../../gcc-src/gcc/cp/pt.c:10798
0x691e75 complete_type(tree_node*)
../../gcc-src/gcc/cp/typeck.c:133
0x5ecffc check_function_type
../../gcc-src/gcc/cp/decl.c:14662
0x5ecffc start_preparsed_function(tree_node*, tree_node*, int)
../../gcc-src/gcc/cp/decl.c:14883
0x6000f3 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../gcc-src/gcc/cp/decl.c:15199
0x686c97 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-src/gcc/cp/parser.c:26129
0x686c97 cp_parser_init_declarator
../../gcc-src/gcc/cp/parser.c:19159
0x68796d cp_parser_simple_declaration
../../gcc-src/gcc/cp/parser.c:12777
0x688575 cp_parser_block_declaration
../../gcc-src/gcc/cp/parser.c:12602
0x666ec4 cp_parser_declaration
../../gcc-src/gcc/cp/parser.c:12500
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Works fine without std=c++1z, alternatively a workaround is to add a cast in
the second partial specialization.

[Bug c++/80665] dynamic cast on nullptr leads to segfault

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
To clarify Richard's statement in the following statement is undefined
Derived* snd_ptr = fst_ptr->as();

When fst_ptr is a null pointer.

[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #10 from Jason Merrill  ---
The committee has recently started indicating explicitly whether a particular
DR is intended to apply to the existing standard or only to the next one; most
fall into the former category.  We weren't doing that at the time of DR 903,
but it clearly is intended to resolve an issue introduced in C++11 with
constexpr, so I think it clearly should apply.

[Bug c++/80662] libstdc++ basic_string casting oddity

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #4 from Jonathan Wakely  ---
And further:

namespace std
{
  struct ostream
  {
ostream& operator<<(const char*)
{
  return *this;
}
  };

#ifndef UNCONSTRAINED
  // GCC 7 code

  template
inline ostream&
operator<<(_Ostream&& __os, const _Tp&__x)
{
  return __os;
}
#else
  // GCC 6 code

  template
inline ostream&
operator<<(ostream&& __os, const _Tp&)
{
  return __os;
}
#endif
}

struct my_stream : public std::ostream {
template
my_stream& operator<<(T&& value)
{
std::ostream::operator<<(value);
return *this;
}
};

int main()
{
my_stream& s = (my_stream{} << "hello world");
}

G++ chooses std::operator<<

Clang chooses my_stream::operator<<

EDG and VC++ say they're ambiguous.

Changing to component=c++, but I'm not convinced G++ is actually wrong here.

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #7 from Xi Ruoyao  ---
std::basic_string<...> is too large.  Replace it with a dummy
default constructable and copyable class Foo.  Then get GIMPLE:

  _1 = &->a;
  _2 = std::vector::at (, 0);
  Foo::Foo (_1, _2);
  _3 = &->b;
  _4 = std::vector::at (, 2);
  Foo::Foo (_3, _4);
  return ;

No exception handling code here.

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Andrzej Krzemienski from comment #5)
> What does this mean that the status of this bug report is "NEW"? It is 2
> years old. In GCC Bugzilla one can assign status "CONFIRMED" to bug reports.
> Why is this one not confirmed? Was nobody able to confirm that this bug
> exists in GCC?
> 
> It really looks serious, as it undermines C++'s exception safety rules and
> guarantees.

Calm down. NEW means confirmed, otherwise it would be UNCONFIRMED.
Writing trollish blog posts won't get the bug fixed any sooner.

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

[akrzemi1 at gmail dot com]

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

--- Comment #5 from Andrzej Krzemienski  ---
What does this mean that the status of this bug report is "NEW"? It is 2 years
old. In GCC Bugzilla one can assign status "CONFIRMED" to bug reports. Why is
this one not confirmed? Was nobody able to confirm that this bug exists in GCC?

It really looks serious, as it undermines C++'s exception safety rules and
guarantees.

[Bug libstdc++/80662] libstdc++ basic_string casting oddity

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Further reduced:

namespace std
{
  // 
  struct string
  {
string(const char* s) : str(s) { }

const char* str;
  };

  // 
  template
struct basic_ostream
{
  basic_ostream& operator<<(const char*)
  {
return *this;
  }
};

  using ostream = basic_ostream;

  inline ostream
  operator<<(ostream& os, const string& s)
  {
os << s.str;
return os;
  }

#ifndef UNCONSTRAINED
  // GCC 7 code

  template
struct __is_convertible_to_basic_ostream
{
  template
  static basic_ostream<_Ch>& __check(basic_ostream<_Ch>*);

  static void __check(void*) = delete;

  using ostream_type = decltype(__check((_Tp*)0));
};

  template
struct __is_convertible_to_basic_ostream<_Tp&>
{
};

  template
inline typename __is_convertible_to_basic_ostream<_Ostream>::ostream_type
operator<<(_Ostream&& __os, const _Tp& __x)
{
  __os << __x;
  return __os;
}
#else
  // GCC 6 code

  template
inline basic_ostream<_CharT, _Traits>&
operator<<(basic_ostream<_CharT, _Traits>&& __os, const _Tp& __x)
{
  __os << __x;
  return __os;
}
#endif
}

struct my_stream : public std::ostream {
template
my_stream& operator<<(T&& value)
{
std::ostream::operator<<(value);
return *this;
}
};

int main()
{
my_stream& s = (my_stream{} << "hello world");
}

[Bug c++/80664] Destructor not called upon exception while initializing a vector

[akrzemi1 at gmail dot com]

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

--- Comment #5 from Andrzej Krzemienski  ---
Thank you for pointing this out. Can anything be done to fix this PR 66139? It
has status "NEW" but is in fact quite old. In the comments above, you have
provided some substantial analysis of the source of the problem. The duplicate
you refer to (PR 66139) does not contain any analysis. It seams to be
abandoned. It is not even "CONFIRMED".

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||akrzemi1 at gmail dot com

--- Comment #4 from Richard Biener  ---
*** Bug 80664 has been marked as a duplicate of this bug. ***

[Bug c++/80664] Destructor not called upon exception while initializing a vector

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
It's the same bug.

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

[Bug c++/80664] Destructor not called upon exception while initializing a vector

[d25fe0be at outlook dot com]

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

--- Comment #3 from d25fe0be@  ---
Is this related to PR 66139?

[Bug libstdc++/80662] libstdc++ basic_string casting oddity

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC|jwakely.gcc at gmail dot com   |ville at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
There's no implicit cast, it's because my_stream{} is an rvalue, so uses the
overload for rvalue streams:

  template 
basic_ostream&
operator<<(basic_ostream&& os, const T& x);

This returns the base class (as all the standard operator<< overloads do).

The only difference between gcc 6 and 7 is that operator is constrained, as
required by https://wg21.link/lwg2534 and G++ selects the constrained overload
rather than the member my_stream::operator<< (maybe because it's more
specialized, not sure yet). Clang always selects the member function, whether
the other one is constrained or not. EDG incorrectly says there's an ambiguous
overload.

So I don't think this is a libstdc++ bug, the changes to the libstdc++ code are
correct and required for conformance. G++ seems to be choosing the wrong
overload.

Reduced:

namespace std
{
  // 
  struct true_type { static constexpr bool value = true; };
  struct false_type { static constexpr bool value = false; };

  template struct enable_if { using type = T; };
  template<> struct enable_if { };

  template struct is_same : false_type { };
  template struct is_same : true_type { };

  template struct remove_reference { using type = T; };
  template struct remove_reference { using type = T; };
  template struct remove_reference { using type = T; };

  template struct is_lvalue_reference : false_type { };
  template struct is_lvalue_reference : true_type { };

  template T declval();

  template using void_t = void;

  template
struct conditional
{
  using type = If;
};

  template
struct conditional
{
  using type = Else;
};

  template struct __and_;

  template
struct __and_
: conditional::type
{ };

  template
struct __and_
: conditional, false_type>::type
{ };

  template
struct __not_ : conditional::type { };

  // 
  template
T&& forward(T& t) { return static_cast(t); }

  // 
  template struct char_traits { };

  struct string
  {
string(const char* s) : str(s) { }

const char* str;
  };

  // 
  template>
struct basic_ostream
{
  basic_ostream& operator<<(const char*)
  {
return *this;
  }
};

  using ostream = basic_ostream;

  inline ostream
  operator<<(ostream& os, const string& s)
  {
os << s.str;
return os;
  }

#ifndef UNCONSTRAINED
  // GCC 7 code

  template
struct __is_convertible_to_basic_ostream
{
  template
  static basic_ostream<_Ch, _Up>& __check(basic_ostream<_Ch, _Up>*);

  static void __check(...);
public:
  using ostream_type =
decltype(__check(declval::type*>()));
  constexpr static bool value = !is_same::value;
};

  template
struct __is_insertable : false_type {};

  template
struct __is_insertable<_Ostream, _Tp,
   void_t()
   << declval())>>
: true_type {};

  template
inline
typename enable_if<__and_<__not_>,
   __is_convertible_to_basic_ostream<_Ostream>,
   __is_insertable<_Ostream&, const _Tp&>>::value,
   typename __is_convertible_to_basic_ostream<
 _Ostream>::ostream_type>::type
operator<<(_Ostream&& __os, const _Tp& __x)
{
  __os << __x;
  return __os;
}
#else
  // GCC 6 code

  template
inline basic_ostream<_CharT, _Traits>&
operator<<(basic_ostream<_CharT, _Traits>&& __os, const _Tp& __x)
{
  __os << __x;
  return __os;
}
#endif
}

struct my_stream : public std::ostream {
template
my_stream& operator<<(T&& value)
{
std::ostream::operator<<(std::forward(value));
return *this;
}
};

int main()
{
my_stream& s = (my_stream{} << "hello world");
}

[Bug c++/80665] dynamic cast on nullptr leads to segfault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
'this' may never be NULL.

[Bug middle-end/79665] gcc's signed (x*x)/200 is slower than clang's

[tnfchris at gcc dot gnu.org]

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

--- Comment #18 from tnfchris at gcc dot gnu.org ---
Author: tnfchris
Date: Mon May  8 09:45:46 2017
New Revision: 247734

URL: https://gcc.gnu.org/viewcvs?rev=247734=gcc=rev
Log:
2017-05-08  Tamar Christina  

PR middle-end/79665
* expr.c (expand_expr_real_2): Move TRUNC_MOD_EXPR, FLOOR_MOD_EXPR,
CEIL_MOD_EXPR, ROUND_MOD_EXPR cases.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/expr.c

[Bug fortran/80666] New: character length parameter fails if declaration order incorrect

[kloedej at knmi dot nl]

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

Bug ID: 80666
   Summary: character length parameter fails if declaration order
incorrect
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kloedej at knmi dot nl
  Target Milestone: ---

For gfortran v.6.3.1 (on Fedora 25) I noticed that this example code:

subroutine test_arg_order(key,keylen)
  implicit none
  character*(keylen), intent(in) :: key
  integer, intent(in):: keylen
end subroutine test_arg_order

gives the error:

>gfortran -c test.F90
test.F90:3:13:

   character*(keylen), intent(in) :: key
 1
Error: Scalar INTEGER expression expected at (1)
test.F90:1:29:

 subroutine test_arg_order(key,keylen)
 1
Error: Symbol ‘key’ at (1) has no IMPLICIT type
>

But if the order of declarations of the parameters is reversed in the
subroutine definition (but for identical order in the parameter list) it works
as expected:

subroutine test_arg_order(key,keylen)
  implicit none
  integer, intent(in):: keylen
  character*(keylen), intent(in) :: key
end subroutine test_arg_order

>gfortran -c test.F90
>

i.e. no error in this case.

Both versions of the code still compiled without error on older gfortran 4.8.x
versions (redhat 7).

The same error message was triggered in the case reported for bug #68108, but
to me this seems a different use case.

[Bug c++/80665] dynamic cast on nullptr leads to segfault

[abenkhadra at protonmail dot com]

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

--- Comment #1 from abenkhadra  ---
A small clarification: the segfault happens upon executing the produced binary
and not in g++ itself.

[Bug c++/80664] Destructor not called upon exception while initializing a vector

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-08
 Ever confirmed|0   |1
  Known to fail||4.8.5, 7.1.0

--- Comment #2 from Richard Biener  ---
.original shows it:

;; Function int main() (null)
;; enabled by -tree-original


{
  <<< Unknown tree: try_block
  {
struct vector v;

struct vector v;
< >::vector (, TARGET_EXPR  , TARGET_EXPR ::~vector ();
  }
  }
  <<< Unknown tree: handler

  try
{
  <;
}
  finally
{
  __cxa_end_catch ();
} >>> >>>;
}

eh, so the construction is not in the try block!

[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Keith Thompson from comment #6)
> (I question the policy of implementing DRs that have not been approved
> by the committee. As I understand it, the existence of a DR merely means
> that *someone* thinks there's a defect in the standard. Many DRs are
> eventually rejected.)

No, many issues that get submitted are eventually rejected, and are closed as
NAD. If it has DR status it means it's been accepted by the committee.

(In reply to Keith Thompson from comment #8)
> That's a surprising interpretation of the word "amendment".

It's the normal Enmglish meaning of the word.

> Searching isocpp.org and other sites, I haven't found any official reference
> to an "amendment" to the C++ standard.  The nearest thing I've found, which
> is referenced in the gcc documentation, is the 1995 amendment to the 1990
> ISO C standard, "ANSI/ISO/IEC 9899-1990/AM 1-1995".  That's definitely not
> a DR.  (The C and C++ standard committees use similar procedures.)

It's not an official ISO term, it's just English.

> Does g++ implement *all* DRs reported against C++11?

Reported? No, because not every issue reported is a DR.

Ideally we implement all issues with DR status. Some aren't implemented, but
that's usually just because it hasn't been done yet.

[Bug c++/80665] New: dynamic cast on nullptr leads to segfault

[abenkhadra at protonmail dot com]

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

Bug ID: 80665
   Summary: dynamic cast on nullptr leads to segfault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abenkhadra at protonmail dot com
  Target Milestone: ---

Dynamic casts on nullptr should return nullptr as per C++ Standard §5.2.7/4.
However, g++ v6.2 segfaults while executing a dynamic_cast wrapped in a
non-virtual method belonging to a parent class. The assumed bug is produced
only at optimization levels higher than -O0.

That is, the code snippet with the following flags doesn't produce the bug

g++ -std=c++11  -Wall -Wextra -Wpedantic -O0 main.cpp -o test

However, compiling it with the following flags does produce a segfault 

g++ -std=c++11  -Wall -Wextra -Wpedantic -O2 main.cpp -o test

Note that the following code snippet works on clang v3.8 and g++ v5.4 without
problems. 

Code snippet:
-

#include 
class Base{
public:
int foo;

template
T* as()
{
return dynamic_cast(this);
}
  virtual ~Base() = default;
};

class Derived: public Base {
public:
  int bar;
};

int main(void) {
Derived* fst_ptr = nullptr;
std::cout << "g++ 6.2 segfaults executing next statement" << std::endl;
Derived* snd_ptr = fst_ptr->as();
std::cout << "Other compilers segfault on last statement as expected" <<
std::endl;
return (*snd_ptr).foo;
}



Platform:
-
Used the prepackaged binary of g++ v6.2 for Ubuntu 16.04.2 

Compiler details:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
6.2.0-3ubuntu11~16.04' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~16.04) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra'
'-Wpedantic' '-O0' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/6/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE main.cpp -mtune=generic -march=x86-64 -std=c++11
-Wall -Wextra -Wpedantic -O0 -fpch-preprocess -fstack-protector-strong
-Wformat-security -o main.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/6"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/6/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/6
 /usr/include/x86_64-linux-gnu/c++/6
 /usr/include/c++/6/backward
 /usr/lib/gcc/x86_64-linux-gnu/6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra'
'-Wpedantic' '-O0' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/6/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -O0 -Wall -Wextra
-Wpedantic -std=c++11 -version -fstack-protector-strong -Wformat-security -o
main.s
GNU C++11 (Ubuntu 6.2.0-3ubuntu11~16.04) version 6.2.0 20160901
(x86_64-linux-gnu)
compiled by GNU C version 6.2.0 20160901, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++11 (Ubuntu 6.2.0-3ubuntu11~16.04) version 6.2.0 20160901
(x86_64-linux-gnu)
compiled by GNU C version 6.2.0 20160901, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param 

[Bug rtl-optimization/75964] insn combiner removes comparison after ABS

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to rsand...@gcc.gnu.org from comment #5)
> Fixed on trunk.  It doesn't look like it's a regression, but maybe we want
> to backport anyway?

We usually backport wrong-code fixes to active branches if easily possible.

[Bug rtl-optimization/75964] insn combiner removes comparison after ABS

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay  ---
(In reply to rsand...@gcc.gnu.org from comment #5)
> It doesn't look like it's a regression, but maybe we want to backport anyway?

Would be great.  It's wrong code after all, and the fix appears to be low
intrusive and without side effects.

[Bug c++/80664] Destructor not called upon exception while initializing a vector

[akrzemi1 at gmail dot com]

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

--- Comment #1 from Andrzej Krzemienski  ---
This happens on all C++11 GCC versions.

[Bug c++/80664] New: Destructor not called upon exception while initializing a vector

[akrzemi1 at gmail dot com]

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

Bug ID: 80664
   Summary: Destructor not called upon exception while
initializing a vector
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akrzemi1 at gmail dot com
  Target Milestone: ---

The following program logs calls to successful constructors and destructors of
class `R`. I expect the number of constructions to equal the number of
destructions. But when second construction fails, the destructor of the
previously fully created object is not called. This is becayse shared_ptr's
destructor is skipped! This happens when list-initializing a vector of
shared_ptr's: 

```
#include 
#include 
#include 
#include 

void acquire_resource() // emulates failure to acquire the second resource
{
  static int resources_exhausted = 0;
  if (resources_exhausted) 
throw std::runtime_error("failed");
  else
++resources_exhausted;
}

struct R
{
  explicit R(int)
  {
  acquire_resource();
  std::puts("create"); 
  }

  R(R const&) = delete; // no copying, no moving

  ~R() { std::puts("destroy"); }
};

int main()
{
  try {
std::vector v {
  std::make_shared(1), // created, but never destroyed
  std::make_shared(2)  // creation fails for this one
};
  }
  catch (...) {}
}
```

I consider the bug serious as it undermines the trust in C++'s "RAII
philosophy".

[Bug c++/80577] Avoid using adj in member function pointers

[drepper.fsp+rhbz at gmail dot com]

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

--- Comment #3 from drepper.fsp+rhbz at gmail dot com  ---
(In reply to drepper.fsp+r...@gmail.com from comment #2)
> final isn't necessary in this case.  An object is used and the type is known.

Ignore this comment, wrong bug.

[Bug c++/80577] Avoid using adj in member function pointers

[drepper.fsp+rhbz at gmail dot com]

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

--- Comment #2 from drepper.fsp+rhbz at gmail dot com  ---
final isn't necessary in this case.  An object is used and the type is known.

[Bug c++/80660] Member function pointer optimization affected by incompatible virtual function

[drepper.fsp+rhbz at gmail dot com]

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

--- Comment #2 from drepper.fsp+rhbz at gmail dot com  ---
final shouldn't be needed in this case.  It's an object that is used, the type
is known.

[Bug c++/80660] Member function pointer optimization affected by incompatible virtual function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-08
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Note that AFAIK we do not use 'final' for code generation yet.

[Bug sanitizer/80659] [7/8 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||6.3.1
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-05-08
  Component|c   |sanitizer
 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
 Ever confirmed|0   |1
Summary|[7 regression]  |[7/8 Regression]
   |-fsanitize=address evokes   |-fsanitize=address evokes
   |ICE in in   |ICE in in
   |gimplify_switch_expr|gimplify_switch_expr
   Target Milestone|--- |7.2
  Known to fail||7.1.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/80655] -Werror=format-truncation inconsistency between x86_32 and x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
sprintf pass doesn't run close to VRP so the optimization opportunity could
have been exposed later.

[Bug tree-optimization/80652] [5 Regression] Union conversion between __m128d and double array does not work under 5.0 through 6.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||rguenth at gcc dot gnu.org
  Component|c++ |tree-optimization
  Known to work||4.9.4, 6.3.0
Summary|Union conversion between|[5 Regression] Union
   |__m128d and double array|conversion between __m128d
   |does not work under 5.0 |and double array does not
   |through 6.2 |work under 5.0 through 6.2
  Known to fail||5.1.0, 5.4.0, 6.2.0

--- Comment #4 from Richard Biener  ---
Probably a pending/missing backport of a fix applied for GCC 6.3 so one could
bisect the GCC 6 branch for the fix.

[Bug tree-optimization/80652] [5 Regression] Union conversion between __m128d and double array does not work under 5.0 through 6.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-08
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

[Bug debug/80646] [5/6/7 Regression] wrong type info for extern inline function when compiling Emacs

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I used gdb 7.12.1 btw.