[Bug libstdc++/88170] [9 Regression] pretty printer FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88170 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Thu Jan 31 07:37:34 2019 New Revision: 268413 URL: https://gcc.gnu.org/viewcvs?rev=268413=gcc=rev Log: PR libstdc++/88170 * c-pretty-print.c (pp_c_enumeration_constant): Print always as a C cast in pp_c_flag_gnu_v3 mode. * cxx-pretty-print.c (pp_cxx_enumeration_constant): Print always as a C cast in pp_c_flag_gnu_v3 mode. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-pretty-print.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cxx-pretty-print.c
[Bug tree-optimization/89135] New: internal compiler error: in gimple_split_edge, at tree-cfg.c:2747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89135
Bug ID: 89135
Summary: internal compiler error: in gimple_split_edge, at
tree-cfg.c:2747
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gsocshubham at gmail dot com
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Created attachment 45572
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45572=edit
Preprocessed code of file named "work11_crash.c"
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
-
COMMAND USED FOR COMPILATION
$ gcc -O1 work11_crash.c -w
work11_crash.c: In function ‘func_12’:
work11_crash.c:355:17: internal compiler error: in gimple_split_edge, at
tree-cfg.c:2747
static int32_t func_12(uint64_t p_13, uint64_t p_14, uint32_t p_15)
^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
-
REDUCED FILE USING CREDUCE
#include "csmith.h"
a, b, c, d, e;
f() {
&
int32_t h;
if (h) {
int64_t **i =
b = 0;
for (; b >= 0;)
;
g:
**i = 0;
uint64_t *j =
*j = safe_rshift_func_uint8_t_u_s(0, 5);
if (c)
goto *d;
}
goto *e;
}
--
[Bug c/89127] missing -Wtype-limits for trivially false expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89127 --- Comment #2 from Marc Glisse --- The warning is not about all comparisons that are always true/false, only about the case where this is "due to the limited range of the data type" (let me stress **type**). Only the first of your examples has that property (it can be rewritten as x
[Bug libstdc++/89130] [9 Regression] std::vector relocation fails for types with deleted move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130 --- Comment #3 from Marc Glisse --- We already discussed this https://gcc.gnu.org/ml/libstdc++/2018-09/msg7.html
[Bug tree-optimization/89134] New: A missing optimization opportunity for a simple branch in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89134
Bug ID: 89134
Summary: A missing optimization opportunity for a simple branch
in loop
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jiangning.liu at amperecomputing dot com
Target Milestone: ---
For this simple case,
__attribute__((pure)) __attribute__((noinline)) int inc(int i)
{
/* Do something else here */
return i+1;
}
extern int do_something(void);
extern int b;
void test(int n)
{
for (int i=0; i
[Bug fortran/52564] Accepts invalid: Missing I/O list after comma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52564 --- Comment #2 from Jerry DeLisle --- Author: jvdelisle Date: Thu Jan 31 03:37:16 2019 New Revision: 268412 URL: https://gcc.gnu.org/viewcvs?rev=268412=gcc=rev Log: 2019-01-30 Jerry DeLisle PR fortran/52564 * io.c (match_io): Add check for comma after '*' without subsequent IO list. * gfortran.dg/print_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/print_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug c/89133] New: bogus -Wcast-align=strict for a member of an aligned struct or union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89133
Bug ID: 89133
Summary: bogus -Wcast-align=strict for a member of an aligned
struct or union
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Assigning the address of an overaligned member of a struct or union that is of
an otherwise less aligned type to a pointer to a type with the same alignment
triggers a -Wcast-align=strict false positive. The alignment of the member
must be the same as that of the pointed-to type regardless of the target in
order to ensure the alignment of the next member which of the pointed-to type.
Note that because the member whose address is cast is the first member, it's
necessarily at the same address and thus has the same alignment as the struct
itself for which the warning is not issued.
Clang issues the same false positive here.
$ cat u.c && gcc -S -Wall -Wextra -Wcast-align=strict u.c
union {
char c;
long long x;
} u;
long long *p0 = (long long*)
long long *q0 = (long long*)
long long *r0 = (long long*)
struct {
char c;
long long x;
} s;
long long *p1 = (long long*)
long long *q1 = (long long*)
long long *r1 = (long long*)
u.c:9:17: warning: cast increases required alignment of target type
[-Wcast-align]
9 | long long *r0 = (long long*)
| ^
u.c:19:17: warning: cast increases required alignment of target type
[-Wcast-align]
19 | long long *r1 = (long long*)
| ^
[Bug other/89106] cast-to-union documentation incorrect w.r.t. lvalueness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89106 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #7 from Martin Sebor --- Fixed in r268411.
[Bug other/89106] cast-to-union documentation incorrect w.r.t. lvalueness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89106 --- Comment #6 from Martin Sebor --- Author: msebor Date: Thu Jan 31 02:33:58 2019 New Revision: 268411 URL: https://gcc.gnu.org/viewcvs?rev=268411=gcc=rev Log: PR other/89106 - cast-to-union documentation incorrect w.r.t. lvalueness gcc/ChangeLog: PR other/89106 * doc/extend.texi (cast to a union): Correct and expand. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug c++/88761] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478 when chaining lambda calls & fold-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88761 --- Comment #4 from Jason Merrill --- The #c0 and #c2 testcases are already fixed, but the #c3 testcase still breaks, so I'm going to treat this PR as being about that one.
[Bug c/89132] missing -Wcast-align casting the address of a function to a more aligned pointer type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89132 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Known to fail||9.0 --- Comment #1 from Martin Sebor --- Clang diagnoses both problems with just -Wcast-align (and apparently always has): u.c:2:16: warning: cast from 'int *' to 'long long *' increases required alignment from 4 to 8 [-Wcast-align] long long *p = (long long*) // -Wcast-align (good) ^~ u.c:5:16: warning: cast from 'void (*)(void)' to 'long long *' increases required alignment from 4 to 8 [-Wcast-align] long long *q = (long long*)f; // missing -Wcast-align ^ 2 warnings generated.
[Bug c/89132] New: missing -Wcast-align casting the address of a function to a more aligned pointer type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89132
Bug ID: 89132
Summary: missing -Wcast-align casting the address of a function
to a more aligned pointer type
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The -Wcast-align warning is documented to
Warn whenever a pointer is cast such that the required alignment of the
target is increased. For example, warn if a char * is cast to an int * on
machines where integers can only be accessed at two- or four-byte boundaries.
The strict form of the warning is documented to trigger "regardless of the
target machine."
The following test case shows that the warning fails to trigger when the
address of a function is cast to a pointer to a type with a stricter alignment.
The test case was compiled for the strictly aligned SPARC but the same problem
affects even x86.
As an aside, it would be helpful to include the alignment in the diagnostic so
that users can more easily tell what the expectations are and by how much
they're off.
$ cat u.c && /build/sparc-solaris2.11/gcc-svn/gcc/xgcc -B
/build/sparc-solaris2.11/gcc-svn/gcc -S -Wall -Wextra -Wcast-align=strict
-o/dev/stdout -xc u.c
int i = 1;
long long *p = (long long*) // -Wcast-align (good)
void f (void) { }
long long *q = (long long*)f; // missing -Wcast-align
.file "u.c"
u.c:2:16: warning: cast increases required alignment of target type
[-Wcast-align]
2 | long long *p = (long long*) // -Wcast-align (good)
|^
.section".text"
.global i
.section".data"
.align 4
.type i, #object
.size i, 4
i:
.long 1
.global p
.align 4
.type p, #object
.size p, 4
p:
.long i
.section".text"
.align 4
.global f
.type f, #function
.proc 020
f:
save%sp, -96, %sp
nop
return %i7+8
nop
.size f, .-f
.global q
.section".data"
.align 4
.type q, #object
.size q, 4
q:
.long f
.ident "GCC: (GNU) 9.0.0 20190118 (experimental)"
[Bug c/89129] [meta-bug] bogus/missing -Wtype-limits warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89129 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Martin Sebor from comment #1) > -Wtype-limits was introduced in GCC 4.3. While that flag controlling it may only have been introduced in 4.3, I think the actual messages printed by it existed before then, just without any warning flag controlling them. ISTR Apple's issuing type limits warnings, and they stopped putting out new versions with 4.2 (i.e. before 4.3)...
[Bug c++/86379] [8/9 Regression] Class member access of |using|'d field goes horribly awry in presence of templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86379 Alexandre Oliva changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED --- Comment #4 from Alexandre Oliva --- https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01764.html
[Bug sanitizer/89124] __attribute__((no_sanitize_address)) interferes with __attribute__((target(xxx)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124 --- Comment #4 from Thiago Macieira --- Or permit the inlining if the function is also __artificial__. It's documented, but I don't see anyone needing to use that besides gcc's own headers.
[Bug c/89131] New: redundant -Wabsolute-value when -Wconversion is used and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89131
Bug ID: 89131
Summary: redundant -Wabsolute-value when -Wconversion is used
and vice versa
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The newly introduced -Wabsolute-value warning (also by -Wextra) partly
duplicates the functionality of the -Wconversion warning (disabled by default).
Enabling both options leads to duplicate diagnostics for the same problem, as
the example below shows.
Normally, to avoid drowning users in excessive complaints GCC tries to avoid
issuing multiple warnings for the same construct, even if the warnings are
slightly different (e.g., -Warray-bounds, -Wrestrict, and -Wstringop-overflow
for basically the same bug).
In this case, either this particular instance of -Wabsolute-value should be
disabled when -Wconversion is enabled or (perhaps preferably), the other way
around.
$ cat u.c && gcc -S -Wall -Wextra -Wconversion u.c
int f (long x)
{
return __builtin_abs (x);
}
u.c: In function ‘f’:
u.c:3:10: warning: absolute value function ‘__builtin_abs’ given an argument of
type ‘long int’ but has parameter of type ‘int’ which may cause truncation of
value [-Wabsolute-value]
3 | return __builtin_abs (x);
| ^
u.c:3:25: warning: conversion from ‘long int’ to ‘int’ may change value
[-Wconversion]
3 | return __builtin_abs (x);
| ^
[Bug libstdc++/89130] [9 Regression] std::vector relocation fails for types with deleted move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130 --- Comment #2 from Jonathan Wakely --- However, the code that this relocation replaces uses move_if_noexcept which is also incorrect for weird allocators. So maybe those cases are already incorrect.
[Bug libstdc++/89130] [9 Regression] std::vector relocation fails for types with deleted move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130
Jonathan Wakely changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely ---
This fixes the example above:
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -883,7 +883,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus >= 201103L
template
-inline void
+inline __enable_if_t::value>
__relocate_object_a(_Tp* __dest, _Up* __orig, _Allocator& __alloc)
noexcept(noexcept(std::allocator_traits<_Allocator>::construct(__alloc,
__dest, std::move(*__orig)))
@@ -895,6 +895,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__traits::destroy(__alloc, std::__addressof(*__orig));
}
+ template
+inline __enable_if_t::value>
+__relocate_object_a(_Tp*, _Up*, _Allocator&) noexcept(false)
+{ }
+
// This class may be specialized for specific types.
template
struct __is_trivially_relocatable
The trick here is to select an overload of __relocate_object_a that has a
potentially throwing noexcept-specifier, which means that std::vector will
never try to use it.
This only works if allocator_traits::construct forwards the arguments
unchanged, because otherwise the is_constructible check is wrong.
Maybe as discussed we need to detect when allocator_traits::construct has been
specialized, and not try to relocate in that case.
Or maybe we should just revert this relocation stuff for now.
[Bug libstdc++/89130] New: [9 Regression] std::vector relocation fails for types with deleted move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130
Bug ID: 89130
Summary: [9 Regression] std::vector relocation fails for types
with deleted move constructor
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: redi at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
struct X {
X() { }
X(const X&) { }
X(X&&) = delete;
};
int main()
{
const X x;
std::vector v;
v.push_back(x);
}
In file included from
/home/jwakely/gcc/9/include/c++/9.0.1/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
from
/home/jwakely/gcc/9/include/c++/9.0.1/bits/allocator.h:46,
from /home/jwakely/gcc/9/include/c++/9.0.1/vector:64,
from del.cc:7:
/home/jwakely/gcc/9/include/c++/9.0.1/ext/new_allocator.h: In instantiation of
'void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
X; _Args = {X}; _Tp = X]':
/home/jwakely/gcc/9/include/c++/9.0.1/bits/alloc_traits.h:482:2: required
from 'static void std::allocator_traits
>::construct(std::allocator_traits >::allocator_type&,
_Up*, _Args&& ...) [with _Up = X; _Args = {X}; _Tp = X;
std::allocator_traits >::allocator_type =
std::allocator]'
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_uninitialized.h:888:67:
required from 'void std::__relocate_object_a(_Tp*, _Up*, _Allocator&) [with _Tp
= X; _Up = X; _Allocator = std::allocator]'
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_uninitialized.h:919:47:
required from '_ForwardIterator std::__relocate_a_1(_InputIterator,
_InputIterator, _ForwardIterator, _Allocator&) [with _InputIterator = X*;
_ForwardIterator = X*; _Allocator = std::allocator]'
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_uninitialized.h:940:37:
required from '_ForwardIterator std::__relocate_a(_InputIterator,
_InputIterator, _ForwardIterator, _Allocator&) [with _InputIterator = X*;
_ForwardIterator = X*; _Allocator = std::allocator]'
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_vector.h:430:35: required from
'static constexpr bool std::vector<_Tp, _Alloc>::_S_use_relocate() [with _Tp =
X; _Alloc = std::allocator]'
/home/jwakely/gcc/9/include/c++/9.0.1/bits/vector.tcc:460:33: required from
'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const X&}; _Tp = X; _Alloc =
std::allocator; std::vector<_Tp, _Alloc>::iterator =
__gnu_cxx::__normal_iterator >; typename
std::_Vector_base<_Tp, _Alloc>::pointer = X*]'
/home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_vector.h:1162:4: required from
'void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = X;
_Alloc = std::allocator; std::vector<_Tp, _Alloc>::value_type = X]'
del.cc:13:16: required from here
/home/jwakely/gcc/9/include/c++/9.0.1/ext/new_allocator.h:145:20: error: use of
deleted function 'X::X(X&&)'
145 | noexcept(noexcept(::new((void *)__p)
|^~
146 |_Up(std::forward<_Args>(__args)...)))
|~~~
del.cc:4:3: note: declared here
4 | X(X&&) = delete;
| ^
[Bug libstdc++/89130] [9 Regression] std::vector relocation fails for types with deleted move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-31 Ever confirmed|0 |1
[Bug target/71617] rs6000.c:8483:32: warning: comparison is always true due to limited range of data type [-Wtype-limits]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71617 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-01-31 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Should this be resolved as fixed then?
[Bug c/89129] [meta-bug] bogus/missing -Wtype-limits warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89129 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-31 Version|9.0 |4.3.0 Ever confirmed|0 |1 Alias||Wtype-limits --- Comment #1 from Martin Sebor --- -Wtype-limits was introduced in GCC 4.3.
[Bug c/89129] New: [meta-bug] bogus/missing -Wtype-limits warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89129 Bug ID: 89129 Summary: [meta-bug] bogus/missing -Wtype-limits warnings Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This meta bug tracks -Wtype-limits false negatives and false positives.
[Bug libstdc++/89128] New: Missing CTAD deduction guides for std::stack and std::queue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89128
Bug ID: 89128
Summary: Missing CTAD deduction guides for std::stack and
std::queue
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
https://godbolt.org/z/IdXUBQ
std::deque dq;
auto st = std::stack{dq};
This should be deduced as equivalent to
auto st = std::stack>{dq};
because of the deduction guide in http://eel.is/c++draft/stack.defn
template
stack(Container) -> stack;
Instead, libstdc++ gives an error.
It looks to me as if nobody's gotten around to putting the required deduction
guides in /libstdc++-v3/include/bits/stl_stack.h yet.
Same deal for std::queue:
std::list lst;
auto q = std::queue{lst};
should be deduced as equivalent to
auto q = std::queue>{lst};
[Bug c/89127] missing -Wtype-limits for trivially false expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89127 Martin Sebor changed: What|Removed |Added Keywords||diagnostic See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89126 Known to fail||4.3.5, 4.4.7, 4.8.5, 4.9.4, ||5.4.0, 6.5.0, 7.3.0, 8.2.0, ||9.0 --- Comment #1 from Martin Sebor --- This never worked. See also bug 89126.
[Bug c/89127] New: missing -Wtype-limits for trivially false expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89127
Bug ID: 89127
Summary: missing -Wtype-limits for trivially false expressions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC appears to fold certain non-constant relational expressions into constants
very early when it determines their value based on the limited range of the
non-constant operand. For instance, it folds (x * x < 0) to false for any
integer x. This ability would suggest that GCC should likewise be able to
issue -Wtype-limits warnings for such expressions as the manual indicates it's
designed to do:
Warn if a comparison is always true or always false due to the limited range
of the data type.
However, GCC does not issue the -Wtype-limits warning in these cases. Either
the manual needs to be updated to make it clear that the warning doesn't
consider such expressions or (preferably) the warning should be enhanced to
detect these cases since they could be masking bugs.
$ cat u.c && gcc -S -Wall -Wextra -Wtype-limits
-fdump-tree-original=/dev/stdout u.c
void f (int x)
{
if (x + __INT_MAX__ + 1 < 0) // folded to false but no -Wtype-limits
__builtin_abort ();
if (x - x < 0) // ditto
__builtin_abort ();
if (x * x < 0) // ditto
__builtin_abort ();
if (__builtin_abs (x) < 0) // ditto
__builtin_abort ();
}
;; Function f (null)
;; enabled by -tree-original
{
if (0)
{
__builtin_abort ();
}
if (0)
{
__builtin_abort ();
}
if (0)
{
__builtin_abort ();
}
if (0)
{
__builtin_abort ();
}
}
[Bug c/89126] missing -Wtype-limits for int variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89126 --- Comment #2 from Martin Sebor --- In ILP32 it doesn't work for long either.
[Bug c++/88988] [8/9 Regression] ICE: Segmentation fault (in lookup_name_real_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88988 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Jan 30 23:28:53 2019 New Revision: 268407 URL: https://gcc.gnu.org/viewcvs?rev=268407=gcc=rev Log: PR c++/88988 * lambda.c (is_capture_proxy): Don't return true for DECL_OMP_PRIVATIZED_MEMBER artificial vars. * testsuite/libgomp.c++/pr88988.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr88988.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/lambda.c trunk/libgomp/ChangeLog
[Bug c/89126] missing -Wtype-limits for int variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89126 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Known to fail||4.4.7, 4.8.5, 4.9.4, 5.4.0, ||6.4.0, 7.3.0, 8.2.0, 9.0 --- Comment #1 from Martin Sebor --- This never seems to have worked. Interestingly, Clang has the same bug.
[Bug c/89126] New: missing -Wtype-limits for int variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89126
Bug ID: 89126
Summary: missing -Wtype-limits for int variables
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC issues -Wtype-limits warnings for relational expressions that either cannot
be true or cannot be false due to the limits of the type of one of their
operands. This seems to work except for operands of type int where GCC fails
to issue any warnings.
$ cat u.c && gcc -S -Wall -Wextra -Wpedantic u.c
int fchar (signed char x)
{
if (x <= __SCHAR_MAX__) // -Wtype-limits (good)
return 1;
if (x > __SCHAR_MAX__)// -Wtype-limits (good)
return 1;
return 0;
}
int fshrt (short x)
{
if (x <= __SHRT_MAX__)// -Wtype-limits (good)
return 1;
if (x > __SHRT_MAX__) // -Wtype-limits (good)
return 1;
return 0;
}
int fint (int x)
{
if (x <= __INT_MAX__) // missing -Wtype-limits
return 1;
if (x > __INT_MAX__) // missing -Wtype-limits
return 1;
return 0;
}
int flong (int x)
{
if (x <= __LONG_MAX__)// -Wtype-limits (good)
return 1;
if (x > __LONG_MAX__) // -Wtype-limits (good)
return 1;
return 0;
}
u.c: In function ‘fchar’:
u.c:3:9: warning: comparison is always true due to limited range of data type
[-Wtype-limits]
3 | if (x <= __SCHAR_MAX__) // -Wtype-limits (good)
| ^~
u.c:6:9: warning: comparison is always false due to limited range of data type
[-Wtype-limits]
6 | if (x > __SCHAR_MAX__)// -Wtype-limits (good)
| ^
u.c: In function ‘fshrt’:
u.c:14:9: warning: comparison is always true due to limited range of data type
[-Wtype-limits]
14 | if (x <= __SHRT_MAX__)// -Wtype-limits (good)
| ^~
u.c:17:9: warning: comparison is always false due to limited range of data type
[-Wtype-limits]
17 | if (x > __SHRT_MAX__) // -Wtype-limits (good)
| ^
u.c: In function ‘flong’:
u.c:37:9: warning: comparison is always true due to limited range of data type
[-Wtype-limits]
37 | if (x <= __LONG_MAX__)// -Wtype-limits (good)
| ^~
u.c:40:9: warning: comparison is always false due to limited range of data type
[-Wtype-limits]
40 | if (x > __LONG_MAX__) // -Wtype-limits (good)
| ^
[Bug libstdc++/89117] [9 regression] filesystem::path's replace_extension() broken?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89117
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Wed Jan 30 23:18:22 2019
New Revision: 268406
URL: https://gcc.gnu.org/viewcvs?rev=268406=gcc=rev
Log:
PR libstdc++/89117 fix path::replace_extension("") case
Previously the operator+=(extension) call would have re-parsed the path
and recreated the components with the right extension. Since optimising
it to not re-parse the whole string, we need to actually remove the
extension from the final filename before appending anything to it, and
append the dot to that final component too.
PR libstdc++/89117
* src/c++17/fs_path.cc (path::replace_extension): Erase extension from
final component as well as from _M_pathname. Append the dot using
operator+= instead of only to _M_pathname.
(path::_M_find_extension): Reformat slightly.
* testsuite/27_io/filesystem/path/modifiers/replace_extension.cc:
Add more test cases.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++17/fs_path.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/modifiers/replace_extension.cc
--- Comment #3 from Jonathan Wakely ---
Fixed, thanks for the report.
[Bug libstdc++/89117] [9 regression] filesystem::path's replace_extension() broken?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89117
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Wed Jan 30 23:18:22 2019
New Revision: 268406
URL: https://gcc.gnu.org/viewcvs?rev=268406=gcc=rev
Log:
PR libstdc++/89117 fix path::replace_extension("") case
Previously the operator+=(extension) call would have re-parsed the path
and recreated the components with the right extension. Since optimising
it to not re-parse the whole string, we need to actually remove the
extension from the final filename before appending anything to it, and
append the dot to that final component too.
PR libstdc++/89117
* src/c++17/fs_path.cc (path::replace_extension): Erase extension from
final component as well as from _M_pathname. Append the dot using
operator+= instead of only to _M_pathname.
(path::_M_find_extension): Reformat slightly.
* testsuite/27_io/filesystem/path/modifiers/replace_extension.cc:
Add more test cases.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++17/fs_path.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/modifiers/replace_extension.cc
--- Comment #3 from Jonathan Wakely ---
Fixed, thanks for the report.
[Bug c/60170] No -Wtype-limits warning with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60170 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Known to fail||4.4.7, 4.8.5, 4.9.4, 5.4.0, ||6.4.0, 7.3.0, 8.2.0, 9.0 --- Comment #3 from Martin Sebor --- No change in GCC 9. G++ has diagnosed the code since version 5 (at all -O levels). Clang since 3.2.
[Bug c/89122] bad fix-it hint for FLT_MAX when is included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89122 --- Comment #2 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01756.html
[Bug libstdc++/89121] std::min_element (and max_element) 3.6 times slower than hand written loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89121 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- .
[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #10 from David Edelsohn --- Protobufs didn't used to work on AIX. If it does, great. CMake on AIX is broken. AIX behaves differently for export of global symbols, yes, but -bexpall -- exporting all symbols -- is completely wrong. Also, I strongly doubt that Protobufs or the application requires runtime linking (-brtl). And this likely is the reason that -bbigtoc is added because rtl is pulling in all global functions for symbolic overriding which overflows the TOC. This is layer upon layer of incompetence. -bexpall likely is exporting symbols that should not be exported, causing collisions and/or forcing symbols into the a conflicting section. If one looks at libtool support for AIX (and GCC build), it explicitly builds an export file from a shell pipeline that utilizes "nm". It's not perfect, but a lot better and safer than exporting everything and hoping that nothing bad happens. Guess what? Something bad happened.
[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Paprocki from comment #8) > David, -brtl and -bexpall are coming from CMake itself: > https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Platform/AIX-XL. > cmake > > *All* software (open-source and closed-source) using CMake as a build system > uses these flags by default when building on AIX. AIX is hard enough to > wrangle open-source software on -- don't shoot the messenger. And this is why I keep on saying to people CMAKE is much worse than auto-tools. They don't know what they are doing.
[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #8 from Andrew Paprocki --- David, -brtl and -bexpall are coming from CMake itself: https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Platform/AIX-XL.cmake *All* software (open-source and closed-source) using CMake as a build system uses these flags by default when building on AIX. AIX is hard enough to wrangle open-source software on -- don't shoot the messenger. I'm just trying to determine the root cause of the failure and I have no problem putting in the time to PR CMake or multiple projects to override these settings if I have to in order to fix their worldview of AIX. > Is protobufs even known to build on AIX? Like I said above, protobufs builds and runs fine on AIX using GCC 5. I only hit this when I try GCC 6+.
[Bug fortran/67531] No IEEE rounding support for powerpc long double type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67531 --- Comment #9 from Uroš Bizjak --- (In reply to David Edelsohn from comment #7) > What progress do you expect? IBM long double does not support non-default > rounding. This will be fixed when PPC64LE long double defaults to IEEE 128 > bit floating point. ieee_arithmetic.F90 can be enhanced to pass "kind" argument to support_fpu_rounding_mode, so it would be defined in fpu-glibc.h as: int support_fpu_rounding_mode (int mode, int kind) Using some #ifdeffery (involving __powerpc__ and __float128), the function could return 0 for unsupported kinds. Please see how underflow control is handled in fpu-glibc.h for alpha, where target supports underflow control only for 32bit and 64bit hardware floats, not for 128bit soft-fp floats.
[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #7 from David Edelsohn --- Is protobufs even known to build on AIX? Whoever wrote the link command for AIX didn't know what they were doing and threw every option they could at the problem until it appeared to work. This is wrong. -bexpall -bsvr4 -brtl likely is very wrong. Until it's proven that this isn't cockpit error, this won't be analyzed or fixed.
[Bug target/89057] [8/9 Regression] AArch64 ld3 st4 less optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057 --- Comment #4 from Allan Jensen --- While that change might have made things worse. The real problem is probably that the registers for those instructions are loaded and stored using intrinsics, so proper register allocation and combining cant be performed. For ARMv7 for instance the same code can be optimized to having no moves but just a single vswp instruction between ld3 and st4. And MSVC and clang can do that but GCC can not.
[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246 --- Comment #7 from Vladimir Makarov --- Author: vmakarov Date: Wed Jan 30 21:49:23 2019 New Revision: 268404 URL: https://gcc.gnu.org/viewcvs?rev=268404=gcc=rev Log: 2019-01-30 Vladimir Makarov PR rtl-optimization/87246 * lra-constraints.c (simplify_operand_subreg): Reload memory in subreg if the address became invalid. 2019-01-30 Vladimir Makarov PR rtl-optimization/87246 * gcc.target/i386/pr87246.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr87246.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug target/89125] Misoptimization of converting sin(x) and cos(x) into sincos(x,,)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #6 from kargl at gcc dot gnu.org --- Checking with FreeBSD developers on C99 compliance.
[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #6 from Andrew Paprocki --- The source code for main.cc is found here: https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/compiler/main.cc
[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #5 from Andrew Paprocki --- Created attachment 45571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45571=edit g++-8 -S output for main.cc
[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #4 from Andrew Paprocki --- This occurs while building a project that depends on the protobuf library. I'll attach main.cc.s, and command lines are below. If I take the exact main.cc.o compilation line and simply swap out GCC 8.2.0 for g++-7, g++-6, g++-5, both GCC 7.3.0 & GCC 6.4.0 fail in the same manner, but GCC 5.5.0 succeeds. This is how main.cc.o is compiled: g++-8 -maix64 -pthread -DGOOGLE_PROTOBUF_CMAKE_BUILD -DHAVE_PTHREAD -DHAVE_ZLIB -D_LIBCXXABI_FUNC_VIS="" -I/path/to/third_party/protobuf/cmake -I/path/to/third_party/protobuf/src -D__STDC_FORMAT_MACROS -O2 -g -DNDEBUG -std=c++11 -o CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o -c /path/to/third_party/protobuf/src/google/protobuf/compiler/main.cc ... verbose output shows cc1plus invocation: cc1plus -quiet -v -I /path/to/third_party/protobuf/cmake -I /path/to/third_party/protobuf/src -imultilib pthread/ppc64 -iprefix /path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/ -D_ALL_SOURCE -D__COMPATMATH__ -D__64BIT__ -D_THREAD_SAFE -D GOOGLE_PROTOBUF_CMAKE_BUILD -D HAVE_PTHREAD -D HAVE_ZLIB -D _LIBCXXABI_FUNC_VIS= -D __STDC_FORMAT_MACROS -D NDEBUG /path/to/third_party/protobuf/src/google/protobuf/compiler/main.cc -quiet -dumpbase main.cc -maix64 -auxbase-strip CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o -g -O2 -std=c++11 -version -o /tmp/ccVqNDE3.s ... verbose output shows as invocation: as -u -a64 -mppc64 -many -o CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o /tmp/ccVqNDE3.s This is how the build is attempting to link main.cc.o into a binary: g++-8 -maix64 -pthread -D__STDC_FORMAT_MACROS -O2 -g -DNDEBUG -Wl,-bnoipath -Wl,-brtl -Wl,-bbigtoc -Wl,-bexpall CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o -o protoc-3.6.1 -Wl,-blibpath:/path/to/lib64:/usr/lib:/lib libprotobuf.a libprotoc.a libprotobuf.a /path/to/lib64/libz.so Result of running verbose output on the link: COLLECT_GCC_OPTIONS='-maix64' '-pthread' '-D' '__STDC_FORMAT_MACROS' '-O2' '-g' '-D' 'NDEBUG' '-o' 'protoc-3.6.1' '-v' '-shared-libgcc' /path/to/gcc/bin/../libexec/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/collect2 -bpT:0x1000 -bpD:0x2000 -btextro -b64 -L/path/to/lib64 -brtl -R /path/to/lib64 -bsvr4 -o protoc-3.6.1 /lib/crt0_64.o /path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/pthread/ppc64/crtcxa.o /path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/pthread/ppc64/crtdbase.o -L/path/to/gcc/lib/pthread/ppc64 -R /path/to/gcc/lib/pthread/ppc64 -L/path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/pthread/ppc64 -L/path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/../../../pthread/ppc64 -L/path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0 -L/path/to/gcc/bin/../lib/gcc -L/path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/../../.. -bnoipath -brtl -bbigtoc -bexpall CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o -blibpath:/path/to/lib64:/usr/lib:/lib libprotobuf.a libprotoc.a libprotobuf.a /path/to/lib64/libz.so -lstdc++ -lm -lgcc_s /path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/pthread/ppc64/libgcc.a -lpthreads -lc -lgcc_s /path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/pthread/ppc64/libgcc.a -brtl -R /path/to/lib64 ld: 0711-308 SEVERE ERROR: Object CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o, csect <_main.ro_> The csect is part of the .text section. collect2: error: ld returned 12 exit status
[Bug c++/85481] [8/9 Regression] ICE in maybe_explain_implicit_delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85481
--- Comment #5 from Paolo Carlini ---
A better behaved testcase:
class a { ~a(); };
class b { a c; ~b() = default; };
class B { virtual ~B(); b d; };
template class E : B { };
Essentially, the ICE is triggered by the wrong use of 'template' - thus
cp_parser_explicit_instantiation - additionally to the other issue.
[Bug target/89112] Incorrect code generated by rs6000 memcmp expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112 --- Comment #2 from acsawdey at gcc dot gnu.org --- I'm seeing this on both gcc-8-branch and trunk, but only with -mcpu=power9. I'll figure out what happened here and get it fixed in trunk then back ported to 8.
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 Ian Lance Taylor changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #3 from Ian Lance Taylor --- Clearly something is badly broken, but I don't know how to find out what it is. There is no S/390 machine on the GCC compile farm. Added Dominik Vogt who contributed the initial S/390 support to gccgo.
[Bug middle-end/89125] Misoptimization of converting sin(x) and cos(x) into sincos(x,,)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
--- Comment #5 from Steve Kargl ---
On Wed, Jan 30, 2019 at 08:47:50PM +, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
>
> --- Comment #4 from Marc Glisse ---
> This looks like a target issue, gcc does produce a call to sincos here. So
> please specify your target precisely.
>
Yes, it seems to be a target issue. It's i585-*-freebsd
and x86_64-*-freebsd.
I've found that gcc/config/freebsd.h contains
#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
AFAIK, FreeBSD is C99 compliant. This is an area I haven't worked
in. I might be able to change this to default_libc_has_function,
but that doesn't include sincos. So, it seems I need a function,
perhaps, bsd_libc_has_function in targhooks.[ch]
/* Assume that c99 functions are present at the runtime,
including sincos. */
bool
bsd_libc_has_function (enum function_class fn_class)
{
if (fn_class == function_c94
|| fn_class == function_c99_misc
|| fn_class == function_c99_math_complex
|| fn_class == function_sincos)
return true;
return false;
}
[Bug sanitizer/89124] __attribute__((no_sanitize_address)) interferes with __attribute__((target(xxx)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124
--- Comment #3 from Jakub Jelinek ---
We have (for a few years already) refused to inline if the callee and caller
disagree on the requested (-fsanitize=address related) sanitization flags:
static bool
sanitize_attrs_match_for_inline_p (const_tree caller, const_tree callee)
{
if (!caller || !callee)
return true;
return ((sanitize_flags_p (SANITIZE_ADDRESS, caller)
== sanitize_flags_p (SANITIZE_ADDRESS, callee))
&& (sanitize_flags_p (SANITIZE_POINTER_COMPARE, caller)
== sanitize_flags_p (SANITIZE_POINTER_COMPARE, callee))
&& (sanitize_flags_p (SANITIZE_POINTER_SUBTRACT, caller)
== sanitize_flags_p (SANITIZE_POINTER_SUBTRACT, callee)));
}
I guess we could make an exception and allow inlining always_inline functions
that do have these enabled into a function that disables that.
[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 --- Comment #27 from Bill Schmidt --- Author: wschmidt Date: Wed Jan 30 20:52:08 2019 New Revision: 268403 URL: https://gcc.gnu.org/viewcvs?rev=268403=gcc=rev Log: 2019-01-30 Bill Schmidt PR target/87064 * config/rs6000/vsx.md (*vsx_reduc__v4sf_scalar): Disable for little-endian. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/vsx.md
[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #18 from Uroš Bizjak --- Fixed for gcc-9.
[Bug middle-end/89125] Misoptimization of converting sin(x) and cos(x) into sincos(x,,)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 --- Comment #4 from Marc Glisse --- This looks like a target issue, gcc does produce a call to sincos here. So please specify your target precisely.
[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 --- Comment #17 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jan 30 20:44:35 2019 New Revision: 268402 URL: https://gcc.gnu.org/viewcvs?rev=268402=gcc=rev Log: PR fortran/88678 * config/fpu-glibc.h (support_fpu_trap): Do not try to enable exceptions to determine if exception is supported. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config/fpu-glibc.h
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-30 Ever confirmed|0 |1 --- Comment #3 from Bill Schmidt --- (Confirmed. Kelvin has a patch.)
[Bug middle-end/89125] Misoptimization of converting sin(x) and cos(x) into sincos(x,,)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 --- Comment #3 from Steve Kargl --- On Wed, Jan 30, 2019 at 08:06:44PM +, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 > > --- Comment #2 from Dominique d'Humieres --- > See pr31249. > Don't see the relevance in that I'm not advocating that the middle-end transform the sin(x), cos(x) pair into a complex function cexpi. function foo(x) complex foo real,intent(in) :: x foo = cmplx(cos(x),sin(x)) end gfcx -o - -S -O3 a.f90 .file "a.f90" .text .p2align 4 .globl foo_ .type foo_, @function foo_: .LFB0: .cfi_startproc subq$24, %rsp .cfi_def_cfa_offset 32 movss (%rdi), %xmm2 movaps %xmm2, %xmm0 movss %xmm2, 4(%rsp) callcosf movss 4(%rsp), %xmm2 movss %xmm0, (%rsp) movaps %xmm2, %xmm0 callsinf movss (%rsp), %xmm1 movss %xmm0, 12(%rsp) movss %xmm1, 8(%rsp) movq8(%rsp), %xmm0 addq$24, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE0: .size foo_, .-foo_ .ident "GCC: (GNU) 9.0.1 20190125 (experimental)" .section.note.GNU-stack,"",@progbits On FreeBSD and suspect with glibc, there is a clear win Single precision, 100M calls for x in [0, 2) ./testf -s -n 100 -m 0 -M 2 100M sincosf calls in 4.235 seconds. 100M sinf and 100M cosf calls in 5.330 seconds. Double precision, 100M calls for x in [0, 2) ./testd -s -n 100 -m 0 -M 2 100M sincos calls in 5.222 seconds. 100M sin and 100M cos calls in 8.105 seconds.
[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 --- Comment #16 from Steve Kargl --- On Wed, Jan 30, 2019 at 06:33:52PM +, bergner at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 > > --- Comment #14 from Peter Bergner --- > (In reply to Uroš Bizjak from comment #10) > > Can someone please test the patch in Comment #9 on powerpc? It should fix > > all failures, modulo ieee_10.f90 which is fixed by [1]. > > > > [1] https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01685.html > > I did a bootstrap and regtest of the attached patch using revision 268398 > which > includes your patch [1]. The patch showed no regressions and fixed all of the > ieee_*.f90 and large_1.f90 tests, so I think this patch is good to go for > powerpc*-linux. > > The large_2.f90 failure I mentioned earlier is not caused by this patch, but > maybe due to [1] or some other earlier patch. I will track that down. > Peter, thanks for checking Uros' patches. Uros the patches are OK to commit. PS: Yes, my xterm suppressed the last character of your name.
[Bug middle-end/89125] Misoptimization of converting sin(x) and cos(x) into sincos(x,,)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 --- Comment #2 from Dominique d'Humieres --- See pr31249.
[Bug middle-end/89125] Misoptimization of converting sin(x) and cos(x) into sincos(x,,)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
--- Comment #1 from kargl at gcc dot gnu.org ---
Fortran code used in harmonic analysis often contains lines
of form
p = cmplx(cos(x),sin(x)) ! compute exp(i*x) for real x
On platforms with a sincos(x, , ) routine the above should
be transformed to
call sincos(x, , )
p = cmplx(c, s)
The reason is that both sin() and cos() perform argument reduction
of x into the range [0,pi/4]. sincos() performs this reduce once,
and hence is typically faster. The same optimization should apply
to C/C++ code.
#include
double
foo(double x)
{
double c,s,res;
c = cos(x);
s = sin(x);
res = c * s;
return res;
}
% ~/work/x/bin/gcc -o - -S -O3 -o a.s a.c
.file "a.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB3:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movsd %xmm0, 8(%rsp)
callcos
movsd 8(%rsp), %xmm1
movsd %xmm0, (%rsp)
movapd %xmm1, %xmm0
callsin
mulsd (%rsp), %xmm0
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE3:
.size foo, .-foo
.ident "GCC: (GNU) 9.0.1 20190125 (experimental)"
.section.note.GNU-stack,"",@progbits
[Bug middle-end/89125] New: Misoptimization of converting sin(x) and cos(x) into sincos(x,,)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 Bug ID: 89125 Summary: Misoptimization of converting sin(x) and cos(x) into sincos(x,,) Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: ---
[Bug c/89122] bad fix-it hint for FLT_MAX when is included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89122 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-30 CC||dmalcolm at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed. It's missing the pertinent entries from known-headers.cc. Working on a fix.
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #2 from Jakub Jelinek --- For comparison, in pretty much the same build environment (20 days earlier) with 8.2.1 20190109 I see === go tests === Running target unix/ FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments FAIL: go.test/test/ken/cplx2.go execution, -O2 -g === go Summary for unix/ === # of expected passes7278 # of unexpected failures2 # of expected failures 1 # of untested testcases 7 # of unsupported tests 3 === libgo Summary === # of expected passes163 # of unexpected failures163 where the unexpected failures for libgo are with -m31 (only very few 31-bit libraries around).
[Bug sanitizer/89124] __attribute__((no_sanitize_address)) interferes with __attribute__((target(xxx)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124 --- Comment #2 from Thiago Macieira --- -fsanitize=address missing from the command-line in the previous comment. It should be: gcc -c -mavx2 -fsanitize=address test.cpp
[Bug c++/89119] [7/8 Regression] internal compiler error: in tsubst_copy with RANGE_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89119 Marek Polacek changed: What|Removed |Added Summary|[7/8/9/ Regression] |[7/8 Regression] internal |internal compiler error: in |compiler error: in |tsubst_copy with RANGE_EXPR |tsubst_copy with RANGE_EXPR --- Comment #8 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/89119] [7/8/9/ Regression] internal compiler error: in tsubst_copy with RANGE_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89119 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Wed Jan 30 19:04:05 2019 New Revision: 268400 URL: https://gcc.gnu.org/viewcvs?rev=268400=gcc=rev Log: PR c++/89119 - ICE with value-initialization in template. * pt.c (tsubst_copy_and_build): Handle RANGE_EXPR. * g++.dg/cpp0x/initlist-value3.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist-value3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 Jakub Jelinek changed: What|Removed |Added Target||s390x-linux CC||krebbel at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Most of the tests don't print anything interesting into the go.log, just Execution timeout is: 300 spawn [open ...] FAIL: go.go-torture/execute/const-1.go execution, -O2 and similar.
[Bug target/88892] [8 Regression] Double-to-float conversion uses wrong rounding mode when followed by memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892 --- Comment #15 from Segher Boessenkool --- Not in 8.2, no, that was released half a year ago already. But 8.3, yes, it is lined up for that.
[Bug sanitizer/89124] __attribute__((no_sanitize_address)) interferes with __attribute__((target(xxx)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124
--- Comment #1 from Thiago Macieira ---
Worse:
$ cat test.cpp
#include
#ifdef __GNUC__
__attribute__((no_sanitize_address))
#endif
void f(void *ptr)
{
_mm256_loadu_si256((__m256i *)ptr);
}
$ gcc -c -mavx2 test.cpp
[same errors]
[Bug libstdc++/89120] std::minmax_element 2.5 times slower than hand written loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89120 --- Comment #1 from Marc Glisse --- First there is the issue of iterator vs value, as in your other PR. The performance of minmax depends a lot on the element type and the distribution. The standard requires that we perform only 3n/2 comparisons (not 2n like your version), which essentially prescribes the implementation. However, minmax is probably the most classical example shown in classes on branch prediction. For a uniform choice of a permutation, the 2n comparisons can be well predicted (O(log n) are mispredicted) while if you only do 3n/2 comparisons, n/2 of those are unpredictable, so n/4 are badly predicted, and that costs a lot.
[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 --- Comment #15 from Peter Bergner --- My bad, I guess large_2.f90 has been failing for a while now (PR67531) and isn't related to this bug or patches at all, so as far as I'm concerned, this bug is resolved as fixed once the proposed patch above is committed. Thanks for working and fixing this!
[Bug other/89106] cast-to-union documentation incorrect w.r.t. lvalueness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89106 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #5 from Martin Sebor --- Created attachment 45570 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45570=edit Proposed fix. Okay, I'm fine with referring to a temporary instead. I see what you mean about the lifetime but saying it's unspecified seems unnecessary -- temporaries have a temporary lifetime that extends to the end of the full expression and that presumably is the minimum that should apply here as well. I left the reference to compound literals in place. I think it's still useful (especially because of the lifetime). I did some more testing and clarified that it's a C only feature. Attached is what I've got.
[Bug sanitizer/89124] New: __attribute__((no_sanitize_address)) interferes with __attribute__((target(xxx)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124
Bug ID: 89124
Summary: __attribute__((no_sanitize_address)) interferes with
__attribute__((target(xxx)))
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
$ cat test.cpp
#include
#ifdef __GNUC__
__attribute__((target("avx2"), no_sanitize_address))
#endif
void f(void *ptr)
{
_mm256_loadu_si256((__m256i *)ptr);
}
$ gcc -c test.cpp && echo ok
ok
$ gcc -c -fsanitize=addreess test.cpp
In file included from
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/include/immintrin.h:41,
from :1:
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/include/avxintrin.h:
In function 'void f(void*)':
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/include/avxintrin.h:919:1:
error: inlining failed in call to always_inline '__m256i
_mm256_loadu_si256(const __m256i_u*)': function attribute mismatch
_mm256_loadu_si256 (__m256i_u const *__P)
^~
:8:23: note: called from here
_mm256_loadu_si256((__m256i *)ptr);
~~^~~~
Works fine in Clang. Godbolt link: https://godbolt.org/z/rg5kUD
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #18 from Jerry DeLisle --- (In reply to Luke Robison from comment #17) > (In reply to Jerry DeLisle from comment #8) > > > Luke, do you ever build gcc? > > I applied these patches to 8.2.0 and got the expected error message and > iostat of 26. Looks good to me. Thanks. I can backport this so its there sooner, its pretty safe patch.
[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 --- Comment #14 from Peter Bergner --- (In reply to Uroš Bizjak from comment #10) > Can someone please test the patch in Comment #9 on powerpc? It should fix > all failures, modulo ieee_10.f90 which is fixed by [1]. > > [1] https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01685.html I did a bootstrap and regtest of the attached patch using revision 268398 which includes your patch [1]. The patch showed no regressions and fixed all of the ieee_*.f90 and large_1.f90 tests, so I think this patch is good to go for powerpc*-linux. The large_2.f90 failure I mentioned earlier is not caused by this patch, but maybe due to [1] or some other earlier patch. I will track that down.
[Bug libstdc++/89121] std::min_element (and max_element) 3.6 times slower than hand written loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89121 --- Comment #2 from Marc Glisse --- If you write: auto mins = *std::min_element(f.begin(), f.end()); so that you ask for the value, the benchmark now says the perf is exactly the same for the 2 versions. I would close this as invalid.
[Bug go/89123] New: Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 Bug ID: 89123 Summary: Too many go test failures on s390x-linux Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: jakub at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- As can be seen in https://kojipkgs.fedoraproject.org/packages/gcc/9.0.1/0.2.fc30/data/logs/s390x/build.log go has way too many failed tests on s390x: === go Summary for unix/ === # of expected passes2506 # of unexpected failures654 # of expected failures 1 # of untested testcases 18 # of unsupported tests 3 === libgo Summary === # of unexpected failures368 Detailed failures are available by uudecoding the above build.log.
[Bug fortran/48636] Enable more inlining with -O2 and higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #45 from Dominique d'Humieres --- The last comment is almost six year old, closing as FIXED. If I missed some issues they should be tested against a current release(trunk is now 9.0) and a new PR should be filed.
[Bug fortran/45288] Double initialization: Warn if the value is different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45288 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Dominique d'Humieres --- > The following program (pasted in the #fortran IRC channel) is accepted > by gfortran -- unless -std=f2008 is used. % gfc pr45288.f90 -std=f95 pr45288.f90:8:25: 8 | PRINT '(4(4(F5.2,3H),/))',Matrix | 1 Warning: The H format specifier at (1) is a Fortran 95 deleted feature pr45288.f90:19:28: 19 | DATA Matrix(2,1)/2.0/ ! individual values |1 Error: GNU Extension: re-initialization of 'matrix' at (1) % gfc pr45288.f90 -pedantic pr45288.f90:19:28: 19 | DATA Matrix(2,1)/2.0/ ! individual values |1 Warning: GNU Extension: re-initialization of 'matrix' at (1) since at least GGC5, closing as WORKSFORME.
[Bug fortran/33056] [Meta-bug] Data - statement related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056 Bug 33056 depends on bug 45288, which changed state. Bug 45288 Summary: Double initialization: Warn if the value is different https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45288 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME
[Bug target/89112] Incorrect code generated by rs6000 memcmp expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-30 Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/89122] New: bad fix-it hint for FLT_MAX when is included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89122 Bug ID: 89122 Summary: bad fix-it hint for FLT_MAX when is included Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- In a program that refers to a macro like FLT_MAX or FLT_MIN with but not included GCC issues an error (as it should) but suggests replacing the macros with INT_MAX or INT_MIN, respectively, instead of suggesting to include the header where the referenced macros are defined. (Clang doesn't do any better.) $ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic x.c #include float f = FLT_MAX; x.c:3:11: error: ‘FLT_MAX’ undeclared here (not in a function); did you mean ‘INT_MAX’? 3 | float f = FLT_MAX; | ^~~ | INT_MAX
[Bug libstdc++/89121] std::min_element (and max_element) 3.6 times slower than hand written loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89121 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I guess the important difference is that std::min_element doesn't return the minimum value, but iterator for the minimum value. Finding the element with minimum value is more expensive than the value itself.
[Bug c++/89119] [7/8/9/ Regression] internal compiler error: in tsubst_copy with RANGE_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89119 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #6 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01735.html
[Bug target/88892] [8 Regression] Double-to-float conversion uses wrong rounding mode when followed by memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892 --- Comment #14 from Victor Stinner --- > New Revision: 268083 > URL: https://gcc.gnu.org/viewcvs?rev=268083=gcc=rev Great! Would it be possible to get a fix in GCC 8.2?
[Bug c++/88857] [7/8/9 Regression] ICE in build_value_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88857 --- Comment #7 from Will Benfold --- I think it's not so much class vs struct: I get an ICE iff 'a' is private. Just changing class -> struct stops the ICE, but then it comes back again if you make 'a' private. Similarly, with a class you can make the ICE go away if you make 'a' public.
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714 --- Comment #28 from Jakub Jelinek --- #c27 now successfully bootstrapped where it previously failed, regtest still pending.
[Bug other/89106] cast-to-union documentation incorrect w.r.t. lvalueness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89106 --- Comment #4 from Alexander Monakov --- My concern is that the cast does not "create a compound literal": what it creates is an object, more specifically, an unnamed temporary object in automatic storage with unspecified lifetime [1]. A compound literal in function scope similarly creates an unnamed object. Likewise, the "result" of a cast-to-union is that temporary object, taken as rvalue. So to explain it well to users, the documentation would have to say something like: A cast to a union creates a temporary object of the given union type, initialized via a member matching the type of the operand, and taken as rvalue (unlike a compound literal, which yields an lvalue). [1] gcc doesn't seem to emit any gimple clobber statements for such casts, so effectively the lifetime is "entire function scope", but that is likely not intentional
[Bug libstdc++/89121] New: std::min_element (and max_element) 3.6 times slower than hand written loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89121 Bug ID: 89121 Summary: std::min_element (and max_element) 3.6 times slower than hand written loop Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: antoshkka at gmail dot com Target Milestone: --- std::min_element is slow when there's a lot of data and it does not fit into the CPU cache: http://quick-bench.com/tlgxCx9CUMZgOfYbwhFaEI0WNOg
[Bug libstdc++/89120] New: std::minmax_element 2.5 times slower than hand written loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89120 Bug ID: 89120 Summary: std::minmax_element 2.5 times slower than hand written loop Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: antoshkka at gmail dot com Target Milestone: --- std::minmax_element is slow when there's a lot of data and it does not fit into the CPU cache: http://quick-bench.com/Z0iRfbm2_S9KvQ1C92ydh8USF-8
[Bug target/88547] missed optimization for vector comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88547 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug fortran/67743] Associating entity is not auto-typed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67743 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dominique d'Humieres --- This has been fixed since GCC 7.4, likely revisions r253077 for GGC8 and r253794 for GCC7, closing.
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Doesn't ICE for me even if I (on current trunk) revert the r266395 change. Do we need this as a P1 regression when it doesn't reproduce anymore?
[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 --- Comment #13 from Peter Bergner --- All of the ieee_*.f90 tests and large_1.f90 seem to be working on powerpc64le-linux now. However, I'm seeing a new execution test failure with large_2.f90. I'll have a quick look at that.
[Bug c++/88857] [7/8/9 Regression] ICE in build_value_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88857
--- Comment #6 from Marek Polacek ---
(In reply to Jakub Jelinek from comment #5)
> Indeed:
> class S { int a; };
> void foo (const S &, int);
>
> template
> void
> bar ()
> {
> foo ({});
> }
>
> With s/class/struct/ it doesn't ICE. build_value_init has an assertion that
> 346 /* The AGGR_INIT_EXPR tweaking below breaks in templates. */
> 347 gcc_assert (!processing_template_decl
> 348 || (SCALAR_TYPE_P (type) || TREE_CODE (type) ==
> ARRAY_TYPE));
> So, shall convert_like_real just not call it at all if
> processing_template_decl?
Likely, or only for scalar types. This is the same problem I hit recently with
tweaking the narrowing detection. I could poke at this later, unless you want
it.
[Bug c++/88857] [7/8/9 Regression] ICE in build_value_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88857
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Indeed:
class S { int a; };
void foo (const S &, int);
template
void
bar ()
{
foo ({});
}
With s/class/struct/ it doesn't ICE. build_value_init has an assertion that
346 /* The AGGR_INIT_EXPR tweaking below breaks in templates. */
347 gcc_assert (!processing_template_decl
348 || (SCALAR_TYPE_P (type) || TREE_CODE (type) ==
ARRAY_TYPE));
So, shall convert_like_real just not call it at all if
processing_template_decl?
[Bug fortran/51512] RFC: Bogus "Return value of function"/"INTENT(OUT) was not set" with allocatable results/dummies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51512 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Dominique d'Humieres --- > IMO this is exactly what warnings are for. I suggest to close this PR as > WONTFIX. The PR is now more than seven year old without feedback, closing.
[Bug c++/86379] [8/9 Regression] Class member access of |using|'d field goes horribly awry in presence of templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86379 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #3 from Alexandre Oliva --- mine
[Bug c++/89119] [7/8/9/ Regression] internal compiler error: in tsubst_copy with RANGE_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89119 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-30 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/46354] attribute((aligned(...))) can incorrectly decrease structure field alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46354 Luke changed: What|Removed |Added CC||lukebenes at hotmail dot com --- Comment #5 from Luke --- For the LLVM/Clang version of this bug, See: https://bugs.llvm.org/show_bug.cgi?id=9253
