[Bug fortran/80477] New: Polymorphic functions (thus operators) generates memory leaks

[stefano.zaghi at cnr dot it]

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

Bug ID: 80477
   Summary: Polymorphic functions (thus operators) generates
memory leaks
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefano.zaghi at cnr dot it
  Target Milestone: ---

Created attachment 41241
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41241=edit
Code test to raise the memory leaks

Dear all,
I faced with a possible serious bug: polymorphic functions (necessary to define
polymorphic operators in OOP programs) generate memory leaks making OOP program
not feasible.

In the attached example "polymorphic_operators_memory_leaks.f90" I show the
possible bug in less than 100 lines. Essentially, the derived type "a_type_t"
defines the operators "=" and "+" in a polymorphic way (in order to allow
"a_type_t" to be extended while all other "agents" using "a_type_t" do not need
to be changed, OOP). The assignment operator does not create memory leaks
because it is subroutine that does not allocate temporary. On the contrary, the
operator "+" is a function that allocates a temporary: this temporary generates
the memory leaks because it is not correctly destroyed after its usage.

I checked the above conclusion with "valgrind" and it confirms that the "+"
operator (function) generates the leaks. Note that the same code compiled and
run with Intel Fortran (17.0.2) does not generates memory leaks and it works as
expected. Moreover, is the "+" operator/function is modified disallowing
polymorphic (namely changing "class(a_type_t), allocatable :: res" with
"type(a_type_t) :: res" the leaks disappear, thus I could conclude that the
leaks are generated only for polymorphic function results.

A word of advice: the test is designed to point out the memory leaks
occurrences, running it your RAM will be quickly consumed! Please, be rapid to
quickly kill it before your OS start swapping on HD. To test it with valgrind I
added a little "ui": it can be executed without arguments, thus its loop will
be very long (and your RAM totally consumed) or you can pass one integer
argument and the loop will do the iterations you provided, e.g. "a.out 1" will
execute 1 iteration loop. This is written into the code comments.

Please, consider that if this is really a bug, all serious OOP programs are
indeed impossible to be done.

Thank you very much for your help.

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

  Attachment #41239|0   |1
is obsolete||

--- Comment #37 from PeteVine  ---
Comment on attachment 41239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41239
Assembly files produced with -fverbose-asm

Wrong bug, sorry. I can't get used to bugzilla jumping to the next issue on
posting a comment.

[Bug libstdc++/54924] Warn for std::string constructor with wrong size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
The patch for bug 79214 should take care of the -Wno-system-header problem.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79214
[Bug 79214] -Wno-system-header defeats strncat buffer overflow warnings

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

--- Comment #13 from PeteVine  ---
Created attachment 41240
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41240=edit
Assembly files produced with -fverbose-asm

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #36 from PeteVine  ---
Created attachment 41239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41239=edit
Assembly files produced with -fverbose-asm

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

--- Comment #12 from PeteVine  ---
It even reproduces the following way:

I built an instrumented ARMv7 binary natively, ran it on a Cortex-A53, copied
the gcda file back, recompiled with -fprofile-use and got the same 20%
slowdown.

Surely, that must count (pun intended) for something, as both CPU's are
in-order designs.

[Bug middle-end/79234] warn on past the end reads by library functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-20
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00925.html

[Bug bootstrap/80476] GCC 7 can't be compiled with bootstrap-O3

[mikulas at artax dot karlin.mff.cuni.cz]

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

mikulas at artax dot karlin.mff.cuni.cz changed:

   What|Removed |Added

 CC||mikulas at artax dot 
karlin.mff.cu
   ||ni.cz

--- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz ---
Created attachment 41238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41238=edit
failed build log

[Bug bootstrap/80476] New: GCC 7 can't be compiled with bootstrap-O3

[mikulas at artax dot karlin.mff.cuni.cz]

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

Bug ID: 80476
   Summary: GCC 7 can't be compiled with bootstrap-O3
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

When compiling GCC 7 with -O3 (using the configure flag
--with-build-config=bootstrap-O3), it fails due to uninitialized variables.

This is the script to compile GCC:

#!/bin/sh
set -e
MAKEFLAGS=-j12
export MAKEFLAGS
../gcc-7-20170416/configure \
--prefix=/usr/local/gcc/\
--enable-lto\
--with-system-zlib  \
--enable-languages=c,c++\
--enable-multilib   \
--with-multilib-list=m32,m64,mx32   \
--with-build-config=bootstrap-O3\
&&
nice -n 20 make bootstrap

This is the result:

In file included from ../../gcc-7-20170416/gcc/target.h:53:0,
 from ../../gcc-7-20170416/gcc/ira-color.c:25:
../../gcc-7-20170416/gcc/hard-reg-set.h: In function 'bool
ira_reassign_pseudos(int*, int, HARD_REG_ELT_TYPE*, HARD_REG_ELT_TYPE (*)[2],
HARD_REG_ELT_TYPE (*)[2], bitmap)':
../../gcc-7-20170416/gcc/hard-reg-set.h:174:18: error: '*((void*)& saved +24)'
may be used uninitialized in this function [-Werror=maybe-uninitialized]
  scan_tp_[1] = scan_fp_[1]; } while (0)
  ^
../../gcc-7-20170416/gcc/ira-color.c:4327:16: note: '*((void*)& saved +24)' was
declared here
   HARD_REG_SET saved[2];
^
In file included from ../../gcc-7-20170416/gcc/target.h:53:0,
 from ../../gcc-7-20170416/gcc/ira-color.c:25:
../../gcc-7-20170416/gcc/hard-reg-set.h:173:18: error: '*((void*)& saved +16)'
may be used uninitialized in this function [-Werror=maybe-uninitialized]
  scan_tp_[0] = scan_fp_[0]; \
  ^
../../gcc-7-20170416/gcc/ira-color.c:4327:16: note: '*((void*)& saved +16)' was
declared here
   HARD_REG_SET saved[2];
^
In file included from ../../gcc-7-20170416/gcc/target.h:53:0,
 from ../../gcc-7-20170416/gcc/ira-color.c:25:
../../gcc-7-20170416/gcc/hard-reg-set.h:174:18: error: '*((void*)& saved +8)'
may be used uninitialized in this function [-Werror=maybe-uninitialized]
  scan_tp_[1] = scan_fp_[1]; } while (0)
  ^
