[Bug c/90267] [7.3 regression] wrong code generated wth -O2 as missing data dependence base on memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90267 --- Comment #2 from Andrew Pinski --- Use either -fno-strict-aliasing or change STRU_CCH_DLTPC_PARA to use an union and access it via that.
[Bug c/90267] [7.3 regression] wrong code generated wth -O2 as missing data dependence base on memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90267 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- You are violating C aliasing rules for sure.
[Bug c/90267] New: [7.3 regression] wrong code generated wth -O2 as missing data dependence base on memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90267
Bug ID: 90267
Summary: [7.3 regression] wrong code generated wth -O2 as
missing data dependence base on memory
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
Created attachment 46254
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46254=edit
a simple testcase
test case attached, and we can see the code in line 42 clear the memory point
with pstruDlTpcPara, so the value in the memory cross the line 42 is different.
39 TpcFingerNum[TpcIdex][0] = *(UINT32*)(void*)pstruDlTpcPara;
40 TpcFingerNum[TpcIdex][1] = pstruDlTpcPara->ucThreeSlotFngNum;
41
42 *(volatile UINT32*)(void*)pstruDlTpcPara = 0;
43
44 TpcFingerNum[TpcIdex][2] = *(UINT32*)(void*)pstruDlTpcPara;
45 TpcFingerNum[TpcIdex][3] = pstruDlTpcPara->ucThreeSlotFngNum;
base on the gcc 7.3, in the dumpfile test.c.037t.fre1, we can see the value _6
get before the operator of clear the memory. So it miss the data dependence
base on memory.
(Generated by cmd:../../GCC/gcc-730/binary/bin/gcc test.c -dAp -S -O2 -g3
-fdump-tree-all)
37 _4 = MEM[(struct STRU_CCH_DLTPC_PARA
*)][_1].ucThreeSlotFngNum;
38 _6 = (unsigned int) _4;
39 TpcFingerNum[TpcIdex.0_2][1] = _6;
40 MEM[(volatile UINT32 *)pstruDlTpcPara_20] ={v} 0;
41 _8 = MEM[(UINT32 *)pstruDlTpcPara_20];
42 TpcFingerNum[TpcIdex.0_2][2] = _8;
43 TpcFingerNum[TpcIdex.0_2][3] = _6;
[Bug c++/85679] [DR2094] __is_trivially_copyable returns false with volatile scalar type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85679 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-27 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I agree that DR 2094 makes volatile-qualified scalars trivially copyable.
[Bug c++/66268] struct { volatile int x; } should not be trivially copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66268 --- Comment #3 from Jonathan Wakely --- I think DR 2094 makes this report invalid, and GCC correct.
[Bug c++/89695] unexpected copying of trivially copyable prvalue arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89695 --- Comment #3 from Jonathan Wakely --- I believe this is required by the ABI for trivially copyable types.
[Bug lto/71535] ICE in LTO1 with -fopenmp offloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71535 --- Comment #4 from Jose Manuel Monsalve Diaz --- Same for Hotspot of the same benchmarks suite
[Bug lto/71535] ICE in LTO1 with -fopenmp offloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71535 Jose Manuel Monsalve Diaz changed: What|Removed |Added CC||josem at udel dot edu --- Comment #3 from Jose Manuel Monsalve Diaz --- This also seems to happen when compiling the LUD version of the rodinia_3.1 benchmarks found here: http://lava.cs.virginia.edu/Rodinia/download_links.htm If you download them and try: cd openmp/lud/ g++ -foffload="-lm" -lm -fopenmp -DOMP_OFFLOAD omp/lud_omp.c omp/lud.c common/common.c -o lud -I./common/ You get this: common/common.c: In function ‘func_ret_t lud_verify(float*, float*, int)’: common/common.c:187:1: warning: no return statement in function returning non-void [-Wreturn-type] } ^ lto1: internal compiler error: in input_overwrite_node, at lto-cgraph.c:1208 0x85a221 input_overwrite_node ../../gcc8.2/gcc/lto-cgraph.c:1206 0x85a221 input_node ../../gcc8.2/gcc/lto-cgraph.c:1303 0x85a221 input_cgraph_1 ../../gcc8.2/gcc/lto-cgraph.c:1552 0x85a221 input_symtab() ../../gcc8.2/gcc/lto-cgraph.c:1860 0x5b9a91 read_cgraph_and_symbols ../../gcc8.2/gcc/lto/lto.c:2897 0x5b9a91 lto_main() ../../gcc8.2/gcc/lto/lto.c:3362 Please submit a full bug report,
[Bug target/87213] ICE in final_scan_insn_1, at final.c:3070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87213 Segher Boessenkool changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-26 Known to work||7.0, 9.0 Host|powerpc64le-linux-gnu | Ever confirmed|0 |1 Known to fail||8.0 --- Comment #1 from Segher Boessenkool --- It does not fail on GCC 7 or GCC 9, but it does still fail like this on GCC 8. Confirmed.
[Bug libstdc++/90266] missing or broken check for vector::size() exceeding max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90266 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Jonathan Wakely --- Yes, it should be fixed in 9+ assuming I added the length checks in all the right places.
[Bug libstdc++/90266] missing or broken check for vector::size() exceeding max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90266 Richard Smith changed: What|Removed |Added Version|unknown |8.3.0 --- Comment #3 from Richard Smith --- (In reply to Jonathan Wakely from comment #1) > Which version are you using? (You didn't say) Sorry for leaving that out! I was using "clang (trunk)" on godbolt, which is apparently 8.3.0. Sounds like this was fixed in the interim?
[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS (can lead to build failures when libunwind-headers from MacPorts is active)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251 Eric Gallager changed: What|Removed |Added Summary|config/gettext.m4 and |config/gettext.m4 and |config/iconv.m4 contaminate |config/iconv.m4 contaminate |CPPFLAGS|CPPFLAGS (can lead to build ||failures when ||libunwind-headers from ||MacPorts is active) --- Comment #10 from Eric Gallager --- (In reply to Eric Gallager from comment #9) > (In reply to Eric Gallager from comment #8) > > r265896 might have affected this > > Update: apparently not; I still had to deactivate libunwind-headers again on > my latest build of gcc Since I keep running into this, I'm adding that part to the title for easier findability
[Bug c++/89088] Dllexport for explicit template instantiation missing inline methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89088 --- Comment #1 from Martin Storsjö --- FWIW, Clang (when operating in MinGW mode, where it tries to follow what GCC does) also had the same issue. There this issue was fixed by making dllexport export inline methods as well, for template instantiations: https://github.com/llvm-project/clang/commit/2061b0cab0002c264af632bf5e6ba5306c589c94
[Bug libstdc++/90266] missing or broken check for vector::size() exceeding max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90266 --- Comment #2 from Jonathan Wakely --- I think I fixed this in r263789 for PR 78448 and then changed the return value of max_size() in r265021 for PR 87544.
[Bug libstdc++/90266] missing or broken check for vector::size() exceeding max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90266 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug c++/89087] Dllexport for explicit template instantiation with nested classes loses nested class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89087 --- Comment #1 from Martin Storsjö --- FWIW, Clang (when operating in MinGW mode, where it tries to follow what GCC does) also had the same issue. There this issue was fixed by emitting definitions for nested classes even if a template instantiation has been declared, like this: https://github.com/llvm-project/clang/commit/7331c3301af9628719664c9a4feea576df3994a9
[Bug libstdc++/90266] missing or broken check for vector::size() exceeding max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90266 --- Comment #1 from Jonathan Wakely --- Which version are you using? (You didn't say) With trunk I get length_error thrown from the first push_back in f or g: terminate called after throwing an instance of 'std::length_error' what(): vector::_M_realloc_insert
[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference false positive after r270574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264 --- Comment #3 from Roman Zhuykov --- (In reply to Jeffrey A. Law from comment #1) > We set *seq = 0. > > Assume we do not return -1 from line A. > > The for loop's initial test will be false because out = *seq = 0 > > out - *seq must also be zero and if that's <= len, then we'll *out = `\0' > which dereferences a NULL pointer. The point is, that if "line A" is not a false positive, then "line B" version also must be warned. Let me than say it is a false negative. Originally it was asprintf, which always sets *seq to non-null, or returns negative when ENOMEM. But compiler doesn't know that logic.
[Bug libstdc++/90266] missing or broken check for vector::size() exceeding max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90266 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-26 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/90266] New: missing or broken check for vector::size() exceeding max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90266
Bug ID: 90266
Summary: missing or broken check for vector::size() exceeding
max_size()
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
#include
using T = int;
size_t e() {
std::vector vb;
return vb.max_size();
}
size_t f() {
std::vector vb(e());
vb.push_back({});
return vb.size();
}
size_t g() {
std::vector vb(e());
vb.push_back({});
vb.push_back({});
return vb.size();
}
Compiled using -m32, I find:
* e() returns 0x3fff (good)
* f() invokes operator new(-4) and returns 0 (wrong; should throw
length_error)
* g() invokes operator new(-4) twice (?!) and returns 1
It looks like the check for size() exceeding max_size() is missing. [For a
compiler that deletes unused new/delete pairs, f() otherwise could incorrectly
compile to just "return 0;" with no exception thrown. Presumably the same would
happen under -m64 with an allocator that has a 32-bit max_size().]
[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172 Bug 86172 depends on bug 90264, which changed state. Bug 90264 Summary: [9/10 Regression] -Wnull-dereference false positive after r270574 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference false positive after r270574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jeffrey A. Law --- Not a false positive. See c#1.
[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference false positive after r270574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264 --- Comment #1 from Jeffrey A. Law --- It doesn't look like a false positive to me. We set *seq = 0. Assume we do not return -1 from line A. The for loop's initial test will be false because out = *seq = 0 out - *seq must also be zero and if that's <= len, then we'll *out = `\0' which dereferences a NULL pointer.
[Bug c++/90265] [9/10 Regression] ICE in build_call_a at gcc/cp/call.c:396 since r268377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265 Martin Liška changed: What|Removed |Added Last reconfirmed||2019-4-26 Target Milestone|--- |9.0
[Bug c++/90265] New: [9/10 Regression] ICE in build_call_a at gcc/cp/call.c:396 since r268377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265
Bug ID: 90265
Summary: [9/10 Regression] ICE in build_call_a at
gcc/cp/call.c:396 since r268377
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
It's a code snippet reduced from pulseeffects project:
$ cat pulse.ii
void (*a)(int, int, int, void *) = [](auto, auto, auto, auto) {};
$ g++ pulse.ii -c
pulse.ii: In instantiation of ‘static decltype (((const*)0)->operator()(static_cast(), static_cast(),
static_cast(),
static_cast()))::_FUN(auto:1, auto:2, auto:3, auto:4) [with auto:1 = int; auto:2 =
int; auto:3 = int; auto:4 = void*; decltype (((const*)0)->operator()(static_cast(), static_cast(),
static_cast(), static_cast())) =
void]’:
pulse.ii:1:64: recursively required from ‘::operator decltype (((const*)0)->operator()(static_cast(), static_cast(),
static_cast(), static_cast()))
(*)(auto:1, auto:2, auto:3, auto:4)() const [with auto:1 = int; auto:2 = int;
auto:3 = int; auto:4 = void*; decltype (((const*)0)->operator()(static_cast(), static_cast(),
static_cast(), static_cast())) =
void]’
pulse.ii:1:64: required from here
pulse.ii:1:64: internal compiler error: Segmentation fault
1 | void (*a)(int, int, int, void *) = [](auto, auto, auto, auto) {};
|^
0xf13a7f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:326
0x77b7fe0f ???
/usr/src/debug/glibc-2.29-5.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x83e44e contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3289
0x83e44e build_call_a(tree_node*, int, tree_node**)
/home/marxin/Programming/gcc/gcc/cp/call.c:396
0x996ae2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18889
0x9a3888 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18241
0x9a3888 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:17917
0x9a0762 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:17033
0x9a0610 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:17324
0x99fe6c instantiate_decl(tree_node*, bool, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:24773
0x9c69c3 instantiate_pending_templates(int)
/home/marxin/Programming/gcc/gcc/cp/pt.c:24889
0x8df02b c_parse_final_cleanups()
/home/marxin/Programming/gcc/gcc/cp/decl2.c:4818
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/90264] New: [9/10 Regression] -Wnull-dereference false positive after r270574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264
Bug ID: 90264
Summary: [9/10 Regression] -Wnull-dereference false positive
after r270574
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhroma at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, law at redhat dot com, rguenth at
gcc dot gnu.org
Blocks: 86172
Target Milestone: ---
Reduced manually from lib/colors.c in util-linux 2.33.1
int like_asprintf(char **strp);
int cn_sequence(char **seq) {
char *out;
int len;
*seq = 0;
/* Warning disappears when using second line
(comment line A and uncomment line B). */
if ((len = like_asprintf(seq)) < 1) return -1; //line A
//len = like_asprintf(seq);//line B
for (out = *seq; out && *out; out++);
if ((out - *seq) > len) return -2;
*out = '\0';
return 0;
}
with "-O2 -Wnull-dereference"
: In function 'cn_sequence':
:13:8: warning: potential null pointer dereference [-Wnull-dereference]
13 | *out = '\0';
| ~^~
It seems odd to have warning with "line A" version and not to warn in "line B"
example.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
[Bug 86172] [meta-bug] issues with -Wnull-dereference
[Bug middle-end/90263] Calls to mempcpy should use memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263 --- Comment #4 from Wilco --- (In reply to Jakub Jelinek from comment #3) > Because then you penalize properly maintained targets which do have > efficient mempcpy. And even if some targets don't have efficient mempcpy > right now, that doesn't mean they can't have it in the future. On the > caller side, when not expanded inline, calling mempcpy instead of memcpy is > smaller, often requires fewer registers to be live across the call etc. Few targets have an optimized mempcpy, particularly when you look at other libraries besides GLIBC. We could easily have a target hook to emit mempcpy, but I believe the default should be to do what's fastest for most targets.
[Bug middle-end/90263] Calls to mempcpy should use memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263 --- Comment #3 from Jakub Jelinek --- Because then you penalize properly maintained targets which do have efficient mempcpy. And even if some targets don't have efficient mempcpy right now, that doesn't mean they can't have it in the future. On the caller side, when not expanded inline, calling mempcpy instead of memcpy is smaller, often requires fewer registers to be live across the call etc.
[Bug middle-end/90263] Calls to mempcpy should use memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263 --- Comment #2 from Wilco --- (In reply to Jakub Jelinek from comment #1) > As stated several times in the past, I strongly disagree. Why? GCC already does this for bzero and bcopy.
[Bug target/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178 Jakub Jelinek changed: What|Removed |Added Status|RESOLVED|REOPENED CC||jakub at gcc dot gnu.org Resolution|FIXED |--- --- Comment #10 from Jakub Jelinek --- The patch has been reverted (and is not the right fix anyway).
[Bug middle-end/90263] Calls to mempcpy should use memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- As stated several times in the past, I strongly disagree.
[Bug middle-end/90263] New: Calls to mempcpy should use memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
Bug ID: 90263
Summary: Calls to mempcpy should use memcpy
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
While GCC now inlines fixed-size mempcpy like memcpy, GCC still emits calls to
mempcpy rather than converting to memcpy. Since most libraries, including
GLIBC, do not have optimized mempcpy for most targets, calling mempcpy is less
efficient than calling memcpy and emitting an extra addition to compute the
result.
int *mempcopy1 (int *p, int *q)
{
return __builtin_mempcpy (p, q, 16);
}
int *mempcopy2 (int *p, int *q, long n)
{
return __builtin_mempcpy (p, q, n);
}
mempcopy1:
ldp x2, x3, [x1]
stp x2, x3, [x0], 16
ret
mempcopy2:
b mempcpy
[Bug middle-end/90262] New: Inline small constant memmoves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90262
Bug ID: 90262
Summary: Inline small constant memmoves
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
GCC does not inline fixed-size memmoves. However memmove can be as easily
inlined as memcpy. The existing memcpy infrastructure could be reused/expanded
for this - all loads would be emitted first, followed by the stores. Large
memmoves could be inlined on targets with vector registers. Targets without
vector registers could emit an overlap check and use inlined memcpy for the no
overlap case.
void copy(int *p, int *q)
{
__builtin_memcpy(p, q, 24);
}
void move(int *p, int *q)
{
__builtin_memmove(p, q, 24);
}
copy:
ldp x2, x3, [x1]
stp x2, x3, [x0]
ldr x1, [x1, 16]
str x1, [x0, 16]
ret
move:
mov x2, 24
b memmove
The memmove could be expanded using the same number of registers:
ldp x2, x3, [x1]
ldr x1, [x1, 16]
stp x2, x3, [x0]
str x1, [x0, 16]
[Bug tree-optimization/88797] [7/8/9/10 Regression] Unneeded branch added when function is inlined (function runs faster if not inlined)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88797 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #7 from Jeffrey A. Law --- It looks like the usual tension between path splitting and if-conversion. I think this one is trivial to address though. Investigating.
[Bug c++/90243] diagnostic notes that belong to a suppressed error about an uninitialized variable in a constexpr function are still shown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90243 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #4 from Jonathan Wakely --- Fixed on trunk.
[Bug c++/90243] diagnostic notes that belong to a suppressed error about an uninitialized variable in a constexpr function are still shown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90243 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Apr 26 16:33:02 2019 New Revision: 270610 URL: https://gcc.gnu.org/viewcvs?rev=270610=gcc=rev Log: PR c++/90243 - orphaned note in uninstantiated constexpr function gcc/cp: PR c++/90243 - orphaned note in uninstantiated constexpr function * decl.c (check_for_uninitialized_const_var): Suppress notes if no error was shown. gcc/testsuite: PR c++/90243 * g++.dg/diagnostic/pr90243.C: New test. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr90243.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/87979] ICE in compute_split_row at modulo-sched.c:2393
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87979 --- Comment #5 from Roman Zhuykov --- Author: zhroma Date: Fri Apr 26 16:04:54 2019 New Revision: 270609 URL: https://gcc.gnu.org/viewcvs?rev=270609=gcc=rev Log: Backport modulo-sched fixes from mainline 2019-04-23 Roman Zhuykov modulo-sched: prevent division by zero (PR87979) PR rtl-optimization/87979 * modulo-sched.c (sms_schedule): Start ii value "mii" should not equal zero. modulo-sched: fix branch scheduling issue (PR84032) PR rtl-optimization/84032 * modulo-sched.c (ps_insn_find_column): Change condition so that branch will always be the last insn in a row inside partial schedule. gcc/testsuite: PR rtl-optimization/87979 * gcc.dg/pr87979.c: New test. PR rtl-optimization/84032 * gcc.dg/pr84032.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr84032.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr87979.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/modulo-sched.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/84032] ICE in optimize_sc, at modulo-sched.c:1064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84032 --- Comment #7 from Roman Zhuykov --- Author: zhroma Date: Fri Apr 26 16:04:54 2019 New Revision: 270609 URL: https://gcc.gnu.org/viewcvs?rev=270609=gcc=rev Log: Backport modulo-sched fixes from mainline 2019-04-23 Roman Zhuykov modulo-sched: prevent division by zero (PR87979) PR rtl-optimization/87979 * modulo-sched.c (sms_schedule): Start ii value "mii" should not equal zero. modulo-sched: fix branch scheduling issue (PR84032) PR rtl-optimization/84032 * modulo-sched.c (ps_insn_find_column): Change condition so that branch will always be the last insn in a row inside partial schedule. gcc/testsuite: PR rtl-optimization/87979 * gcc.dg/pr87979.c: New test. PR rtl-optimization/84032 * gcc.dg/pr84032.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr84032.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr87979.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/modulo-sched.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug debug/90197] [8/9/10 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Apr 26 15:38:33 2019 New Revision: 270606 URL: https://gcc.gnu.org/viewcvs?rev=270606=gcc=rev Log: PR debug/90197 * c-tree.h (c_finish_loop): Add 2 further location_t arguments. * c-parser.c (c_parser_while_statement): Adjust c_finish_loop caller. (c_parser_do_statement): Likewise. (c_parser_for_statement): Likewise. Formatting fixes. * c-typeck.c (c_finish_loop): Add COND_LOCUS and INCR_LOCUS arguments, emit DEBUG_BEGIN_STMTs if needed. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/c/c-tree.h trunk/gcc/c/c-typeck.c
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #14 from Segher Boessenkool --- I committed as r270601, on gcc-9-branch 2019-04-26 Segher Boessenkool PR other/90257 Revert the revert: 2019-04-21 H.J. Lu PR target/90178 Revert: 2018-11-21 Uros Bizjak Revert the revert: 2013-10-26 Vladimir Makarov Revert: 2013-10-25 Vladimir Makarov * lra-spills.c (lra_final_code_change): Remove useless move insns. so this is okay for rs6000 on GCC 9 for now.
[Bug middle-end/90191] [9/10 regression] incorrect -Wformat-overflow with --param max-jump-thread-duplication-stmts=17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90191 --- Comment #6 from Jeffrey A. Law --- NP. It happens to all of us at some point :-)
[Bug middle-end/90191] [9/10 regression] incorrect -Wformat-overflow with --param max-jump-thread-duplication-stmts=17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90191 --- Comment #5 from Dmitry G. Dyachenko --- (In reply to Jeffrey A. Law from comment #4) > Actually I think the warning is valid. Ramping up the aggressiveness of the > threader is what ultimately exposes it. [...] > > But AFAICT the warning is 100% totally valid. You just have to turn up the > optimizer thresholds to expose it. Jeff, thank you for clarification. You are absolutely right -- my test is invalid. Sorry for over-reducing
[Bug c++/90173] [9 Regression] ICE: Segmentation fault (in strip_declarator_types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90173 Paolo Carlini changed: What|Removed |Added Summary|[9/10 Regression] ICE: |[9 Regression] ICE: |Segmentation fault (in |Segmentation fault (in |strip_declarator_types) |strip_declarator_types) --- Comment #4 from Paolo Carlini --- Fixed in trunk so far.
[Bug c++/90173] [9/10 Regression] ICE: Segmentation fault (in strip_declarator_types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90173 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Apr 26 14:51:00 2019 New Revision: 270603 URL: https://gcc.gnu.org/viewcvs?rev=270603=gcc=rev Log: /cp 2019-04-26 Paolo Carlini PR c++/90173 * decl.c (grokdeclarator): Set type to error_mark_node upon error about template placeholder type non followed by a simple declarator-id. /testsuite 2019-04-26 Paolo Carlini PR c++/90173 * g++.dg/cpp1z/class-deduction66.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction66.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #13 from rguenther at suse dot de --- On April 26, 2019 4:37:24 PM GMT+02:00, rguenther at suse dot de wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 > >--- Comment #12 from rguenther at suse dot de de> --- >On April 26, 2019 4:18:03 PM GMT+02:00, "jakub at gcc dot gnu.org" > wrote: >>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 >> >>--- Comment #11 from Jakub Jelinek --- >>Created attachment 46253 >> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46253=edit >>gcc9-pr90257.patch >> >>Untested patch that fixes PR90178 even when the reversion of reversion >>of >>reversion in lra-spills.c is reverted. > >Any reason why this heuristic is good? It looks arbitrary to solve the >particular testcase? In particular we'd keep a chain of 16 forwarders unmerged with your change? >>For the trunk, we could as well replace the lra-spills.c change with >>richi's >>dce change or whatever else. Just it seems to be wrong to rely on >>unoptimal IL >>to perform proper optimizations.
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #12 from rguenther at suse dot de --- On April 26, 2019 4:18:03 PM GMT+02:00, "jakub at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 > >--- Comment #11 from Jakub Jelinek --- >Created attachment 46253 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46253=edit >gcc9-pr90257.patch > >Untested patch that fixes PR90178 even when the reversion of reversion >of >reversion in lra-spills.c is reverted. Any reason why this heuristic is good? It looks arbitrary to solve the particular testcase? >For the trunk, we could as well replace the lra-spills.c change with >richi's >dce change or whatever else. Just it seems to be wrong to rely on >unoptimal IL >to perform proper optimizations.
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #11 from Jakub Jelinek --- Created attachment 46253 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46253=edit gcc9-pr90257.patch Untested patch that fixes PR90178 even when the reversion of reversion of reversion in lra-spills.c is reverted. For the trunk, we could as well replace the lra-spills.c change with richi's dce change or whatever else. Just it seems to be wrong to rely on unoptimal IL to perform proper optimizations.
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #10 from Pat Haugen --- (In reply to Richard Biener from comment #3) > Created attachment 46250 [details] > run_fast_dce also for LRA > > Sth like this could fix it. Yes, that restored the performance.
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #9 from Jakub Jelinek --- I believe the difference is caused by cfg cleanup without the noop move considering (code_label 34 6 37 9 1 (nil) [2 uses]) (note 37 34 36 9 [bb 9] NOTE_INSN_BASIC_BLOCK) (insn 36 37 53 9 (use (reg/i:DI 0 ax)) "pr90178.c":8:1 -1 (nil)) basic block a forwarder block (that seems correct), while with the noop it isn't and thus doesn't try to optimize it. The condition in try_forward_edges is: if (FORWARDER_BLOCK_P (target) && single_succ (target) != EXIT_BLOCK_PTR_FOR_FN (cfun)) and so it already tries to avoid changing forwarders to exit that way. But the single_succ of target is not EXIT, but an empty forwarder block to EXIT: (note 53 36 51 10 [bb 10] NOTE_INSN_BASIC_BLOCK) created by mode-switching.c (create_pre_exit). Wonder if the correct fix for PR90257 isn't extend the above test to also consider further forwarders to exit in the above test.
[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432 --- Comment #10 from Iain Buclaw --- (In reply to Uroš Bizjak from comment #8) > (In reply to ibuclaw from comment #6) > > Author: ibuclaw > > Date: Wed Apr 24 18:57:36 2019 > > New Revision: 270554 > > > > URL: https://gcc.gnu.org/viewcvs?rev=270554=gcc=rev > > Log: > > libphobos: Fix FAIL phobos.exp/core.time on CentOS 5.11, Linux 2.6.18 > > > > Merges upstream druntime e03164b5. > > > > Reviewed-on: https://github.com/dlang/druntime/pull/2581 > > > > libphobos/ChangeLog: > > > > 2019-04-24 Iain Buclaw > > > > PR d/89432 > > * testsuite/lib/libphobos.exp (check_effective_target_linux_pre_2639): > > New proc. > > * testsuite/libphobos.druntime/druntime.exp: Add compiler flag > > -fversion=Linux_Pre_2639 if target is linux_pre_2639. > > * testsuite/libphobos.druntime_shared/druntime_shared.exp: Likewise. > > > > Modified: > > trunk/libphobos/ChangeLog > > trunk/libphobos/libdruntime/MERGE > > trunk/libphobos/libdruntime/core/time.d > > trunk/libphobos/testsuite/lib/libphobos.exp > > trunk/libphobos/testsuite/libphobos.druntime/druntime.exp > > trunk/libphobos/testsuite/libphobos.druntime_shared/druntime_shared.exp > > This part: > > #include > #if !defined LINUX_VERSION_CODE || LINUX_VERSION_CODE < > KERNEL_VERSION(2.6.39) > #error Yes, it is. > #endif > > The KERNEL_VERSION macro expects three arguments, so commas should be used: > > "KERNEL_VERSION(2,6,39)" > Oops, that must have been a fat finger incident when I was switching between 2,6,39 and 4,19,0 to test the trigger.
[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432 --- Comment #9 from Uroš Bizjak --- FYI, a check for a supported clock type in systemtime.d is also needed, otherwise the test tries to access unsupported ClockType.coarse: core.time.TimeException@/home/uros/git/gcc/libphobos/testsuite/../src/std/datetime/systime.d(180): Call to clock_gettime() failed /home/uros/git/gcc/libphobos/testsuite/../src/std/datetime/systime.d:180 @property @trusted long std.datetime.systime.Clock.currStdTime!(2).currStdTime() [0x4eb028] /home/uros/git/gcc/libphobos/testsuite/../src/std/datetime/systime.d:66 @safe std.datetime.systime.SysTime std.datetime.systime.Clock.currTime!(2).currTime(immutable(std.datetime.timezone.TimeZone)) [0x4eac7d] /home/uros/git/gcc/libphobos/testsuite/../src/std/datetime/systime.d:98 @safe void std.datetime.systime.Clock.__unittestL69_2() [0x40a31f] /home/uros/gcc-build/x86_64-pc-linux-gnu/libphobos/testsuite/libphobos2/:1 void std.datetime.systime.__modtest() [0x4ea72e] ../../../../git/gcc/libphobos/libdruntime/core/runtime.d:561 __foreachbody2 [0x632cc7] ../../../../git/gcc/libphobos/libdruntime/rt/minfo.d:777 __foreachbody2 [0x614f28] ../../../../git/gcc/libphobos/libdruntime/gcc/sections/elf_shared.d:107 int gcc.sections.elf_shared.DSO.opApply(scope int delegate(ref gcc.sections.elf_shared.DSO)) [0x6035fa] ../../../../git/gcc/libphobos/libdruntime/rt/minfo.d:770 int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) [0x616cdb] ../../../../git/gcc/libphobos/libdruntime/object.d:1598 int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x60abcb] ../../../../git/gcc/libphobos/libdruntime/core/runtime.d:551 runModuleUnitTests [0x632fc1] ../../../../git/gcc/libphobos/libdruntime/rt/dmain2.d:488 runAll [0x611bf4] ../../../../git/gcc/libphobos/libdruntime/rt/dmain2.d:464 tryExec [0x6117fd] ../../../../git/gcc/libphobos/libdruntime/rt/dmain2.d:497 _d_run_main [0x6119c4] /home/uros/git/gcc/libphobos/libdruntime/__entrypoint.di:44 main [0x4ea9e5] ??:? __libc_start_main [0x345e21d9f3] ??:? ???[0x408a60] ClockType.coarse FAIL: libphobos.phobos/std/datetime/systime.d execution test
[Bug target/90260] New: function multiversioning: template functions not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90260
Bug ID: 90260
Summary: function multiversioning: template functions not
supported
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nheart at gmail dot com
Target Milestone: ---
Created attachment 46252
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46252=edit
Templated function multiversioning
Hey,
I couldn't find a bug report about this or information about it, so hence this
report:
Function multiversion doesn't seem to support templated functions: Attempting
compilation of the attached example results in a rather confusing error
message:
g++ test.cpp:(
test.cpp:7:39: error: ambiguating new declaration ‘template T foo(T)’
__attribute__ ((target("default"))) T foo(T num) {
^~~
test.cpp:2:36: note: old declaration ‘template T foo(T)’
__attribute__ ((target("avx2"))) T foo(T num) {
Cheers,
Nick
[Bug d/90261] New: FAIL: libphobos.phobos/std/file.d on CentOS 5.11, Linux 2.6.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90261 Bug ID: 90261 Summary: FAIL: libphobos.phobos/std/file.d on CentOS 5.11, Linux 2.6.18 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ubizjak at gmail dot com Target Milestone: --- libphobos testing on x86_64 CentOS 5.11 fails to compile a testcase: FAIL: libphobos.phobos/std/file.d with: /tmp/cc36u3o7.o: In function `_D3std4file17__T8setTimesTAyaZ8setTimesFAyaS3std8datetime7systime7SysTimeS3std8datetime7systime7SysTimeZ16trustedUtimensatFNbNiNeiPxaKxG2S4core3sys5posix6signal8timespeciZi': /home/uros/git/gcc/libphobos/testsuite/../src/std/file.d:1272: undefined reference to `utimensat' collect2: error: ld returned 1 exit status compiler exited with status 1 due to non-existent utimensat function in CentOS 5.11's GNU C Library stable release version 2.5, by Roland McGrath et al. Regarding utimensat, its manpage says: VERSIONS utimensat() was added to Linux in kernel 2.6.22; glibc support was added with version 2.6. Support for futimens() first appeared in glibc 2.6.
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #8 from Jakub Jelinek --- (In reply to Richard Biener from comment #3) > Created attachment 46250 [details] > run_fast_dce also for LRA > > Sth like this could fix it. I've verified this patch breaks PR90178 again as well. I think we need to debug why cfg cleanup makes a different decision during the vzeroupper pass on PR90178.
[Bug middle-end/89889] worse code compared to clang with alloca()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89889 --- Comment #3 from Lokesh Janghel --- Is there any target hooks for alloca? Should we do the same like __builtin_alloca_with_align (array allocation) or we assume the problem as a target based (prologue/epilogue optimization) issue?
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #7 from Pat Haugen --- Overall 'perf' cycle counts and hot functions. r270483 --- # Overhead Samples Command Shared Object # ... # 91.17%721643 gcc_base.gcc_hu gcc_base.gcc_hunt_64 8.82% 69840 gcc_base.gcc_hu libc-2.17.so # Overhead Samples Command Shared Object Symbol # ... ... # 6.22% 49295 gcc_base.gcc_hu gcc_base.gcc_hunt_64 [.] reg_is_remote_constant_p.isra.0.part.0 6.18% 48897 gcc_base.gcc_hu libc-2.17.so [.] __memset_power8 6.05% 47651 gcc_base.gcc_hu gcc_base.gcc_hunt_64 [.] bitmap_operation 5.92% 46695 gcc_base.gcc_hu gcc_base.gcc_hunt_64 [.] htab_traverse 3.66% 28957 gcc_base.gcc_hu gcc_base.gcc_hunt_64 [.] canon_rtx 3.59% 28440 gcc_base.gcc_hu gcc_base.gcc_hunt_64 [.] compute_transp 3.35% 26372 gcc_base.gcc_hu gcc_base.gcc_hunt_64 [.] bitmap_element_allocate 2.18% 17151 gcc_base.gcc_hu gcc_base.gcc_hunt_64 [.] compute_dominance_frontiers_1 2.00% 15841 gcc_base.gcc_hu gcc_base.gcc_hunt_64 [.] ggc_set_mark 1.77% 13974 gcc_base.gcc_hu gcc_base.gcc_hunt_64 [.] fixup_var_refs_1 1.69% 13391 gcc_base.gcc_hu gcc_base.gcc_hunt_64 [.] ggc_mark_rtx_children_1 1.54% 12236 gcc_base.gcc_hu gcc_base.gcc_hunt_64 [.] single_set_2.part.0 r270484 --- # Overhead Samples Command Shared Object # ... . # 92.08%814297 gcc_base.base_6 gcc_base.base_64 7.91% 70063 gcc_base.base_6 libc-2.17.so # Overhead Samples Command Shared Object Symbol # ... . ... # 8.14% 71642 gcc_base.base_6 gcc_base.base_64 [.] bitmap_operation 6.92% 60863 gcc_base.base_6 gcc_base.base_64 [.] bitmap_element_allocate 6.01% 53281 gcc_base.base_6 gcc_base.base_64 [.] reg_is_remote_constant_p.isra.0.part.0 5.68% 50081 gcc_base.base_6 gcc_base.base_64 [.] htab_traverse 5.53% 48967 gcc_base.base_6 libc-2.17.so [.] __memset_power8 3.82% 33850 gcc_base.base_6 gcc_base.base_64 [.] compute_transp 3.30% 29142 gcc_base.base_6 gcc_base.base_64 [.] canon_rtx 1.95% 17155 gcc_base.base_6 gcc_base.base_64 [.] compute_dominance_frontiers_1 1.81% 16023 gcc_base.base_6 gcc_base.base_64 [.] ggc_set_mark 1.69% 14989 gcc_base.base_6 gcc_base.base_64 [.] ggc_mark_rtx_children_1 1.57% 13832 gcc_base.base_6 gcc_base.base_64 [.] fixup_var_refs_1 1.48% 13144 gcc_base.base_6 gcc_base.base_64 [.] single_set_2.part.0
[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432 --- Comment #8 from Uroš Bizjak --- (In reply to ibuclaw from comment #6) > Author: ibuclaw > Date: Wed Apr 24 18:57:36 2019 > New Revision: 270554 > > URL: https://gcc.gnu.org/viewcvs?rev=270554=gcc=rev > Log: > libphobos: Fix FAIL phobos.exp/core.time on CentOS 5.11, Linux 2.6.18 > > Merges upstream druntime e03164b5. > > Reviewed-on: https://github.com/dlang/druntime/pull/2581 > > libphobos/ChangeLog: > > 2019-04-24 Iain Buclaw > > PR d/89432 > * testsuite/lib/libphobos.exp (check_effective_target_linux_pre_2639): > New proc. > * testsuite/libphobos.druntime/druntime.exp: Add compiler flag > -fversion=Linux_Pre_2639 if target is linux_pre_2639. > * testsuite/libphobos.druntime_shared/druntime_shared.exp: Likewise. > > Modified: > trunk/libphobos/ChangeLog > trunk/libphobos/libdruntime/MERGE > trunk/libphobos/libdruntime/core/time.d > trunk/libphobos/testsuite/lib/libphobos.exp > trunk/libphobos/testsuite/libphobos.druntime/druntime.exp > trunk/libphobos/testsuite/libphobos.druntime_shared/druntime_shared.exp This part: #include #if !defined LINUX_VERSION_CODE || LINUX_VERSION_CODE < KERNEL_VERSION(2.6.39) #error Yes, it is. #endif The KERNEL_VERSION macro expects three arguments, so commas should be used: "KERNEL_VERSION(2,6,39)" Currently the check always fails with: linux_pre_263917519.c:3:79: error: macro "KERNEL_VERSION" requires 3 arguments, but only 1 given In file included from linux_pre_263917519.c:2: /usr/include/linux/version.h:2: note: macro "KERNEL_VERSION" defined here compiler exited with status 1
Come join me on Africa Oil & Gas Industry
Africa Oil & Gas Industry: An Africa Business Community Hi, Short term business collaboration. Let me know if you have some time to connect for more details. Contact email: kamhe...@gmail.com. Skype: live:kamhed44. Regards, Kamran Hedayat. Click the link below to Join: http://africaoil.ning.com/?xgi=58muZSRPXC7Hxz_source=msg_invite_net If your email program doesn't recognize the web address above as an active link, please copy and paste it into your web browser Members already on Africa Oil & Gas Industry Bas Vlugt, Olamide Jegede, Glenn Labhart, Dakota Muscle, Ray Miles About Africa Oil & Gas Industry A networking community for people who are professionally involved in the African Oil & Gas Industry 1374 members 96 Events 392 blog posts To control which emails you receive on Africa Oil & Gas Industry, or to opt-out, go to: http://africaoil.ning.com/?xgo=ShMVpgcsGWQLZy60QH/ni-HeV8E45PCbijHN32es2NC9iKrJ11YG2z5nE/Z46JW3_source=msg_invite_net
[Bug fortran/83118] [7/8/9/10 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #20 from paul.richard.thomas at gmail dot com --- Hi Rainer, Thanks a million. Unfortunately, we just missed the 9.1 release. Cheers Paul On Thu, 25 Apr 2019 at 09:59, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 > > --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- > > --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE > Uni-Bielefeld.DE> --- > [...] > > I've just applied the patch to trunk, rebuilt f951 on > > sparc-sun-solaris2.11 and tested unlimited_polymorphic_30.f03: the test > > now PASSes for both 32 and 64-bit. > > > > I'll include the patch in tonight's bootstrap and let you know if there > > are any problems elsewhere. > > There weren't any in last night's sparc-sun-solaris2.11 bootstrap: both > 32 and 64-bit unlimited_polymorphic_30.f03 failures are gone. > > Thanks. > Rainer > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug c/90253] no warning for cv-qualified selectors in _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90253 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- I think there was another bug about this w.r.t. -Wignored-qualifiers and/or whether or not typeof should strip qualifiers; can't find it right now though...
[Bug middle-end/90258] [9 Regression] Missing completion for a target option since r264052
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90258 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[9 Regression] Missing |[9/10 Regression] Missing |completion for a target |completion for a target |option since r264052|option since r264052 Martin Liška changed: What|Removed |Added Keywords||patch Summary|[9/10 Regression] Missing |[9 Regression] Missing |completion for a target |completion for a target |option since r264052|option since r264052 --- Comment #2 from Martin Liška --- Patch candidate: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg01032.html
[Bug middle-end/90258] [9 Regression] Missing completion for a target option since r264052
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90258 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[9 Regression] Missing |[9/10 Regression] Missing |completion for a target |completion for a target |option since r264052|option since r264052 Martin Liška changed: What|Removed |Added Keywords||patch Summary|[9/10 Regression] Missing |[9 Regression] Missing |completion for a target |completion for a target |option since r264052|option since r264052 --- Comment #2 from Martin Liška --- Patch candidate: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg01032.html
[Bug rtl-optimization/90249] [9/10 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249 --- Comment #3 from Richard Earnshaw --- (In reply to Segher Boessenkool from comment #2) > What difference is there on some code of significant size? Do you see > regressions then? > > Of course there are some tiny examples where it now does worse, just like > there are examples where it now does better. Across the entirety of CSiBE thumb2 regresses by 0.05% (tested by effectively disabling r265398 on tip of tree). It seems to be specific to Thumb2 code, though. Thumb1 and Arm code now get worse when that specific patch is disabled. Though all three are still worse than gcc-8 overall.
[Bug rtl-optimization/90259] New: ICE: verify_flow_info failed (error: missing REG_EH_REGION note at the end of bb 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259
Bug ID: 90259
Summary: ICE: verify_flow_info failed (error: missing
REG_EH_REGION note at the end of bb 4)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: EH, ice-checking, ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-e300c3-linux-gnu
Created attachment 46251
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46251=edit
Testcase
g++-9.0.0-alpha20190421 snapshot (r270485) ICEs when compiling the attached
testcase w/ -O1 (-O2, -O3, -Os) -ffloat-store -fgcse -fnon-call-exceptions
-fno-forward-propagate -fno-omit-frame-pointer:
% powerpc-e300c3-linux-gnu-g++-9.0.0-alpha20190421 -m32 -O1 -ffloat-store
-fgcse -fnon-call-exceptions -fno-forward-propagate -fno-omit-frame-pointer -c
svj3x11t.cc
svj3x11t.cc: In static member function 'static ar p::as(const
int&, j ...) [with ar = void; i = q::r; j = {o}]':
svj3x11t.cc:30:65: error: missing REG_EH_REGION note at the end of bb 4
30 | static ar as(const int , j...) { (*ao::ap(p1))(j()...); }
| ^
during RTL pass: cprop_hardreg
svj3x11t.cc:30:65: internal compiler error: verify_flow_info failed
0xb0808c verify_flow_info()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/cfghooks.c:265
0xe76ac2 execute_function_todo
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/passes.c:1989
0xe7743a execute_todo
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/passes.c:2031
[Bug middle-end/90258] [9 Regression] Missing completion for a target option since r264052
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90258 Martin Liška changed: What|Removed |Added Component|target |middle-end --- Comment #1 from Martin Liška --- It's a generic issue, not target specific.
[Bug target/90258] [9 Regression] Missing completion for a target option since r264052
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90258 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-26 Known to work||8.3.0 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0
[Bug target/90258] New: [9 Regression] Missing completion for a target option since r264052
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90258 Bug ID: 90258 Summary: [9 Regression] Missing completion for a target option since r264052 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Caused by my commit: $ gcc -mandroida /tmp/main.c gcc: error: unrecognized command line option ‘-mandroida’ While we should print: $ gcc -mandroida /tmp/main.c gcc: error: unrecognized command line option ‘-mandroida’; did you mean ‘-mandroid’?
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 Richard Biener changed: What|Removed |Added Priority|P1 |P2
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-04-26 Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- Thus, ppc folks - did you see a 8% peformance increase at the 2018-11-21 Uros Bizjak Revert the revert: 2013-10-26 Vladimir Makarov Revert: 2013-10-25 Vladimir Makarov * lra-spills.c (lra_final_code_change): Remove useless move insns. revision?
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #5 from Richard Biener --- So - is the regression of 8% compared to GCC 8? If only to some development branch revision then it doesn't count. As I read it the removed code in question only got added during GCC 9 stage3?
[Bug target/89504] Checking ICE in 'gcc.dg/rtl/x86_64/pro_and_epilogue.c'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89504 Vittorio Zecca changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #2 from Vittorio Zecca --- Is this one a duplicate of 79688 ?
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #4 from Richard Biener --- Let's revert the offending commit on the branch but keep it on trunk for further investigation. PR90178 was only a missed optimization.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #28 from Martin Liška --- I'm fine with having that in GCC 9.1 which will be released soon. Thus closing ..
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 --- Comment #3 from Richard Biener --- Created attachment 46250 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46250=edit run_fast_dce also for LRA Sth like this could fix it.
[Bug tree-optimization/90242] [UBSAN]: in vn_reference_compute_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90242 Vittorio Zecca changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #3 from Vittorio Zecca --- On this input file I got this one and two more undefined ~/local/gcc-270309-undefined/bin/gcc c-c++-common/Warray-bounds.c -S -O ../../gcc/gcc/poly-int.h:715:21: runtime error: signed integer overflow: 9223372036854775804 + 4 cannot be represented in type 'long int' ../../gcc/gcc/poly-int.h:753:21: runtime error: signed integer overflow: -9223372036854775807 * 8 cannot be represented in type 'long int' ../../gcc/gcc/cse.c:2215:34: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int' Optimization -O would do.
[Bug rtl-optimization/88879] [9/10 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879 Richard Biener changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #7 from Richard Biener --- Almost all SPEC 2000 tests still fail to build. Time to retire the IA64 port.
[Bug target/90204] [8/9/10 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 --- Comment #14 from rguenther at suse dot de --- On Fri, 26 Apr 2019, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 > > --- Comment #13 from Hongtao.liu --- > (In reply to rguent...@suse.de from comment #10) > > On Thu, 25 Apr 2019, crazylht at gmail dot com wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 > > > > > > --- Comment #9 from Hongtao.liu --- > > > Also what's better between aligned load/store of smaller size VS > > > unaligned > > > load/store of bigger size? > > > > > > aligned load/store of smaller size: > > > > > > movq%rdx, (%rdi) > > > movq-56(%rsp), %rdx > > > movq%rdx, 8(%rdi) > > > movq-48(%rsp), %rdx > > > movq%rdx, 16(%rdi) > > > movq-40(%rsp), %rdx > > > movq%rdx, 24(%rdi) > > > vmovq %xmm0, 32(%rax) > > > movq-24(%rsp), %rdx > > > movq%rdx, 40(%rdi) > > > movq-16(%rsp), %rdx > > > movq%rdx, 48(%rdi) > > > movq-8(%rsp), %rdx > > > movq%rdx, 56(%rdi) > > > > > > unaligned load/store of bigger size: > > > > > > vmovups %xmm2, (%rdi) > > > vmovups %xmm3, 16(%rdi) > > > vmovups %xmm4, 32(%rdi) > > > vmovups %xmm5, 48(%rdi) > > > > bigger stores are almost always a win while bigger loads have > > the possibility to run into store-to-load forwarding issues > > (and bigger stores eventually mitigate them). Based on > > CPU tuning we'd also eventually end up with mov[lh]ps splitting > > unaligned loads/stores. > > From > https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-optimization-reference-manual > > 14.6.3 Prefer Aligned Stores Over Aligned Loads > > Unaligned stores are likely to cause greater performance degradation than > unaligned loads, since there > is a very high penalty on stores to a split cache-line that crosses pages. > This > penalty is estimated at 150 > cycles. Loads that cross a page boundary are executed at retirement. That's a thing to keep in mind when peeling for alignment, but as a general rule for straight-line code the possibility of hitting a page boundary with an unaligned store is small while hitting STLF failure is more likely.
[Bug middle-end/89765] [9/10 Regression] Multiple problems with vec-insert implementation on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89765 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|ASSIGNED|NEW Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #10 from Richard Biener --- Not mine for the rest.
[Bug other/90257] [9/10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257 Richard Biener changed: What|Removed |Added Blocks||26163 Target Milestone|--- |9.2 Summary|8% degradation on cpu2006 |[9/10 Regression] 8% |403.gcc starting with |degradation on cpu2006 |r270484 |403.gcc starting with ||r270484 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)
