[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- (In reply to Martin Sebor from comment #9) > It might be possible for some. I'm not sure how successful it would be for > others. The thread_jumps pass runs four times and moving the warn_restrict > pass before its first instance results in dozens of regressions. This > particular instance of the warning goes away if the warn_restrict pass is > moved before the second to last threads_jump pass, but that still causes > regressions. Moving the pass just before the last threads_jump pass doesn't > help. Either we need to mark some way all the stmts involved in jump threading and ignore warning on those by the late warning passes (setting gimple_no_warning_p on those might be too big hammer, but we have one padding bit close to no_warning, so use that for gimple_jump_threaded_p), or the late warning passes need to be moved before the first jump threading and have infrastructure improvement that they are able to figure stuff out better (say on demand VRP, strlen if needed, etc.) and after that just turn UB statements into __builtin_unreachable or __builtin_trap or whatever based on what the user chooses. I guess the main problem is that we have some jump threading already before the (non-early) inlining. As I said multiple times in the past, the problem with jump threading is that it tends to create statements, just because it sees some often related comparison somewhere else, those statements can be specialized for constants or ranges that actually never occur in the program at runtime, but in many cases no optimization can figure that out. It is a significant difference if the user writes strncpy (, , -1U) vs. when it appears through jump threading like in this example.
[Bug target/86683] ICE in altivec_expand_vec_perm_const at gcc/config/rs6000/rs6000.c:35074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86683 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #3 from Kewen Lin --- The rs6000/altivec.md for those instructions look expected. Hi Martin, could you still reproduce this with trunk?
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775 --- Comment #15 from Jakub Jelinek --- Created attachment 45411 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45411&action=edit gcc9-pr88775-2.patch The following incremental patch (untested except for this testcase and comparisons_pointer.cc) fixes that. Unfortunately there is still ptrs_compare_unequal routine that would need similar treatment, and I'm afraid it will result in less optimized code. This patch alone though could be useful even without the other patch, perhaps if we for pointers like before optimize always. The previous case where we optimized for integral equality comparisons of pointers only if the offsets are the same is both incorrect (for zero sized objects) and in many cases not optimizing enough (it is fine if both offsets are different, all we care is that the problematic cases where one pointer points to the beginning of one object and the other points to one past last byte of another one aren't optimized, everything else can). C99 says: "Tw o pointers compare equal if and only if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space." so I think we have to be conservative and need to treat pointer equality the same as equality of pointers cast to integral types, the question is if we are prepared for this for GCC9. Note, in ptrs_compare_unequal for the one obj, one ptr case (the only interesting one it handles), we could check if the pointer to the obj is known to be into the middle of the object (if size is constant and offset too, that is trivial, other cases might be harder and need more discussions) and in that case we can do whatever it does now. Otherwise, either punt, or e.g. check if obj is a global var and the other ptr points to only automatic vars (or if obj is automatic and ptr points to only global vars). Something else we could do?
[Bug target/88798] AVX512BW code does not use bit-operations that work on mask registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88798 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- See PR88473 for more details. You can use _kor_mask64 if you want explicitly using the mask operations instead of GPR.
[Bug preprocessor/83773] Create new switch, -Wmacro-redefined, to control warning for redefined macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83773 Jonathan Wakely changed: What|Removed |Added Keywords||easyhack Severity|normal |enhancement
[Bug fortran/88768] Derived type io in conjunction with allocatable component and recursion fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88768 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-11 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 7.4.1 up to trunk (9.0). My instrumented fortran gives at run time ==50613==ERROR: AddressSanitizer: attempting double-free on 0x602002d0 in thread T0: #0 0x10a361a7f in wrap_free.part.0 sanitizer_malloc_mac.inc:121 #1 0x10788a1ac in __mod_MOD_recurse (a.out:x86_64+0x111ac) #2 0x10788aad6 in MAIN__ (a.out:x86_64+0x11ad6) #3 0x10788ad08 in main (a.out:x86_64+0x11d08) #4 0x7fff67115ed8 in start (libdyld.dylib:x86_64+0x16ed8) 0x602002d0 is located 0 bytes inside of 8-byte region [0x602002d0,0x602002d8) freed by thread T0 here: #0 0x10a361a7f in wrap_free.part.0 sanitizer_malloc_mac.inc:121 #1 0x107889e4f in __mod_MOD___final_mod_T (a.out:x86_64+0x10e4f) #2 0x10788a2fd in __mod_MOD_set (a.out:x86_64+0x112fd) #3 0x10788a193 in __mod_MOD_recurse (a.out:x86_64+0x11193) #4 0x10788aad6 in MAIN__ (a.out:x86_64+0x11ad6) #5 0x10788ad08 in main (a.out:x86_64+0x11d08) #6 0x7fff67115ed8 in start (libdyld.dylib:x86_64+0x16ed8) previously allocated by thread T0 here: #0 0x10a360a0f in wrap_malloc sanitizer_malloc_mac.inc:114 #1 0x10788a710 in __mod_MOD_set (a.out:x86_64+0x11710) #2 0x10788a1e4 in __mod_MOD_recurse (a.out:x86_64+0x111e4) #3 0x10788a117 in __mod_MOD_recurse (a.out:x86_64+0x11117) #4 0x10788aad6 in MAIN__ (a.out:x86_64+0x11ad6) #5 0x10788ad08 in main (a.out:x86_64+0x11d08) #6 0x7fff67115ed8 in start (libdyld.dylib:x86_64+0x16ed8)
[Bug rtl-optimization/87305] [9 Regression] Segfault in end_hard_regno in setup_live_pseudos_and_spill_after_risky_transforms on aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug fortran/88688] Incorrect association in SELECT TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88688 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-01-11 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I confirm the behavior from at least 4.8 up to trunk (9.0). > It's not clear what the correct behavior should be. ... May be the question could be asked at comp.lang.fortran.
[Bug target/86683] ICE in altivec_expand_vec_perm_const at gcc/config/rs6000/rs6000.c:35074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86683 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Can't reproduce either. Maybe it got fixed with r264675 aka PR87149 fix? Before that change indeed those could be CODE_FOR_nothing if using a cross without assembler or with too old assembler that didn't support the power8 instructions.
[Bug c++/88555] [9 Regression] Pack expansion fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88555 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Maybe dup of PR88312?
[Bug rtl-optimization/88296] [9 Regression] Infinite loop in lra_split_hard_reg_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88296 Jakub Jelinek changed: What|Removed |Added Status|WAITING |NEW CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The hang started with r266422 aka PR88157 fix and got fixed (or made latent) with r266862 aka the second PR88282 fix. I'm going to include the testcase into the testsuite, for Vlad the question is just whether r266862 is a real fix or just made it latent. Given that both are IRA costs changes, I assume it is a real fix.
[Bug tree-optimization/88044] [9 regression] gfortran.dg/transfer_intrinsic_3.f90 hangs after r266171
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-01-11 Ever confirmed|0 |1 --- Comment #9 from Dominique d'Humieres --- Could you please replace (1) 'do n = 0, 3' with 'do n = 2, 3', and (2) 'do n = 0, 3' with 'do n = 0, 0'? I am not 100% confident about what 's = transfer(vs, s)' is supposed to do for zero-sized arrays/strings. In any case the length should never be greater than 2.
[Bug rtl-optimization/88296] [9 Regression] Infinite loop in lra_split_hard_reg_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88296 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Jan 11 10:17:12 2019 New Revision: 267831 URL: https://gcc.gnu.org/viewcvs?rev=267831&root=gcc&view=rev Log: PR rtl-optimization/88296 * gcc.target/i386/pr88296.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr88296.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/88799] Arm -mcpu=PROCESSOR does not result in assembly directives for .arch and .arch_extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88799 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-11 Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw --- GCC needs to be taught about the mp extension to armv7-a.
[Bug target/88785] [9 Regression] ICE in as_a, at machmode.h:353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88785 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/88800] New: Spurious -Werror=array-bounds for non-taken branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88800
Bug ID: 88800
Summary: Spurious -Werror=array-bounds for non-taken branch
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tgrabiec at gmail dot com
Target Milestone: ---
Link to godbolt: https://godbolt.org/z/JXfV2y
gcc flags: -Wall -Werror
Compiles fine with gcc 7.4, errors on 8.2 due to -Warray-bounds.
=
#include
#include
#include
#include
#include
#include
#include
#include
using bytes_view = std::string_view;
struct blob_storage {
struct [[gnu::packed]] ref_type {
blob_storage* ptr;
ref_type() {}
ref_type(blob_storage* ptr) : ptr(ptr) {}
operator blob_storage*() const { return ptr; }
blob_storage* operator->() const { return ptr; }
blob_storage& operator*() const { return *ptr; }
};
using size_type = uint32_t;
using char_type = bytes_view::value_type;
ref_type* backref;
size_type size;
size_type frag_size;
ref_type next;
char_type data[];
blob_storage(ref_type* backref, size_type size, size_type frag_size)
noexcept
: backref(backref)
, size(size)
, frag_size(frag_size)
, next(nullptr)
{
*backref = this;
}
blob_storage(blob_storage&& o) noexcept
: backref(o.backref)
, size(o.size)
, frag_size(o.frag_size)
, next(o.next)
{
*backref = this;
o.next = nullptr;
if (next) {
next->backref = &next;
}
memcpy(data, o.data, frag_size);
}
} __attribute__((packed));
class [[gnu::packed]] managed_bytes {
static constexpr size_t max_inline_size = 15;
struct small_blob {
bytes_view::value_type data[max_inline_size];
};
union [[gnu::packed]] u {
u() {}
~u() {}
blob_storage::ref_type ptr;
small_blob small;
} _u;
int8_t _size; // -1 -> use blob_storage
private:
bool external() const {
return _size < 0;
}
public:
using size_type = blob_storage::size_type;
struct initialized_later {};
managed_bytes(initialized_later, size_type size) {
if (size <= max_inline_size) {
_size = size;
} else {
_size = -1;
auto now = size;
void* p = malloc(sizeof(blob_storage) + now);
new (p) blob_storage(&_u.ptr, size, now);
}
}
managed_bytes(bytes_view v) : managed_bytes(initialized_later(), v.size())
{
if (!external()) {
std::copy(v.begin(), v.end(), _u.small.data);
// ^^^ HERE ^^^
return;
}
auto p = v.data();
auto s = v.size();
auto b = _u.ptr;
while (s) {
memcpy(b->data, p, b->frag_size);
p += b->frag_size;
s -= b->frag_size;
b = b->next;
}
assert(!b);
}
};
static_assert(sizeof(managed_bytes) == 16, "too large");
int main() {
char c[16] = { 0, };
bytes_view v(c, 16);
managed_bytes b(v);
}
=
GCC output:
In static member function ‘static _Tp* std::__copy_move<_IsMove, true,
std::random_access_iterator_tag>::__copy_m(const _Tp*, const _Tp*, _Tp*) [with
_Tp = signed char; bool _IsMove = false]’,
inlined from ‘_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
false; _II = const signed char*; _OI = signed char*]’ at
/usr/include/c++/8/bits/stl_algobase.h:386:30,
inlined from ‘_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove =
false; _II = const signed char*; _OI = signed char*]’ at
/usr/include/c++/8/bits/stl_algobase.h:422:45,
inlined from ‘_OI std::copy(_II, _II, _OI) [with _II = const signed char*;
_OI = signed char*]’ at /usr/include/c++/8/bits/stl_algobase.h:455:8,
inlined from ‘managed_bytes::managed_bytes(bytes_view)’ at
./utils/managed_bytes.hh:195:22,
inlined from ‘managed_bytes::managed_bytes(const bytes&)’ at
./utils/managed_bytes.hh:162:77,
inlined from ‘dht::token dht::bytes_to_token(bytes)’ at
dht/random_partitioner.cc:68:57,
inlined from ‘dht::token dht::random_partitioner::get_token(bytes)’ at
dht/random_partitioner.cc:85:39:
/usr/include/c++/8/bits/stl_algobase.h:368:23: error: ‘void*
__builtin_memmove(void*, const void*, long unsigned int)’ offset 16 from the
object at ‘’ is out of the bounds of referenced subobject
‘managed_bytes::small_blob::data’ with type ‘signed char [15]’ at offset 0
[-Werror=array-bounds]
__builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
~^~~
cc1plus: all warnings being treated as errors
{code}
{code}
[Bug c++/53294] Optimize out some exception code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53294 --- Comment #3 from Antony Polukhin --- Any progress?
[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #35 from Jakub Jelinek --- (In reply to Jürgen Reuter from comment #33) > (In reply to Iain Sandoe from comment #32) > > (In reply to Jürgen Reuter from comment #31) > > > Then I get tons of duplicate symbol lines. > > > > ah well, not so simple then, > > > > then I think the next step is for you to identify the last working revision > > of the compiler - we can then analyse what the change was that caused the > > difference and determine if that's a real regression or just exposing a > > build system issue. > > I fear I don't have the capacities to do that right now. I'm afraid without that there is nothing we can do about it. While bisection can be time consuming, it doesn't need to be time consuming for you (at least not that much), it can be scripted. If you have some compiler that works (guess because this PR got marked as [9 Regression] gcc 8.x works for you) and some compiler that doesn't, I see three options for the bisection. One is build with the "good" compiler and "bad" compiler in two separate directories, verify one works and one doesn't, then make a copy of one of those directories and bisect between the *.o files, start with half "good" ones and half "bad" ones and from the outcome try to narrow it to a particular problematic *.o file. Another one is similar, but if you have "good" and "bad" options, such as e.g. with -O0 it works and -O2 it doesn't, again bisect object files to find the problematic one. And the last one is try to bisect the compiler, after verifying "good"/"bad" try to build gcc from half way in between those revisions etc. The bisection to a particular *.o file is something that might help with the bisection of compilers, you only can bisect the compilation of the problematic TU and on that check what actually changed.
[Bug c++/88752] 8/9 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88752 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org Target Milestone|--- |8.3 Summary|ICE in |8/9 Regression] ICE in |enclosing_instantiation_of, |enclosing_instantiation_of, |at cp/pt.c:13328|at cp/pt.c:13328
[Bug c++/88800] Spurious -Werror=array-bounds for non-taken branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88800 --- Comment #1 from Tomasz Grabiec --- The gcc flags given in the description were incomplete, should be: gcc flags: -Wall -Werror -std=c++17 -O2
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |prathamesh3492 at gcc
dot gnu.org
--- Comment #7 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 45412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45412&action=edit
Untested fix
Hi,
The issue seems to be recursively calling malloc_candidate_p_1 with duplicate
arguments, for example, with above test-case, it shows following trace:
https://pastebin.com/tF5Qg06X
We can see it is calling malloc_candidate_p_1 with resultobj_164=PHI<...>
thrice because resultobj_164 appears 3 times as a phi-arg in:
resultobj_165 = PHI <_12(12), resultobj_164(13), resultobj_164(14),
resultobj_164(15)>
I think it's more of a compile time hog rather than infinite recursion
happening. To avoid that, I simply skipped walking over duplicate args in the
phi in the attached patch:
+bool skip_dup_arg = false;
+for (unsigned j = i; j > 0; j--)
+ if (operand_equal_p (gimple_phi_arg_def (phi, j - 1), arg, 0))
+{
+ skip_dup_arg = true;
+ break;
+}
+if (skip_dup_arg)
+ continue;
+
which appears to compile both the tests again.
I assume a phi stmt usually won't have more than 4 or 5 args, so the loop
shouldn't be too slow in practice ? I will be grateful for any other
suggestions. For the larger test-case it shows 164.08 wall seconds time for
compilation.
Thanks,
Prathamesh
[Bug tree-optimization/88801] New: [9 Regression] Performance regression on 473.astar on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88801 Bug ID: 88801 Summary: [9 Regression] Performance regression on 473.astar on aarch64 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Target Milestone: --- Target: aarch64 We've noticed a performance regression recently on 473.astar on aarch64 (a Cortex-A57 platform). On our systems we see about 8% slowdown and I also see a 4% slowdown (among other similar slowdowns) at: https://lnt.opensuse.org/db_default/v4/SPEC/1947 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=13.260.0&highlight_run=1947 I suspect this is something to do with the recent inlining tweaks.
[Bug libstdc++/88125] Erroneous duplicate "basic_stringbuf" symbol entry in libstdc++ gnu.ver file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88125
--- Comment #5 from Jonathan Wakely ---
Done.
Do we also want this patch?
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1123,6 +1123,7 @@ GLIBCXX_3.4.4 {
GLIBCXX_3.4.5 {
+#ifndef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
# std::string
_ZNKSs11_M_disjunctEPKc;
_ZNKSs15_M_check_lengthE[jmy][jmy]PKc;
@@ -1154,6 +1155,7 @@ GLIBCXX_3.4.5 {
#if !defined(__sun__) && !defined(__svr4__)
_ZNSt19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEppEv;
#endif
+#endif
} GLIBCXX_3.4.4;
GLIBCXX_3.4.6 {
The patterns in the GLIBCXX_3.4.5 node are duplicates of ones in the base
version, that depend on that macro (starting at line 1024):
#ifdef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
# GLIBCXX_ABI compatibility only.
# std::string
_ZNKSs11_M_disjunctEPKc;
_ZNKSs15_M_check_lengthE[jmy][jmy]PKc;
_ZNSs4_Rep26_M_set_length_and_sharableE*;
_ZNSs7_M_copyEPcPKc[jmy];
_ZNSs7_M_moveEPcPKc[jmy];
_ZNSs9_M_assignEPc[jmy]c;
# std::wstring
_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw;
_ZNKSbIwSt11char_traitsIwESaIwEE15_M_check_lengthE[jmy][jmy]PKc;
_ZNSbIwSt11char_traitsIwESaIwEE4_Rep26_M_set_length_and_sharableE*;
_ZNSbIwSt11char_traitsIwESaIwEE7_M_copyEPwPKw[jmy];
_ZNSbIwSt11char_traitsIwESaIwEE7_M_moveEPwPKw[jmy];
_ZNSbIwSt11char_traitsIwESaIwEE9_M_assignEPw[jmy]w;
_ZNKSt13basic_fstreamI[cw]St11char_traitsI[cw]EE7is_openEv;
_ZNKSt14basic_ifstreamI[cw]St11char_traitsI[cw]EE7is_openEv;
_ZNKSt14basic_ofstreamI[cw]St11char_traitsI[cw]EE7is_openEv;
_ZNSi6ignoreE[ilvx];
_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreE[ilvx];
_ZNSt11char_traitsI[cw]E2eqERK[cw]S2_;
_ZNSt19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEppEv;
#endif
This means that when HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT is defined
those patterns appear twice. Those symbols are meant to have multiple versions
(as Brooks pointed out in comment 0) but they are given those versions by asm
.symver directive in src/c++98/compatibility.cc so I don't think the dups in
the linker script are needed. But I might be misunderstanding something.
[Bug libstdc++/88125] Erroneous duplicate "basic_stringbuf" symbol entry in libstdc++ gnu.ver file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88125 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Fri Jan 11 11:39:45 2019 New Revision: 267834 URL: https://gcc.gnu.org/viewcvs?rev=267834&root=gcc&view=rev Log: PR libstdc++/88125 remove duplicate entry in linker script PR libstdc++/88125 * config/abi/pre/gnu.ver (GLIBCXX_3.4.6): Remove unused duplicate pattern for std::basic_stringbuf::str(). Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788 --- Comment #8 from Jakub Jelinek --- I don't see how that can help. First of all, the duplicate SSA_NAMEs don't have to appear just in the same PHI, you can have them in multiple different PHIs too. And, you can have loops there as well, either directly (e.g. a PHI result where one or more arguments of the PHI is equal to the PHI result), or indirectly. So, you probably need to remember the outcome of calling the function on some SSA_NAME already before, and you need to deal with the loops somehow (ignore back edges is one strategy, there are various others, look at other passes).
[Bug tree-optimization/88801] [9 Regression] Performance regression on 473.astar on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88801 Martin Liška changed: What|Removed |Added Keywords||needs-bisection Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-11 Blocks||26163 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you please bisect that? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788 --- Comment #9 from Jakub Jelinek --- And no, you casn't rely on phis having just a few arguments, there are phis with tens of thousands of arguments in real-world code.
[Bug c++/88787] [9 regression] C++ constexpr seems to not get expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Indeed, just verified, the 30_threads/ constexpr.cc issues were introduced in r265788.
[Bug target/86683] ICE in altivec_expand_vec_perm_const at gcc/config/rs6000/rs6000.c:35074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86683 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Martin Liška --- Yes, I can also confirm that it works for me.
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-01-11 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you please provide a test-case? Or build steps how to build your application?
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #2 from Martin Liška --- And please try GCC 8.2, maybe it has been fixed?
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 --- Comment #8 from Martin Liška --- (In reply to Дилян Палаузов from comment #7) > Why doesn’t GCC “make install” put the linker plugin under > $libdir/bfd-plugins and how are program ./configure’s supposed to be written > in a way, that LTO works with both Clang and GCC? It's a location which is automatically used by nm,ar,ranlib,ld when searching for plugins. Should work automatically when using clang, then object files will use proper llvm LTO plugin.
[Bug target/88616] [9 Regression] ICE in gimplify_expr at gcc/gimplify.c:13363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88616 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug c++/88787] [9 regression] C++ constexpr seems to not get expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 --- Comment #9 from Дилян Палаузов --- Yes, $(libdir)/bfd-plugins is a location automatically scanned by ar/nm/ranlib. The question is, why GCC’s “make install” does not put there its linker plugin. As long as nobody installs the linker plugins under $(libdir)/bfd-plugins, how are program ./configure’s supposed to be written in a way, that LTO works with both Clang and GCC?
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Jan 11 12:05:54 2019 New Revision: 267839 URL: https://gcc.gnu.org/viewcvs?rev=267839&root=gcc&view=rev Log: PR bootstrap/88714 * passes.c (finish_optimization_passes): Call print_combine_total_stats inside of pass_combine_1 dump rather than pass_profile_1. Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #3 from dominik.stras...@onespin-solutions.com --- Unfortunately my application is huge and spawns many threads. Can you propose some debugging aid. I am building gcc myself, so I can add anything to libasan that you want.
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #4 from Martin Liška --- (In reply to dominik.strasser from comment #3) > Unfortunately my application is huge and spawns many threads. > > Can you propose some debugging aid. I am building gcc myself, so I can add > anything to libasan that you want. Ok, then please try current GCC trunk. And you can also use: ASAN_OPTIONS="verbosity=3:debug=1" that should provide more diagnostics.
[Bug target/86683] ICE in altivec_expand_vec_perm_const at gcc/config/rs6000/rs6000.c:35074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86683 Segher Boessenkool changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #6 from Segher Boessenkool --- Ah, with an assembler without p8 support. Yes that should be fixed by r264675.
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788 --- Comment #10 from prathamesh3492 at gcc dot gnu.org --- Oops, I didn't realize there could be loop within phi (phi result being an arg too). I will try to come up with a better approach for handling nested PHI's. In the meantime, for stage 4, should I revert the recursive calling hunk ? Thanks, Prathamesh
[Bug tree-optimization/88786] Expand vector copysign (and xorsign) operations in the vectoriser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88786 --- Comment #2 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > I think it's a bit too low-level and having the higher-level op benefits > later optimizations (match.pd patterns, etc.) match.pd will already have seen the scalar form though, so I think we should assume that any optimisations like that have already been applied. AFAIK the only copysign optimisation that happens after vectorisation is the xorsign one. But in a way that's working around the fact that we *haven't* exposed the individual operations. The xorsign_optab only exists as a way of representing the result of a particular fold.
[Bug rtl-optimization/88796] -fstack-protector* kills RTL DSE opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88796
--- Comment #5 from rguenther at suse dot de ---
On January 10, 2019 8:49:58 PM GMT+01:00, "jakub at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88796
>
>--- Comment #3 from Jakub Jelinek ---
>We also use magic alias set e.g. directly in RTL DSE
>(ALIAS_SET_MEMORY_BARRIER).
>
>Anyway, there are multiple MEMs that need to be treated specially. For
>the TLS
>cases, it is e.g. on x86_64:
>(insn 15 27 16 2 (parallel [
>(set (reg:CCZ 17 flags)
>(unspec:CCZ [
>(mem/v/f/c:DI (plus:DI (reg/f:DI 19 frame)
>(const_int -8 [0xfff8])) [3
>D.1946+0 S8 A64])
>(mem/f:DI (const_int 40 [0x28]) [4
>MEM[( long unsigned int *)40B]+0 S8 A64 AS1])
>] UNSPEC_SP_TEST))
>(clobber (scratch:DI))
>]) "pr87370.c":23:1 978 {stack_protect_test_di}
> (nil))
>
>so there is MEM_VOLATILE_P stack canary MEM where we could use a
>special
>MEM_EXPR, after all, we apparently already have there a VAR_DECL, and
>can
>check that in crtl->stack_protect_guard, so this part shouldn't be that
>hard,
>except that we for some strange reason treat all volatile reads as
>killing
>everything, so we'd need to ignore MEM_VOLATILE_P for that special
>case. The
>initial set ssp is a store to a volatile mem, so perhaps just ignoring
>such
>MEMs altogether would DTRT.
>The next thing is the TLS MEM, which has some MEM_EXPR in there (and
>isn't
>volatile). Can that use some magic VAR_DECL in MEM_EXPR instead of the
>expression it uses? It is weird that outside of MEM_EXPR it actually
>doesn't
>record anywhere that it is another address space. Can we ignore this
>MEM
>altogether too?
>
>Finally, with -mstack-protector-guard=global, we have e.g.:
>(insn 13 25 14 2 (parallel [
>(set (reg:CCZ 17 flags)
>(unspec:CCZ [
>(mem/v/f/c:DI (plus:DI (reg/f:DI 19 frame)
>(const_int -8 [0xfff8])) [3
>D.1946+0 S8 A64])
> (mem/v/f/c:DI (symbol_ref:DI ("__stack_chk_guard")
>[flags 0x40] ) [3
>__stack_ch
>k_guard+0 S8 A64])
>] UNSPEC_SP_TEST))
>(clobber (scratch:DI))
>]) "pr87370.c":23:1 978 {stack_protect_test_di}
> (nil))
>
>so there is yet another MEM_VOLATILE_P memory. Wonder why we are so
>conservative about the volatile MEM reads, e.g. for a volatile MEM read
>from a
>var I don't see why it should kill frame related stores.
Looks like DSE is too conservative here for no good reason? BTW, I'd prefer a
alias analysis solution without special casing things in DSE.
[Bug middle-end/88758] [9 Regression] 186.crafty in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88758 --- Comment #8 from Martin Liška --- Author: marxin Date: Fri Jan 11 13:20:01 2019 New Revision: 267840 URL: https://gcc.gnu.org/viewcvs?rev=267840&root=gcc&view=rev Log: Add a testcase (PR middle-end/88758). 2019-01-11 Martin Liska PR middle-end/88758 * g++.dg/lto/pr88758_0.C: New test. * g++.dg/lto/pr88758_1.C: New test. Added: trunk/gcc/testsuite/g++.dg/lto/pr88758_0.C trunk/gcc/testsuite/g++.dg/lto/pr88758_1.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/88802] New: std::hash not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88802
Bug ID: 88802
Summary: std::hash not implemented
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at kera dot name
Target Milestone: ---
See https://stackoverflow.com/q/54147254/560648.
C++17 requires that std::hash be provided. MSVS does, but dev
libstdc++ doesn't (and neither does libc++). This seems to be the case on trunk
still.
#include
int main()
{
std::hash h;
return h(nullptr);
}
Result:
main.cpp: In function 'int main()':
main.cpp:4:31: error: use of deleted function
'std::hash::hash()'
std::hash h;
Expected result:
Good build and some return code.
[Bug libstdc++/88802] std::hash not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88802 --- Comment #1 from Tomalak Geret'kal --- [unord.hash]/2 > Each specialization of hash is either enabled or disabled, as described > below. [ Note: Enabled specializations meet the Cpp17Hash requirements, and > disabled specializations do not. — end note ] Each header that declares the > template hash provides enabled specializations of hash for nullptr_t and all > cv-unqualified arithmetic, enumeration, and pointer types. For any type Key > for which neither the library nor the user provides an explicit or partial > specialization of the class template hash, hash is disabled. (Clang HEAD does support this, it turns out.)
[Bug libstdc++/88802] std::hash not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88802 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-11 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- On it ...
[Bug c++/88800] Spurious -Werror=array-bounds for non-taken branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88800 Paweł Dziepak changed: What|Removed |Added CC||pdziepak at quarnos dot org --- Comment #2 from Paweł Dziepak --- Smaller reproducer: https://godbolt.org/z/M1EFOv
[Bug target/88778] Odd Complex value load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88778
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-11
Ever confirmed|0 |1
--- Comment #3 from H.J. Lu ---
More examples:
[hjl@gnu-cfl-1 pr88778]$ cat z.i
_Complex float
foo (_Complex float x)
{
return x;
}
[hjl@gnu-cfl-1 pr88778]$ make z.s
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2 -S z.i
[hjl@gnu-cfl-1 pr88778]$ cat z.s
.file "z.i"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movq%xmm0, -8(%rsp)
movss -8(%rsp), %xmm0
movss %xmm0, -16(%rsp)
movss -4(%rsp), %xmm0
movss %xmm0, -12(%rsp)
movq-16(%rsp), %xmm0
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 9.0.0 20190110 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 pr88778]$ cat x.i
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
__m128
foo (_Complex float x)
{
return __extension__ (__m128)(__v4sf) { __real x, __imag x,
0.0, 0.0f };
}
[hjl@gnu-cfl-1 pr88778]$ make x.s
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2 -S x.i
[hjl@gnu-cfl-1 pr88778]$ cat x.s
.file "x.i"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movq%xmm0, -16(%rsp)
movss -12(%rsp), %xmm0
movss -16(%rsp), %xmm1
unpcklps%xmm0, %xmm1
movq%xmm1, %xmm0
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 9.0.0 20190110 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 pr88778]$
[Bug fortran/88803] New: gfortran documentation warning: '.' or ',' must follow @xref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88803 Bug ID: 88803 Summary: gfortran documentation warning: '.' or ',' must follow @xref Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- I see these warnings building gfortran across many versions including current trunk: ../../gcc/fortran/gfortran.texi:1472: warning: `.' or `,' must follow @xref, not `o'. ../../gcc/fortran/gfortran.texi:1473: warning: `.' or `,' must follow @xref, not `e'.
[Bug libstdc++/88802] std::hash not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88802 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Jan 11 14:54:49 2019 New Revision: 267845 URL: https://gcc.gnu.org/viewcvs?rev=267845&root=gcc&view=rev Log: PR libstdc++/88802 define std::hash for C++17 PR libstdc++/88802 * include/bits/functional_hash.h (hash): Define specialization for C++17 (P0513R0, LWG 2817). * testsuite/20_util/hash/nullptr.cc: New test. Added: trunk/libstdc++-v3/testsuite/20_util/hash/nullptr.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/functional_hash.h
[Bug c++/88804] New: Inconsistently diagnosed unused but set static variable in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88804
Bug ID: 88804
Summary: Inconsistently diagnosed unused but set static
variable in lambda
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
void foo(int);
template void call(T t) {
t(0);
}
void bar() {
static int x=3;
call([](auto){
foo(x);
});
}
$ cat y.cpp
void foo(int);
template void call(T t) {
t(0);
}
void bar() {
static int x=3;
call([](int){
foo(x);
});
}
$ g++ -fsyntax-only -Wunused-but-set-variable x.cpp
x.cpp: In function ‘void bar()’:
x.cpp:6:13: warning: variable ‘x’ set but not used [-Wunused-but-set-variable]
static int x=3;
^
$ g++ -fsyntax-only -Wunused-but-set-variable y.cpp
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC)
x is incorrectly diagnosed as unused when used in a lambda with an auto
parameter, but not in a lambda with a type parameter (or no parameter). This
happens even if the lambda isn't called, but does not happen if the lambda is
called in the same function where it is declared.
[Bug tree-optimization/88044] [9 regression] gfortran.dg/transfer_intrinsic_3.f90 hangs after r266171
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044 --- Comment #10 from seurer at gcc dot gnu.org --- I tried both (1) and (2) and the test case does not hang.
[Bug libfortran/88805] New: hidden symbol `__cpu_model' is referenced by DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805 Bug ID: 88805 Summary: hidden symbol `__cpu_model' is referenced by DSO Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu Compiling a basic fortran hello world yields: $ ./gfortran a.f90 /usr/bin/ld: a.out: hidden symbol `__cpu_model' in /tmp/gcc9/bin/../lib/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a(cpuinfo.o) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status This was previously referenced under PR80600, but that PR was for BSD. I am seeing this on Linux (CentOS 6), with versions 8.2, 7.4, and current trunk. 8.1 and 7.3 worked. GCC in this case was configured with: --disable-nls --disable-multilib --enable-languages=fortran
[Bug c++/88806] New: extern "C" variables declared in different namespaces are considered different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88806
Bug ID: 88806
Summary: extern "C" variables declared in different namespaces
are considered different
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m101010a at gmail dot com
Target Milestone: ---
$ cat x.cpp
namespace A { extern "C" int g; }
namespace B { extern "C" int g; }
using namespace A;
using namespace B;
void f() { g; }
$ g++ -fsyntax-only x.cpp
x.cpp: In function ‘void f()’:
x.cpp:5:12: error: reference to ‘g’ is ambiguous
void f() { g; }
^
x.cpp:2:30: note: candidates are: ‘int B::g’
namespace B { extern "C" int g; }
^
x.cpp:1:30: note: ‘int A::g’
namespace A { extern "C" int g; }
^
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC)
This is part of the example from the C++ standard section 9.7.3
(namespace.udir) paragraph 6, with g changed from a function to a variable.
Since A::g and B::g refer to the same entity, there should be no ambiguity
between them.
[Bug libfortran/88807] New: misleading indentation warnings building libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88807 Bug ID: 88807 Summary: misleading indentation warnings building libgfortran Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- While building libgfortran, I receive the following warnings for -Wmisleading-indentation: ../../../libgfortran/generated/minloc0_4_i1.c: In function 'minloc0_4_i1': ../../../libgfortran/generated/minloc0_4_i1.c:138:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] 138 | else | ^~~~ ../../../libgfortran/generated/minloc0_4_i1.c:152:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' 152 | n = 0; | ^ ../../../libgfortran/generated/minloc0_8_i1.c: In function 'minloc0_8_i1': ../../../libgfortran/generated/minloc0_8_i1.c:138:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] 138 | else | ^~~~ ../../../libgfortran/generated/minloc0_8_i1.c:152:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' 152 | n = 0; | ^ ../../../libgfortran/generated/minloc0_16_i1.c: In function 'minloc0_16_i1': ../../../libgfortran/generated/minloc0_16_i1.c:138:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] 138 | else | ^~~~ ../../../libgfortran/generated/minloc0_16_i1.c:152:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' 152 | n = 0; | ^ ../../../libgfortran/generated/minloc0_4_i2.c: In function 'minloc0_4_i2': ../../../libgfortran/generated/minloc0_4_i2.c:138:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] 138 | else | ^~~~ ../../../libgfortran/generated/minloc0_4_i2.c:152:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' 152 | n = 0; | ^ ../../../libgfortran/generated/minloc0_8_i2.c: In function 'minloc0_8_i2': ../../../libgfortran/generated/minloc0_8_i2.c:138:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] 138 | else | ^~~~ ../../../libgfortran/generated/minloc0_8_i2.c:152:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' 152 | n = 0; | ^ ../../../libgfortran/generated/minloc0_16_i2.c: In function 'minloc0_16_i2': ../../../libgfortran/generated/minloc0_16_i2.c:138:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] 138 | else | ^~~~ ../../../libgfortran/generated/minloc0_16_i2.c:152:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' 152 | n = 0; | ^ ../../../libgfortran/generated/minloc0_4_i4.c: In function 'minloc0_4_i4': ../../../libgfortran/generated/minloc0_4_i4.c:138:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] 138 | else | ^~~~ ../../../libgfortran/generated/minloc0_4_i4.c:152:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' 152 | n = 0; | ^ ../../../libgfortran/generated/minloc0_4_i8.c: In function 'minloc0_4_i8': ../../../libgfortran/generated/minloc0_4_i8.c:138:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] 138 | else | ^~~~ ../../../libgfortran/generated/minloc0_4_i8.c:152:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' 152 | n = 0; | ^ ../../../libgfortran/generated/minloc0_16_i4.c: In function 'minloc0_16_i4': ../../../libgfortran/generated/minloc0_16_i4.c:138:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] 138 | else | ^~~~ ../../../libgfortran/generated/minloc0_16_i4.c:152:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' 152 | n = 0; | ^ ../../../libgfortran/generated/minloc0_8_i8.c: In function 'minloc0_8_i8': ../../../libgfortran/generated/minloc0_8_i8.c:138:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] 138 | else | ^~~~ ../../../libgfortran/generated/minloc0_8_i8.c:152:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' 152 | n = 0; | ^ ../../../libgfortran/generated/minloc0_8_i4.c: In function 'minloc0_8_i4': ../../../libgfortran/generated/minloc0_8_i4.c:138:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation
[Bug tree-optimization/88797] Unneeded branch added when function is inlined (function runs faster if not inlined)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88797
--- Comment #5 from Cassio Neri ---
There's a (fragile) workaround:
void use(unsigned);
#define VERSION 0
bool f(unsigned x, unsigned y) {
#if VERSION == 0
return x < + (y <= );
#else
bool b = y <= ;
return x < + b;
#endif
}
void test_f(unsigned x, unsigned y) {
for (unsigned i = 0; i < ; ++i)
use(f(x++, y++));
}
f is till the same. Version 0 of test_f has 4 jumps whereas version 1 has only
one.
https://godbolt.org/z/gZZQ2f
[Bug libstdc++/88802] std::hash not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88802 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for GCC 9.
[Bug target/80517] [missed optimization] constant propagation through Intel intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80517
Matthias Kretz changed:
What|Removed |Added
Version|8.0 |9.0
--- Comment #3 from Matthias Kretz ---
GCC 9 almost resolves this. However, for some reason this extended test case is
not fully optimized: https://gcc.godbolt.org/z/jRrHth
i.e. the call to dont_call_me() should be eliminated as dead code
#include
inline __m128i cmp(__m128i x, __m128i y) {
return _mm_cmpeq_epi16(x, y);
}
inline unsigned to_bits(__m128i mask0) {
return _pext_u32(_mm_movemask_epi8(mask0), 0x);
}
inline __m128i to_vmask(unsigned bits) {
__m128i mask = _mm_set1_epi16(bits);
mask = _mm_and_si128(mask, _mm_setr_epi16(1, 2, 4, 8, 16, 32, 64, 128));
mask = _mm_cmpeq_epi16(mask, _mm_setzero_si128());
mask = _mm_xor_si128(mask, _mm_cmpeq_epi16(mask, mask));
return mask;
}
inline bool is_eq(unsigned bits, __m128i vmask) {
return to_bits(vmask) == bits;
}
extern const auto a = __m128i{0x0001'0002'0004'0003, 0x0009'0008'0007'0006};
extern const auto b = __m128i{0x0001'0002'0005'0003, 0x'0008'0007'0006};
extern const auto c = cmp(a, b);
extern const auto d = to_bits(c);
void call_me();
void dont_call_me();
void f() {
if (is_eq(d, cmp(b, a))) {
call_me();
} else {
dont_call_me();
}
}
[Bug target/80517] [missed optimization] constant propagation through Intel intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80517
--- Comment #4 from Matthias Kretz ---
A similar test case showing that something is still missing
(https://gcc.godbolt.org/z/t1DT7E):
#include
inline __m128i cmp(__m128i x, __m128i y) {
return _mm_cmpeq_epi16(x, y);
}
inline unsigned to_bits(__m128i mask0) {
return _pext_u32(_mm_movemask_epi8(mask0), 0x);
}
inline __m128i to_vmask(unsigned bits) {
__m128i mask = _mm_set1_epi16(bits);
mask = _mm_and_si128(mask, _mm_setr_epi16(1, 2, 4, 8, 16, 32, 64, 128));
mask = _mm_cmpeq_epi16(mask, _mm_setzero_si128());
mask = _mm_xor_si128(mask, _mm_cmpeq_epi16(mask, mask));
return mask;
}
auto f(__m128i x, __m128i y) {
// should be:
// vpcmpeqw %xmm1, %xmm0, %xmm0
// ret
return to_vmask(to_bits(cmp(x, y)));
}
auto f(unsigned bits) {
// should be equivalent to `return 0xff & bits;`
return to_bits(to_vmask(bits));
}
[Bug target/80517] [missed optimization] constant propagation through Intel intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80517
--- Comment #5 from Marc Glisse ---
(In reply to Matthias Kretz from comment #3)
> GCC 9 almost resolves this. However, for some reason this extended test case
> is not fully optimized: https://gcc.godbolt.org/z/jRrHth
> i.e. the call to dont_call_me() should be eliminated as dead code
We are left with:
_GLOBAL__sub_I__Z1fv ()
{
[local count: 1073741824]:
d = 125;
return;
}
f ()
{
unsigned int d.1_1;
[local count: 1073741824]:
d.1_1 = d;
if (d.1_1 == 125)
[...]
This is a classic, if the initialization of global variables is only noticed to
be constant after optimizations (as opposed to in the front-end), gcc doesn't
manage to turn the dynamic initialization into a static one. Making the
intrinsics constexpr may help, but really this is something that would be nice
to fix eventually, there are several PRs blocked by this.
[Bug target/88808] New: bitwise operators on AVX512 masks fail to use the new mask instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88808
Bug ID: 88808
Summary: bitwise operators on AVX512 masks fail to use the new
mask instructions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
Test case (https://godbolt.org/z/gyCN12):
#include
using V [[gnu::vector_size(16)]] = float;
auto f(V x) {
auto mask = _mm_fpclass_ps_mask(x, 16) | _mm_fpclass_ps_mask(x, 8);
return _mm_mask_blend_ps(mask, x, x + 1);
}
auto g(V x) {
auto mask = _kor_mask8(_mm_fpclass_ps_mask(x, 16), _mm_fpclass_ps_mask(x,
8));
return _mm_mask_blend_ps(mask, x, x + 1);
}
Function f should compile to the same code as g does, i.e. use korb instead of
kmovb + orl + kmovb. Similar test cases can be constructed for kxor, kand, and
kandn as well as for masks of 8 and 16 bits (likely for 32 and 64 as well, but
I have not tested it). For kand it's a bit trickier to trigger, but e.g. the
following shows it:
__mmask8 foo = 0;
auto f(V x) {
auto mask0 = _mm_fpclass_ps_mask(x, 16);
auto mask1 = _mm_fpclass_ps_mask(x, 8);
foo = mask0 | mask1;
return _mm_mask_blend_ps(mask0 & mask1, x, x + 1);
}
[Bug target/80517] [missed optimization] constant propagation through Intel intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80517 --- Comment #6 from Marc Glisse --- (In reply to Matthias Kretz from comment #4) > A similar test case showing that something is still missing You don't seem to be passing constants here, so this is unrelated to this PR. If you file a new one, please annotate your example explaining where you expect what to simplify to what and why. > (https://gcc.godbolt.org/z/t1DT7E): Adding -fdump-tree-optimized=- -g0 and showing the compiler output makes this more understandable for me...
[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 --- Comment #11 from Martin Sebor --- I understand what jump threading does but I don't know enough about how it works to have a clear idea how viable marking up the created statements would be. To avoid false negatives it would need to make it possible to distinguish invalid statements in the original code from invalid statements it introduced. At the time it runs there may not be a way to tell one from the other yet (the distinction between valid and invalid isn't exposed until after the constants along the newly introduced path have been fully propagated into those statements). I have been meaning to look into it for a couple of releases. It won't happen for GCC 9 but in 10, the planned integration of the strlen and sprintf passes (and perhaps also -Wstringop-overflow, and maybe even -Wrestrict, which would include this warning) may be a good opportunity to experiment with some of these ideas. That said, no solution will ever be perfect. There will always be some false positives (and false negatives), no matter how early or late these warnings run. What I think is even more pressing and important than the redesign (and far more realistic than hoping it will completely solve the problem) is to make #pragma diagnostic work reliably for middle-end warnings.
[Bug libfortran/88807] misleading indentation warnings building libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88807 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to nightstrike from comment #0) > While building libgfortran, I receive the following warnings for > -Wmisleading-indentation: > > ../../../libgfortran/generated/minloc0_4_i1.c: In function 'minloc0_4_i1': > ../../../libgfortran/generated/minloc0_4_i1.c:138:5: warning: this 'else' > clause does not guard... [-Wmisleading-indentation] > 138 | else > | ^~~~ These files were GENERATED from an m4 file. There cannot not be anything misleading in these files as a human isn't expected to read the GENERATED c code.
[Bug libfortran/88805] hidden symbol `__cpu_model' is referenced by DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805 --- Comment #1 from kargl at gcc dot gnu.org --- This appears to be either a problem with your binutils or pilot error. It is not a problem with libgfortran.
[Bug c++/88800] Spurious -Werror=array-bounds for non-taken branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88800
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-11
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||8.2.0, 9.0
--- Comment #3 from Martin Sebor ---
Confirmed. The warning is issued by the restrict pass when the memmove call is
being folded into MEM_REF, i.e.,
__builtin_memmove (&b.data, &c, 16);
into:
_15 = MEM[(char * {ref-all})&c];
MEM[(char * {ref-all})&b] = _15;
and before b.size's initial negative value has been constant-propagated. I
don't know if teaching the restrict pass about MEM_REF rather than having the
folder call into the pass would be viable given the unreliability of the
MEM_REF argument.
[Bug c++/88806] extern "C" variables declared in different namespaces are considered different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88806 --- Comment #1 from Andrew Pinski --- Related to the old bug 27227.
[Bug target/88808] bitwise operators on AVX512 masks fail to use the new mask instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88808 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- See PR88473 and PR88798. I'd personally probably revert the changes to make the mask operations separate from GPR operations and just use special RTL patterns if GPR operation can't do it (e.g. andn when not BMI, or 64-bit logicals on 32-bit targets), but it is too late for that for GCC9.
[Bug libfortran/88805] hidden symbol `__cpu_model' is referenced by DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805 --- Comment #2 from Andrew Pinski --- >/usr/bin/ld: a.out: hidden symbol `__cpu_model' in >/tmp/gcc9/bin/../lib/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a(cpuinfo.o) is >referenced by DSO Could you figure out which shared library references __cpu_model ? I doubt it is one that GCC just built. I suspect it is libc which means your libc is broken. You will most likely need a newer libc which does not reference __cpu_model any more.
[Bug target/88809] New: do not use rep-scasb for inline strlen/memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88809 Bug ID: 88809 Summary: do not use rep-scasb for inline strlen/memchr Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amonakov at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-*, i?86-*-* Performance difference between libc strlen and x86 rep-scasb has grown too large and seems unlikely to improve anytime soon. On most x86 cores, microcode for rep-scasb is not too sophisticated and runs at 0.5 bytes per cycle or worse (according to Agner Fog's research; with SkylakeX managing 1 b/c), plus some overhead for entering/leaving the microcode loop (I think on the order of 20 cycles, but don't have exact info). Whereas libc strlen typically has small overhead for short strings and uses register-wide operations on long strings, sustaining on the order of 4-8 b/c only with integer registers or even in the ballpark of 16-64 b/c with SSE/AVX (sorry, don't have exact figures here). A call to strlen is also shorter by itself (rep-scasb needs extra instructions to setup %rax and fixup %rcx). (although to be fair, a call to strlen prevents use of redzone and clobbers more registers) Therefore I suggest we don't use rep-scasb for inline strlen anymore by default (we currently do at -Os). This is in part motivated by PR 88793 and the Redhat bug referenced from there.
[Bug tree-optimization/88793] Document that __attribute__ ((cold)) is not equivalent to __builtin_except because of optimization for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793 --- Comment #4 from Alexander Monakov --- (In reply to Alexander Monakov from comment #3) > I think it's fair to raise the question if gcc should not use scasb/cmpsb by > default (I thought there was a bug for that but apparently there isn't?). We had PR 43052 for memcmp/cmpsb, which was (accidentally?) fixed. I've now opened PR 88809 for strlen/scasb.
[Bug target/88809] do not use rep-scasb for inline strlen/memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88809 --- Comment #1 from Andrew Pinski --- (In reply to Alexander Monakov from comment #0) > Therefore I suggest we don't use rep-scasb for inline strlen anymore by > default (we currently do at -Os). This is in part motivated by PR 88793 and > the Redhat bug referenced from there. Is it smaller to call a function or inline it? -Os is really truely optimize for size no matter what. I know non-embedded folks don't like that and it is also the reason why Apple added -Oz (a similar thing to this -Os issue but on PowerPC where the string instructions are used).
[Bug target/88809] do not use rep-scasb for inline strlen/memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88809 --- Comment #2 from Andrew Pinski --- >(although to be fair, a call to strlen prevents use of redzone and clobbers >more registers) And causes more register pressure ...
[Bug tree-optimization/88793] Document that __attribute__ ((cold)) is not equivalent to __builtin_except because of optimization for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793 Florian Weimer changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88809 --- Comment #5 from Florian Weimer --- (In reply to Alexander Monakov from comment #3) > (-Os is not "minimize size at all costs"). Bug 88809 comment 1 says the exact opposite. 8-/
[Bug target/88778] Odd Complex value load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88778
--- Comment #4 from 刘袋鼠 ---
Currently _Complex is classified as SSE_REG_CLASS, and need two 2 hardreg to
handle it. We may need to handle things like TARGET_HARD_REGNO_MODE_OK in
backend. So that ira can work suitable for our complex operation.
static int
classify_argument (machine_mode mode, const_tree type,
enum x86_64_reg_class classes[MAX_CLASSES], int bit_offset)
...
case E_SCmode:
classes[0] = X86_64_SSE_CLASS;
...
static unsigned int
ix86_hard_regno_nregs (unsigned int regno, machine_mode mode)
{
...
if (COMPLEX_MODE_P (mode))
return 2;
...
}
[Bug fortran/88803] gfortran documentation warning: '.' or ',' must follow @xref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88803 Eric Gallager changed: What|Removed |Added Keywords||documentation CC||egallager at gcc dot gnu.org Severity|normal |minor
[Bug tree-optimization/88044] [9 regression] gfortran.dg/transfer_intrinsic_3.f90 hangs after r266171
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044 --- Comment #11 from Dominique d'Humieres --- > I tried both (1) and (2) and the test case does not hang. Could you please try '0, 1', '1, 2', and '0, 2'?
[Bug tree-optimization/88793] Document that __attribute__ ((cold)) is not equivalent to __builtin_except because of optimization for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793 --- Comment #6 from Andrew Pinski --- (In reply to Florian Weimer from comment #5) > (In reply to Alexander Monakov from comment #3) > > (-Os is not "minimize size at all costs"). > > Bug 88809 comment 1 says the exact opposite. 8-/ And the manual says: It also performs further optimizations designed to reduce code size. Also see the thread at: https://gcc.gnu.org/ml/gcc/2017-08/msg00280.html
[Bug target/88696] Power VSX builtins missing vmuluwm / vector int vec_mul (vector int, vector int);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88696 --- Comment #1 from Lauri Kasanen --- Actually, seems this is only a documentation bug. vec_mul for the int vectors is not listed on any of the "PowerPC AltiVec/VSX Built-in Functions" pages, even though it works. It emulates the multiplication on older ppc and on power8 correctly emits vmuluwm, since r224494.
[Bug c++/88114] "virtual ~destructor() = default": Destructor not created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88114 --- Comment #5 from Tobias Burnus --- Updated patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00646.html
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 --- Comment #8 from Tom Tromey --- Sorry about the extreme delay on this. I think my patch has long since bit-rotted, but I can attach it for reference. I believe my assignment situation got sorted out so this should be fine to read and/or copy from.
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 --- Comment #9 from Tom Tromey --- Created attachment 45413 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45413&action=edit ancient patch
[Bug target/88798] AVX512BW code does not use bit-operations that work on mask registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88798 --- Comment #3 from Wojciech Mula --- Sorry, I didn't find that bug; I think you may close this one. BTW, I had checked the code on godbolt.org before submitting. I tested also with their "GCC (trunk)", but the generated code is the same as for 8.2. The trunk's version is "g++ (GCC-Explorer-Build) 9.0.0 20190109 (experimental)" -- seems it's a fresh version and should already include the fixes Andrew mentioned.
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 --- Comment #10 from Tom Tromey --- Also I think all the test suite changes never really worked.
[Bug target/88614] ICE: output_operand: invalid %z value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88614 --- Comment #2 from Jeffrey A. Law --- Author: law Date: Fri Jan 11 18:44:00 2019 New Revision: 267851 URL: https://gcc.gnu.org/viewcvs?rev=267851&root=gcc&view=rev Log: PR 88777 PR 88614 * genattrtab.c (min_fn): Don't translate values. (min_attr_value): Return INT_MAX when the value can't be calculated. Return minimum among any values that can be calculated. (max_attr_value): Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/genattrtab.c
[Bug target/88777] [9 Regression] Out-of-range offsets building glibc test-tgmath2.c for hppa-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88777 --- Comment #5 from Jeffrey A. Law --- Author: law Date: Fri Jan 11 18:44:00 2019 New Revision: 267851 URL: https://gcc.gnu.org/viewcvs?rev=267851&root=gcc&view=rev Log: PR 88777 PR 88614 * genattrtab.c (min_fn): Don't translate values. (min_attr_value): Return INT_MAX when the value can't be calculated. Return minimum among any values that can be calculated. (max_attr_value): Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/genattrtab.c
[Bug tree-optimization/88044] [9 regression] gfortran.dg/transfer_intrinsic_3.f90 hangs after r266171
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044 --- Comment #12 from seurer at gcc dot gnu.org --- None of those hang, either. I also experimented with the options a bit. The as-is options affecting optimization are: -O3 -funroll-loops -fpeel-loops -finline-functions Change to -O1 and no hang. Dropping the other ones or using -O2 and it still hangs.
[Bug tree-optimization/88693] [9 Regression] Wrong code since r263018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88693 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Jan 11 19:04:32 2019 New Revision: 267852 URL: https://gcc.gnu.org/viewcvs?rev=267852&root=gcc&view=rev Log: PR tree-optimization/88693 * tree-ssa-strlen.c (get_min_string_length): Don't set *full_string_p for STRING_CSTs that don't contain any NUL characters in the first TREE_STRING_LENGTH bytes. * gcc.c-torture/execute/pr88693.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr88693.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-strlen.c
[Bug tree-optimization/88693] [9 Regression] Wrong code since r263018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88693 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788
--- Comment #11 from Jakub Jelinek ---
Look e.g. at -O2:
void bar (int);
void
foo (int x)
{
int i = 0;
if (x == 8)
{
x = 16;
goto lab;
}
for (; i < 100; i++)
{
lab:
bar (x);
}
}
but pretty much any time you have a loop where some var doesn't really change,
but there is some other edge to the loop header with a different value for that
var.
[Bug rtl-optimization/87305] [9 Regression] Segfault in end_hard_regno in setup_live_pseudos_and_spill_after_risky_transforms on aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305 --- Comment #6 from Vladimir Makarov --- Author: vmakarov Date: Fri Jan 11 19:25:31 2019 New Revision: 267854 URL: https://gcc.gnu.org/viewcvs?rev=267854&root=gcc&view=rev Log: 2019-01-11 Vladimir Makarov PR rtl-optimization/87305 * lra-assigns.c (setup_live_pseudos_and_spill_after_risky_transforms): Add code for little endian pseudos used as paradoxical subreg. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-assigns.c
[Bug c++/88114] "virtual ~destructor() = default": Destructor not created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88114 --- Comment #6 from Tobias Burnus --- Author: burnus Date: Fri Jan 11 19:40:13 2019 New Revision: 267855 URL: https://gcc.gnu.org/viewcvs?rev=267855&root=gcc&view=rev Log: PR C++/88114 Gen destructor of an abstract class PR C++/8811 * decl2.c (maybe_emit_vtables): If needed, generate code for the destructor of an abstract class. (mark_used): Update comment for older function-name change. PR C++/88114 * g++.dg/cpp0x/defaulted61.C: New. * g++.dg/cpp0x/defaulted62.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/defaulted61.C trunk/gcc/testsuite/g++.dg/cpp0x/defaulted62.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/8811] Internal compiler error in extract_constrain_insn_cached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8811 --- Comment #2 from Tobias Burnus --- Author: burnus Date: Fri Jan 11 19:40:13 2019 New Revision: 267855 URL: https://gcc.gnu.org/viewcvs?rev=267855&root=gcc&view=rev Log: PR C++/88114 Gen destructor of an abstract class PR C++/8811 * decl2.c (maybe_emit_vtables): If needed, generate code for the destructor of an abstract class. (mark_used): Update comment for older function-name change. PR C++/88114 * g++.dg/cpp0x/defaulted61.C: New. * g++.dg/cpp0x/defaulted62.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/defaulted61.C trunk/gcc/testsuite/g++.dg/cpp0x/defaulted62.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/88114] "virtual ~destructor() = default": Destructor not created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88114 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Tobias Burnus --- FIXED on the GCC 9 trunk
[Bug c/88718] Strange inconsistency between old style and new style definitions of inline functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88718 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00659.html
[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at redhat dot com
[Bug libfortran/88805] hidden symbol `__cpu_model' is referenced by DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #3 from Janne Blomqvist --- (In reply to Andrew Pinski from comment #2) > >/usr/bin/ld: a.out: hidden symbol `__cpu_model' in > >/tmp/gcc9/bin/../lib/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a(cpuinfo.o) is > >referenced by DSO > > > Could you figure out which shared library references __cpu_model ? I doubt > it is one that GCC just built. > > I suspect it is libc which means your libc is broken. You will most likely > need a newer libc which does not reference __cpu_model any more. libgfortran/generated/matmul_*.c uses __cpu_model. As to why it does that instead of using the function multiversioning support, well, beats me.
[Bug libstdc++/86655] std::assoc_legendre should not constrain the value of m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86655 --- Comment #4 from emsr at gcc dot gnu.org --- Created attachment 45414 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45414&action=edit This is a patch on both std and tr1, both sph_legendre and assoc_legendre. 2018-01-11 Edward Smith-Rowland <3dw...@verizon.net> PR libstdc++/86655 - std::assoc_legendre should not constrain the value of m * include/tr1/legendre_function.tcc (__assoc_legendre_p, __sph_legendre): If degree > order Don't throw, return 0. * testsuite/special_functions/02_assoc_legendre/pr86655.cc: New test. * testsuite/special_functions/20_sph_legendre/pr86655.cc: New test. * testsuite/tr1/5_numerical_facilities/special_functions/ 02_assoc_legendre/pr86655.cc: New test. * testsuite/tr1/5_numerical_facilities/special_functions/ 22_sph_legendre/pr86655.cc: New test.
[Bug fortran/88810] New: gcc/fortran/dependency.c:2200: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810 Bug ID: 88810 Summary: gcc/fortran/dependency.c:2200: possible cut'n'paste error ? Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- gcc/fortran/dependency.c:2200] -> [trunk/gcc/fortran/dependency.c:2205]: (style) The if condition is the same as the previous if condition Source code is /* Set reverse if backward dependence and not inhibited. */ if (reverse && reverse[m] == GFC_ENABLE_REVERSE) reverse[m] = (this_dep == GFC_DEP_BACKWARD) ? GFC_REVERSE_SET : reverse[m]; /* Set forward if forward dependence and not inhibited. */ if (reverse && reverse[m] == GFC_ENABLE_REVERSE) reverse[m] = (this_dep == GFC_DEP_FORWARD) ? GFC_FORWARD_SET : reverse[m]; Comment and code on 2nd if don't match.
[Bug lto/88733] [9 Regression] ICE in wide_int_to_tree_1, at tree.c:1561
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88733 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Jan 11 21:03:53 2019 New Revision: 267858 URL: https://gcc.gnu.org/viewcvs?rev=267858&root=gcc&view=rev Log: PR middle-end/85956 PR lto/88733 * tree-inline.h (struct copy_body_data): Add adjust_array_error_bounds field. * tree-inline.c (remap_type_1): Formatting fix. If TYPE_MAX_VALUE of ARRAY_TYPE's TYPE_DOMAIN is newly error_mark_node, replace it with a dummy "omp dummy var" variable if id->adjust_array_error_bounds. * omp-low.c (new_omp_context): Set cb.adjust_array_error_bounds. fortran/ * trans-openmp.c: Include attribs.h. (gfc_walk_alloc_comps, gfc_omp_clause_linear_ctor): Handle VAR_DECL max bound with "omp dummy var" attribute like NULL or error_mark_node - recompute number of elts independently. testsuite/ * c-c++-common/gomp/pr85956.c: New test. * g++.dg/gomp/pr88733.C: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr85956.c trunk/gcc/testsuite/g++.dg/gomp/pr88733.C Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-openmp.c trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c trunk/gcc/tree-inline.h
