[Bug debug/86452] ICE in force_decl_die, at dwarf2out.c:25922 with -g1 and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86452 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Jul 13 06:42:31 2018 New Revision: 262624 URL: https://gcc.gnu.org/viewcvs?rev=262624&root=gcc&view=rev Log: 2018-07-13 Richard Biener PR debug/86452 * dwarf2out.c (gen_type_die_with_usage): Use scope_die_for instead of get_context_die. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug tree-optimization/86489] ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489 --- Comment #7 from kugan at gcc dot gnu.org --- Author: kugan Date: Fri Jul 13 05:25:47 2018 New Revision: 262622 URL: https://gcc.gnu.org/viewcvs?rev=262622&root=gcc&view=rev Log: gcc/ChangeLog: 2018-07-13 Kugan Vivekanandarajah Richard Biener PR middle-end/86489 * tree-ssa-loop-niter.c (number_of_iterations_popcount): Check that the loop latch destination where phi is defined. gcc/testsuite/ChangeLog: 2018-07-13 Kugan Vivekanandarajah PR middle-end/86489 * gcc.dg/pr86489.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr86489.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug tree-optimization/86259] [8/9 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #22 from Martin Sebor ---
In areas where the authors of the proposal find the standard open to
interpretation and when they feel it doesn't contradict the surveyed
implementation practice they tend to suggest to tighten the requirements on
implementations (I think they surveyed mainly Clang and GCC) to make code valid
that may be questionable today. Their implementation survey isn't
comprehensive and so in some cases they may be suggesting changes that would
invalidate some optimizations. It's not entirely clear to me that this is one
such case -- they may only be thinking of allocated storage and not auto/static
objects as suggested in 2.3.3 Q9b in N2263.
WG14 takes a different view from the authors: where we agree that the standard
is unclear we would like to tighten the requirements on programs to allow
better analysis, better optimization, and better detection of bugs. WG14 has
formed a study group to try to come up with the next revision of the proposal
that's closer to WG14's goal.
With respect to objects and their subobjects, the existing requirements are
sufficiently clear and existing practice shows that compilers have been relying
on those requirements for some time (GCC well over a decade). For example:
struct S { char a[4], b[4]; };
void f (struct S *p, int i)
{
if (i < 4) i = 4;
char b = p->b[0];
p->a[i] = 0;// assumed not to change p->b (undefined otherwise)
if (p->b[0] != b) // folded to false
__builtin_abort (); // eliminated
}
In function ‘f’:
warning: array subscript 4 is above array bounds of ‘char[4]’ [-Warray-bounds]
p->a[i] = 0;// assumed not to change p->b (undefined if it did)
^~~
;; Function f (f, funcdef_no=0, decl_uid=1960, cgraph_uid=0, symbol_order=0)
f (struct S * p, int i)
{
[local count: 1073741825]:
i_6 = MAX_EXPR ;
p_4(D)->a[i_6] = 0;
return;
}
Besides GCC, Intel ICC also performs the same optimization.
The test cases in this report are variations on this theme. The only
difference is that they use built-in functions to access the elements of the
distinct subobjects rather than accessing them directly. GCC has just extended
the optimization above to a subset of calls of built-in functions. Besides
strlen(), here's another example from GCC 7:
struct S { char a[4], b[4]; };
void f (struct S *p, int i)
{
int n = __builtin_snprintf (0, 0, "%s", p->a); // n must be between 0 and 3
if (n > 3) // folded to false
__builtin_abort ();// eliminated
}
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 --- Comment #8 from Matt Bentley --- > This is incorrect for floating point types and non scalars. And it > introduces an extra check at runtime if value is not known to compile time. This is the overload for scalar types, read the function description line. The extra check is negligible compared to the overhead caused by the alternative looping code vs memset, as is benchmarked above. I had to read up on how floating-point is implementation-defined, so yes you're right, the specialization would have to be further constricted to integral and scalar pointer types using __is_integral_helper & __is_scalar. Whether the commonality of zero-wiping newly allocated arrays outweights the overhead of an additional check for non-zero fills, is a good question.
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #7 from Andrew Pinski ---
(In reply to Matt Bentley from comment #6)
> Suggested patch for libstdc++, std_algobase.h, line 688:
> template
> inline typename
> __gnu_cxx::__enable_if<__is_scalar<_Tp>::__value, void>::__type
> __fill_a(_ForwardIterator __first, _ForwardIterator __last,
>const _Tp& __value)
> {
> if (__value != reinterpret_cast<_Tp>(0))
> {
> const _Tp __tmp = __value;
> for (; __first != __last; ++__first)
> *__first = __tmp;
> }
> else
> {
> if (const size_t __len = __last - __first)
> __builtin_memset(reinterpret_cast(__first), 0, __len *
> sizeof(_Tp));
> }
> }
>
> Comments?
This is incorrect for floating point types and non scalars. And it introduces
an extra check at runtime if value is not known to compile time.
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #6 from Matt Bentley ---
Suggested patch for libstdc++, std_algobase.h, line 688:
template
inline typename
__gnu_cxx::__enable_if<__is_scalar<_Tp>::__value, void>::__type
__fill_a(_ForwardIterator __first, _ForwardIterator __last,
const _Tp& __value)
{
if (__value != reinterpret_cast<_Tp>(0))
{
const _Tp __tmp = __value;
for (; __first != __last; ++__first)
*__first = __tmp;
}
else
{
if (const size_t __len = __last - __first)
__builtin_memset(reinterpret_cast(__first), 0, __len *
sizeof(_Tp));
}
}
Comments?
[Bug tree-optimization/86259] [8/9 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #21 from Davin McCall ---
Looking at this further, the proposal actually states, for the address-of
operator:
> When the operand designates an object, the result has the single provenance
> of the outermost object containing that object.
That's "outermost" object; it implies that taking the address of an
inner/contained object, and manipulating it to point at other parts of the
containing object, should actually be fine (adding an integer offset with empty
provenance should not affect the provenance of the pointer, according to the
proposal). Martin Sebor: doesn't that contradict what you said in comment #8 ?
In any case it seems it should allow the case I was concerned about, i.e
calculating the containing object address from a contained object address.
While we can agree that it is anyway not allowed to advance a pointer past the
end of an array, including an "array" consisting of a single object not
actually declared as an array, surely casting the pointer to an integer type
should get around that problem - but doesn't, in the program below, for which
GCC 8.1 bizarrely generates code that prints "NO" (indicating that it has
determined that len != 7) and then returns 7 (indicating that len == 7).
Clearly this could only be "correct" if there is undefined behaviour - though
it is somewhat bad handling even then - however I cannot see the U.B. in this
program and no warnings are generated (which is at least a QOI issue). Note
that by the provenance proposal the 'sp_ip' variable should have the provenance
of the containing object, 'u', and so when cast to char * should be perfectly
capable of navigating the entire union object:
---8>---
#include
#include
#include
#include
struct S {
char a[4];
char b[4];
char c[4];
};
union U {
struct S s;
char xx[12];
};
int main()
{
union U u;
u.s = (struct S){0, 0, 0};
char *bp = u.s.b;
uintptr_t sp_ip = (uintptr_t)bp - offsetof(struct S,b);
strcpy(u.xx, "abcdefghijk");
size_t len = strlen((char *)(union U *)sp_ip + 4);
puts(len == 7 ? "YES" : "NO");
return len;
}
---<8---
[Bug testsuite/86510] [9 regression] test case g++.dg/warn/pr86453.C fails starting with r262596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86510 --- Comment #1 from Martin Sebor --- Author: msebor Date: Thu Jul 12 22:42:00 2018 New Revision: 262609 URL: https://gcc.gnu.org/viewcvs?rev=262609&root=gcc&view=rev Log: PR testsuite/86510 - test case g++.dg/warn/pr86453.C fails starting with r262596 gcc/testsuite/ChangeLog: g++.dg/warn/pr86453.C: Adjust. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/pr86453.C
[Bug testsuite/86510] [9 regression] test case g++.dg/warn/pr86453.C fails starting with r262596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86510 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Test adjusted in r262609. Thanks.
[Bug middle-end/86511] Unordered comparisons are expanded with branchless code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86511 Andrew Pinski changed: What|Removed |Added Target|alphaev68-linux-gnu | --- Comment #1 from Andrew Pinski --- Doesn't GCC 9 default to -fno-trapping-math now? (if so the documentation needs to be fixed)?
[Bug middle-end/86511] New: Unordered comparisons are expanded with branchless code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86511
Bug ID: 86511
Summary: Unordered comparisons are expanded with branchless
code
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following testcase:
--cut here--
#include
extern void abort (void);
extern void exit (int);
volatile double x = __builtin_nan ("");
volatile int i;
int
main (void)
{
i = !__builtin_isless (x, 1.0);
if (fetestexcept (FE_INVALID))
abort ();
}
--cut here--
compiles for alphaev68-linux-gnu (-O2 -mieee) to brachless code:
cvtsts $f12,$f11
cmptun/su $f10,$f11,$f12
ftoit $f12,$2
>> cmptle/su $f11,$f10,$f12
cmpult $31,$2,$2
ftoit $f12,$1
cmovne $1,1,$2
bis $31,$2,$1
ldq $2,i($29) !literal
where cmptle generates unwanted exception and the testcase aborts.
gcc-7.3.0 generates:
cvtsts $f12,$f11
trapb
cmptun/su $f10,$f11,$f12
trapb
fbne $f12,$L2
cmptle/su $f11,$f10,$f12
trapb
fbeq $f12,$L5
$L2:
ldq $2,i($29) !literal
which avoids cmptle for unordered arguments.
Both compilers generate following _.optimized tree dump:
x.0_1 ={v} x;
_2 = x.0_1 u>= 1.0e+0;
_3 = (int) _2;
i ={v} _3;
gcc-9 expands to branchless code:
...
(insn 14 13 15 2 (set (reg:SF 87)
(mem/u/c:SF (lo_sum:DI (reg:DI 86)
(symbol_ref/u:DI ("*$LC1") [flags 0x2])) [0 S4 A32]))
"inf-compare-7.c":16 211 {*movsf}
(nil))
(insn 15 14 16 2 (set (reg:DF 85)
(float_extend:DF (reg:SF 87))) "inf-compare-7.c":16 144
{*extendsfdf2_ieee}
(expr_list:REG_EQUAL (const_double:DF 1.0e+0 [0x0.8p+1])
(nil)))
(insn 16 15 17 2 (set (reg:DF 90)
(unordered:DF (reg:DF 70 [ x.0_1 ])
(reg:DF 85))) "inf-compare-7.c":16 176 {*cmpdf_internal}
(nil))
(insn 17 16 18 2 (set (reg:DI 89)
(ne:DI (subreg:DI (reg:DF 90) 0)
(const_int 0 [0]))) "inf-compare-7.c":16 149 {*setne_internal}
(nil))
(insn 18 17 19 2 (set (reg:SI 88)
(subreg:SI (reg:DI 89) 0)) "inf-compare-7.c":16 214 {*movsi}
(nil))
(insn 19 18 20 2 (set (reg:DI 92)
(high:DI (symbol_ref/u:DI ("*$LC1") [flags 0x2]))) "inf-compare-7.c":16
221 {*movdi}
(nil))
(insn 20 19 21 2 (set (reg:SF 93)
(mem/u/c:SF (lo_sum:DI (reg:DI 92)
(symbol_ref/u:DI ("*$LC1") [flags 0x2])) [0 S4 A32]))
"inf-compare-7.c":16 211 {*movsf}
(nil))
(insn 21 20 22 2 (set (reg:DF 91)
(float_extend:DF (reg:SF 93))) "inf-compare-7.c":16 144
{*extendsfdf2_ieee}
(expr_list:REG_EQUAL (const_double:DF 1.0e+0 [0x0.8p+1])
(nil)))
(insn 22 21 23 2 (set (reg:DF 94)
(le:DF (reg:DF 91)
(reg:DF 70 [ x.0_1 ]))) "inf-compare-7.c":16 176 {*cmpdf_internal}
(nil))
(insn 23 22 24 2 (set (reg:SI 76)
(if_then_else:SI (ne (subreg:DI (reg:DF 94) 0)
(const_int 0 [0]))
(const_int 1 [0x1])
(reg:SI 88))) "inf-compare-7.c":16 152 {*movsicc_internal}
(nil))
...
where gcc-7 expands to:
...
(insn 21 20 22 2 (set (reg:SF 97)
(mem/u/c:SF (lo_sum:DI (reg:DI 96)
(symbol_ref/u:DI ("*$LC1") [flags 0x2])) [2 S4 A32]))
"inf-compare-7.c":16 230 {*movsf}
(nil))
(insn 22 21 23 2 (set (reg:DF 95)
(float_extend:DF (reg:SF 97))) "inf-compare-7.c":16 161
{*extendsfdf2_ieee}
(expr_list:REG_EQUAL (const_double:DF 1.0e+0 [0x0.8p+1])
(nil)))
(insn 23 22 24 2 (set (reg:DF 98)
(unordered:DF (reg:DF 70 [ x.0_1 ])
(reg:DF 95))) "inf-compare-7.c":16 194 {*cmpdf_ieee}
(nil))
(jump_insn 24 23 53 2 (set (pc)
(if_then_else (ne:CC (reg:DF 98)
(const_double:DF 0.0 [0x0.0p+0]))
(label_ref 31)
(pc))) "inf-compare-7.c":16 205 {*fbcc_normal}
(int_list:REG_BR_PROB 100 (nil))
-> 31)
;; succ: 6 [1.0%]
;; 4 [99.0%] (FALLTHRU)
;; basic block 4, loop depth 0, count 0, freq 9900, maybe hot
;; prev block 2, next block 5, flags: (NEW, REACHABLE, RTL, MODIFIED)
;; pred: 2 [99.0%] (FALLTHRU)
(note 53 24 25 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 25 53 26 4 (set (reg:DI 100)
(high:DI (symbol_ref/u:DI ("*$LC1") [flags 0x2]))) "inf-compare-7.c":16
240 {*movdi}
(nil))
(insn 26 25 27 4 (set (reg:SF 101)
(mem/u/c:SF (lo_sum:DI (reg:DI 100)
(symbol_ref/u:DI ("*$LC1") [flags 0x2])) [2 S4 A32]))
"inf-compare-7.c":16 230 {*movsf}
(nil))
(insn 27 26 28 4 (set (reg:DF 99)
(float_extend:DF (reg:SF 101))) "inf-compare-7.c":16 161
{*extendsfdf2_ieee}
(expr_list:REG_EQUAL (const_double:DF 1.0e+0 [0x0.8p+1])
(nil)))
(insn 28 27 29 4 (set (reg:DF 102)
[Bug tree-optimization/86509] Invalid conversion of comparison with infinity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86509 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Uroš Bizjak --- The regression is actually in the middle-end, I'll open a new PR.
[Bug c++/86503] Segmentation fault signal terminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86503 --- Comment #2 from Jonathan Wakely --- (In reply to Richard Biener from comment #1) > You run out of memory or stack. Try ulimit -s unlimited Yes but that seems to be because GCC goes into an infinte recursive instantiation, which it shouldn't do.
[Bug libstdc++/86507] std::filesystem not work on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86507 --- Comment #3 from Jonathan Wakely --- (In reply to tower120 from comment #0) > All 7.x with > "experimental/filesystem" worked fine. Are you sure about that? You might be able to include the header, but nothing else works. Anyway, this is an exact duplicate of PR 85670, which was already fixed by PR 78870.
[Bug testsuite/86510] New: [9 regression] test case g++.dg/warn/pr86453.C fails starting with r262596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86510 Bug ID: 86510 Summary: [9 regression] test case g++.dg/warn/pr86453.C fails starting with r262596 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- make -k check-gcc RUNTESTFLAGS=dg.exp=g++.dg/warn/pr86453.C . . . # of unexpected failures6 FAIL: g++.dg/warn/pr86453.C -std=c++98 (test for warnings, line 4) FAIL: g++.dg/warn/pr86453.C -std=c++98 (test for excess errors) FAIL: g++.dg/warn/pr86453.C -std=c++11 (test for warnings, line 4) FAIL: g++.dg/warn/pr86453.C -std=c++11 (test for excess errors) FAIL: g++.dg/warn/pr86453.C -std=c++14 (test for warnings, line 4) FAIL: g++.dg/warn/pr86453.C -std=c++14 (test for excess errors) Does this test case need updating witht he changes made in r262596? spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/pr86453.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++98 -pedantic-errors -Wno-long-long -flto -S -o pr86453.s /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/pr86453.C:4:44: warning: ignoring attribute 'packed' because it conflicts with attribute 'aligned' [-Wattributes] FAIL: g++.dg/warn/pr86453.C -std=c++98 (test for warnings, line 4) FAIL: g++.dg/warn/pr86453.C -std=c++98 (test for excess errors) Excess errors: /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/pr86453.C:4:44: warning: ignoring attribute 'packed' because it conflicts with attribute 'aligned' [-Wattributes] Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/pr86453.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++11 -pedantic-errors -Wno-long-long -flto -S -o pr86453.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/pr86453.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++11 -pedantic-errors -Wno-long-long -flto -S -o pr86453.s /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/pr86453.C:4:44: warning: ignoring attribute 'packed' because it conflicts with attribute 'aligned' [-Wattributes] FAIL: g++.dg/warn/pr86453.C -std=c++11 (test for warnings, line 4) FAIL: g++.dg/warn/pr86453.C -std=c++11 (test for excess errors) Excess errors: /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/pr86453.C:4:44: warning: ignoring attribute 'packed' because it conflicts with attribute 'aligned' [-Wattributes] Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/pr86453.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++14 -pedantic-errors -Wno-long-long -flto -S -o pr86453.s(timeout = 300) spawn -ignore SIGHUP /home/seurer
[Bug tree-optimization/86509] Invalid conversion of comparison with infinity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86509
--- Comment #1 from Uroš Bizjak ---
Ops, no, the above is with gcc-7.3.
gcc-9 correctly emits:
x.0_1 ={v} x;
_2 = x.0_1 u<=
1.79769313486231570814527423731704356798070567525844996599e+308;
_3 = (int) _2;
i ={v} _3;
_4 = fetestexcept (131072);
which is later compiled to branchless code:
cmptun/su $f11,$f10,$f12
ftoit $f12,$2
cmptle/su $f11,$f10,$f12
cmpult $31,$2,$2
ftoit $f12,$1
cmovne $1,1,$2
Unfortunately, cmptle generates exception, so the testcase aborts.
[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43064 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #8 from David Malcolm --- Looks like we're passing plain INTEGER_CST nodes around in initializers. Extending the location wrapper code to wrap all such constants (and not just in function call params like in GCC 8) might well fix this. Or maybe just extend it to initializers.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490
--- Comment #9 from zenith432 at users dot sourceforge.net ---
It is worth studying what gold is doing, because it's not just skipping the
object files in the archives.
If you link with
gcc -flto -save-temps -fuse-ld=gold -o x main.o libfoo.a libbar.a
The res file shows resolutions only for main.o.
Now link with
gcc -flto -save-temps -fuse-ld=gold -u bar -o x main.o libfoo.a libbar.a
The res file shows resolutions for main.o and exactly one of libfoo.a or
libbar.a.
Now add definitions as follows
void f1() {} to foo.c
void f2() {} to bar.c
so you can tell them apart.
Now link with
gcc -flto -save-temps -fuse-ld=gold -u f1 -o x main.o libfoo.a libbar.a
gcc -flto -save-temps -fuse-ld=gold -u f2 -o x main.o libfoo.a libbar.a
each time, the resolution file shows gold resolving just one of the .a files
which was requested with the -u.
Now link with
gcc -flto -save-temps -fuse-ld=gold -u f1 -u f2 -o x main.o libfoo.a libbar.a
to link all in.
This does give an error, but it's a gold error for multiple defs, not an lto1
error for multiple prevailing defs. Look at the res file you'll see
resolutions for all three input files, but there is just one prevailing def for
symbol bar - the other instance of bar gets resolution PREEMPTED_IR.
[Bug tree-optimization/86509] New: Invalid conversion of comparison with infinity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86509
Bug ID: 86509
Summary: Invalid conversion of comparison with infinity
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following testcase, derived from testsuite/gcc.dg/torture/inf-compare-7.c fails
on alpha due to invalid conversion of (NaN != Infinity) to (NaN < Infinity):
--cut here--
#include
extern void abort (void);
extern void exit (int);
volatile double x = __builtin_nan ("");
volatile int i;
int
main (void)
{
i = x != __builtin_inf ();
if (fetestexcept (FE_INVALID))
abort ();
}
--cut here--
The _.optimized tree dump shows:
x.0_1 ={v} x;
_2 = x.0_1 > 1.79769313486231570814527423731704356798070567525844996599e+308;
_3 = ~_2;
_4 = (int) _3;
i ={v} _4;
and the comparison gets compiled to:
cmptlt/su $f12,$f11,$f10
Please note that cmptlt and cmptle insns trap with NaN argument, while cmpteq
and cmptun don't.
Please note that when using:
i = x != 1e308;
compiler compiles via:
x.0_1 ={v} x;
_2 = x.0_1 !=
1.1097906362944045541740492309677311846337e+308;
_3 = (int) _2;
i ={v} _3;
to
cmpteq/su $f12,$f11,$f10
which doesn't trap.
[Bug middle-end/85974] [8/9 Regression] Failure to optimize difference of two pointers into a compile time constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85974
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #4 from Martin Sebor ---
The optimization aside, the code in the test violates the C constraint that:
When two pointers are subtracted, both shall point to elements of the same
array object, or one past the last element of the array object; ...
Since s.f and s.b and distinct arrays (with s.b being treated as an array of
one element), the behavior of the test case is undefined. GCC should diagnose
it before some optimization relies on code not doing these kinds of bad things
(as we have seen recently in bug 86259).
A valid (and more straightforward) way of writing the same code is:
struct S
{
char a, b, f[3];
} s;
long i = offsetof (struct S, f) - offsetof (struct S, b);
or (for the purposes of testing):
long i = ((char*)&s + offsetof (struct S, f)) - (char*)&s + offsetof (struct
S, b));
[Bug c/53769] [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #7 from Florian Weimer --- Furthermore, if I don't misread the standard, the expectation is that if an implementation does not support threads, it still recognizes _Thread_local and mostly ignores it, so that it is available even if __STDC_NO_THREADS__ is not defined. (Which is of course rather dodgy if you need to conform to an existing ABI for thread-local variables, so I think the committee made a mistake here.) __STDC_NO_THREADS__ only reflects the existence of the and nothing else.
[Bug middle-end/86508] New: missing -Wattributes on an ignored attempt to reduce struct alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86508
Bug ID: 86508
Summary: missing -Wattributes on an ignored attempt to reduce
struct alignment
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC silently accepts the defintion of the struct below but ignores the
attribute because it attempts to relax its alignment.
$ cat x.c && gcc -S -Wall -Wextra -m32 x.c
#define A 2
struct __attribute__ ((aligned (A))) S
{
int *p;
} s;
_Static_assert (_Alignof (s) == A, "#1");
x.c:8:1: error: static assertion failed: "#1"
_Static_assert (_Alignof (s) == A, "#1");
^~
GCC does diagnose the failed attempt with the _Alignas specifier, though G++
not only fails to diagnose it but also honors it and decrease the struct's
alignment.
Intel ICC issues a helpful message here:
warning #1366: a reduction in alignment without the "packed" attribute is
ignored
struct __attribute__ ((aligned (A))) S
[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.4.1, 7.3.1, 8.1.1, 9.0 Resolution|--- |FIXED Known to fail||6.4.0, 7.3.0, 8.1.0 --- Comment #20 from Richard Biener --- Fixed everywhere.
[Bug c++/86190] [6/7/8/9 Regression] -Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug middle-end/85974] [8/9 Regression] Failure to optimize difference of two pointers into a compile time constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85974 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.2 --- Comment #3 from Richard Biener --- Mine.
[Bug rtl-optimization/85645] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||8.1.1, 9.0 Target Milestone|--- |7.4 Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |maybe_record_trace_start, |maybe_record_trace_start, |at dwarf2cfi.c:2348 |at dwarf2cfi.c:2348 Known to fail||8.1.0
[Bug target/85593] [6/7/8/9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5 Summary|[6,7,8,9 Regression] GCC on |[6/7/8/9 Regression] GCC on |ARM allocates R3 for local |ARM allocates R3 for local |variable when calling naked |variable when calling naked |function with O2|function with O2 |optimizations enabled |optimizations enabled
[Bug c++/85569] [8/9 Regression] is_invocable(F, decltype(objs)...) fails with "not supported by dump_expr#" unless via indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85569 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.2
[Bug tree-optimization/84362] [7/8/9 Regression] Auto-vectorization regression when accessing member variable through getter/accessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84362 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.4 --- Comment #3 from Richard Biener --- I will take a look.
[Bug fortran/85352] [6/7/8/9 Regression] Incorrect error diagnosed for dummy argument used in specification expression to subprogram with ENTRY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85352 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43064 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #6) > If I remember correctly, the problem here is constants and other > non-expression nodes don't have a location, so diagnostics use > input_location, which points to the end of the initializer. Something like > X+1 should work. > > If so, David started fixing this problem cc-ing him then.
[Bug target/82092] [8/9 regression] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.2
[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 --- Comment #6 from Eric Gallager --- (In reply to Will Hawkins from comment #5) > I am using this as a jumping-off point to get involved with contributing > code to gcc. I have nothing to offer yet, but I wanted to note here that I > am going to start looking into this. > > Will OK cool, do you want to be the assignee then?
[Bug target/81497] [7 Regression] error compiling arm_acle.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81497 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||8.1.1 Target Milestone|--- |7.4 Summary|[7/8 Regression] error |[7 Regression] error |compiling arm_acle.h|compiling arm_acle.h
[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829 --- Comment #19 from Richard Biener --- Author: rguenth Date: Thu Jul 12 16:33:26 2018 New Revision: 262598 URL: https://gcc.gnu.org/viewcvs?rev=262598&root=gcc&view=rev Log: 2018-07-12 Richard Biener PR target/84829 * config/gnu-user.h (GNU_USER_TARGET_NO_PTHREADS_LIB_SPEC): Remove -mieee-fp handling. * gcc.target/i386/pr84829.c: New testcase. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr84829.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/gnu-user.h branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829 --- Comment #18 from Richard Biener --- Author: rguenth Date: Thu Jul 12 16:29:50 2018 New Revision: 262597 URL: https://gcc.gnu.org/viewcvs?rev=262597&root=gcc&view=rev Log: 2018-07-12 Richard Biener PR target/84829 * config/gnu-user.h (GNU_USER_TARGET_NO_PTHREADS_LIB_SPEC): Remove -mieee-fp handling. * gcc.target/i386/pr84829.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr84829.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/gnu-user.h branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c/86453] [8 Regression] error: type variant differs by TYPE_PACKED in free_lang_data since r255469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86453 --- Comment #13 from Martin Sebor --- Author: msebor Date: Thu Jul 12 16:21:06 2018 New Revision: 262596 URL: https://gcc.gnu.org/viewcvs?rev=262596&root=gcc&view=rev Log: PR c/86453 - error: type variant differs by TYPE_PACKED in free_lang_data since r255469 gcc/ChangeLog: PR c/86453 * attribs.c (decl_attributes): Reject conflicting attributes before calling attribute handlers. gcc/testsuite/ChangeLog: PR c/86453 * c-c++-common/Wattributes.c: Adjust. * gcc.dg/Wattributes-10.c: New test. * g++.dg/Wattributes-3.C: Adjust. * gcc.dg/Wattributes-6.c: Adjust. * gcc.dg/pr18079.c: Adjust. * gcc.dg/torture/pr42363.c: Adjust. Added: trunk/gcc/testsuite/gcc.dg/Wattributes-10.c Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Wattributes.c trunk/gcc/testsuite/g++.dg/Wattributes-3.C trunk/gcc/testsuite/gcc.dg/Wattributes-6.c trunk/gcc/testsuite/gcc.dg/pr18079.c trunk/gcc/testsuite/gcc.dg/torture/pr42363.c
[Bug ipa/86436] IPA-ICF: miissed optimization at class template member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86436 --- Comment #2 from petschy at gmail dot com --- Folding instantiations of member functions of class templates is a low hanging fruit IMHO. So if they are not handled ATM, then consider this ticket as a feature request, rather than a bug.
[Bug tree-optimization/86506] [9 Regression] tree-vect-patterns.c:225: shift too large for type ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86506 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-12 Component|c |tree-optimization Version|8.0 |9.0 Target Milestone|--- |9.0 Summary|tree-vect-patterns.c:225: |[9 Regression] |shift too large for type ? |tree-vect-patterns.c:225: ||shift too large for type ? Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- .
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 Andrew Pinski changed: What|Removed |Added CC||tower120 at gmail dot com --- Comment #29 from Andrew Pinski --- *** Bug 86507 has been marked as a duplicate of this bug. ***
[Bug libstdc++/86507] std::filesystem not work on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86507 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- This is a dup of bug 78870 which is/being fixed for GCC 9.x. *** This bug has been marked as a duplicate of bug 78870 ***
[Bug tree-optimization/86489] ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489
sudi at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2018-7-12
CC||sudi at gcc dot gnu.org
--- Comment #6 from sudi at gcc dot gnu.org ---
(In reply to kugan from comment #1)
> Sorry about the breakage, I am trying to reproduce it on x86-64. Please let
> me know if you have testcase.
This can reproduce the failure:
int a = 0, b = 0;
void fn1() {
int c = 0;
for (; a; a--)
c += b;
while ((c - 1) & c)
;
}
[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86004 --- Comment #8 from seurer at gcc dot gnu.org --- *** Bug 86496 has been marked as a duplicate of this bug. ***
[Bug lto/86496] [9 regression] plugin required to handle lto object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86496 seurer at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from seurer at gcc dot gnu.org --- Argh. I searched for that other bug report via the failing file names but couldn't find it and thus doubted my own vague memory of it. *** This bug has been marked as a duplicate of bug 86004 ***
[Bug c++/86374] [8/9 regression] template member name lookup problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86374 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED CC||nathan at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug tree-optimization/86489] ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489 --- Comment #5 from Pat Haugen --- (In reply to kugan from comment #3) > index f6fa2f7..fbdf838 100644 > --- a/gcc/tree-ssa-loop-niter.c > +++ b/gcc/tree-ssa-loop-niter.c > @@ -2555,6 +2555,7 @@ number_of_iterations_popcount (loop_p loop, edge exit, > ... = PHI . */ >gimple *phi = SSA_NAME_DEF_STMT (b_11); >if (gimple_code (phi) != GIMPLE_PHI > + || (gimple_bb (phi) != loop_latch_edge (loop)->dest) >|| (gimple_assign_lhs (and_stmt) > != gimple_phi_arg_def (phi, loop_latch_edge (loop)->dest_idx))) > return false; This fixes the problem for me.
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 --- Comment #18 from Wilco --- (In reply to niva from comment #17) > (In reply to Wilco from comment #16) > > (In reply to niva from comment #15) > > > (In reply to Vladimir Makarov from comment #14) > ... > > If you implement the hook like I did on AArch64 then the problem is worked > > around reasonably. > : > Do you mean the hook TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS? > > Actually we are using the mips target where this hook is > already present. Is this enough? Yes on MIPS it should work fine.
[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 Matthias Klose changed: What|Removed |Added CC||doko at debian dot org --- Comment #9 from Matthias Klose --- please see https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa for more recent builds.
[Bug target/84413] [8/9 Regression] -mtune=skylake,skylake-avx512,cannonlake,icelake disable many optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84413 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-12 Summary|-mtune=skylake,skylake-avx5 |[8/9 Regression] |12,cannonlake,icelake |-mtune=skylake,skylake-avx5 |disable many optimizations |12,cannonlake,icelake ||disable many optimizations Ever confirmed|0 |1
[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829 --- Comment #17 from Richard Biener --- Author: rguenth Date: Thu Jul 12 12:47:48 2018 New Revision: 262584 URL: https://gcc.gnu.org/viewcvs?rev=262584&root=gcc&view=rev Log: 2018-07-12 Richard Biener PR target/84829 * config/gnu-user.h (GNU_USER_TARGET_NO_PTHREADS_LIB_SPEC): Remove -mieee-fp handling. * gcc.target/i386/pr84829.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr84829.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/gnu-user.h branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug debug/86462] [9 Regression] Quite huge debug info size increase introduced in r262511
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86462 --- Comment #6 from Richard Biener --- Author: rguenth Date: Thu Jul 12 12:32:30 2018 New Revision: 262583 URL: https://gcc.gnu.org/viewcvs?rev=262583&root=gcc&view=rev Log: 2018-07-12 Richard Biener PR debug/86462 * dwarf2out.c (gen_block_die): Only output blocks when they have at least one !DECL_IGNORED_P variable. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug debug/86462] [9 Regression] Quite huge debug info size increase introduced in r262511
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86462 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug libstdc++/86507] std::filesystem not work on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86507 --- Comment #1 from tower120 --- Created attachment 44388 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44388&action=edit compilation error message
[Bug libstdc++/86507] New: std::filesystem not work on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86507
Bug ID: 86507
Summary: std::filesystem not work on Windows
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tower120 at gmail dot com
Target Milestone: ---
Just including "filesystem" header on gcc 8.1 under windows (mingw-w64) cause
compilation error. See attached file. All 7.x with "experimental/filesystem"
worked fine.
#include
int main() {
return 0;
}
Problem code here:
bits/fs_path.h
#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
if (__p.is_absolute()
|| (__p.has_root_name() && __p.root_name() != root_name()))
operator=(__p);
error: no match for 'operator!=' (operand types are
'std::filesystem::__cxx11::path' and 'std::filesystem::__cxx11::path')
[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 Richard Biener changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #8 from Richard Biener --- (In reply to Jonny Grant from comment #7) > (In reply to rguent...@suse.de from comment #6) > > On Thu, 12 Jul 2018, jg at jguk dot org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 > > > > > > --- Comment #5 from Jonny Grant --- > > > Richard, > > > Ok I will have a look at that soon... > > > > > > Could I ask, do you know if GCC already has dwarf sanity checks when > > > outputting > > > .debug_str size to check offsets are not larger than the size? > > > > It does have a lot of sanity checks but I don't remember any specific > > one for offsets into sections. > > Would be good to add some sanity checks.. offsets into a buffer are always > risky... It's not so easy given the assembler is involved here, too. > > Note you are using a pre-release of GCC 8.1 so maybe make sure to update > > that. > > > > What version of binutils are you using? > > $ ld --version > GNU ld (GNU Binutils for Ubuntu) 2.30 good > yes, I'm using 8.0.1 from Ubuntu.. wish distros had latest releases of > things like GCC... I'm pretty sure Ubuntu has packages for GCC 8.1[.1]
[Bug tree-optimization/86489] ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489 --- Comment #4 from Richard Biener --- (In reply to kugan from comment #3) > (In reply to Richard Biener from comment #2) > > gimple *phi = SSA_NAME_DEF_STMT (b_11); > > if (gimple_code (phi) != GIMPLE_PHI > > || (gimple_assign_lhs (and_stmt) > > != gimple_phi_arg_def (phi, loop_latch_edge (loop)->dest_idx))) > > return false; > > > > this may fail if the PHI in question is not the correct one in which case > > it may not have the argument at the latch dest_idx. Try first verifying > > that the loop latch destination is indeed gimple_bb (phi). > > yes, thanks for spotting. I am testing the following patch: > > diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c > index f6fa2f7..fbdf838 100644 > --- a/gcc/tree-ssa-loop-niter.c > +++ b/gcc/tree-ssa-loop-niter.c > @@ -2555,6 +2555,7 @@ number_of_iterations_popcount (loop_p loop, edge exit, > ... = PHI . */ >gimple *phi = SSA_NAME_DEF_STMT (b_11); >if (gimple_code (phi) != GIMPLE_PHI > + || (gimple_bb (phi) != loop_latch_edge (loop)->dest) >|| (gimple_assign_lhs (and_stmt) > != gimple_phi_arg_def (phi, loop_latch_edge (loop)->dest_idx))) > return false; > > is checking that there is argument at the latch dest_idx (argument count of > PHI) is still necessary? No, the number of edges determines that. The above patch is OK if it bootstraps/tests OK. Richard.
[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 --- Comment #7 from Jonny Grant --- (In reply to rguent...@suse.de from comment #6) > On Thu, 12 Jul 2018, jg at jguk dot org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 > > > > --- Comment #5 from Jonny Grant --- > > Richard, > > Ok I will have a look at that soon... > > > > Could I ask, do you know if GCC already has dwarf sanity checks when > > outputting > > .debug_str size to check offsets are not larger than the size? > > It does have a lot of sanity checks but I don't remember any specific > one for offsets into sections. Would be good to add some sanity checks.. offsets into a buffer are always risky... > Note you are using a pre-release of GCC 8.1 so maybe make sure to update > that. > > What version of binutils are you using? $ ld --version GNU ld (GNU Binutils for Ubuntu) 2.30 yes, I'm using 8.0.1 from Ubuntu.. wish distros had latest releases of things like GCC...
[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 --- Comment #6 from rguenther at suse dot de --- On Thu, 12 Jul 2018, jg at jguk dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 > > --- Comment #5 from Jonny Grant --- > Richard, > Ok I will have a look at that soon... > > Could I ask, do you know if GCC already has dwarf sanity checks when > outputting > .debug_str size to check offsets are not larger than the size? It does have a lot of sanity checks but I don't remember any specific one for offsets into sections. Note you are using a pre-release of GCC 8.1 so maybe make sure to update that. What version of binutils are you using?
[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829 --- Comment #16 from Richard Biener --- Author: rguenth Date: Thu Jul 12 11:53:34 2018 New Revision: 262582 URL: https://gcc.gnu.org/viewcvs?rev=262582&root=gcc&view=rev Log: 2018-07-12 Richard Biener PR target/84829 * config/gnu-user.h (GNU_USER_TARGET_NO_PTHREADS_LIB_SPEC): Remove -mieee-fp handling. * gcc.target/i386/pr84829.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr84829.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/gnu-user.h trunk/gcc/testsuite/ChangeLog
[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 --- Comment #5 from Jonny Grant --- Richard, Ok I will have a look at that soon... Could I ask, do you know if GCC already has dwarf sanity checks when outputting .debug_str size to check offsets are not larger than the size?
[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 --- Comment #4 from Richard Biener --- (In reply to Jonny Grant from comment #3) > Hello Richard > It's commercial source code that can't be disclosed. > Is there another way to create a test case which has the same issue? a lot > of debug information? You may want to look at https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction which talks about how to reduce a testcase. In particular getting the number of input objects reduced by using -r at link time may help (if the bug reproduces then...). If you manage to reduce to a single input source you can use standard reduction tools like creduce or delta to reduce (and obfuscate) the testcase.
[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 --- Comment #3 from Jonny Grant --- Hello Richard It's commercial source code that can't be disclosed. Is there another way to create a test case which has the same issue? a lot of debug information?
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 --- Comment #17 from niva at niisi dot msk.ru --- (In reply to Wilco from comment #16) > (In reply to niva from comment #15) > > (In reply to Vladimir Makarov from comment #14) ... > If you implement the hook like I did on AArch64 then the problem is worked > around reasonably. : Do you mean the hook TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS? Actually we are using the mips target where this hook is already present. Is this enough?
[Bug tree-optimization/86489] ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489 --- Comment #3 from kugan at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) > gimple *phi = SSA_NAME_DEF_STMT (b_11); > if (gimple_code (phi) != GIMPLE_PHI > || (gimple_assign_lhs (and_stmt) > != gimple_phi_arg_def (phi, loop_latch_edge (loop)->dest_idx))) > return false; > > this may fail if the PHI in question is not the correct one in which case > it may not have the argument at the latch dest_idx. Try first verifying > that the loop latch destination is indeed gimple_bb (phi). yes, thanks for spotting. I am testing the following patch: diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c index f6fa2f7..fbdf838 100644 --- a/gcc/tree-ssa-loop-niter.c +++ b/gcc/tree-ssa-loop-niter.c @@ -2555,6 +2555,7 @@ number_of_iterations_popcount (loop_p loop, edge exit, ... = PHI . */ gimple *phi = SSA_NAME_DEF_STMT (b_11); if (gimple_code (phi) != GIMPLE_PHI + || (gimple_bb (phi) != loop_latch_edge (loop)->dest) || (gimple_assign_lhs (and_stmt) != gimple_phi_arg_def (phi, loop_latch_edge (loop)->dest_idx))) return false; is checking that there is argument at the latch dest_idx (argument count of PHI) is still necessary?
[Bug target/86497] [8/9 regression] wasted instructions for x86 float x!=x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86497 --- Comment #3 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #2) > Started with r254167, so maybe related to PR84251. Yes, it is the same issue. As said in PR84251, we have to wrap COMPARE into UNSPEC, so this defeats some passes (in this case fwprop1 pass) that look at RTX code of the pattern.
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #16 from Wilco --- (In reply to niva from comment #15) > (In reply to Vladimir Makarov from comment #14) > > Author: vmakarov > > Date: Thu May 14 20:40:44 2015 > > New Revision: 223202 > > > > URL: https://gcc.gnu.org/viewcvs?rev=223202&root=gcc&view=rev > > Log: > > 2015-05-14 Vladimir Makarov > > > > PR rtl-optimization/65862 > > * target.def (ira_change_pseudo_allocno_class): New hook. > > * targhooks.c (default_ira_change_pseudo_allocno_class): Default > > value of the hook. > > * targhooks.h (default_ira_change_pseudo_allocno_class): New > > extern > > * doc/tm.texi.in (TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS): Add the > > hook. > > * ira-costs.c (find_costs_and_classes): Call the hook and change > > classes when it is necessary. > > * doc/tm.texi: Update. > > > > > > Modified: > > trunk/gcc/ChangeLog > > trunk/gcc/doc/tm.texi > > trunk/gcc/doc/tm.texi.in > > trunk/gcc/ira-costs.c > > trunk/gcc/target.def > > trunk/gcc/targhooks.c > > trunk/gcc/targhooks.h > > : > Is it true that this patch fixes the problem? > If so then why this bug is not marked as resolved? > (I'm asking because I am greatly interested in this fix.) If you implement the hook like I did on AArch64 then the problem is worked around reasonably. Note there were several follow-on patches, and the issue still exists on almost all targets. So in that sense it is not fixed until it works better by default (I don't mind if this bug gets closed but we will need another to keep track of this issue until GCC does the right thing by default).
[Bug target/86497] [8/9 regression] wasted instructions for x86 float x!=x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86497 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r254167, so maybe related to PR84251.
[Bug fortran/86468] [8/9 regression] ICE verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86468 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-12 Target Milestone|9.0 |8.2 Summary|[9 regression] ICE |[8/9 regression] ICE |verify_gimple failed|verify_gimple failed Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The ICE appears only if the compiler is configured with --enable-checking=yes. Revision r251448 (2017-08-30) does not ICE, while r256000 (2017-12-26) does.
[Bug fortran/86312] missing runtime warning for array temporary with -fcheck=array-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86312 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-07-12 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Related to/ duplicate of PRs 48655 and 63689. -Warray-temporaries is emitted when the front-end create a temporary, but this temporary may be optimized away and in this case there is no reason to emit a warning with -fcheck=array-temps. So the question is "Is the temporary for xx(:)%i optimized away or not?". > Minor documentation issue: -Warray-temporaries is not listed on > https://gcc.gnu.org/onlinedocs/gfortran/Option-Summary.html, > therefore I had a hard time finding it. Confirmed, but it is documented in https://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html#Error-and-Warning-Options > Also: Couldn't it be included in -Wall or at least -Wextra? Why? Its intent is only to help users to optimize their codes.
[Bug debug/86462] [9 Regression] Quite huge debug info size increase introduced in r262511
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86462
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
The differences are of the form
<3><11d>: Abbrev Number: 9 (DW_TAG_lexical_block)
<4><11e>: Abbrev Number: 10 (DW_TAG_GNU_call_site)
to
<3><11d>: Abbrev Number: 9 (DW_TAG_lexical_block)
<11e> DW_AT_ranges : 0x560
<4><122>: Abbrev Number: 10 (DW_TAG_GNU_call_site)
and similar
<4><6ef>: Abbrev Number: 26 (DW_TAG_lexical_block)
<4><6f0>: Abbrev Number: 26 (DW_TAG_lexical_block)
<4><6f1>: Abbrev Number: 27 (DW_TAG_GNU_call_site)
to
<4><6f3>: Abbrev Number: 26 (DW_TAG_lexical_block)
<6f4> DW_AT_ranges : 0x5a0
<4><6f8>: Abbrev Number: 26 (DW_TAG_lexical_block)
<6f9> DW_AT_ranges : 0x5d0
<4><6fd>: Abbrev Number: 27 (DW_TAG_GNU_call_site)
and I believe the fix involves emitting less lexical blocks in the first
place, not not annotating already generated lexical block DIEs with
ranges.
For computer_time above the frontend generates
computer_time (real(kind=8) & restrict tnow)
{
integer(kind=4) count_max;
integer(kind=4) count_rate;
integer(kind=4) counted;
static logical(kind=4) first = 1;
static logical(kind=4) first_flip;
static real(kind=8) tfirst;
real(kind=8) tmax;
real(kind=8) trate;
{
integer(kind=4) count.0;
integer(kind=4) count_rate.1;
integer(kind=4) count_max.2;
_gfortran_system_clock_4 (&count.0, &count_rate.1, &count_max.2);
...
}
and we output the lexical block because of the vars even though they
are all DECL_IGNORED. This is because of the simplified logic in
gen_block_die:
/* Determine if this block directly contains any "significant"
local declarations which we will need to output DIEs for. */
if (debug_info_level > DINFO_LEVEL_TERSE)
/* We are not in terse mode so *any* local declaration counts
as being a "significant" one. */
must_output_die = ((BLOCK_VARS (stmt) != NULL
|| BLOCK_NUM_NONLOCALIZED_VARS (stmt))
&& (TREE_USED (stmt)
|| TREE_ASM_WRITTEN (stmt)
|| BLOCK_ABSTRACT (stmt)));
else if ((TREE_USED (stmt)
|| TREE_ASM_WRITTEN (stmt)
|| BLOCK_ABSTRACT (stmt))
&& !dwarf2out_ignore_block (stmt))
must_output_die = 1;
Of course the question is why DECL_INGORED vars are retained in BLOCK_VARS
at all. For code-generation local_decls is authorative, BLOCK_VARS is only
for debug information generation. But BLOCK_VARS and gimple_bind_vars
are too interwound to remove those easily which means the above code
would need to walk BLOCK_VARS (and BLOCK_NONLOCALIZED_VARS).
So with that fixed I get an overall saving (comparing trunk and gcc8 though):
> bloaty induct2.o -- ../../gcc8-g/gcc/induct2.o
VM SIZE FILE SIZE
++ GROWING++
[ = ] 0 .rela.debug_loc+1.45Ki +1.3%
[ = ] 0 .debug_loc+695 +0.9%
[ = ] 0 .debug_line +167 +1.1%
[ = ] 0 .rela.debug_ranges +48 +1.2%
[ = ] 0 .rela.debug_info +24 +0.0%
[ = ] 0 .debug_ranges +16 +0.9%
[ = ] 0 .debug_abbrev +11 +0.8%
[ = ] 0 [Unmapped] +3 +7.5%
-- SHRINKING --
[ = ] 0 .debug_info-2.44Ki -3.3%
-0.7%-740 .text -740 -0.7%
[ = ] 0 .rela.text-288 -0.3%
[ = ] 0 .symtab-96 -2.0%
-6.6% -32 .rodata.cst8 -32 -6.6%
[ = ] 0 .strtab-24 -0.8%
[ = ] 0 .comment -21 -33.3%
[ = ] 0 .debug_str -16 -0.3%
-0.7%-772 TOTAL -1.23Ki -0.2%
I will test
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 1127713cbaf..995a463bddc 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -25632,13 +25632,30 @@ gen_block_die (tree stmt, dw_die_ref context_die)
/* Determine if this block directly contains any "significant"
local declarations which we will need to output DIEs for. */
if (debug_info_level > DINFO_LEVEL_TERSE)
- /* We are not in terse mode so *any* local declaration counts
- as being a "significant" one. */
- must_output_die = ((BLOCK_VARS (stmt) != NULL
- || BLOCK_NUM_NONLOCALIZED_VARS (stmt))
- && (TREE_USED (stmt)
- || TREE_ASM_WRITTEN (stmt)
- || BLOCK_ABSTRACT (stmt)));
+ {
+ /* We are not in terse mode so any local declaration that
+is n
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 --- Comment #5 from Matt Bentley --- What would be even more useful is a warning: for unused data.
[Bug middle-end/86505] [6/7/8/9 Regression] __builtin_va_arg_pack_len() computes the number of arguments wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86505
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |ASSIGNED
Known to work||4.4.7
Version|unknown |8.1.0
Keywords||wrong-code
Last reconfirmed||2018-07-12
Component|c |middle-end
Ever confirmed|0 |1
Summary|__builtin_va_arg_pack_len() |[6/7/8/9 Regression]
|computes the number of |__builtin_va_arg_pack_len()
|arguments wrongly |computes the number of
||arguments wrongly
Target Milestone|--- |6.5
Known to fail||4.5.2, 6.4.0, 7.3.0, 8.1.0,
||9.0
--- Comment #1 from Richard Biener ---
Confirmed. This is because funA is inlined as follows
__attribute__((always_inline))
funB (unsigned int param)
{
int D.1995;
int D.1994;
unsigned int param;
int D.1981;
int _4;
int _6;
:
param_5 = param_2(D);
_6 = __builtin_va_arg_pack_len ();
:
:
_7 = _6;
_4 = _7;
:
:
return _4;
}
here obviously while va_arg_pack_len is correctly not resolved it needs
to be adjusted by the additional variadic args that got passed to funA.
The testcase is somewhat artificial because we refuse to inline once
variadic args are accessed in the callee but still it shows a bug.
I will try to fix that.
[Bug c/86506] tree-vect-patterns.c:225: shift too large for type ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86506 David Binderman changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from David Binderman --- svn blame says 262276 rsandifo precision = 1 << ceil_log2 (precision);
[Bug c/86506] tree-vect-patterns.c:225: shift too large for type ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86506
--- Comment #1 from David Binderman ---
$ ~/gcc/results.262549.ubsan/bin/gcc -c -O3 bug450.c
bug450.c: In function ‘b’:
bug450.c:5:21: warning: assignment to ‘int’ from ‘void (*)()’ makes integer
from pointer without a cast [-Wint-conversion]
a[c] = a[c + 1] = b;
^
../../trunk/gcc/tree-vect-patterns.c:225:17: runtime error: shift exponent 64
is too large for 32-bit type 'int'
$ cat bug450.c
int *a;
void b() {
int c;
for (; c; c += 2)
a[c] = a[c + 1] = b;
}
[Bug tree-optimization/86504] vectorization failure for a nest loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86504
Richard Biener changed:
What|Removed |Added
Target||arm
CC||rguenth at gcc dot gnu.org
Blocks||53947
--- Comment #3 from Richard Biener ---
The issue is the inner complete loop unrolling pass which unrolls loops up to
16 times (a --param controls that number). You can get good code via
-fdisable-tree-cunrolli for example.
So the vectorization issue would be that basic-block vectorization doesn't
catch this in a very nice way - on x86 we pull out the invariant computation
and have a vectorized (outer) loop storing to d. But we fail to
vectorize the add because we are restricted to a single basic-block and the
stores are still in the inner loop (obviously):
t.c:9:15: note: not vectorized: no grouped stores in basic block.
instead we see
_238 = MEM[(char *)&g_s2 + 15B];
_239 = (unsigned char) _238;
_240 = _236 + _239;
_242 = (char) _240;
_234 = {_32, _46, _60, _74, _88, _102, _116, _130, _144, _158, _172, _186,
_200, _214, _228, _242};
vect_cst__237 = _234;
[local count: 63136020]:
# vectp_g_d.0_227 = PHI
# ivtmp_31 = PHI
MEM[(char *)vectp_g_d.0_227] = vect_cst__237;
vectp_g_d.0_15 = vectp_g_d.0_227 + 16;
ivtmp_241 = ivtmp_31 + 1;
if (ivtmp_241 < 128)
goto ; [99.00%]
else
goto ; [1.00%]
[local count: 62498283]:
goto ; [100.00%]
[local count: 637738]:
return;
so this is a duplicate of the bug that says BB vectorization doesn't consider
a vector CONSTRUCTOR as sink.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/86497] [8/9 regression] wasted instructions for x86 float x!=x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86497 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-12 Target Milestone|--- |8.2 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. I _think_ I've seen a duplicate...
[Bug c++/86503] Segmentation fault signal terminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86503 --- Comment #1 from Richard Biener --- You run out of memory or stack. Try ulimit -s unlimited
[Bug c/86506] New: tree-vect-patterns.c:225: shift too large for type ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86506 Bug ID: 86506 Summary: tree-vect-patterns.c:225: shift too large for type ? Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- From a ubsan build of gcc trunk: ../../trunk/gcc/tree-vect-patterns.c:225:17: runtime error: shift exponent 64 is too large for 32-bit type 'int' Source code is precision = 1 << ceil_log2 (precision); Maybe better code precision = 1UL << ceil_log2 (precision); I'll have a go a generating a test case.
[Bug lto/86496] [9 regression] plugin required to handle lto object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86496 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/86495] [8/9 Regression] false no return statement warning in "if constexpr" branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86495 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |8.2 Summary|false no return statement |[8/9 Regression] false no |warning in "if constexpr" |return statement warning in |branch |"if constexpr" branch
[Bug tree-optimization/86489] ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489 --- Comment #2 from Richard Biener --- gimple *phi = SSA_NAME_DEF_STMT (b_11); if (gimple_code (phi) != GIMPLE_PHI || (gimple_assign_lhs (and_stmt) != gimple_phi_arg_def (phi, loop_latch_edge (loop)->dest_idx))) return false; this may fail if the PHI in question is not the correct one in which case it may not have the argument at the latch dest_idx. Try first verifying that the loop latch destination is indeed gimple_bb (phi).
[Bug tree-optimization/86504] vectorization failure for a nest loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86504 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-12 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed, I've seen this in other similar loops. Thanks for filing a bug report for this
[Bug tree-optimization/86492] [8/9 Regression] store-merging wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed for 8.2+.
[Bug tree-optimization/80122] __builtin_va_arg_pack() and __builtin_va_arg_pack_len() does not work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80122 --- Comment #14 from rpirrera at aitek dot it --- (In reply to Richard Biener from comment #13) > Can you please open a new bugreport? Btw, your snippet doesn't compile > because you miss ANSI_BOLD and friends, removing it and adding a #include > makes it compile fine (but not link, a main is missing). > So in the new bugreport you open please provide a _complete_ testcase. Opened a new bugreport here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86505. Thank you.
[Bug c/86505] New: __builtin_va_arg_pack_len() computes the number of arguments wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86505
Bug ID: 86505
Summary: __builtin_va_arg_pack_len() computes the number of
arguments wrongly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rpirrera at aitek dot it
Target Milestone: ---
I have found another issue with __builtin_va_arg_pack_len() that happens when
the functions that uses __builtin_va_arg_pack() calls another function that
uses __builtin_va_arg_pack_len(), the argument len is miscalculated as you can
see in the attached example.
This was working in GCC version 4.4.7.
#include
/*** TESTBUILTIN BEGIN /
static inline __attribute__(( __always_inline__)) int
funA(unsigned int param, ...)
{
return __builtin_va_arg_pack_len();
}
static inline __attribute__(( __always_inline__)) int
funB(unsigned int param, ...)
{
return funA(param, 2, 4, __builtin_va_arg_pack());
}
int
testBuiltin(void)
{
int rc = funB(0,1,2);
if (rc != 4) {
return 1;
}
return 0;
}
int
main(void)
{
int rc;
rc = testBuiltin();
if (rc == 1) {
printf("Test Failed!\n");
return rc;
}
printf("Test Succeeded!\n");
return rc;
}
Thank you!
[Bug tree-optimization/86492] [8/9 Regression] store-merging wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Thu Jul 12 07:46:04 2018 New Revision: 262577 URL: https://gcc.gnu.org/viewcvs?rev=262577&root=gcc&view=rev Log: PR tree-optimization/86492 * gimple-ssa-store-merging.c (imm_store_chain_info::coalesce_immediate_stores): Call check_no_overlap even for the merge_overlapping case. * gcc.c-torture/execute/pr86492.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/pr86492.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/gimple-ssa-store-merging.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/86492] [8/9 Regression] store-merging wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Jul 12 07:39:33 2018 New Revision: 262576 URL: https://gcc.gnu.org/viewcvs?rev=262576&root=gcc&view=rev Log: PR tree-optimization/86492 * gimple-ssa-store-merging.c (imm_store_chain_info::coalesce_immediate_stores): Call check_no_overlap even for the merge_overlapping case. Formatting fix. * gcc.c-torture/execute/pr86492.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr86492.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-store-merging.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/86504] vectorization failure for a nest loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86504 --- Comment #1 from Jiangning Liu --- Created attachment 44387 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44387&action=edit bad vectorizatoin result for boundary size 8
[Bug tree-optimization/86504] New: vectorization failure for a nest loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86504
Bug ID: 86504
Summary: vectorization failure for a nest loop
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jiangning.liu at amperecomputing dot com
Target Milestone: ---
Created attachment 44386
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44386&action=edit
bad vectorizatoin result for boundary size 16
For the case below, the code generated by “gcc -O3” is very ugly, and the inner
loop can be correctly vectorized. Please refer to attached file
test_loop_inner_16.s.
char g_d[1024], g_s1[1024], g_s2[1024];
void test_loop(void)
{
char *d = g_d, *s1 = g_s1, *s2 = g_s2;
for ( int y = 0; y < 128; y++ )
{
for ( int x = 0; x < 16; x++ )
d[x] = s1[x] + s2[x];
d += 16;
}
}
If we change inner loop “for ( int x = 0; x < 16; x++ )” to be like “for ( int
x = 0; x < 32; x++ )”, i.e. the loop boundary size changes from 16 to 32, very
beautiful vectorization code would be generated. For example, the code below is
the aarch64 result for loop boundary size 32, and it the same case for x86.
test_loop:
.LFB0:
.cfi_startproc
adrpx2, g_s1
adrpx3, g_s2
add x2, x2, :lo12:g_s1
add x3, x3, :lo12:g_s2
adrpx0, g_d
adrpx1, g_d+2048
add x0, x0, :lo12:g_d
add x1, x1, :lo12:g_d+2048
ldp q1, q2, [x2]
ldp q3, q0, [x3]
add v1.16b, v1.16b, v3.16b
add v0.16b, v0.16b, v2.16b
.p2align 3,,7
.L2:
str q1, [x0]
str q0, [x0, 16]!
cmp x0, x1
bne .L2
ret
The code generated for loop boundary size 8 is also very bad.
Any idea?
[Bug tree-optimization/80122] __builtin_va_arg_pack() and __builtin_va_arg_pack_len() does not work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80122 Richard Biener changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Richard Biener --- Can you please open a new bugreport? Btw, your snippet doesn't compile because you miss ANSI_BOLD and friends, removing it and adding a #include makes it compile fine (but not link, a main is missing). So in the new bugreport you open please provide a _complete_ testcase.
[Bug c++/86480] [8/9 Regression] error: parameter packs not expanded with '...' in a recursive variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86480 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||7.3.1 Keywords||rejects-valid Last reconfirmed||2018-07-12 Ever confirmed|0 |1 Summary|[8 Regression] error: |[8/9 Regression] error: |parameter packs not |parameter packs not |expanded with '...' in a|expanded with '...' in a |recursive variadic lambda |recursive variadic lambda Known to fail||8.1.1, 9.0 --- Comment #3 from Richard Biener --- Confirmed.
[Bug c/86453] [8 Regression] error: type variant differs by TYPE_PACKED in free_lang_data since r255469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86453 Richard Biener changed: What|Removed |Added Keywords|patch | Component|middle-end |c Known to work||9.0 Summary|[8/9 Regression] error: |[8 Regression] error: type |type variant differs by |variant differs by |TYPE_PACKED in |TYPE_PACKED in |free_lang_data since|free_lang_data since |r255469 |r255469 Known to fail||8.1.0 --- Comment #11 from Richard Biener --- Fixed on trunk sofar.
[Bug c/86453] [8 Regression] error: type variant differs by TYPE_PACKED in free_lang_data since r255469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86453 --- Comment #12 from Richard Biener --- Author: rguenth Date: Thu Jul 12 07:13:36 2018 New Revision: 262575 URL: https://gcc.gnu.org/viewcvs?rev=262575&root=gcc&view=rev Log: 2018-07-12 Richard Biener PR c/86453 * c-attribs.c (handle_packed_attribute): Do not build a variant type with TYPE_PACKED, instead ignore the attribute if we may not apply to the original type. * g++.dg/warn/pr86453.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/warn/pr86453.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/86479] [9 Regression] [graphite] ICE in gimplify_modify_expr, at gimplify.c:5756
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86479 --- Comment #4 from Richard Biener --- Author: rguenth Date: Thu Jul 12 07:11:50 2018 New Revision: 262574 URL: https://gcc.gnu.org/viewcvs?rev=262574&root=gcc&view=rev Log: 2018-07-12 Richard Biener PR middle-end/86479 * fold-const.c (fold_binary_op_with_conditional_arg): Do not move possibly trapping operations into the conditional. * gcc.dg/graphite/pr86479.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr86479.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/86479] [9 Regression] [graphite] ICE in gimplify_modify_expr, at gimplify.c:5756
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86479 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 86479, which changed state. Bug 86479 Summary: [9 Regression] [graphite] ICE in gimplify_modify_expr, at gimplify.c:5756 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86479 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