../../gcc-7-20170416/gcc/ira-color.c:4327:16: note: '*((void*)& saved +8)' was
declared here
   HARD_REG_SET saved[2];
^
In file included from ../../gcc-7-20170416/gcc/target.h:53:0,
 from ../../gcc-7-20170416/gcc/ira-color.c:25:
../../gcc-7-20170416/gcc/hard-reg-set.h:173:18: error: 'saved' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
  scan_tp_[0] = scan_fp_[0]; \
  ^
../../gcc-7-20170416/gcc/ira-color.c:4327:16: note: 'saved' was declared here
   HARD_REG_SET saved[2];
^
cc1plus: all warnings being treated as errors
Makefile:1106: návod pro cíl ,,ira-color.o" selhal
make[3]: *** [ira-color.o] Chyba 1
make[3]: *** Čeká se na nedokončené úlohy...
rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gfdl.pod gcc.pod gcov-dump.pod
gcov-tool.pod
make[3]: Opouští se adresář ,,/usr/src/gcc-7.1.0-test/gcc"
Makefile:4588: návod pro cíl ,,all-stage2-gcc" selhal
make[2]: *** [all-stage2-gcc] Chyba 2
make[2]: Opouští se adresář ,,/usr/src/gcc-7.1.0-test"
Makefile:22065: návod pro cíl ,,stage2-bubble" selhal
make[1]: *** [stage2-bubble] Chyba 2
make[1]: Opouští se adresář ,,/usr/src/gcc-7.1.0-test"
Makefile:22268: návod pro cíl ,,bootstrap" selhal
make: *** [bootstrap] Chyba 2

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

--- Comment #11 from PeteVine  ---
I've just retested gcc7 on both ARM platforms. 

AArch64 gets a 3% improvement now, while ARMv7 reproduces the issue, just as
before. I'm compiling/profiling on a Cortex A5 which could be the main reason
behind all this, as it doesn't have hard division.

