[Bug c/86885] New: gcc erroneously allows constructor/destructor attributes on nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86885 Bug ID: 86885 Summary: gcc erroneously allows constructor/destructor attributes on nested functions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Target Milestone: --- Nested functions cannot meaningfully be called outside of the lifetime of a particular instance of the block in which they are nested. However, gcc allows them to be given the constructor or destructor attribute, causing them to be called at init/fini time without a meaningful value for the hidden context pointer, potentially leading to runaway wrong behavior. The GCC documentation on nested functions related to this issue is also outdated and imprecise: "If you try to call the nested function through its address after the containing function exits, all hell breaks loose. If you try to call it after a containing scope level exits, and if it refers to some of the variables that are no longer in scope, you may be lucky, but it’s not wise to take the risk. If, however, the nested function does not refer to anything that has gone out of scope, you should be safe." Due to various transformations that may be performed, it seems impossible to guarantee that a nested function called after the containing function exits, or without any containing function ever existing (the ctor/dtor case), does not attempt to access the containing function's stack frame, even if the code path taken does not access local variables at the abstract machine level. For instance hoisting could cause accesses that would reasonably be assumed to be valid. I don't see any indication that GCC has the necessary machinery to prevent such transformations. Applying the ctor/dtor attributes to a nested function should be an error, and the documentation should be updated to reflect that it's invalid to call a nested function outside the lifetime of the containing block. Source of this issue was a question on Stack Overflow: https://stackoverflow.com/questions/51736547/how-to-specify-priority-in-attribute-constructor-for-nested-functions
[Bug tree-optimization/86884] New: aggressive loop optimization and effective type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86884
Bug ID: 86884
Summary: aggressive loop optimization and effective type
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As requested in https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00514.html, for
the following (undefined) C test case, the aggressive loop optimization
determines the upper bound of the loop to be 3 based on the size of X::c. As a
result, the loop is eliminated and the call to abort is made unconditionally
even though the representation of the object stored in memory is a
nul-terminated string of 15 characters, and so the number of characters at p->c
before the final nul is 11.
The test case is undefined because the object of type struct Y is being
accessed by an lvalue of type struct X, and the array at p->c is not
nul-terminated so the loop accesses memory beyond the end of p->c. That the
effective type of the object ar p may actually be struct Y is not relevant (or
considered). But according to the discussion at the thread above, even though
this is undefined in C, it's apparently meant to be well-defined in GIMPLE.
$ cat e.c && gcc -O2 -S -Wall -fdump-tree-cddce1=/dev/stdout e.c
struct X { int i; char c[4]; int j;};
struct Y { char c[16]; };
void f (struct X *p)
{
struct Y y = { "012345678901234" };
__builtin_memcpy (p, &y, sizeof (struct Y));
// *p's effective type is now struct Y
int n = 0;
while (p->c[n])
++n;
if (n < 7)
__builtin_abort ();
}
Marking useful stmt: MEM[(char * {ref-all})p_6(D)] =
0x343332313039383736353433323130;
Marking useful stmt: __builtin_abort ();
Found loop 1 to be finite: upper bound found.
Processing worklist:
processing: __builtin_abort ();
processing: MEM[(char * {ref-all})p_6(D)] = 0x343332313039383736353433323130;
Eliminating unnecessary statements:
Deleting : n_9 = n_2 + 1;
Deleting : if (_1 != 0)
Deleting : _1 = p_6(D)->c[n_2];
...
fix_loop_structure: removing loop 1
f (struct X * p)
{
__int128 unsigned y;
int n;
struct Y y;
:
MEM[(char * {ref-all})p_6(D)] = 0x343332313039383736353433323130;
__builtin_abort ();
}
[Bug c/84890] Overly verbose notes for missing headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #10 from Eric Gallager --- ASSIGNED since there's an assignee.
[Bug c++/86878] G++ should warn about invalid alignments passed to allocation functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86878 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-08 Ever confirmed|0 |1
[Bug c++/86878] G++ should warn about invalid alignments passed to allocation functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86878
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
Created attachment 44517
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44517&action=edit
Prototype patch.
Confirmed. Adding the warning to the middle-end is pretty simple. With the
operator declared with the attribute I get the following with my simple patch
(the real solution will use its own option to control the warning):
pr86878.C: In function ‘int main()’:
pr86878.C:11:15: warning: argument 2 value 5 is not a positive power of two
[-Wattributes]
(void) alloc(10, 5);
~^~~
pr86878.C:4:7: note: in a call to allocation function ‘void* alloc(std::size_t,
std::size_t)’ declared here
void* alloc(std::size_t, std::size_t);
^
pr86878.C:12:24: warning: argument 2 value (std::align_val_t)5 is not a
positive power of two [-Wattributes]
(void) ::operator new(10, std::align_val_t{5});
~~^
pr86878.C:6:7: note: in a call to allocation function ‘void* operator new(long
unsigned int, std::align_val_t)’ declared here
void* operator new(__SIZE_TYPE__, std::align_val_t)
^~~~
[Bug preprocessor/81419] GCC wrongly suggests function-like macro as fixit hint for undefined object-like macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81419 --- Comment #2 from Eric Gallager --- (In reply to Martin Sebor from comment #1) > Confirmed. There are few other similar bugs for these fix-it hints (e.g., > pr80567 or pr80684). I haven't looked at the implementation but from the > symptoms it feels like the problem is that the search doesn't fully consider > the context in which the undeclared is used. I.e., it doesn't distinguish > between a function call, other kinds of expressions, a type, or even a > keyword, etc. Hopefully GCC can learn to make these distinctions in time for GCC 9.
[Bug tree-optimization/80147] missing maybe-uninitialized warning on variable with no side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147 --- Comment #6 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #2) > (In reply to Eric Gallager from comment #1) > > ...but if that's the case, then why doesn't the warning go away for i1, too? > > Because "is-used" is given before optimization, while may-be-used are given > after optimization. I don't think this is a bug, but expected behaviour > given that optimization should allow more precise warnings (hence, > discarding a false positive). It would be nice if we could avoid warning > about f1(i1), but that is hard with the current Wuninitialized > implementation (and a different already reported bug). Which other bug is that?
[Bug libstdc++/84654] libstdc++ tries to use __float128 when compiling with -mno-float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84654 Jonathan Wakely changed: What|Removed |Added Target Milestone|8.3 |7.4 --- Comment #8 from Jonathan Wakely --- Backported to gcc-7-branch for 7.4
[Bug libstdc++/68519] condition_variable::wait_for does not work properly with float duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68519 Jonathan Wakely changed: What|Removed |Added Target Milestone|8.0 |7.4 --- Comment #11 from Jonathan Wakely --- Fixed for 7.4 too.
[Bug libstdc++/86292] Missing exception safety when constructing vector from input iterator pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86292 Jonathan Wakely changed: What|Removed |Added Target Milestone|8.2 |7.4 --- Comment #7 from Jonathan Wakely --- Also fixed for 7.4
[Bug libstdc++/86861] 18_support/new_aligned.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86861 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|8.3 |7.4 --- Comment #9 from Jonathan Wakely --- operator new(size_t, align_val_t) should work correctly for gcc 7.4 and 8.3 and trunk.
[Bug libstdc++/84654] libstdc++ tries to use __float128 when compiling with -mno-float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84654 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 22:50:49 2018 New Revision: 263382 URL: https://gcc.gnu.org/viewcvs?rev=263382&root=gcc&view=rev Log: PR libstdc++/84654 Disable __float128 specializations for -mno-float128 Backport from mainline 2018-05-08 Jonathan Wakely PR libstdc++/85672 * include/Makefile.am [!ENABLE_FLOAT128]: Change c++config.h entry to #undef _GLIBCXX_USE_FLOAT128 instead of defining it to zero. * include/Makefile.in: Regenerate. * include/bits/c++config (_GLIBCXX_USE_FLOAT128): Move definition within conditional block. Backport from mainline 2018-05-01 Tulio Magno Quites Machado Filho PR libstdc++/84654 * acinclude.m4: Set ENABLE_FLOAT128 instead of _GLIBCXX_USE_FLOAT128. * config.h.in: Remove references to _GLIBCXX_USE_FLOAT128. * configure: Regenerate. * include/Makefile.am: Replace the value of _GLIBCXX_USE_FLOAT128 based on ENABLE_FLOAT128. * include/Makefile.in: Regenerate. * include/bits/c++config: Define _GLIBCXX_USE_FLOAT128. [!defined(__FLOAT128__) && !defined(__SIZEOF_FLOAT128__)]: Undefine _GLIBCXX_USE_FLOAT128. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/acinclude.m4 branches/gcc-7-branch/libstdc++-v3/config.h.in branches/gcc-7-branch/libstdc++-v3/configure branches/gcc-7-branch/libstdc++-v3/include/Makefile.am branches/gcc-7-branch/libstdc++-v3/include/Makefile.in branches/gcc-7-branch/libstdc++-v3/include/bits/c++config
[Bug libstdc++/86138] [7/8 Regression] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138 --- Comment #28 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 22:50:55 2018 New Revision: 263383 URL: https://gcc.gnu.org/viewcvs?rev=263383&root=gcc&view=rev Log: Declare some explicit instantiations for strings in Debug Mode The empty reps and the I/O functions do not need to be implicitly instantiated to enable assertions, so declare the explicit instantiations when _GLIBCXX_EXTERN_TEMPLATE == -1 (i.e. when _GLIBCXX_ASSERTIONS is defined). Backport from mainline 2018-06-27 Jonathan Wakely PR libstdc++/86138 * include/bits/basic_string.tcc: [_GLIBCXX_EXTERN_TEMPLATE < 0] Declare explicit instantiations of COW empty reps and I/O functions. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/basic_string.tcc
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86734 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.4 --- Comment #5 from Jonathan Wakely --- Fixed for 7.4 and 8.3
[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 --- Comment #16 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 22:50:49 2018 New Revision: 263382 URL: https://gcc.gnu.org/viewcvs?rev=263382&root=gcc&view=rev Log: PR libstdc++/84654 Disable __float128 specializations for -mno-float128 Backport from mainline 2018-05-08 Jonathan Wakely PR libstdc++/85672 * include/Makefile.am [!ENABLE_FLOAT128]: Change c++config.h entry to #undef _GLIBCXX_USE_FLOAT128 instead of defining it to zero. * include/Makefile.in: Regenerate. * include/bits/c++config (_GLIBCXX_USE_FLOAT128): Move definition within conditional block. Backport from mainline 2018-05-01 Tulio Magno Quites Machado Filho PR libstdc++/84654 * acinclude.m4: Set ENABLE_FLOAT128 instead of _GLIBCXX_USE_FLOAT128. * config.h.in: Remove references to _GLIBCXX_USE_FLOAT128. * configure: Regenerate. * include/Makefile.am: Replace the value of _GLIBCXX_USE_FLOAT128 based on ENABLE_FLOAT128. * include/Makefile.in: Regenerate. * include/bits/c++config: Define _GLIBCXX_USE_FLOAT128. [!defined(__FLOAT128__) && !defined(__SIZEOF_FLOAT128__)]: Undefine _GLIBCXX_USE_FLOAT128. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/acinclude.m4 branches/gcc-7-branch/libstdc++-v3/config.h.in branches/gcc-7-branch/libstdc++-v3/configure branches/gcc-7-branch/libstdc++-v3/include/Makefile.am branches/gcc-7-branch/libstdc++-v3/include/Makefile.in branches/gcc-7-branch/libstdc++-v3/include/bits/c++config
[Bug libstdc++/86861] 18_support/new_aligned.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86861 --- Comment #8 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 22:50:19 2018 New Revision: 263376 URL: https://gcc.gnu.org/viewcvs?rev=263376&root=gcc&view=rev Log: PR libstdc++/86861 Meet precondition for Solaris memalign Solaris memalign requires alignment to be at least sizeof(int), so increase it as needed. Also move the check for valid alignments from the fallback implementation of aligned_alloc into operator new, as it's required for all of aligned_alloc, memalign, posix_memalign and __aligned_malloc. Backport from mainline 2018-08-07 Jonathan Wakely PR libstdc++/86861 * libsupc++/new_opa.cc [_GLIBCXX_HAVE_MEMALIGN] (aligned_alloc): Replace macro with inline function. [__sun]: Increase alignment to meet memalign precondition. [!HAVE__ALIGNED_MALLOC && !HAVE_POSIX_MEMALIGN && !HAVE_MEMALIGN] (aligned_alloc): Move check for valid alignment to operator new. Remove redundant check for non-zero size, it's enforced by the caller. (operator new): Move check for valid alignment here. Use __builtin_expect on check for zero size. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/libsupc++/new_opa.cc
[Bug libstdc++/80893] std::vector creation dereferences null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80893
--- Comment #6 from Jonathan Wakely ---
Author: redi
Date: Tue Aug 7 22:50:45 2018
New Revision: 263381
URL: https://gcc.gnu.org/viewcvs?rev=263381&root=gcc&view=rev
Log:
PR libstdc++/80893 Fix null dereference in vector
Backport from mainline
2017-06-17 Jonathan Wakely
PR libstdc++/80893
* testsuite/23_containers/vector/bool/80893.cc: Add { target c++11 }.
Backport from mainline
2017-05-31 Jonathan Wakely
PR libstdc++/80893
* include/bits/stl_bvector.h (vector::_M_initialize): Avoid
null pointer dereference when size is zero.
* testsuite/23_containers/vector/bool/80893.cc: New.
* testsuite/util/testsuite_allocator.h (PointerBase::PointerBase):
Add non-explicit constructor from nullptr.
(PointerBase::derived() const): Add const-qualified overload.
Added:
branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/vector/bool/80893.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/stl_bvector.h
branches/gcc-7-branch/libstdc++-v3/testsuite/util/testsuite_allocator.h
[Bug libstdc++/86292] Missing exception safety when constructing vector from input iterator pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86292 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 22:50:33 2018 New Revision: 263379 URL: https://gcc.gnu.org/viewcvs?rev=263379&root=gcc&view=rev Log: PR libstdc++/86292 fix exception safety of std::vector constructor Backport from mainline 2018-06-25 Jonathan Wakely PR libstdc++/86292 * include/bits/stl_vector.h (vector::_M_range_initialize): Add try-catch block. * testsuite/23_containers/vector/cons/86292.cc: New. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/vector/cons/86292.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/stl_vector.h
[Bug libstdc++/68519] condition_variable::wait_for does not work properly with float duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68519 --- Comment #10 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 22:50:40 2018 New Revision: 263380 URL: https://gcc.gnu.org/viewcvs?rev=263380&root=gcc&view=rev Log: PR libstdc++/68519 use native duration to avoid rounding errors Backport from mainline 2017-12-14 Jonathan Wakely PR libstdc++/68519 * include/std/condition_variable (condition_variable::wait_for): Convert duration to native clock's duration before addition. * testsuite/30_threads/condition_variable/members/68519.cc: New test. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/30_threads/condition_variable/members/68519.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/std/condition_variable
[Bug libstdc++/60555] std::system_category().default_error_condition() doesn't map system errno values to std::generic_category()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60555 --- Comment #14 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 22:50:24 2018 New Revision: 263377 URL: https://gcc.gnu.org/viewcvs?rev=263377&root=gcc&view=rev Log: PR libstdc++/60555 std::system_category() should recognise POSIX errno values Backport from mainline 2018-08-03 Jonathan Wakely * src/c++11/system_error.cc (system_error_category::default_error_condition): Add workaround for ENOTEMPTY and EEXIST having the same value on AIX. * testsuite/19_diagnostics/error_category/system_category.cc: Add extra testcases for EDOM, EILSEQ, ERANGE, EEXIST and ENOTEMPTY. Backport from mainline 2018-08-01 Jonathan Wakely PR libstdc++/60555 * src/c++11/system_error.cc (system_error_category::default_error_condition): New override to check for POSIX errno values. * testsuite/19_diagnostics/error_category/generic_category.cc: New * testsuite/19_diagnostics/error_category/system_category.cc: New test. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/19_diagnostics/error_category/generic_category.cc branches/gcc-7-branch/libstdc++-v3/testsuite/19_diagnostics/error_category/system_category.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/src/c++11/system_error.cc
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86734 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 22:50:11 2018 New Revision: 263374 URL: https://gcc.gnu.org/viewcvs?rev=263374&root=gcc&view=rev Log: PR libstdc++/86734 use addressof in reverse_iterator::operator-> Backport from mainline 2018-07-30 Jonathan Wakely PR libstdc++/86734 * include/bits/stl_iterator.h (reverse_iterator::operator->): Use addressof (LWG 2188). * testsuite/24_iterators/reverse_iterator/dr2188.cc: New test. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/24_iterators/reverse_iterator/dr2188.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/stl_iterator.h
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593
--- Comment #5 from H.J. Lu ---
This test:
---
struct Foo
{
int bar(int a, int b, int c, int i1, int i2, int i3, int d);
};
int Foo::bar(int a, int b, int c, int i1, int i2, int i3, int d)
{
return 0;
}
---
also triggers SUPPORTS_STACK_ALIGNMENT check in based_loc_descr
on Linux/x86-64.
[Bug c++/86862] Segfault using extern template on class deriving from streambuf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86862 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-07 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed. Doesn't seem to be a regression, fails for every version at least as far back as 4.3.6
[Bug c++/86883] Unexpected error: expansion pattern '' contains no argument packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86883 --- Comment #1 from Jonathan Wakely --- See also PR 68342 and PR 85569
[Bug c++/86883] Unexpected error: expansion pattern '' contains no argument packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86883 --- Comment #2 from Jonathan Wakely --- And PR 86859
[Bug c++/86883] New: Unexpected error: expansion pattern '' contains no argument packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86883
Bug ID: 86883
Summary: Unexpected error: expansion pattern ''
contains no argument packs
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v.reshetnikov at gmail dot com
Target Milestone: ---
/** BEGIN SOURCE **/
template
struct A {
template class Head, T... Args>
static constexpr Head foo = { };
};
template
struct C {
static constexpr auto value = x;
};
using type = decltype(A::foo);
static_assert(type::value == 1);
/*** END SOURCE ***/
The g++ 8.2.0 compiler rejects this code:
/** BEGIN OUTPUT **/
:4:34: error: expansion pattern '' contains no argument
packs
static constexpr Head foo = { };
^
/*** END OUTPUT ***/
I believe the code is correct and should be compiled successfully. For
comparison, Clang accepts it.
[Bug c++/86879] G++ should warn about redundant tests for null pointers returned from functions with __attribute__((returns_nonnull))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86879 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-07 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. It sounds like a useful enhancement. It also shouldn't be hard to implement -- similar functionality already exists for function arguments declared nonnull, and for addresses of functions and non-allocated objects.
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593
--- Comment #4 from H.J. Lu ---
This patch seems to work
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index b67481dd2db..6ecdc4562d0 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -14304,7 +14304,8 @@ based_loc_descr (rtx reg, poly_int64 offset,
if (elim != reg)
{
elim = strip_offset_and_add (elim, &offset);
-gcc_assert ((SUPPORTS_STACK_ALIGNMENT
+gcc_assert (((SUPPORTS_STACK_ALIGNMENT
+|| !crtl->stack_realign_tried)
&& (elim == hard_frame_pointer_rtx
|| elim == stack_pointer_rtx))
|| elim == (frame_pointer_needed
@@ -20492,7 +20493,8 @@ compute_frame_pointer_to_fb_displacement (poly_int64
offset)
this, assume that while we cannot provide a proper value for
frame_pointer_fb_offset, we won't need one either. */
frame_pointer_fb_offset_valid
-= ((SUPPORTS_STACK_ALIGNMENT
+= (((SUPPORTS_STACK_ALIGNMENT
+ || !crtl->stack_realign_tried)
&& (elim == hard_frame_pointer_rtx
|| elim == stack_pointer_rtx))
|| elim == (frame_pointer_needed
[Bug libstdc++/84535] std::thread constructor missing constraint on first argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84535 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.0 |8.3 --- Comment #5 from Jonathan Wakely --- Fixed for GCC 8.3 too.
[Bug libstdc++/60555] std::system_category().default_error_condition() doesn't map system errno values to std::generic_category()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60555 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.0 |8.3
[Bug libstdc++/86874] [8/9 Regression] std::swap on std::variant fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86874 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for GCC 8.3
[Bug libstdc++/84535] std::thread constructor missing constraint on first argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84535 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 21:38:59 2018 New Revision: 263370 URL: https://gcc.gnu.org/viewcvs?rev=263370&root=gcc&view=rev Log: PR libstdc++/84535 constrain std::thread constructor The standard requires that the std::thread constructor is constrained so it can't be called with a first argument of type std::thread. The current implementation only meets that requirement if the constructor is called with one argument, by using deleted overloads. This uses an enable_if constraint to enforce the requirement for any number of arguments. Also add a static assertion to give a more readable error for invalid arguments that cannot be invoked. Backport from mainline 2018-05-03 Jonathan Wakely PR libstdc++/84535 * include/std/thread (thread::__not_same): New SFINAE helper. (thread::thread(_Callable&&, _Args&&...)): Add SFINAE constraint that first argument is not a std::thread. Add static assertion to check INVOKE expression is valid. (thread::thread(thread&), thread::thread(const thread&&)): Remove. * testsuite/30_threads/thread/cons/84535.cc: New. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/30_threads/thread/cons/84535.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/std/thread
[Bug libstdc++/86861] 18_support/new_aligned.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86861 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 21:38:45 2018 New Revision: 263367 URL: https://gcc.gnu.org/viewcvs?rev=263367&root=gcc&view=rev Log: PR libstdc++/86861 Meet precondition for Solaris memalign Solaris memalign requires alignment to be at least sizeof(int), so increase it as needed. Also move the check for valid alignments from the fallback implementation of aligned_alloc into operator new, as it's required for all of aligned_alloc, memalign, posix_memalign and __aligned_malloc. Backport from mainline 2018-08-07 Jonathan Wakely PR libstdc++/86861 * libsupc++/new_opa.cc [_GLIBCXX_HAVE_MEMALIGN] (aligned_alloc): Replace macro with inline function. [__sun]: Increase alignment to meet memalign precondition. [!HAVE__ALIGNED_MALLOC && !HAVE_POSIX_MEMALIGN && !HAVE_MEMALIGN] (aligned_alloc): Move check for valid alignment to operator new. Remove redundant check for non-zero size, it's enforced by the caller. (operator new): Move check for valid alignment here. Use __builtin_expect on check for zero size. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/libsupc++/new_opa.cc
[Bug libstdc++/60555] std::system_category().default_error_condition() doesn't map system errno values to std::generic_category()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60555 --- Comment #13 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 21:38:55 2018 New Revision: 263369 URL: https://gcc.gnu.org/viewcvs?rev=263369&root=gcc&view=rev Log: PR libstdc++/60555 std::system_category() should recognise POSIX errno values Backport from mainline 2018-08-03 Jonathan Wakely * src/c++11/system_error.cc (system_error_category::default_error_condition): Add workaround for ENOTEMPTY and EEXIST having the same value on AIX. * testsuite/19_diagnostics/error_category/system_category.cc: Add extra testcases for EDOM, EILSEQ, ERANGE, EEXIST and ENOTEMPTY. Backport from mainline 2018-08-01 Jonathan Wakely PR libstdc++/60555 * src/c++11/system_error.cc (system_error_category::default_error_condition): New override to check for POSIX errno values. * testsuite/19_diagnostics/error_category/generic_category.cc: New * testsuite/19_diagnostics/error_category/system_category.cc: New test. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/19_diagnostics/error_category/generic_category.cc branches/gcc-8-branch/libstdc++-v3/testsuite/19_diagnostics/error_category/system_category.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/src/c++11/system_error.cc
[Bug libstdc++/86874] [8/9 Regression] std::swap on std::variant fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86874 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 21:38:50 2018 New Revision: 263368 URL: https://gcc.gnu.org/viewcvs?rev=263368&root=gcc&view=rev Log: PR libstdc++/86874 fix std::variant::swap regression Backport from mainline 2018-08-07 Jonathan Wakely PR libstdc++/86874 * include/std/variant (_Copy_ctor_base::_M_destructive_move): Define here instead of in _Move_assign_base. (_Copy_ctor_base::_M_destructive_move): Define. (_Copy_assign_base::operator=): Use _M_destructive_move when changing the contained value to another alternative. (_Move_assign_base::operator=): Likewise. (_Move_assign_base::_M_destructive_move): Remove. * testsuite/20_util/variant/86874.cc: New test. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/variant/86874.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/std/variant
[Bug inline-asm/59155] ICE: in reg_overlap_mentioned_p, at rtlanal.c:1473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #9 from Arseny Solokha ---
(In reply to Marc Glisse from comment #0)
> double f(double x){
> asm volatile("":"+X"(x));
> return x;
> }
> double g(double x,double y){
> return f(f(x)+f(y));
> }
>
> compiled with -O2:
>
> a.c: In function 'g':
> a.c:7:1: internal compiler error: in reg_overlap_mentioned_p, at
> rtlanal.c:1473
> }
> ^
> 0x967015 reg_overlap_mentioned_p(rtx_def const*, rtx_def const*)
> /data/repos/gcc/pristine/gcc/rtlanal.c:1473
> 0x7cde02 match_asm_constraints_1
> /data/repos/gcc/pristine/gcc/function.c:7164
> 0x7cdfda rest_of_match_asm_constraints
> /data/repos/gcc/pristine/gcc/function.c:7207
> 0x7cdfda execute
> /data/repos/gcc/pristine/gcc/function.c:7239
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See for instructions.
gcc 7.3 ICEs for me on this testcase as reported here, while all newer branches
including trunk reject it w/ the diagnotsic shown in comment 1. Thus, this PR
applies to 7 branch only.
[Bug rtl-optimization/86882] New: [9 Regression] ICE in reg_overlap_mentioned_p, at rtlanal.c:1873
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86882
Bug ID: 86882
Summary: [9 Regression] ICE in reg_overlap_mentioned_p, at
rtlanal.c:1873
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-9.0.0-alpha20180805 (r263320) ICEs when compiling the following snippet w/
-march=btver1 -O2 (-O3, -Ofast):
unsigned char pe;
unsigned char
ii (int dc)
{
if (dc != 0)
{
int jd = 0x101;
jd ^= pe;
pe ^= jd;
}
return pe;
}
% x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20180805 -march=btver1 -O2 -c
hpojzrvb.c
during RTL pass: combine
hpojzrvb.c: In function 'ii':
hpojzrvb.c:15:1: internal compiler error: in reg_overlap_mentioned_p, at
rtlanal.c:1873
}
^
0x6487d2 reg_overlap_mentioned_p(rtx_def const*, rtx_def const*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/rtlanal.c:1873
0xc4f4db reg_referenced_p(rtx_def const*, rtx_def const*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/rtlanal.c:1149
0x1444168 try_combine
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/combine.c:4043
0x1446bca combine_instructions
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/combine.c:1320
0x1446bca rest_of_handle_combine
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/combine.c:14917
0x1446bca execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180805/work/gcc-9-20180805/gcc/combine.c:14962
[Bug libstdc++/86874] [8/9 Regression] std::swap on std::variant fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86874 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 19:13:26 2018 New Revision: 263365 URL: https://gcc.gnu.org/viewcvs?rev=263365&root=gcc&view=rev Log: PR libstdc++/86874 fix std::variant::swap regression PR libstdc++/86874 * include/std/variant (_Copy_ctor_base::_M_destructive_move): Define here instead of in _Move_assign_base. (_Copy_ctor_base::_M_destructive_move): Define. (_Copy_assign_base::operator=): Use _M_destructive_move when changing the contained value to another alternative. (_Move_assign_base::operator=): Likewise. (_Move_assign_base::_M_destructive_move): Remove. * testsuite/20_util/variant/86874.cc: New test. Added: trunk/libstdc++-v3/testsuite/20_util/variant/86874.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/variant
[Bug c++/86881] New: tree check fail with flag Wshadow-compatible-local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86881
Bug ID: 86881
Summary: tree check fail with flag Wshadow-compatible-local
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
void a() {
auto b([] {});
if (0)
auto b = 0;
}
compiled with recent gcc trunk and flag -Wshadow-compatible-local
as so:
$ ~/gcc/results.263341/bin/gcc -c -std=gnu++14 -Wshadow-compatible-local
bug454.cc
does this:
bug454.cc:4:10: internal compiler error: tree check: expected record_type or
uni
on_type or qual_union_type, have template_type_parm in lookup_base, at
cp/search
.c:198
auto b = 0;
^
0x7619b8 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../trunk/gcc/tree.c:9351
0x98faee tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_
code, tree_code)
../../trunk/gcc/tree.h:3154
0x98faee lookup_base(tree_node*, tree_node*, int, base_kind*, int)
../../trunk/gcc/cp/search.c:198
0x81442a build_user_type_conversion_1
../../trunk/gcc/cp/call.c:3782
0x815bc1 implicit_conversion
../../trunk/gcc/cp/call.c:1902
0x819d18 can_convert_arg(tree_node*, tree_node*, tree_node*, int, int)
../../trunk/gcc/cp/call.c:10673
0x8f4a4e check_local_shadow
../../trunk/gcc/cp/name-lookup.c:2737
The problem seems to have existed since before revision 262370.
Oracle E-Business Users Contact List
Hi, Hope you having a great day! I just wanted to be aware if you looking to acquire Oracle E-Business Users Contact List for your marketing efforts? We also have users of: Microsoft Dynamics 365, Ab Initio, SAS Enterprise, Deltek Vision, Zucchetti and many more... Kindly review and let me be aware of your interest so that I can get back to you with the exact counts, sample and more info regarding the same. Do let me be aware if you have any questions for me. Regards, Meghan Hudson Database Executive If you do not wish to receive these emails. Please respond Exit.
[Bug libstdc++/60441] Incorrect textual representation for std::mersenne_twister_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60441 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-07 Ever confirmed|0 |1
[Bug libstdc++/86880] Incorrect mersenne_twister_engine equality comparison between rotated states
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86880 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-07 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=60441 Ever confirmed|0 |1
[Bug target/86838] [9 Regression] ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86838 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 Sandro Mani changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3 from Sandro Mani --- @hjl.to...@gmail.com Any ideas?
[Bug target/86838] [9 Regression] ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86838 --- Comment #3 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Aug 7 17:22:19 2018 New Revision: 263362 URL: https://gcc.gnu.org/viewcvs?rev=263362&root=gcc&view=rev Log: [AArch64] Fix -mlow-precision-div (PR 86838) The "@" handling broke -mlow-precision-div, because the scalar forms of the instruction were provided by a pattern that also provided FRECPX (and so were parameterised on an unspec code as well as a mode), while the SIMD versions had a dedicated FRECPE pattern. This patch moves the scalar FRECPE handling to the SIMD pattern too (as for FRECPS) and uses a separate pattern for FRECPX. The convention in aarch64-simd-builtins.def seemed to be to add comments only if the mapping wasn't obvious (i.e. not just sticking "aarch64_" on the beginning and "" on the end), so the patch deletes the reference to the combined pattern instead of rewording it. There didn't seem to be any coverage of -mlow-precision-div in the testsuite, so the patch adds some tests for it. 2018-08-07 Richard Sandiford gcc/ PR target/86838 * config/aarch64/iterators.md (FRECP, frecp_suffix): Delete. * config/aarch64/aarch64-simd.md (aarch64_frecp): Fold FRECPE into... (@aarch64_frecpe): ...here and the move FRECPX to... (aarch64_frecpx): ...this new pattern. * config/aarch64/aarch64-simd-builtins.def: Remove comment about aarch64_frecp. gcc/testsuite/ PR target/86838 * gcc.target/aarch64/frecpe_1.c: New test. * gcc.target/aarch64/frecpe_2.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/aarch64/frecpe_1.c trunk/gcc/testsuite/gcc.target/aarch64/frecpe_2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-simd-builtins.def trunk/gcc/config/aarch64/aarch64-simd.md trunk/gcc/config/aarch64/iterators.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/86858] [9 Regression] GCC ICE at -O3 in as_a, at is-a.h:197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86858 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #2 from rsandifo at gcc dot gnu.org --- Mine.
[Bug c++/86871] [8/9 Regression] ICE: gimple check: expected gimple_assign(error_mark), have gimple_call(trunc_mod_expr) in gimple_assign_lhs, at gimple.h:2462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86871 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #6 from rsandifo at gcc dot gnu.org --- Mine.
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 --- Comment #2 from Sandro Mani --- Started with commit cd557ff63f388ad27c376d0a225e74d3594a6f9d Author: hjl Date: Thu Aug 10 15:29:05 2017 + i386: Don't use frame pointer without stack access When there is no stack access, there is no need to use frame pointer even if -fno-omit-frame-pointer is used and caller's frame pointer is unchanged. gcc/ PR target/81736 * config/i386/i386.c (ix86_finalize_stack_realign_flags): Renamed to ... (ix86_finalize_stack_frame_flags): This. Also clear frame_pointer_needed if -fno-omit-frame-pointer is used without stack access. (ix86_expand_prologue): Replace ix86_finalize_stack_realign_flags with ix86_finalize_stack_frame_flags. (ix86_expand_epilogue): Likewise. (ix86_expand_split_stack_prologue): Likewise. * doc/invoke.texi: Add a note for -fno-omit-frame-pointer. gcc/testsuite/ PR target/81736 * gcc.target/i386/pr81736-1.c: New test. * gcc.target/i386/pr81736-2.c: Likewise. * gcc.target/i386/pr81736-3.c: Likewise. * gcc.target/i386/pr81736-4.c: Likewise. * gcc.target/i386/pr81736-5.c: Likewise. * gcc.target/i386/pr81736-6.c: Likewise. * gcc.target/i386/pr81736-7.c: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@251028 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #16 from qinzhao at gcc dot gnu.org --- please test the proposed patch on your platform, let me know the result.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #15 from qinzhao at gcc dot gnu.org --- Created attachment 44516 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44516&action=edit proposed patch
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480 Paolo Carlini changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Paolo Carlini --- Closing again.
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480 --- Comment #21 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Aug 7 16:40:18 2018 New Revision: 263361 URL: https://gcc.gnu.org/viewcvs?rev=263361&root=gcc&view=rev Log: /cp 2018-08-07 Paolo Carlini PR c++/59480, DR 136 * decl.c (check_no_redeclaration_friend_default_args): New. (duplicate_decls): Use the latter; also check that a friend declaration specifying default arguments is a definition. /testsuite 2018-08-07 Paolo Carlini PR c++/59480, DR 136 * g++.dg/other/friend8.C: New. * g++.dg/other/friend9.C: Likewise. * g++.dg/other/friend10.C: Likewise. * g++.dg/other/friend11.C: Likewise. * g++.dg/other/friend12.C: Likewise. * g++.dg/other/friend13.C: Likewise. * g++.dg/other/friend14.C: Likewise. * g++.dg/other/friend15.C: Likewise. * g++.dg/parse/defarg4.C: Compile with -fpermissive -w. * g++.dg/parse/defarg8.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/other/friend10.C trunk/gcc/testsuite/g++.dg/other/friend11.C trunk/gcc/testsuite/g++.dg/other/friend12.C trunk/gcc/testsuite/g++.dg/other/friend13.C trunk/gcc/testsuite/g++.dg/other/friend14.C trunk/gcc/testsuite/g++.dg/other/friend15.C trunk/gcc/testsuite/g++.dg/other/friend8.C trunk/gcc/testsuite/g++.dg/other/friend9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/defarg4.C trunk/gcc/testsuite/g++.dg/parse/defarg8.C
[Bug c++/86878] G++ should warn about invalid alignments passed to allocation functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86878 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 16:10:29 2018 New Revision: 263360 URL: https://gcc.gnu.org/viewcvs?rev=263360&root=gcc&view=rev Log: PR libstdc++/86861 Meet precondition for Solaris memalign Solaris memalign requires alignment to be at least sizeof(int), so increase it as needed. Also move the check for valid alignments from the fallback implementation of aligned_alloc into operator new, as it's required for all of aligned_alloc, memalign, posix_memalign and __aligned_malloc. This adds a branch to check for undefined behaviour which we could just ignore, so the check could just be removed. It should certainly be removed if PR 86878 is implemented to issue a warning about calls with invalid alignments. PR libstdc++/86861 * libsupc++/new_opa.cc [_GLIBCXX_HAVE_MEMALIGN] (aligned_alloc): Replace macro with inline function. [__sun]: Increase alignment to meet memalign precondition. [!HAVE__ALIGNED_MALLOC && !HAVE_POSIX_MEMALIGN && !HAVE_MEMALIGN] (aligned_alloc): Move check for valid alignment to operator new. Remove redundant check for non-zero size, it's enforced by the caller. (operator new): Move check for valid alignment here. Use __builtin_expect on check for zero size. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/new_opa.cc
[Bug libstdc++/86861] 18_support/new_aligned.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86861 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Tue Aug 7 16:10:29 2018 New Revision: 263360 URL: https://gcc.gnu.org/viewcvs?rev=263360&root=gcc&view=rev Log: PR libstdc++/86861 Meet precondition for Solaris memalign Solaris memalign requires alignment to be at least sizeof(int), so increase it as needed. Also move the check for valid alignments from the fallback implementation of aligned_alloc into operator new, as it's required for all of aligned_alloc, memalign, posix_memalign and __aligned_malloc. This adds a branch to check for undefined behaviour which we could just ignore, so the check could just be removed. It should certainly be removed if PR 86878 is implemented to issue a warning about calls with invalid alignments. PR libstdc++/86861 * libsupc++/new_opa.cc [_GLIBCXX_HAVE_MEMALIGN] (aligned_alloc): Replace macro with inline function. [__sun]: Increase alignment to meet memalign precondition. [!HAVE__ALIGNED_MALLOC && !HAVE_POSIX_MEMALIGN && !HAVE_MEMALIGN] (aligned_alloc): Move check for valid alignment to operator new. Remove redundant check for non-zero size, it's enforced by the caller. (operator new): Move check for valid alignment here. Use __builtin_expect on check for zero size. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/new_opa.cc
[Bug target/86386] [8/9 Regression] unaligned load from stack with -Os -fno-tree-dce -mstringop-strategy=vector_loop -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86386 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from H.J. Lu --- Fixed for GCC 9 and 8.3.
[Bug target/86386] [8/9 Regression] unaligned load from stack with -Os -fno-tree-dce -mstringop-strategy=vector_loop -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86386 --- Comment #8 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Aug 7 15:06:01 2018 New Revision: 263359 URL: https://gcc.gnu.org/viewcvs?rev=263359&root=gcc&view=rev Log: i386: Set cfun->machine->max_used_stack_alignment if needed cfun->machine->max_used_stack_alignment is used to decide how stack frame should be aligned. This is independent of any psABIs nor 32-bit vs 64-bit. It is always safe to compute max_used_stack_alignment. We compute it only if 128-bit aligned load/store may be generated on misaligned stack slot which will lead to segfault. gcc/ Backport from mainline PR target/86386 * config/i386/i386.c (ix86_finalize_stack_frame_flags): Set cfun->machine->max_used_stack_alignment if needed. gcc/testsuite/ Backport from mainline PR target/86386 * gcc.target/i386/pr86386.c: New file. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr86386.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/i386/i386.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/86872] [9 Regression] LTO bootstrap failed with profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86872
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #3 from David Malcolm ---
(In reply to H.J. Lu from comment #0)
> On x86-64, r263300 gave
Annotating it with the code in question:
> In function ‘gimple_simplify_32’:
> lto1: internal compiler error: in linemap_check_ordinary, at
> libcpp/include/line-map.h:587
> 0x5e2991 ???
> ../../src-trunk/libcpp/include/line-map.h:587
linemap_assert (MAP_ORDINARY_P (map));
> 0x93aeae ???
> ../../src-trunk/libcpp/line-map.c:754
In linemap_line_start:
/* Allocate the new line_map. However, if the current map only has a
single line we can sometimes just increase its column_bits instead. */
if (line_delta < 0
|| last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
|| SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits))
|| range_bits < map->m_range_bits)
map = linemap_check_ordinary
(const_cast
(linemap_add (set, LC_RENAME,
ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
ORDINARY_MAP_FILE_NAME (map),
to_line)));
> 0x1d653e2 ???
> ../../src-trunk/gcc/lto-streamer-in.c:194
in lto_location_cache::apply_location_cache ():
linemap_line_start (line_table, loc.line, max + 1);
> 0x1d6661f ???
> ../../src-trunk/gcc/lto-streamer-in.c:304
in stream_input_location_now:
data_in->location_cache.apply_location_cache ();
> 0xbc5f88 ???
> ../../src-trunk/gcc/gimple-streamer-in.c:111
in input_gimple_stmt:
/* Read location information. Caching here makes no sense until streamer
cache can handle the following gimple_set_block. */
gimple_set_location (stmt, stream_input_location_now (&bp, data_in));
(etc)
linemap_add can return NULL with LC_LEAVE, but we have LC_RENAME.
The return value ("map") comes from:
linemap_assert (reason != LC_ENTER_MACRO);
line_map_ordinary *map
= linemap_check_ordinary (new_linemap (set, start_location));
map->reason = reason;
linemap_check_ordinary is:
linemap_assert (MAP_ORDINARY_P (map));
which, in turn is:
inline bool
MAP_ORDINARY_P (const line_map *map)
{
return map->start_location < LINE_MAP_MAX_LOCATION;
}
map->start_location shouldn't be able to change.
I believe what's happened is that:
to_line >= LINE_MAP_MAX_LOCATION
within linemap_line_start.
That way, linemap_add would (unexpectedly) create a macro map, rather than an
ordinary map.
Presumably we need some kind of overflow handling here (assuming that the above
correctly characterizes the cause of the crash).
Also, it seems bad to be running out of location_t values. We probably should
double-check that we're packing things efficiently.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #14 from qinzhao at gcc dot gnu.org --- reported by christophe.l...@linaro.org: After this change,(disable strcmp/strncmp inlining with O2 below and Os), I've noticed that: FAIL: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand "__builtin_memcmp" 6 on arm-none-linux-gnueabi --with-mode thumb --with-cpu cortex-a9 and forcing -march=armv5t via RUNTESTFLAGS The log says: gcc.dg/strcmpopt_6.c: pattern found 4 times FAIL: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand "__builtin_memcmp" 6 although this is NOT the exactly same bug as this PR, I listed here to fix the testcase all together with this PR.
[Bug libstdc++/86880] New: Incorrect mersenne_twister_engine equality comparison between rotated states
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86880
Bug ID: 86880
Summary: Incorrect mersenne_twister_engine equality comparison
between rotated states
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
mersenne_twister_engines whose textual representation should be equal should
also compare equal.
The following program has two engines with initial states
|2 1 2
and
|3 1 2.
The engine with state |3 1 2 transitions to states
0 |1 2,
0 2 |2,
|0 2 1,
and
2 |2 1.
The textual representation of states |2 1 2 and 2 |2 1 are both specified to
be "2 1 2". That is, adjusted by rotation, the states are the same.
The engines are compared while in those states.
The comparison fails with libstdc++.
Online compiler: https://wandbox.org/permlink/RqdbiJZk6gVN0ici
Note: libstdc++ does not produce "2 1 2" as the textual representation
(as reported by PR 60441).
=== SOURCE ():
#include
#ifdef NDEBUG
#undef NDEBUG
#endif
#include
#ifdef TRACE
#include
#undef TRACE
#define TRACE( X ) do { X } while(0)
#else
#define TRACE( X ) //
#endif
int main(void) {
typedef unsigned int EngResType;
constexpr size_t word_size = 3u;
constexpr size_t state_size = 3u;
constexpr size_t shift_size = 1u;
constexpr size_t tempering_l = word_size;
using namespace std;
using EngineType = std::mersenne_twister_engine<
EngResType, word_size, state_size,
shift_size,
0u,
0x0,
0u, 0x0,
0u, 0x0,
0u, 0x0,
tempering_l,
0>;
EngineType mteA(0b010), mteB(0b011);
TRACE( cout << "Engine A: " << mteA << endl;
cout << "Engine B: " << mteB << "\n" << endl; );
for (int i = 0; i < 4; ++i) {
mteB();
TRACE( cout << "Engine B: " << mteB << endl; );
}
TRACE( cout << "\nEngine A: " << mteA << endl;
cout << "Engine B: " << mteB << endl; );
assert(mteA == mteB);
}
=== COMPILER INVOCATION:
g++ -std=c++17 -pedantic-errors -Wall -Wextra -Werror -xc++ - -o ./a.out
=== RUN SCRIPT:
./a.out
=== EXPECTED RUN OUTPUT:
(Exits with rc=0).
=== ACTUAL RUN OUTPUT:
a.out: :47: int main(): Assertion `mteA == mteB' failed.
=== COMPILER VERSION INFO:
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 9.0.0 20180805 (experimental) (GCC)
[Bug target/86785] hppa port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86785 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Earnshaw --- Really fixed by commit r263344
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86785, which changed state. Bug 86785 Summary: hppa port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86785 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86807] spu port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86807 --- Comment #4 from Richard Earnshaw --- Author: rearnsha Date: Tue Aug 7 14:33:09 2018 New Revision: 263358 URL: https://gcc.gnu.org/viewcvs?rev=263358&root=gcc&view=rev Log: Fix PR number for HPPA speculation patch: PR target/86807 -> PR target/86785 This just fixes the PR number in the ChangeLog. Nothing we can do about the SVN history. Modified: trunk/gcc/ChangeLog
[Bug target/86785] hppa port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86785 --- Comment #1 from Richard Earnshaw --- Author: rearnsha Date: Tue Aug 7 14:33:09 2018 New Revision: 263358 URL: https://gcc.gnu.org/viewcvs?rev=263358&root=gcc&view=rev Log: Fix PR number for HPPA speculation patch: PR target/86807 -> PR target/86785 This just fixes the PR number in the ChangeLog. Nothing we can do about the SVN history. Modified: trunk/gcc/ChangeLog
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 79133, which changed state. Bug 79133 Summary: lambda capture shadowing parameter & decltype confusion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79133 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/79133] lambda capture shadowing parameter & decltype confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79133 Ville Voutilainen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Ville Voutilainen --- Fixed.
[Bug c++/79133] lambda capture shadowing parameter & decltype confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79133 --- Comment #6 from ville at gcc dot gnu.org --- Author: ville Date: Tue Aug 7 13:46:16 2018 New Revision: 263357 URL: https://gcc.gnu.org/viewcvs?rev=263357&root=gcc&view=rev Log: PR c++/79133 gcc/cp/ PR c++/79133 * name-lookup.c (check_local_shadow): Reject captures and parameters with the same name. testsuite/ PR c++/79133 * g++.dg/cpp0x/lambda/lambda-shadow3.C: New. * g++.dg/cpp1y/lambda-generic-variadic18.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c
[Bug libstdc++/86874] [8/9 Regression] std::swap on std::variant fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86874 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug middle-end/64463] Add warning: returns_nonnull attribute on a function compared against NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64463 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > Incorrectly putting the attribute on the function is likely to be much rarer > than unnecessarily checking the result. And PR 84202 would address the problem of incorrectly placing the attribute, and would be based on the definition, not how the callers use it.
[Bug middle-end/64463] Add warning: returns_nonnull attribute on a function compared against NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64463 --- Comment #4 from Jonathan Wakely --- (In reply to Reini Urban from comment #0) > I would like to see a warning when a returns_nonnull function is compared > against a NULL value, and then actual code is removed or skipped based on > that attribute. I don't care if any code is removed or skipped, I want the warning anyway. If the code isn't removed then it means you're performing unnecessary work, pessimising your code. > Which is either a difficult to diagnose declaration error, > or a logical error in the usage. > > warning: returns_nonnull attribute on a function compared against NULL This wording seems to be aimed at the author of the function, suggesting that the attribute might be misplaced. I think the warning should instead be aimed at the caller, telling them to remove the redundant check. Incorrectly putting the attribute on the function is likely to be much rarer than unnecessarily checking the result.
[Bug middle-end/64463] Add warning: returns_nonnull attribute on a function compared against NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64463 --- Comment #3 from Jonathan Wakely --- I created the very similar PR 86879 for the C++ front-end (it also covers an additional case, where a function returns a reference and the address is compared to null).
[Bug c++/86879] New: G++ should warn about redundant tests for null pointers returned from functions with __attribute__((returns_nonnull))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86879
Bug ID: 86879
Summary: G++ should warn about redundant tests for null
pointers returned from functions with
__attribute__((returns_nonnull))
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
void* get() __attribute__((returns_nonnull));
int main() { return get() ? 0 : 1; }
This compiles without any diagnostic, but the check for a null pointer is
redundant because of the attribute.
It seems like this would fit under -Wnonnull-compare
Also, this should produce a similar warning:
int& ref();
int main()
{
return &ref() ? 0 : 1;
}
This check can never fail, because a reference cannot be bound to a null
pointer, but G++ is silent. Clang says:
nonnull.cc:5:11: warning: reference cannot be bound to dereferenced null
pointer in well-defined C++ code; pointer may be assumed to always convert to
true [-Wundefined-bool-conversion]
return &ref() ? 0 : 1;
^ ~
nonnull.cc:1:6: note: 'ref' returns a reference
int& ref();
^
1 warning generated.
[Bug fortran/86863] [OOP][F2008] type-bound module procedure name not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86863 Zaak changed: What|Removed |Added CC||zbeekman at gmail dot com --- Comment #2 from Zaak --- It appears that `module procedure` can also cause a link-time error that will get resolved when switching to `module subroutine`. I haven't dug into this too much, but I get missing/unresolved symbols, but if I switch the implementation to `module subroutine` then the unresolved symbols go away. The linker errors look like: Undefined symbols for architecture x86_64: "___vtab_fgr_mesh_Fgr.5058", referenced from: ___timestep_MOD_store in Timestep_implementation.f90.o "___vtab_grid_index_Fd_grid.5056", referenced from: ___timestep_MOD_store in Timestep_implementation.f90.o "___vtab_material_type_Material.5041", referenced from: ___timestep_MOD_store in Timestep_implementation.f90.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status Changing `module procedure` to `module subroutine` and adding the interface variables, variable declarations, etc. resolves this linker issue. So it seems that the compiler generates code looking for the wrong symbols when `module procedure` is used vs `module subroutine` inside of a submodule (maybe?) I'm not entirely sure how to go about creating a minimally complete verifiable example for this. Compilation was done with GFortran 8.2 (installed via Homebrew) on macOS and the CMake based build system has the compiler drive the linker, we don't call ld directly ourselves anywhere.
[Bug c++/86878] New: G++ should warn about invalid alignments passed to allocation functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86878
Bug ID: 86878
Summary: G++ should warn about invalid alignments passed to
allocation functions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
__attribute__ ((__alloc_align__(2)))
void* alloc(std::size_t, std::size_t);
int main()
{
(void) alloc(10, 5);
(void) ::operator new(10, std::align_val_t{5});
}
This compiles without diagnostics, but should produce two warnings because 5 is
not a power of two and so is not a valid alignment.
The attribute means that the call to alloc(10, 5) returns memory aligned to 5,
which seems unlikely. I think the attribute should imply that the argument is a
valid alignment.
It's undefined to call that operator new with a value that is not a valid
alignment, so a warning is definitely warranted there.
[Bug middle-end/83023] branch probabilities pessimize malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83023 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Implemented.
[Bug middle-end/83023] branch probabilities pessimize malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83023 --- Comment #4 from Martin Liška --- Author: marxin Date: Tue Aug 7 11:59:13 2018 New Revision: 263355 URL: https://gcc.gnu.org/viewcvs?rev=263355&root=gcc&view=rev Log: Add malloc predictor (PR middle-end/83023). 2018-08-07 Martin Liska PR middle-end/83023 * predict.c (expr_expected_value_1): Handle DECL_IS_MALLOC, BUILT_IN_REALLOC and DECL_IS_OPERATOR_NEW. * predict.def (PRED_MALLOC_NONNULL): New predictor. * doc/extend.texi: Document that malloc attribute adds hit to compiler. 2018-08-07 Martin Liska PR middle-end/83023 * gcc.dg/predict-16.c: New test. * g++.dg/predict-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/predict-1.C trunk/gcc/testsuite/gcc.dg/predict-16.c Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi trunk/gcc/predict.c trunk/gcc/predict.def trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/32815] crtstuff.c,warning, will always evaluate as 'true'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32815 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from John David Anglin --- These warnings are not a problem.
[Bug bootstrap/86872] [9 Regression] LTO bootstrap failed with profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86872 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka --- I have seen failure at same point coming and going while working on the streaming changes. I think it is some kind of overflow problem in linemaps that needs specific series of events to trigger which is there for some time.
[Bug c++/86181] [DR 1839] static object mangling conflicts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86181 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|RESOLVED|SUSPENDED Last reconfirmed||2018-08-07 Resolution|INVALID |--- Summary|static object mangling |[DR 1839] static object |conflicts |mangling conflicts Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- CWG 1839 hasn't been resolved yet and doesn't even have a proposed resolution in the issues list. It's not a bug for GCC to follow the current standard. However DR 426 says it's ill-formed. As a result of DR 426 the meaning of the program changed from undefined to ill-formed between C++14 and C++17, so GCC was previously correct, but the standard changed. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#426 If 1839 is going to make more changes in this area then this PR should be suspended until any change happens.
[Bug c++/86181] static object mangling conflicts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86181 --- Comment #3 from Jonathan Wakely --- I've asked you repeatedly to provide links to the clang bugs you're quoting from.
[Bug c++/86876] friend typedef'ed class in template class can not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86876
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Jonathan Wakely ---
(In reply to rockeet from comment #0)
> // code:
> #include
> template
> struct A {
> template
> struct X {
> void foo(U* p) { printf("p->a = %d\n", p->a); }
> };
> };
> template
> struct B {
> typedef typename A::template X > X;
> // friend typenameX; // g++ fail
It's not helpful to report a compilation failure for code with the problem
commented out. You need to provide the code that produces the error.
Anyway, this is invalid. The C++ grammar says a typename-specifier must be one
of:
typename nested-name-specifier identifier
typename nested-name-specifier simple-template-id
typename nested-name-specifier template simple-template-id
As the compiler says, a nested-name-specifier is expected, and so your code is
invalid.
[Bug c++/86871] [8/9 Regression] ICE: gimple check: expected gimple_assign(error_mark), have gimple_call(trunc_mod_expr) in gimple_assign_lhs, at gimple.h:2462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86871
johannes.hirte at datenkhaos dot de changed:
What|Removed |Added
CC||johannes.hirte at datenkhaos
dot d
||e
--- Comment #5 from johannes.hirte at datenkhaos dot de ---
backtrace:
$ gdb --quiet --args
/home/jhirte/Develop/compiler/gcc-installed/bin/x86_64-pc-linux-gnu-gcc
-march=bdver4 -O2 -ftree-vectorize -o test.o test.ii
Reading symbols from
/home/jhirte/Develop/compiler/gcc-installed/bin/x86_64-pc-linux-gnu-gcc...done.
(gdb) set follow-fork-mode child
(gdb) run
Starting program:
/home/jhirte/Develop/compiler/gcc-installed/bin/x86_64-pc-linux-gnu-gcc
-march=bdver4 -O2 -ftree-vectorize -o test.o test.ii
[New process 4459]
process 4459 is executing new program:
/home/jhirte/Develop/compiler/gcc-installed/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/cc1plus
during GIMPLE pass: vect
test.ii: In function 'void j()':
test.ii:10:6: internal compiler error: gimple check: expected
gimple_assign(error_mark), have gimple_call(round_div_expr) in
gimple_assign_lhs, at gimple.h:2445
void j() {
^
0xae0ea6 gimple_check_failed(gimple const*, char const*, int, char const*,
gimple_code, tree_code)
../../gcc/gcc/gimple.c:1212
0x107bf03 GIMPLE_CHECK2
../../gcc/gcc/gimple.h:74
0x107bf03 gimple_assign_lhs
../../gcc/gcc/gimple.h:2445
0x107bf03 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
_slp_tree*, _slp_instance*)
../../gcc/gcc/tree-vect-stmts.c:8973
0x10884f0 vect_transform_loop(_loop_vec_info*)
../../gcc/gcc/tree-vect-loop.c:7782
0x10ad969 vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:740
0xf86b05 execute
../../gcc/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/80925] [8 Regression] vect peeling failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925 --- Comment #33 from Rainer Orth --- Author: ro Date: Tue Aug 7 08:58:20 2018 New Revision: 263353 URL: https://gcc.gnu.org/viewcvs?rev=263353&root=gcc&view=rev Log: Fix gcc.dg/vect/no-section-anchors-vect-69.c on SPARC etc. (PR tree-optimization/80925) 2018-08-07 Steve Ellcey Rainer Orth PR tree-optimization/80925 * gcc.dg/vect/no-section-anchors-vect-69.c: Expect 3 loops vectorized on !vect_hw_misalign targets. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c
[Bug c++/86871] [8/9 Regression] ICE: gimple check: expected gimple_assign(error_mark), have gimple_call(trunc_mod_expr) in gimple_assign_lhs, at gimple.h:2462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86871
--- Comment #4 from Sergei Trofimovich ---
Shortened even more by removing operator overload:
int b;
int c;
void g() {
for (int f; f; f++) {
int d = 0;
for (int e = -1; e <= 1; e++) {
int a = f + e;
if (a)
d = *(&c + a);
}
*(&b + f) = d;
}
}
[Bug tree-optimization/80925] [8 Regression] vect peeling failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925 --- Comment #32 from Rainer Orth --- Author: ro Date: Tue Aug 7 08:51:29 2018 New Revision: 263352 URL: https://gcc.gnu.org/viewcvs?rev=263352&root=gcc&view=rev Log: Fix gcc.dg/vect/no-section-anchors-vect-69.c on SPARC etc. (PR tree-optimization/80925) 2018-08-07 Steve Ellcey Rainer Orth PR tree-optimization/80925 * gcc.dg/vect/no-section-anchors-vect-69.c: Expect 3 loops vectorized on !vect_hw_misalign targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c
[Bug tree-optimization/86858] [9 Regression] GCC ICE at -O3 in as_a, at is-a.h:197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86858 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-07 CC||marxin at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Version|unknown |9.0 Target Milestone|--- |9.0 Summary|gcc ICE at -O3 in as_a, at |[9 Regression] GCC ICE at |is-a.h:197 |-O3 in as_a, at is-a.h:197 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r263132.
[Bug c++/86876] friend typedef'ed class in template class can not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86876 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug c++/86871] [8/9 Regression] ICE: gimple check: expected gimple_assign(error_mark), have gimple_call(trunc_mod_expr) in gimple_assign_lhs, at gimple.h:2462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86871 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-07 CC||marxin at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Target Milestone|--- |8.3 Summary|ICE: gimple check: expected |[8/9 Regression] ICE: |gimple_assign(error_mark), |gimple check: expected |have|gimple_assign(error_mark), |gimple_call(trunc_mod_expr) |have |in gimple_assign_lhs, at|gimple_call(trunc_mod_expr) |gimple.h:2462 |in gimple_assign_lhs, at ||gimple.h:2462 Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Confirmed, started with r256210.
[Bug libstdc++/86874] [8/9 Regression] std::swap on std::variant fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86874 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-07 CC||marxin at gcc dot gnu.org Known to work||7.3.0 Target Milestone|--- |8.3 Summary|std::swap on std::variant |[8/9 Regression] std::swap |fails to compile|on std::variant fails to ||compile Ever confirmed|0 |1 Known to fail||8.2.0, 9.0 --- Comment #1 from Martin Liška --- Confirmed.
[Bug c++/86875] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86875 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-07 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|internal compiler error: in |[8/9 Regression] ICE in |tsubst_copy, at |tsubst_copy, at |cp/pt.c:15478 |cp/pt.c:15478 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with r258398.
[Bug c++/86876] friend typedef'ed class in template class can not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86876
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2018-8-7
CC||jason at gcc dot gnu.org,
||marxin at gcc dot gnu.org,
||nathan at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
Note that both clang++ and ICC reject as well:
$ clang++ pr86876.cpp -c
pr86876.cpp:12:22: error: expected a qualified name after 'typename'
friend typenameX; // g++ fail
^
1 error generated.
$ source>(12): error: a class or namespace qualified name is required
friend typenameX; // g++ fail
^
(6): error #308: member "B::a [with T=int]" (declared at line 15) is
inaccessible
void foo(U* p) { printf("p->a = %d\n", p->a); }
^
detected during instantiation of "void A::X::foo(U *) [with
T=int, U=B]" at line 19
compilation aborted for (code 2)
Compiler returned: 2
[Bug tree-optimization/86865] [9 Regression] Wrong code w/ -O2 -floop-parallelize-all -fstack-reuse=none -fwrapv -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-loop-ivcanon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86865 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-07 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Known to work||8.1.0 Blocks||59859 Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #1 from Martin Liška --- Confirmed, it's probably related to Graphite. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 [Bug 59859] [meta-bug] GRAPHITE issues
[Bug target/86877] ICE in vectorizable_load, at tree-vect-stmts.c:8038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86877 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug target/86877] ICE in vectorizable_load, at tree-vect-stmts.c:8038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86877 Martin Liška changed: What|Removed |Added Last reconfirmed||2018-8-7 CC||kyrylo.tkachov at arm dot com, ||ramana at gcc dot gnu.org, ||rdsandiford at googlemail dot com Target Milestone|--- |9.0
[Bug target/86877] New: ICE in vectorizable_load, at tree-vect-stmts.c:8038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86877 Bug ID: 86877 Summary: ICE in vectorizable_load, at tree-vect-stmts.c:8038 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: aarch64-linux-gnu Following ICEs: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/vect/vect-8.f90 --param vect-epilogues-nomask=1 -Ofast -mstrict-align during GIMPLE pass: vect /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/vect/vect-8.f90:11:0: SUBROUTINE kernel(tk) internal compiler error: in vectorizable_load, at tree-vect-stmts.c:8038 0x1473fd7 vectorizable_load /home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:8038 0x1479c1e vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*, _slp_tree*, _slp_instance*) /home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:9715 0x149dd52 vect_transform_loop_stmt /home/marxin/Programming/gcc/gcc/tree-vect-loop.c:8224 0x149eaa6 vect_transform_loop(_loop_vec_info*) /home/marxin/Programming/gcc/gcc/tree-vect-loop.c:8446 0x14c565d try_vectorize_loop_1 /home/marxin/Programming/gcc/gcc/tree-vectorizer.c:945 0x14c583b try_vectorize_loop_1 /home/marxin/Programming/gcc/gcc/tree-vectorizer.c:978 0x14c58f7 try_vectorize_loop /home/marxin/Programming/gcc/gcc/tree-vectorizer.c:995 0x14c5ad3 vectorize_loops() /home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1077 0x13549f5 execute /home/marxin/Programming/gcc/gcc/tree-ssa-loop.c:414
[Bug c++/86181] static object mangling conflicts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86181 --- Comment #2 from zhonghao at pku dot org.cn --- I reported the code to llvm. A developer of llvm said: Clang follows the agreed direction for CWG issue 1839, which says that redeclaration lookup for 'extern int i;' finds the 'static int i;' declared at namespace scope and thus the internal linkage is inherited. Does gcc follow a different lookup?