[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM

[ramana at gcc dot gnu.org]

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

--- Comment #17 from Ramana Radhakrishnan  ---
Created attachment 41237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41237=edit
AArch64 prototype.

Patch.

[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM

[ramana at gcc dot gnu.org]

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

--- Comment #16 from Ramana Radhakrishnan  ---
(In reply to Jakub Jelinek from comment #10)
> aarch64_function_arg_alignment
> has:
>   for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
> alignment = std::max (alignment, DECL_ALIGN (field));
> and thus has similar problem (no testcases in this case though).

A prototype fix (needs tidying up for sure!) that warns for aarch64 is as
attached. There are no regressions on a full bootstrap and test run. I would be
grateful for any comments.

Note that I haven't managed to actually trigger an ABI warning because of this
on aarch64. 

Note that this is dependent on clarification with respect to the AAPCS . 

I'm not yet happy with the amount of refactoring we have to do to get the
warnings on ARM.


regards
Ramana

[Bug libstdc++/80251] Is the is_aggregate meta function missing?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug target/79804] ICE in print_reg, at config/i386/i386.c:17637

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.0 |8.0

--- Comment #5 from Uroš Bizjak  ---
Fixed.

[Bug target/79804] ICE in print_reg, at config/i386/i386.c:17637

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Apr 20 20:25:17 2017
New Revision: 247037

URL: https://gcc.gnu.org/viewcvs?rev=247037=gcc=rev
Log:
PR target/79804
* config/i386/i386.c (print_reg): Remove assert for disalowed
regno values, call output_operand_lossage instead.

testsuite/ChangeLog:

PR target/79804
* gcc.target/i386/pr79804.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr79804.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/80425] Extra inter-unit register move with zero-extension

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
We have the following fragment:

8: r96:DI=zero_extend(r93:SI)
   REG_DEAD r93:SI
   13: r91:V8DI#0=r95:V16SI>>r96:DI
   REG_DEAD r96:DI
   REG_DEAD r95:V16SI

IRA allocates general regs to r96 and r93.  And it means insn 8
alternative (0) r (1) rmWz {*zero_extendsidi2} as requiring no any
reload.

So why does IRA choose general regs for r96 instead of SSE ones.  For insn 8 we
have the following alternatives:

"=...r   ,...,?*Ym,..."
"... rmWz,...,r   ,..."

Alternative '?*Ym, r' discourages usage of SSE regs as Y has *
(exluded from pseudo class consideration).  It is also discouraged in
LRA as it has ?

So I don't know how to fix it in IRA or in LRA.  I am pretty sure the
old RA and reload would have had the same problem.

Probably the issue should be fixed in machine dependent code.  But the fix
might create more problems.

[Bug libstdc++/80251] Is the is_aggregate meta function missing?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Author: ville
Date: Mon Apr  3 15:57:06 2017
New Revision: 246651

URL: https://gcc.gnu.org/viewcvs?rev=246651=gcc=rev
Log:
Implement std::is_aggregate.
* include/std/type_traits (is_aggregate, is_aggregate_v): New.
* testsuite/20_util/is_aggregate/requirements/explicit_instantiation.cc:
New.
* testsuite/20_util/is_aggregate/requirements/typedefs.cc: Likewise.
* testsuite/20_util/is_aggregate/value.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/20_util/is_aggregate/
trunk/libstdc++-v3/testsuite/20_util/is_aggregate/requirements/
   
trunk/libstdc++-v3/testsuite/20_util/is_aggregate/requirements/explicit_instantiation.cc
trunk/libstdc++-v3/testsuite/20_util/is_aggregate/requirements/typedefs.cc
trunk/libstdc++-v3/testsuite/20_util/is_aggregate/value.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits

[Bug tree-optimization/79534] [7/8 Regression] tree-ifcombine aarch64 performance regression with trunk@245151

[brzycki at gmail dot com]

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

--- Comment #11 from Brian Rzycki  ---
HI James, if you don't see any major regressions and some good uplifts I
understand if this case is considered marginal. From my perspective I think
it's best to close this ticket and move on to more pressing issues.  Thank you
for analyzing this.

[Bug target/78090] [x86_64]: GCC allows integer register for inter unit conversion under -mtune-ctrl=^inter_unit_conversions .

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
Fixed.

[Bug libstdc++/54924] Warn for std::string constructor with wrong size

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
As a heads up, with the patch for bug 79234 applied and with -Wsystem-headers
explicitly specified GCC issues the warnings below (the -Warray-bounds is
printed even without the patch).  Unfortunately, with the default
-Wno-system-headers, warnings from std::string and the rest of libstdc++
headers are suppressed.

$ cat t.C && /build/gcc-79234/gcc/xg++ -B /build/gcc-79234/gcc -nostdinc++ -I
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I /build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include -I
/src/gcc/79234/libstdc++-v3/libsupc++ -I
/src/gcc/79234/libstdc++-v3/include/backward -I
/src/gcc/79234/libstdc++-v3/testsuite/util -L
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -O2 -S -Wall
-Wsystem-headers t.C

#include 

std::string s ("abc", 5);

In file included from
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:66:0,
 from
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:39,
 from
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/string:40,
 from t.C:1:
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_iterator_base_funcs.h:
In function ‘(static initializers for t.C)’:
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_iterator_base_funcs.h:104:21:
warning: array subscript is above array bounds [-Warray-bounds]
   return __last - __first;
  ~~~^
In file included from
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/string:40:0,
 from t.C:1:
In static member function ‘static std::char_traits::char_type*
std::char_traits::copy(std::char_traits::char_type*, const
char_type*, std::size_t)’,
inlined from ‘static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy(_CharT*, const _CharT*, std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::size_type) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’ at
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:324:21,
inlined from ‘void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_construct(_InIterator, _InIterator, std::forward_iterator_tag)
[with _FwdIterator = const char*; _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’,
inlined from ‘void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_construct(_InIterator, _InIterator) [with _InIterator = const
char*; _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:220:23,
inlined from ‘std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(const _CharT*, std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’ at
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:486:21,
inlined from ‘void __static_initialization_and_destruction_0(int, int)’ at
t.C:3:24,
inlined from ‘(static initializers for t.C)’ at t.C:3:25:
/build/gcc-79234/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:292:66:
warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’
reading 5 bytes from a region of size 4 [-Wstringop-overflow=]
  return static_cast(__builtin_memcpy(__s1, __s2, __n));
  ^

[Bug target/78090] [x86_64]: GCC allows integer register for inter unit conversion under -mtune-ctrl=^inter_unit_conversions .

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Apr 20 19:04:36 2017
New Revision: 247036

URL: https://gcc.gnu.org/viewcvs?rev=247036=gcc=rev
Log:
PR target/78090
* config/i386/constraints.md (Yc): New register constraint.
* config/i386/i386.md (*float2_mixed):
Use Yc constraint for alternative 2 of operand 0.  Remove
preferred_for_speed attribute.

testsuite/ChangeLog:

PR target/78090
* gcc.target/i386/conversion-2.c: Remove obsolete test.


Removed:
trunk/gcc/testsuite/gcc.target/i386/conversion-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/constraints.md
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #11 from Jonathan Wakely  ---
This has been fixed by PR 80473 (I probably should have just changed the
component for this bug rather than create another one).

We can revisit simplifying the traits once Daniel's new bug is fixed, but for
now there's nothing more to be done.

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

[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||m...@sven-woop.de

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

[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for gcc 7

[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu Apr 20 18:36:27 2017
New Revision: 247035

URL: https://gcc.gnu.org/viewcvs?rev=247035=gcc=rev
Log:
PR c++/80473 allow suppressing notes about over-aligned new

Backport from mainline r247033
gcc/cp:

PR c++/80473
* init.c (build_new_1): Suppress notes about over-aligned new when
the warning is suppressed.

gcc/testsuite:

PR c++/80473
* g++.dg/diagnostic/pr80473.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/diagnostic/pr80473.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/init.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu Apr 20 18:02:05 2017
New Revision: 247033

URL: https://gcc.gnu.org/viewcvs?rev=247033=gcc=rev
Log:
PR c++/80473 allow suppressing notes about over-aligned new

gcc/cp:

PR c++/80473
* init.c (build_new_1): Suppress notes about over-aligned new when
the warning is suppressed.

gcc/testsuite:

PR c++/80473
* g++.dg/diagnostic/pr80473.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/diagnostic/pr80473.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/61806] [C++11] Expression sfinae w/o access gives hard error in partial template specializations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2014-12-14 00:00:00 |2017-4-20

--- Comment #2 from Jonathan Wakely  ---
EDG accepts it too.

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[daniel.kruegler at googlemail dot com]

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

--- Comment #10 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Daniel Krügler from comment #6)
> > Do you recommend to reopen 51222 or should I open a separate bug? I'm
> > inclined to create a new one at the moment.
> 
> Agreed, let's have a new bug for that.

I have just created DR 80475.

[Bug c++/80475] New: Unevaluated combined delete new expression doesn't handle access error in class template SFINAE

[daniel.kruegler at googlemail dot com]

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

Bug ID: 80475
   Summary: Unevaluated combined delete new expression doesn't
handle access error in class template SFINAE
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.kruegler at googlemail dot com
  Target Milestone: ---

The following code, compiled with gcc 7.0.1 20170419 (experimental) using the
flags

-Wall -Wextra -std=c++11 -pedantic

or - alternatively -

-Wall -Wextra -std=c++1z -pedantic

//---
struct true_type 
{
  static const bool value = true;
};

struct false_type 
{
  static const bool value = false;
};

template
T&& declval();

template
struct is_direct_constructible_impl : false_type
{ };

template
struct is_direct_constructible_impl
: true_type
{ };

struct S
{
  S(int);
};

struct DCS
{
  DCS(int) = delete;
};

struct PCS
{
private:
  PCS(int);
};

struct DDS 
{
  DDS(int);
  ~DDS() = delete;
};

struct PDS 
{
  PDS(int);
private:
  ~PDS() = default;
};

int main() 
{
  static_assert(is_direct_constructible_impl::value, "Ouch");
  static_assert(!is_direct_constructible_impl::value, "Ouch");
  static_assert(!is_direct_constructible_impl::value, "Ouch");
  static_assert(!is_direct_constructible_impl::value, "Ouch");
  static_assert(!is_direct_constructible_impl::value, "Ouch");
}
//---

is rejected with the following diagnostics:


prog.cc: In instantiation of 'struct is_direct_constructible_impl':
prog.cc:57:56:   required from here
prog.cc:20:25: error: 'PCS::PCS(int)' is private within this context
   decltype(::delete ::new T(declval()))>
 ^~~
prog.cc:37:3: note: declared private here
   PCS(int);
   ^~~
prog.cc:20:25: error: 'PCS::PCS(int)' is private within this context
   decltype(::delete ::new T(declval()))>
 ^~~
prog.cc:37:3: note: declared private here
   PCS(int);
   ^~~
prog.cc: In function 'int main()':
prog.cc:57:3: error: static assertion failed: Ouch
   static_assert(!is_direct_constructible_impl::value, "Ouch");
   ^
prog.cc:57:18: error: 'PCS::PCS(int)' is private within this context
   static_assert(!is_direct_constructible_impl::value, "Ouch");
  ^~
prog.cc:37:3: note: declared private here
   PCS(int);
   ^~~
prog.cc: In instantiation of 'struct is_direct_constructible_impl':
prog.cc:59:56:   required from here
prog.cc:22:1: error: 'PDS::~PDS()' is private within this context
 { };
 ^
prog.cc:50:3: note: declared private here
   ~PDS() = default;
   ^
prog.cc:22:1: error: 'PDS::~PDS()' is private within this context
 { };
 ^
prog.cc:50:3: note: declared private here
   ~PDS() = default;
   ^
prog.cc:59:3: error: static assertion failed: Ouch
   static_assert(!is_direct_constructible_impl::value, "Ouch");
   ^
prog.cc:59:18: error: 'PDS::~PDS()' is private within this context
   static_assert(!is_direct_constructible_impl::value, "Ouch");
  ^~
prog.cc:50:3: note: declared private here
   ~PDS() = default;
   ^


This code example is somewhat different from PR 51222 because it uses "class
template SFINAE" and is maybe related to PR 61806. 

This example occurred while discussing a possible alternative implementation of
is_constructible, see PR 80390.

[Bug c++/79078] Warnings from deprecated attribute are too noisy

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #8 from Marek Polacek  ---
One thing we should do is to

--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -12643,7 +12643,7 @@ grokparms (tree parmlist, tree *parms)
  if (deprecated_state != DEPRECATED_SUPPRESS)
{
  tree deptype = type_is_deprecated (type);
- if (deptype)
+ if (deptype && !TYPE_BEING_DEFINED (deptype))
warn_deprecated_use (deptype, NULL_TREE);
}


i.e. don't warn if the deprecated type is being defined.  For the out of class
definition like
void D::f(const D&) { }
it'd be nice if we could somehow walk the qualifying scopes and if DEPTYPE
here:
12643   if (deprecated_state != DEPRECATED_SUPPRESS)
12644 {
12645   tree deptype = type_is_deprecated (type);
12646   if (deptype && !TYPE_BEING_DEFINED (deptype))
12647 warn_deprecated_use (deptype, NULL_TREE);
12648 }
is the same as one of the scopes, don't warn.

[Bug target/78090] [x86_64]: GCC allows integer register for inter unit conversion under -mtune-ctrl=^inter_unit_conversions .

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords|ra  |
 Status|NEW |ASSIGNED
  Component|rtl-optimization|target
Version|unknown |7.0
   Target Milestone|--- |8.0

--- Comment #3 from Uroš Bizjak  ---
I have a patch in testing.

[Bug libstdc++/68397] std::tr1::expint fails in __expint_En_cont_frac for some long double arguments due to low __max_iter value

[emsr at gcc dot gnu.org]

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

--- Comment #3 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Thu Apr 20 15:41:59 2017
New Revision: 247027

URL: https://gcc.gnu.org/viewcvs?rev=247027=gcc=rev
Log:
2017-04-20  Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/68397 std::tr1::expint fails ... long double arguments.
* include/tr1/exp_integral.tcc: Increase iteration limits.
* testsuite/tr1/5_numerical_facilities/special_functions/15_expint/
pr68397.cc: New test.
* testsuite/special_functions/14_expint/pr68397.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/special_functions/14_expint/pr68397.cc
   
trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/15_expint/pr68397.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/tr1/exp_integral.tcc

[Bug tree-optimization/80457] vectorizable_condition does not update the vectorizer cost model

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
Patch here:  https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00808.html

This is being held for GCC 8.

[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
This doesn't even depend on system headers, the following prints 18 lines of
notes and location info (but no warnings) when -w is used:

template T&& declval();

template
struct is_constructible { enum { value = 0 }; };

template
struct is_constructible
{ enum { value = 1 }; };

struct alignas(64) A { int i; };

constexpr bool b = is_constructible::value;


a3.cc: In substitution of ‘template struct
is_constructible [with T = A; U = A]’:
a3.cc:12:42:   required from here
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
 struct is_constructible
^
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
a3.cc: In instantiation of ‘struct is_constructible’:
a3.cc:12:42:   required from here
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
a3.cc:7:40: note: uses ‘void* operator new(long unsigned int)’, which does not
have an alignment parameter
a3.cc:7:40: note: use ‘-faligned-new’ to enable C++17 over-aligned new support

[Bug target/71617] rs6000.c:8483:32: warning: comparison is always true due to limited range of data type [-Wtype-limits]

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
This does not seem to warn with trunk anymore.

[Bug rtl-optimization/80474] New: ipa-cp wrongly adding LO(symbol) twice

[jan.smets at nokia dot com]

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

Bug ID: 80474
   Summary: ipa-cp wrongly adding LO(symbol) twice
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

On MIPS, O32
GCC 6.3.1 (does not happen on GCC5, but there it's not similarly optimized by
ipa-cp)

I wasn't yet successful at producing a minimized testcase.

A function is called and one of the arguments is a function pointer.
On mips the symbol is loaded in two steps, the HI and the LO part.
The LO part is an increment and is happening twice, resulting in a bogus
pointer being passed.


409 INITEVENT (PP_MASK_QX,   T01, OUTRESEG_DRAM_DATA_ECC_UNCORRECTABLE_0,
0,1,
"OUTRESEG_DRAM_DATA_ECC_UNCORRE  CTABLE_0", ERROR_EVENT,   
_ext_dram_unc_err, myFunce);
0x04431644 <+11384>: beqzt4,0x4431730 
0x04431648 <+11388>: addiu   s1,s1,-9260

t4 is zero, so branches to 0x4431730 


 # BLOCK 530 freq:156 seq:526
 # PRED: 543 [69.5%]
$L599:
 #(jump_insn 4608 4607 4691 (set (pc)
 #(if_then_else (eq (reg:SI 12 $12 [orig:1564 _4488 ] [1564])
 #(const_int 0 [0]))
 #(label_ref 4678)
 #(pc))) myfile.c:409 472 {*branch_equalitysi}
 # (int_list:REG_BR_PROB 5000 (nil))
 # -> 4678)
beq $12,$0,$L592 # 4608 *branch_equalitysi  [length = 4]
 #(insn 4691 4608 27788 (set (reg/f:SI 17 $17 [6100])
 #(lo_sum:SI (reg/f:SI 17 $17 [6102])
 #(symbol_ref:SI ("myFunce") [flags 0x3] ))) 300 {*lowsi}
 # (expr_list:REG_EQUAL (symbol_ref:SI ("myFunce") [flags 0x3]
)
 #(nil)))
addiu   $17,$17,%lo(myFunce)# 4691 *lowsi  [length = 4]


s1 is now 0x442dbd4 , which is myFunce()

 77370x04431730 <+11620>: bnezt2,0x4439a0c 
 77380x04431734 <+11624>: addiu   s1,s1,-9260

t2 is 0x2000, so branches to 0x4439a0c and changes s1 from 0x442dbd4 (correct)
to 0x442b7a8 (incorrect)


 # BLOCK 545 freq:78 seq:541
 # PRED: 530 [50.0%] 
$L592:
 #(jump_insn 4680 4679 15195 (set (pc)
 #(if_then_else (ne (reg:SI 10 $10 [orig:456 prephitmp_915 ] [456]) 
 #(const_int 0 [0]))
 #(label_ref 15192) 
 #(pc))) myfile.c:409 472 {*branch_equalitysi}
 # (int_list:REG_BR_PROB 7002 (nil)) 
 # -> 15192) 
bne $10,$0,$L601 # 4680 *branch_equalitysi  [length = 4]
 #(insn/s 15195 4680 4681 (set (reg/f:SI 17 $17 [6100])
 #(lo_sum:SI (reg/f:SI 17 $17 [6102])
 #(symbol_ref:SI ("myFunce") [flags 0x3] ))) 300 {*lowsi}
 # (expr_list:REG_EQUAL (symbol_ref:SI ("myFunce") [flags 0x3]
)
 #(nil)))
addiu   $17,$17,%lo(myFunce)# 15195*lowsi  [length = 4]

[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.2

[Bug target/57796] AVX2 gather vectorization: code bloat and reduction of performance

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 20 14:26:26 2017
New Revision: 247026

URL: https://gcc.gnu.org/viewcvs?rev=247026=gcc=rev
Log:
2017-04-20  Richard Biener  

PR tree-optimization/57796
* tree-vect-stmts.c (vect_model_store_cost): Cost scatters
as N scalar stores.
(vect_model_load_cost): Cost gathers as N scalar loads.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug debug/80453] [6/7 Regression] another compare-debug failure

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[6/7/8 Regression] another  |[6/7 Regression] another
   |compare-debug failure   |compare-debug failure

--- Comment #12 from Richard Biener  ---
Fixed on trunk sofar.

[Bug debug/80453] [6/7/8 Regression] another compare-debug failure

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 20 14:23:10 2017
New Revision: 247024

URL: https://gcc.gnu.org/viewcvs?rev=247024=gcc=rev
Log:
2017-04-20  Richard Biener  

PR tree-optimization/80453
* tree-ssa-sccvn.h (struct vn_phi_s): Add cclhs and ccrhs members.
* tree-ssa-sccvn.c (cond_stmts_equal_p): Use recorded lhs and rhs
from the conditions.
(vn_phi_eq): Pass them down.
(vn_phi_lookup): Record them.
(vn_phi_insert): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-sccvn.h

[Bug c++/80473] [7/8 Regression] notes about over-aligned new not suppressed in system-headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-20
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This is easy to fix, I have a patch.

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[daniel.kruegler at googlemail dot com]

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

--- Comment #9 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #8)
> Maybe we should just ask Jason to suppress the notes in a SFINAE context.

Yes, that sounds like a preferred direction to me.

[Bug c++/80473] New: [7/8 Regression] notes about over-aligned new not suppressed in system-headers

[redi at gcc dot gnu.org]

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

Bug ID: 80473
   Summary: [7/8 Regression] notes about over-aligned new not
suppressed in system-headers
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
struct alignas(64) A { int i; };
constexpr bool b = std::is_constructible::value;

With -Wall this produces unhelpful output referring to an unevaluated
new-expression inside libstdc++ internals:

In file included from a2.cc:1:0:
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits: In substitution of
‘template struct
std::__is_direct_constructible_impl<_Tp, _Arg, decltype (::new _Tp)> [with _Tp
= A; _Arg = A]’:
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:143:12:   required from
‘struct std::__and_ >’
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:995:12:   required from
‘struct std::__is_direct_constructible_new_safe’
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:1077:12:   required from
‘struct std::__is_direct_constructible_new’
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:1085:12:   required from
‘struct std::__is_direct_constructible’
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:1125:12:   required from
‘struct std::__is_constructible_impl’
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:1136:12:   required from
‘struct std::is_constructible’
a2.cc:3:47:   required from here
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:990:16: note: uses ‘void*
operator new(long unsigned int)’, which does not have an alignment parameter
   decltype(::new _Tp(std::declval<_Arg>()))>
^~~
/home/jwakely/gcc/7/include/c++/7.0.1/type_traits:990:16: note: use
‘-faligned-new’ to enable C++17 over-aligned new support


The actual -Waligned-new warning is suppressed due to being in a system header,
but the note is not.

It's debatable whether warning about the new-expression as an unevaluated
operand is useful anyway, but the note should not be printed if the warning is
suppressed.

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Maybe we should just ask Jason to suppress the notes in a SFINAE context.

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Daniel Krügler from comment #6)
> Do you recommend to reopen 51222 or should I open a separate bug? I'm
> inclined to create a new one at the moment.

Agreed, let's have a new bug for that.

> Another question I have is the following: What is you main motivation to
> introduce the idiom
> 
> struct __uneval_new_t;
> inline void* operator new(std::size_t, std::__uneval_new_t*);
> decltype(::delete ::new((__uneval_new_t*)0) _Tp(std::declval<_Arg>()))
> 
> compared to the seemingly simpler alternative
> 
> decltype(::delete ::new _Tp(std::declval<_Arg>()))
> 
> ?

It's to solve the problem reported in this PR: for over-aligned types we get
several lines of output telling us that aligned-new isn't supported without
-faligned-new. That isn't useful in this context, because we're not actually
trying to allocate it, just test the validity of the expression. It's certainly
not useful to the end user, because the new-expression is an implementation
detail deep inside libstdc++.

By introducing the new overload we avoid that problem, but still test whether
the type can be constructed. I could have simply used ::new((void*)0) to use
the predefined placement new, but that isn't declared in , so I
would have had to add a declaration for it (and that isn't supposed to be
declared by ).

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[daniel.kruegler at googlemail dot com]

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

--- Comment #6 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #2)
> Created attachment 41235 [details]
> avoid over-aligned new in is_constructible
> 
> [..]. We can also combine it
> with the delete check, because PR 51222 is fixed.

It seems that PR 51222 didn't cover private destructors. Using this test class

struct PS 
{
  PS(int);
private:
  ~PS() = default;
};

The attempt to evaluate the revised __is_direct_constructible_impl
produces a compiler error (so not SFINAE-friendly), but the current
implementation (using std::is_destructible) works nicely. 

Do you recommend to reopen 51222 or should I open a separate bug? I'm inclined
to create a new one at the moment.

Another question I have is the following: What is you main motivation to
introduce the idiom

struct __uneval_new_t;
inline void* operator new(std::size_t, std::__uneval_new_t*);
decltype(::delete ::new((__uneval_new_t*)0) _Tp(std::declval<_Arg>()))

compared to the seemingly simpler alternative

decltype(::delete ::new _Tp(std::declval<_Arg>()))

?

[Bug c++/80456] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Oops, sorry Marek, seems you've said all that already, ignore my comment... :(.

[Bug c++/80456] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
The test() call is represented as *(volatile struct A *) this, A::test () and
the *this dereference in that case is what triggers the error (well, this
itself).
This is created by:
8827  /* In an expression of the form `a->f()' where `f' turns
8828 out to be a static member function, `a' is
8829 none-the-less evaluated.  */
8830  if (TREE_CODE (TREE_TYPE (fn)) != METHOD_TYPE
8831  && !is_dummy_object (instance)
8832  && TREE_SIDE_EFFECTS (instance))
8833call = build2 (COMPOUND_EXPR, TREE_TYPE (call),
8834   instance, call);

So shall we have some exception of *this if it is volatile and still ignore it?

[Bug libstdc++/79862] Compilation error while building libstdc++

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #14 from Jonathan Wakely  ---
Fix for gcc 8. I'm not going to backport this, as systems without 
are weird and broken.

[Bug libstdc++/79862] Compilation error while building libstdc++

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
Author: redi
Date: Thu Apr 20 13:04:28 2017
New Revision: 247021

URL: https://gcc.gnu.org/viewcvs?rev=247021=gcc=rev
Log:
PR79862 check macro for type aliases that depend on 

PR libstdc++/79862
* include/std/atomic [!_GLIBCXX_USE_C99_STDINT_TR1] (atomic_int8_t)
(atomic_uint8_t, atomic_int16_t, atomic_uint16_t, atomic_int32_t,
(atomic_uint32_t, atomic_int64_t, atomic_uint64_t)
(atomic_int_least8_t, atomic_uint_least8_t, atomic_int_least16_t)
(atomic_uint_least16_t, atomic_int_least32_t, atomic_uint_least32_t)
(atomic_int_least64_t, atomic_uint_least64_t, atomic_int_fast8_t)
(atomic_uint_fast8_t, atomic_int_fast16_t, atomic_uint_fast16_t)
(atomic_int_fast32_t, atomic_uint_fast32_t, atomic_int_fast64_t)
(atomic_uint_fast64_t, atomic_intmax_t, atomic_uintmax_t): Don't
define.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/atomic

[Bug c++/69967] #pragma GCC diagnostic ignored being ignored for -Wunused-variable in some cases

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Marek Polacek  ---
Closing.

[Bug c++/80380] misleading behavior with designated initializers for std::vector

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-20
 Ever confirmed|0   |1

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-20
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed :(.

[Bug c++/80452] [DR 1579] incorrect value category deduced for return value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-20
 Ever confirmed|0   |1

[Bug c++/80469] Undefined symbol for abstract class impl with -fvisibility=hidden

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Ubikovich from comment #5)
> (In reply to Markus Trippelsdorf from comment #4)
> > (In reply to Ubikovich from comment #3)
> > > >> You need to provide the definition of dothis() somewhere.
> > > 
> > > There is the definition:
> > > 
> > > // subimpl.cpp
> > > #include "subimpl.h"
> > > void A::dothis() {}
> > 
> > Yeah, put "__attribute__ ((visibility("default")))" above it and you're 
> > done.
> 
> Why if move implement of A::a() to subimpl.cpp it not reproduced?

Because then the compiler sees the definition of A::dothis in the same TU.
And it doesn't generate a undefined symbol for main.cpp.

But this is not the right place to discuss this.
Read https://www.akkadia.org/drepper/dsohowto.pdf if you need more info.

[Bug c++/80472] New: cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[redi at gcc dot gnu.org]

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

Bug ID: 80472
   Summary: cannot use push/pop with #pragma GCC diagnostic
warning "-Wsystem-headers"
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 58876, 69769, 70692
  Target Milestone: ---

Given the following header:

#pragma GCC system_header
#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wsystem-headers"
// want warnings here despite being in a system header
#pragma GCC diagnostic pop
// But don't want warnings here
int missing_return() { }


A file including it will warn with -Wreturn-type (or -Wall):

In file included from dep.cc:1:0:
dep.h: In function ‘int missing_return()’:
dep.h:8:24: warning: no return statement in function returning non-void
[-Wreturn-type]
 int missing_return() { }
^

The warning should be disabled again by the "pop", but -Wsystem-headers stays
active once enabled.

This makes it very difficult for libstdc++ to selectively enable important
warnings, e.g. Bug 58876


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
[Bug 58876] No non-virtual-dtor warning in std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769
[Bug 69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692
[Bug 70692] No warning when std::function binds a reference to
a temporary

[Bug c++/80469] Undefined symbol for abstract class impl with -fvisibility=hidden

[theubik at mail dot ru]

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

--- Comment #5 from Ubikovich  ---
(In reply to Markus Trippelsdorf from comment #4)
> (In reply to Ubikovich from comment #3)
> > >> You need to provide the definition of dothis() somewhere.
> > 
> > There is the definition:
> > 
> > // subimpl.cpp
> > #include "subimpl.h"
> > void A::dothis() {}
> 
> Yeah, put "__attribute__ ((visibility("default")))" above it and you're done.

Why if move implement of A::a() to subimpl.cpp it not reproduced?

[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED
   Target Milestone|4.4.5   |5.0
  Known to fail||

--- Comment #24 from Jonathan Wakely  ---
This started working again with 5.1.0

ap.cc: In function ‘int main()’:
ap.cc:7:9: warning: ‘template class std::auto_ptr’ is deprecated
[-Wdeprecated-declarations]
std::auto_ptr p( (S*) 1234 );
 ^
In file included from /home/jwakely/gcc/5.1.0/include/c++/5.1.0/memory:81:0,
 from ap.cc:1:
/home/jwakely/gcc/5.1.0/include/c++/5.1.0/bits/unique_ptr.h:49:28: note:
declared here
   template class auto_ptr;
^

[Bug c/80468] [7/8 Regression] ICE on invalid AVX512 code with -m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-20
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 41236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41236=edit
gcc7-pr80468.patch

Untested fix.

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Of course. Your response is not late, I just couldn't CC you and attach the
patch at the same time, so mentioned you in a follow-up :-)

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #3)
> Daniel, please see above.

Sorry for the late response. I would like to shortly double-check, can you
await a definitive response until tomorrow?

[Bug libstdc++/80390] std::pair of aligned type gives bogus warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com
  Component|c++ |libstdc++

--- Comment #3 from Jonathan Wakely  ---
Daniel, please see above.

[Bug c++/80390] std::pair of aligned type gives bogus warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Created attachment 41235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41235=edit
avoid over-aligned new in is_constructible

Daniel, does this seem like a reasonable simplification of
__is_direct_constructible? The idea is to declare an operator new for internal
use in unevaluated contexts, and then use that for the new-expression that
tests direct-constructibility. We can also combine it with the delete check,
because PR 51222 is fixed.

[Bug tree-optimization/57245] Floating-point constant truncation ignores -frounding-math

[nsz at gcc dot gnu.org]

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

--- Comment #3 from nsz at gcc dot gnu.org ---
note that this may cause the omission of underflow, overflow and inexact
exceptions too (so in principle it's an invalid transformation even
without -frounding-math but with -ftrapping-math ):

float x,y;
void f(void)
{
  x = 0x1p-1000; // truncated to 0
  y = 0x1p1000; // truncated to inf
}

[Bug c++/80456] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Yeah, it doesn't need to evaluate 'this' in that declaration, it's calling a
static member function.

[Bug target/80464] [7 regression] S/390: ICE failed to split vector move

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P4  |P2

[Bug rtl-optimization/80463] [5/6/7 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2
  Known to work||4.5.0
   Target Milestone|7.0 |5.5

[Bug tree-optimization/57245] Floating-point constant truncation ignores -frounding-math

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #2 from Joseph S. Myers  ---
*** Bug 80450 has been marked as a duplicate of this bug. ***

[Bug target/80450] -std=c99 breaks -frounding-math on i686

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #2 from Joseph S. Myers  ---
This is just the same bug as any other constant truncation wrongly ignoring the
rounding mode (as if 0x1p-2000L were being converted - the semantics with
standard excess precision being that 0x1p-2000L gets computed then converted to
double).

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

[Bug target/71991] Inconsistency for __attribute__ ((__always_inline__)) among LTO and non-LTO compilation

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Ok, the first test-case started to fail w/ LTO from r217659. Honza, can you
please take a look and provide hint what to do?

[Bug tree-optimization/80457] vectorizable_condition does not update the vectorizer cost model

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|7.0 |---

[Bug c++/80456] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
How is the C++ abstract machine defined in this case?  I don't think you can
constexpr evaluate any volatile load -- but of course in this case 'this'
shouldn't be considered volatile in that sense?

[Bug c++/80439] __attribute__((target("xxx"))) not applied to lambdas

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Hmm, I think it would make sense if lambdas (and nested functions) "inherit"
both target and optimize attributes from their parents.

[Bug other/71250] -Wmissing-field-initializers documentation is incomplete

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
Author: amonakov
Date: Thu Apr 20 10:23:38 2017
New Revision: 247018

URL: https://gcc.gnu.org/viewcvs?rev=247018=gcc=rev
Log:
doc: mention handling of {0} in -Wmissing-field-initializers (PR 71250)

PR other/71250
* doc/invoke.texi (-Wmissing-field-initializers): Mention that warning
is suppressed for '{ 0 }' in C.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug libstdc++/80451] [6/7 Regression] return implicit type conversion to std::experimental::optional does not compile

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.0 |6.4

[Bug other/71250] -Wmissing-field-initializers documentation is incomplete

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Alexander Monakov  ---
Fixed (the checked in text is different from my suggestion in comment #2,
because in the documentation there are further examples, and the C++ treatment
of '{ }' was already explained).

[Bug target/80450] -std=c99 breaks -frounding-math on i686

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
I think unless you use long double you can't rely on -O2 -frounding-math
behavior.
-std=c99 enables -fexcess-precision=standard.

I think the unconditional zero is correct here.

[Bug tree-optimization/80430] Vectorizer undervalues cost of alias checking for versioning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-20
 Blocks||53947
   Target Milestone|8.0 |---
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  One trivial improvement would be to use scalar_stmt (there's no
vector code emitted).

Another issue is that we combine the runtime cost model check with the alias
checks rather than emitting a separate gimple-cond for this.

Plus for a loop nest we should eventually version the whole nest (even if only
vectorizing the innermost loop) in case the versioning conditions are invariant
in the outer loop.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug rtl-optimization/80429] -fcompare-debug failure on ppc64le with LRA

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Yes sorry, fixed on trunk.  Backports pending.

[Bug rtl-optimization/80429] -fcompare-debug failure on ppc64le with LRA

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Richard Biener from comment #3)
> Fixed on trunk (sofar)?

Yes.

[Bug rtl-optimization/80429] -fcompare-debug failure on ppc64le with LRA

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0.1
  Known to fail|7.0 |

--- Comment #3 from Richard Biener  ---
Fixed on trunk (sofar)?

[Bug tree-optimization/80426] [6 Regression] wrong manipulation of range based on INT_MIN

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
   Target Milestone|7.0 |6.4

[Bug middle-end/80421] [5 Regression] Case dispatch is scrambled in switch-statement

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/30455] i386 generates unnecessary TEST instructions for arithmetic ops on memory

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Uroš Bizjak  ---
gcc-7 generates for the original testcase:

add_zf:
addl%esi, (%rdi)
movl%ecx, %eax
cmove   %edx, %eax
ret

So, fixed.

[Bug target/71607] [5/6/7 Regression] [ARM] ice due to forbidden enabled attribute dependency on instruction operands

[prakhar.bahuguna at arm dot com]

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

--- Comment #12 from Prakhar Bahuguna  ---
(In reply to Christophe Monat from comment #10)
> (In reply to Ramana Radhakrishnan from comment #9)
> 
> Hello Ramana,
> 
> Is there a plan to have this patch delivered upstream at some point in the
> near future ?
> 
> Best regards,
> --C

Hi Christophe,

The patch has now been posted to the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00872.html

Regards,

Prakhar

[Bug debug/80453] [6/7 Regression] another compare-debug failure

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Created attachment 41234
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41234=edit
patch

Patch I am testing that is less pessimizing (we need to remember valueized
controlling condition args).

[Bug debug/80453] [6/7 Regression] another compare-debug failure

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|7.0 |6.4
Summary|another compare-debug   |[6/7 Regression] another
   |failure |compare-debug failure

[Bug c++/51222] [C++11][SFINAE] Unevaluated combined delete new expression completely broken

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
We should revisit the library traits now this is fixed:

  // Implementation for non-reference types. To meet the proper
  // variable definition semantics, we also need to test for
  // is_destructible in this case.
  // This form should be simplified by a single expression:
  // ::delete ::new _Tp(declval<_Arg>()), see c++/51222.
  struct __do_is_direct_constructible_impl
  {
template()))>
  static true_type __test(int);

[Bug c++/80390] std::pair of aligned type gives bogus warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-20
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The new-expression comes from  where we check if the pair members
are constructible.

I'm not sure whether we'd want to suppress this warning in a SFINAE context, or
if the library should use a placement new-expression there instead.

[Bug inline-asm/80470] Can't compile wait4 implementation on i586 target

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Created attachment 41233
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41233=edit
Another test-case

There's another test-case which is sensible to -O, which causes an inlining to
happen and after that a constraint can't be satisfied.

[Bug tree-optimization/79534] [7 Regression] tree-ifcombine aarch64 performance regression with trunk@245151

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #10 from James Greenhalgh  ---
The most striking improvement was in libquantum, for which we saw a 15%
performance improvement on Cortex-A72 (3% on cortex-A57) directly attributable
to basic block ordering after this patch.

Otherwise, I don't have a direct before/after comparison for just Honza's patch
across a wider set of benchmarks, but our nightly runs show general
improvements in benchmarks from Spec which are sensitive to block reordering
after the day of the patch. I don't see any large regressions in this time.

[Bug target/53877] __lzcnt_u16/__lzcnt_u32/__lzcnt_u64 aren't implemented

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Yukhin Kirill from comment #3)
> Done.

[Bug middle-end/80423] [7 Regression] GC related -fcompare-debug failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/54077] Bytemark FP EMULATION 9%-15% slower than with clang

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #20 from Uroš Bizjak  ---
Assuming fixed due to PR55286 fix, please retest with newer gcc version if not.

[Bug debug/56950] compare-debug failure for gcc.dg/pr41345.c with fschedule-insns

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Uroš Bizjak  ---
Works OK with gcc-7.

[Bug libstdc++/69769] arithmetic operation on pointer to a function

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Wolfgang Roehrl from comment #0)
> The compiler accepts this programm despite of performing an arithmetic
> operation on pointer to a function.

Arithmetic on (non-atomic) function pointers is supported by GCC:
https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html

So this is consistent with the built-in types.

[Bug middle-end/80423] [7 Regression] GC related -fcompare-debug failure

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 20 09:18:02 2017
New Revision: 247014

URL: https://gcc.gnu.org/viewcvs?rev=247014=gcc=rev
Log:
PR middle-end/80423
* tree.h (build_array_type): Add typeless_storage default argument.
* tree.c (type_cache_hasher::equal): Also compare
TYPE_TYPELESS_STORAGE flag for ARRAY_TYPEs.
(build_array_type): Add typeless_storage argument, set
TYPE_TYPELESS_STORAGE to it, if shared also hash it, and pass to
recursive call.
(build_nonshared_array_type): Adjust build_array_type_1 caller.
(build_array_type): Likewise.  Add typeless_storage argument.
c-family/
* c-common.c (complete_array_type): Preserve TYPE_TYPELESS_STORAGE.
cp/
* tree.c (build_cplus_array_type): Call build_array_type
with the intended TYPE_TYPELESS_STORAGE flag value, instead
of calling build_array_type and modifying later TYPE_TYPELESS_STORAGE
on the shared type.
testsuite/
* g++.dg/other/pr80423.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/pr80423.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug debug/80453] another compare-debug failure

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
So the issue is that vn_phi_eq depends on cond_stmts_equal_p which may change
if we value-number the controlling condition after the PHI itself which can
trivially happen with SCC based value-numbering as controlling conditions are
not part of the SCC.

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 246964)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -2941,10 +2941,12 @@ cond_stmts_equal_p (gcond *cond1, gcond
   else
 return false;

+#if 0
   lhs1 = vn_valueize (lhs1);
   rhs1 = vn_valueize (rhs1);
   lhs2 = vn_valueize (lhs2);
   rhs2 = vn_valueize (rhs2);
+#endif
   return ((expressions_equal_p (lhs1, lhs2)
   && expressions_equal_p (rhs1, rhs2))
  || (commutative_tree_code (code1)

would fix this (and pessimize PHI VN of course).

[Bug target/66334] cleanup block fails to initialize EBX

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Uroš Bizjak  ---
(In reply to Andrew Pinski from comment #14)
> Fixed for 6.1.

[Bug inline-asm/80470] Can't compile wait4 implementation on i586 target

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Thanks both. Better error than a strange behavior. Well, would it worth for
somehow more explicitly document that clobbering stack pointer is a wrong
think/invalid?