[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 --- Comment #12 from rguenther at suse dot de --- On Fri, 11 Jan 2019, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 > > --- Comment #11 from Martin Sebor --- > I understand what jump threading does but I don't know enough about how it > works to have a clear idea how viable marking up the created statements would > be. Jump threading just makes existing paths explicit, thus path sensitive analysis would come up with similar answers. There may be cases where we could prove such paths are unreachable and fail to do so, but the cases where the path ends up in this kind of "undefined" builtin call do not count IMHO because it is exactly those cases we want to warn about - so we cannot really reason they cannot happen because of that.
[Bug c/88662] Document trap representations of _Bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662 --- Comment #8 from gnzlbg --- > I think it should be sufficient to either mention which types have padding > bits, I am not sure. An intrinsic that tells me that _Bool has 7 padding bits does not provide me with any new information. The C standard guarantees that _Bool has 1 value bit, so if `sizeof(_Bool)` returns N, then _Bool must have N * CHAR_BITS - 1 padding bits AFAICT. My question is which values are those padding bits allowed to take, which is unspecified in the C standard AFAICT. N1356 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1356.htm) stated: > GCC defines it to have one value bit with the other bits being padding bits > and undefined behavior if you access a _Bool representation with any of the > padding bits having a nonzero value (such representations being trap > representations) Documenting that this is how GCC defines the value that the padding bits in _Bool are allowed to take would be an useful guarantee, even if the standard does not require GCC to make this guarantee.
[Bug c++/88832] the layout of .data section of a binary is slightly changed when -g option is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88832 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab --- dup *** This bug has been marked as a duplicate of bug 88831 ***
[Bug c++/88831] the layout of .data section of a binary is slightly changed when -g option is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88831 --- Comment #1 from Andreas Schwab --- *** Bug 88832 has been marked as a duplicate of this bug. ***
[Bug testsuite/85368] [8 regression] phi-opt-11 test fails on IBM Z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85368 --- Comment #18 from Jakub Jelinek --- Yes. It is a developer only knob which can go away at any time.
[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #13 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #12)
> On Fri, 11 Jan 2019, msebor at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
> >
> > --- Comment #11 from Martin Sebor ---
> > I understand what jump threading does but I don't know enough about how it
> > works to have a clear idea how viable marking up the created statements
> > would
> > be.
>
> Jump threading just makes existing paths explicit, thus path sensitive
> analysis would come up with similar answers. There may be cases where
> we could prove such paths are unreachable and fail to do so, but the
> cases where the path ends up in this kind of "undefined" builtin call
> do not count IMHO because it is exactly those cases we want to warn
> about - so we cannot really reason they cannot happen because of that.
Sure, but the warnings we are talking about typically don't warn about calls
(etc.) that can overflow, but nothing is known about the value ranges of those
arguments. Because then we'd need to warn about void foo (char *x, char *y,
unsigned long z) { __builtin_strncpy (x, y, z); } which indeed can overflow if
user passes wrong arguments. We'd just warn all the time about that though and
the warning wouldn't be useful at all.
[Bug libstdc++/80762] is_constructible gives hard error with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #7 from Tamar Christina --- Hello, I'm now seeing the following failure on GCC 8 /src/gcc/libstdc++-v3/testsuite/experimental/filesystem/path/construct/80762.cc:20: fatal error: experimental/filesystem: No such file or directory compilation terminated. On both arm and aarch64 cross builds.
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788
--- Comment #12 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> Look e.g. at -O2:
> void bar (int);
>
> void
> foo (int x)
> {
> int i = 0;
> if (x == 8)
> {
> x = 16;
> goto lab;
> }
> for (; i < 100; i++)
> {
> lab:
> bar (x);
> }
> }
>
> but pretty much any time you have a loop where some var doesn't really
> change, but there is some other edge to the loop header with a different
> value for that var.
Ah indeed.
Thanks for the explanation!
[Bug libstdc++/80762] is_constructible gives hard error with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #8 from Jonathan Wakely --- I forgot the dg-require-filesystem-ts again.
[Bug target/88510] GCC generates inefficient U64x2/v2di scalar multiply for NEON32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88510 Ramana Radhakrishnan changed: What|Removed |Added Target|armv7-a |arm, aarch64 Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-14 CC||ramana at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #3 from Ramana Radhakrishnan --- We are in stage4 at this point of time and a patch for this between now and when GCC9 releases isn't appropriate (i.e. April). Hopefully someone will pick this up afterwards for both backends as the logic required for the expansion should be pretty much identical give or take backend integration issues. Though I wonder if this is better handled in the fall back path for expansion of v2di multiplications instead of duplicating this logic in both arm and aarch64 backends.
[Bug tree-optimization/88797] [7/8/9 Regression] Unneeded branch added when function is inlined (function runs faster if not inlined)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88797 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-14 CC||law at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |7.5 Summary|Unneeded branch added when |[7/8/9 Regression] Unneeded |function is inlined |branch added when function |(function runs faster if|is inlined (function runs |not inlined)|faster if not inlined) Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- It's path splitting again. -fno-split-paths works around this.
[Bug target/88798] AVX512BW code does not use bit-operations that work on mask registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88798 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-14 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- The testcase still behaves the same on trunk, not sure if exactly a dup or not.
[Bug target/88799] [8/9 Regression] Arm -mcpu=PROCESSOR does not result in assembly directives for .arch and .arch_extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88799 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3
[Bug tree-optimization/88801] [9 Regression] Performance regression on 473.astar on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88801 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #14 from rguenther at suse dot de ---
On Mon, 14 Jan 2019, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
>
> --- Comment #13 from Jakub Jelinek ---
> (In reply to rguent...@suse.de from comment #12)
> > On Fri, 11 Jan 2019, msebor at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
> > >
> > > --- Comment #11 from Martin Sebor ---
> > > I understand what jump threading does but I don't know enough about how it
> > > works to have a clear idea how viable marking up the created statements
> > > would
> > > be.
> >
> > Jump threading just makes existing paths explicit, thus path sensitive
> > analysis would come up with similar answers. There may be cases where
> > we could prove such paths are unreachable and fail to do so, but the
> > cases where the path ends up in this kind of "undefined" builtin call
> > do not count IMHO because it is exactly those cases we want to warn
> > about - so we cannot really reason they cannot happen because of that.
>
> Sure, but the warnings we are talking about typically don't warn about calls
> (etc.) that can overflow, but nothing is known about the value ranges of those
> arguments. Because then we'd need to warn about void foo (char *x, char *y,
> unsigned long z) { __builtin_strncpy (x, y, z); } which indeed can overflow if
> user passes wrong arguments. We'd just warn all the time about that though
> and
> the warning wouldn't be useful at all.
Well, the question is then whether you want to live with false negatives
or false positives... I thought from all the attempts to prevent
early folding that we rather want false positives. Otherwise just
fold all undefined stuff to __builtin_trap().
[Bug libstdc++/88738] treat shared_ptr and unique_ptr more like plain old pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88738 --- Comment #9 from Jonathan Wakely --- The standard maybe_unused attribute seems suitable. If an equality or relational operator function has that attribute, don't warn if its result is unused. So weird operators with side effects can use the attribute.
[Bug c/88662] Document trap representations of _Bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662 --- Comment #9 from Jonathan Wakely --- But it constrains GCC in future, which leaving it unspecified does not.
[Bug libfortran/88805] hidden symbol `__cpu_model' is referenced by DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805 --- Comment #4 from Richard Biener --- It works for me (glibc 2.22). Can you quote the linker command-line (add -v to the compiler command)?
[Bug target/88833] New: [SVE] Redundant moves for WHILELO-based loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88833 Bug ID: 88833 Summary: [SVE] Redundant moves for WHILELO-based loops Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org Target Milestone: --- Compiling this function with -O3 -march=armv8-a+sve: subroutine foo(x, y, z) real :: x(100), y(100), z(100) x = y + z(1) end subroutine foo gives: foo_: .LFB0: .cfi_startproc mov x4, 100 mov x5, x4// Redundant mov x3, 0 ptrue p1.s, all whilelo p0.s, xzr, x4 ld1rw z1.s, p1/z, [x2] .p2align 3,,7 .L2: ld1wz0.s, p0/z, [x1, x3, lsl 2] faddz0.s, z0.s, z1.s st1wz0.s, p0, [x0, x3, lsl 2] incwx3 whilelo p0.s, x3, x5 bne .L2 ret .cfi_endproc There's no need for the move here. We should just be able to use x4 for both WHILELOs. Although the move itself shouldn't be expensive in context, it suggests that the RA isn't seeing an accurate picture, which could hurt in more complex cases.
[Bug ipa/88818] Segfault with vtable-verify LTO optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88818 Richard Biener changed: What|Removed |Added Keywords||lto CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Component|c++ |ipa --- Comment #3 from Richard Biener --- I think VTV is just bit-rotten seriously and it likely never worked with LTO.
[Bug fortran/88821] Inline packing of non-contiguous arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-14 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/88823] ivopts introduces -1(OVF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88823
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-14
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
The flag is usually harmless and might only result in missed optimizations down
the road. At some point it caused VRP to ICE eventually. One -1(OVF) is
built here:
#4 0x0137f9d2 in get_computation_aff_1 (loop=0x76888ee0, at=
, use=0x31d8e00, cand=0x31d8f90,
aff_inv=0x7fffd130, aff_var=0x7fffd2f0, prat=0x7fffd100)
at /space/rguenther/src/gcc-sccvn/gcc/tree-ssa-loop-ivopts.c:3947
(gdb) l
3942 if (stmt_after_increment (loop, cand, at))
3943{
3944 aff_tree cstep_aff;
3945
3946 if (common_type != uutype)
3947cstep_common = fold_convert (common_type, cstep);
where cstep is 4294967295 and common_type is int. That's probably harmless
as we just feed it back to tree-affine. Then there's
#4 0x01383a5a in may_eliminate_iv (data=0x7fffd810,
use=0x31d8e00, cand=0x31d90b0, bound=0x7fffd638, comp=0x7fffd5c4)
at /space/rguenther/src/gcc-sccvn/gcc/tree-ssa-loop-ivopts.c:5147
5147 *bound = fold_convert (TREE_TYPE (cand->iv->base),
(gdb) l
5142}
5143}
5144
5145 cand_value_at (loop, cand, use->stmt, desc->niter, &bnd);
5146
5147 *bound = fold_convert (TREE_TYPE (cand->iv->base),
5148 aff_combination_to_tree (&bnd));
where a similar issue happens (unsigned -> signed convert). This is the
one ending up in the IL.
[Bug target/88834] New: [SVE] Poor addressing mode choices for LD2 and ST2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
Bug ID: 88834
Summary: [SVE] Poor addressing mode choices for LD2 and ST2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Compiling this code with -O3 -march=armv8-a+sve:
void
f (int *restrict x, int *restrict y, int *restrict z, int n)
{
for (int i = 0; i < n; i += 2)
{
x[i] = y[i] + z[i];
x[i + 1] = y[i + 1] - z[i + 1];
}
}
gives:
f:
.LFB0:
.cfi_startproc
cmp w3, 0
ble .L1
sub w4, w3, #1
cntwx3
ptrue p1.s, all
lsr w4, w4, 1
add w4, w4, 1
whilelo p0.s, xzr, x4
.p2align 3,,7
.L3:
ld2w{z4.s - z5.s}, p0/z, [x1]
ld2w{z2.s - z3.s}, p0/z, [x2]
add z0.s, z4.s, z2.s
sub z1.s, z5.s, z3.s
st2w{z0.s - z1.s}, p0, [x0]
incbx1, all, mul #2
whilelo p0.s, x3, x4
incbx0, all, mul #2
incbx2, all, mul #2
incwx3
ptest p1, p0.b
bne .L3
.L1:
ret
.cfi_endproc
Rather than have one INCB per address, we should have a single IV
that tracks the index, something like:
ld2w{z4.s - z5.s}, p0/z, [x1, x4, lsl #2]
ld2w{z2.s - z3.s}, p0/z, [x2, x4, lsl #2]
add z0.s, z4.s, z2.s
sub z1.s, z5.s, z3.s
st2w{z0.s - z1.s}, p0, [x0, x4, lsl #2]
incwx4, all, mul #2 // or inch
I think this will need work in both the target code and ivopts.
[Bug target/88833] [SVE] Redundant moves for WHILELO-based loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88833 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||aarch64 Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-14 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. I see the redundant move as well.
[Bug c/88662] Document trap representations of _Bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662 --- Comment #10 from gnzlbg --- > But it constrains GCC in future, which leaving it unspecified does not. Documenting whether GCC's C _Bool has the same valid and trap representations as the target platform's ABI specifies is a trade-off: it does have a cost as you said, but it also adds value. The question is whether this trade-off is worth it. I am not a compiler expert, but using the same representation of _Bool as the platform's ABI allows GCC to avoid conversions on function arguments, return values, and when passing _Bools through memory. It appears to me that GCC would want to avoid doing these conversions anyways. An alternative here would be to, instead of guaranteeing this behavior, document the current behavior with a disclaimer that the behavior can change. So the cost of documenting this could be kept fairly small. Value-wise, if I want to cast an array of char to an array of _Bool, this guarantee allows me to check whether doing so will introduce undefined behavior, which I think is very valuable. So from my pov, documenting current behavior without guaranteeing it has almost zero cost, and adds a lot of value.
[Bug tree-optimization/88828] Inefficient update of the first element of vector registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88828
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-14
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
I think there's related bugs. foo1 is optimized OK:
y_4 = BIT_INSERT_EXPR ;
return y_4;
while foo is expanded from
[local count: 1073741824]:
_1 = BIT_FIELD_REF ;
_2 = BIT_FIELD_REF ;
_3 = BIT_FIELD_REF ;
y_6 = {f_5(D), _1, _2, _3};
return y_6;
tree forwprop contains code pattern-matching on vector CONSTRUCTORs,
it could be extended to handle this case I think. IIRC it can detect
arbitrary two-vector permutes already, for the above we could go
through an intermediate
_1 = {f_5(D), f_5(D), ... };
y_6 = VEC_PERM <_1, x_7(D), { }>;
and recognize permutes that only replace a single vector element.
So I think we should optimize
__v4sf
foo (__v4sf x, float f)
{
__v4sf y = __extension__ (__v4sf)
{ f, x[2], x[1], x[3] };
return y;
}
as well, first permuting x and then inserting f (at any position).
[Bug tree-optimization/88835] New: [9 Regression] Maybe misleading -Werror=format-overflow since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
Bug ID: 88835
Summary: [9 Regression] Maybe misleading
-Werror=format-overflow since r265648
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
Host: i586-linux-gnu
Created attachment 45424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45424&action=edit
test-case
I originally reported that to elfutils bugzilla.
The warning looks as follows:
$ gcc -m32 /tmp/readelf.i -c -O2 -Werror=format-overflow
readelf.c: In function ‘print_debug_str_section’:
readelf.c:10152:15: error: ‘%*llx’ directive output between 4 and 2147483647
bytes may cause result to exceed ‘INT_MAX’ [-Werror=format-overflow=]
10152 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
| ^~
readelf.c:10152:15: note: directive argument in the range [0,
18446744073709551614]
[Bug tree-optimization/88835] [9 Regression] Maybe misleading -Werror=format-overflow since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835 Martin Liška changed: What|Removed |Added Last reconfirmed||2019-1-14 Known to work||8.2.0 See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=24068 Target Milestone|--- |9.0 Known to fail||9.0
[Bug c++/88830] [9 Regression] ice in maybe_emit_vtables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88830 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Version|8.0 |9.0
[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||aarch64 Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-14 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug c++/88831] the layout of .data section of a binary is slightly changed when -g option is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88831 Richard Biener changed: What|Removed |Added Target||aarch64-linux-gnu Status|UNCONFIRMED |WAITING Last reconfirmed||2019-01-14 Host||x86_64-suse-linux Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- This shouldn't happen. Can you please provide a complete testcase?
[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815 --- Comment #2 from Jakub Jelinek --- I believe it is the @@ -25361,7 +25486,10 @@ return NULL_TREE; case TEMPLATE_PARM_INDEX: - return *tp; + if (dependent_type_p (TREE_TYPE (*tp))) + return *tp; + /* We'll check value-dependence separately. */ + return NULL_TREE; /* Handle expressions with type operands. */ case SIZEOF_EXPR: pt.c (instantiation_dependent_r) hunk that matters for this testcase, at least reverting it makes the testcase succeed.
[Bug target/88836] New: [SVE] Redundant PTEST in loop test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88836
Bug ID: 88836
Summary: [SVE] Redundant PTEST in loop test
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Compiling this code with -O3 -march=armv8-a+sve:
void
f (int *restrict x, int *restrict y, int *restrict z, int n)
{
for (int i = 0; i < n; i += 2)
{
x[i] = y[i] + z[i];
x[i + 1] = y[i + 1] - z[i + 1];
}
}
gives:
f:
.LFB0:
.cfi_startproc
cmp w3, 0
ble .L1
sub w4, w3, #1
cntwx3
ptrue p1.s, all
lsr w4, w4, 1
add w4, w4, 1
whilelo p0.s, xzr, x4
.p2align 3,,7
.L3:
ld2w{z4.s - z5.s}, p0/z, [x1]
ld2w{z2.s - z3.s}, p0/z, [x2]
add z0.s, z4.s, z2.s
sub z1.s, z5.s, z3.s
st2w{z0.s - z1.s}, p0, [x0]
incbx1, all, mul #2
whilelo p0.s, x3, x4
incbx0, all, mul #2
incbx2, all, mul #2
incwx3
ptest p1, p0.b
bne .L3
.L1:
ret
.cfi_endproc
PR88834 is tracking the poor addressing mode choices. But there's also no need
for that PTEST. We should be able to use the flags set by the WHILELO
directly.
[Bug target/88836] [SVE] Redundant PTEST in loop test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88836 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||aarch64 Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-14 CC||ktkachov at gcc dot gnu.org Version|unknown |9.0 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #13 from Richard Biener ---
I think that using a bitmap to mark SSA names already visited and return
true on those would work as well given returning false should (quickly)
propagate.
thus
diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index 37b58853fe1..e14394e9853 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -878,10 +878,14 @@ check_retval_uses (tree retval, gimple *stmt)
}
static bool
-malloc_candidate_p_1 (function *fun, tree retval, gimple *ret_stmt, bool ipa)
+malloc_candidate_p_1 (function *fun, tree retval, gimple *ret_stmt, bool ipa,
+ bitmap visited)
{
cgraph_node *node = cgraph_node::get_create (fun->decl);
+ if (!bitmap_set_bit (visited, SSA_NAME_VERSION (retval)))
+return true;
+
if (!check_retval_uses (retval, ret_stmt))
DUMP_AND_RETURN("Return value has uses outside return stmt"
" and comparisons against 0.")
@@ -925,7 +929,7 @@ malloc_candidate_p_1 (function *fun, tree retval, gimple
*ret_stmt, bool ipa)
gimple *arg_def = SSA_NAME_DEF_STMT (arg);
if (is_a (arg_def))
{
- if (!malloc_candidate_p_1 (fun, arg, phi, ipa))
+ if (!malloc_candidate_p_1 (fun, arg, phi, ipa, visited))
DUMP_AND_RETURN ("nested phi fail")
continue;
}
@@ -987,7 +991,8 @@ malloc_candidate_p (function *fun, bool ipa)
|| TREE_CODE (TREE_TYPE (retval)) != POINTER_TYPE)
DUMP_AND_RETURN("Return value is not SSA_NAME or not a pointer type.")
- if (!malloc_candidate_p_1 (fun, retval, ret_stmt, ipa))
+ auto_bitmap visited;
+ if (!malloc_candidate_p_1 (fun, retval, ret_stmt, ipa, visited))
return false;
}
[Bug c++/88761] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478 when chaining lambda calls & fold-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88761
Dennis Lubert changed:
What|Removed |Added
CC||plasmahh at gmx dot net
--- Comment #3 from Dennis Lubert ---
I was just about to report the same bug (internal compiler error: in
tsubst_copy, at cp/pt.c:15478) but with different code, maybe this can shed
more light on why it is happening, if not, just ignore it:
#include
#include
#include
int main(int argc, const char *argv[])
{
const size_t nf = 10'000'000;
auto loop = [&]( auto& vector )
{
long double cy = 0;
auto per = cy/nf;
};
std::vector pv;
loop( pv );
}
[Bug target/88837] [SVE] Poor vector construction code in VL-specific mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88837 rsandifo at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug target/88837] New: [SVE] Poor vector construction code in VL-specific mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88837 Bug ID: 88837 Summary: [SVE] Poor vector construction code in VL-specific mode Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org Target Milestone: --- The reduction testcases in gcc.target/aarch64/sve/slp_5.c require an initial vector in which all elements except the first two are zero. For the default VL-agnostic mode we generate reasonable code, e.g.: vec_slp_int32_t: .LFB4: .cfi_startproc ldp s2, s1, [x1] cmp w2, 0 ble .L19 mov x3, 0 sbfiz x2, x2, 1, 32 mov z0.b, #0 whilelo p0.s, xzr, x2 insrz0.s, s1 ptrue p1.s, all insrz0.s, s2 .p2align 3,,7 .L20: ld1wz1.s, p0/z, [x0, x3, lsl 2] incwx3 add z0.s, p0/m, z0.s, z1.s whilelo p0.s, x3, x2 bne .L20 But with -msve-vector-bits=256 the code is much worse: vec_slp_int32_t: .LFB4: .cfi_startproc ldp w5, w4, [x1] cmp w2, 0 ble .L31 sub sp, sp, #32 .cfi_def_cfa_offset 32 mov z0.b, #0 str z0, [sp] mov x3, 0 sbfiz x2, x2, 1, 32 whilelo p0.s, xzr, x2 ldr x6, [sp] bfi x6, x5, 0, 32 mov x5, x6 bfi x5, x4, 32, 32 str x5, [sp] ldr z0, [sp] .p2align 3,,7 .L28: ld1wz1.s, p0/z, [x0, x3, lsl 2] add x3, x3, 8 add z0.s, p0/m, z0.s, z1.s whilelo p0.s, x3, x2 bne .L28 We should try to optimise this, probably by implementing vec_init_optab for fixed-length vectors.
[Bug libstdc++/80762] is_constructible gives hard error with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762 --- Comment #10 from Jonathan Wakely --- Author: redi Date: Mon Jan 14 11:30:47 2019 New Revision: 267915 URL: https://gcc.gnu.org/viewcvs?rev=267915&root=gcc&view=rev Log: PR libstdc++/80762 add missing dg-require-filesystem-ts PR libstdc++/80762 * testsuite/experimental/filesystem/path/construct/80762.cc: Add dg-require-filesystem-ts directive. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/testsuite/experimental/filesystem/path/construct/80762.cc
[Bug libstdc++/80762] is_constructible gives hard error with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- Should be fixed now.
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788 --- Comment #14 from prathamesh3492 at gcc dot gnu.org --- Created attachment 45425 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45425&action=edit Patch Hi, In the attached patch, I cache results of malloc_candidate_p_1 and avoid traversing "back edges". Does it look OK ? One issue was with creation of hash_table: hash_table *mc_cache = new hash_table (100); Using num_ssa_names instead of 100 resulted in allocation failure (and ICE) for spinning-smaller.ii. Is using a smaller number like 100 OK correctness wise ? I think Richard's patch in comment 13 is a better approach, since returning false should indeed propagate quickly. Testing that patch. Thanks, Prathamesh
[Bug target/88838] New: [SVE] Use 32-bit WHILELO in LP64 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88838
Bug ID: 88838
Summary: [SVE] Use 32-bit WHILELO in LP64 mode
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Compiling this test with -O3 -march=armv8-a+sve:
void
f (int *restrict x, int *restrict y, int *restrict z, int n)
{
for (int i = 0; i < n; i += 1)
x[i] = y[i] + z[i];
}
produces:
f:
.LFB0:
.cfi_startproc
cmp w3, 0
ble .L1
mov x4, 0
sxtwx3, w3
whilelo p0.s, xzr, x3
.p2align 3,,7
.L3:
ld1wz1.s, p0/z, [x1, x4, lsl 2]
ld1wz0.s, p0/z, [x2, x4, lsl 2]
add z0.s, z0.s, z1.s
st1wz0.s, p0, [x0, x4, lsl 2]
incwx4
whilelo p0.s, x4, x3
bne .L3
.L1:
ret
We could (and should) avoid the SXTW by using WHILELO on W registers instead of
X registers.
vect_verify_full_masking checks which IV widths are supported for WHILELO but
prefers to go to Pmode width. This is because using Pmode allows ivopts to
reuse the IV for indices (as in the loads and store above). However, it would
be better to use a 32-bit WHILELO with a truncated 64-bit IV if:
(a) the limit is extended from 32 bits.
(b) the detection loop in vect_verify_full_masking detects that using a 32-bit
IV would be correct.
The thing to avoid is when using a 32-bit IV might wrap (see
vect_set_loop_masks_directly). In that case it would be better to stick with
64-bit WHILELOs.
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788 --- Comment #15 from Richard Biener --- (In reply to prathamesh3492 from comment #14) > Created attachment 45425 [details] > Patch > > Hi, > In the attached patch, I cache results of malloc_candidate_p_1 and avoid > traversing "back edges". > Does it look OK ? I think it's overkill and not needed. > One issue was with creation of hash_table: > hash_table *mc_cache = new hash_table (100); > > Using num_ssa_names instead of 100 resulted in allocation failure (and ICE) > for spinning-smaller.ii. > Is using a smaller number like 100 OK correctness wise ? > > I think Richard's patch in comment 13 is a better approach, since returning > false should indeed propagate quickly. Testing that patch. Thanks, you can actually cache 'visited' around the loop over exit block preds, just move the auto_bitmap visited; before the loop. > Thanks, > Prathamesh
[Bug target/88839] New: [SVE] Poor implementation of blend-like permutes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88839
Bug ID: 88839
Summary: [SVE] Poor implementation of blend-like permutes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Compiling this code with -O3 -msve-vector-bits=256:
typedef int v8si __attribute__((vector_size(32)));
v8si
f (v8si x, v8si y, v8si sel)
{
return __builtin_shuffle (x, y, (v8si) { 0, 9, 2, 11, 4, 13, 6, 15 });
}
produces an inefficient TBL-based sequence.
In these blend-like cases, where index I of the output comes from index I of
one of the inputs, we should be able to use a SEL with an appropriate predicate
constant. The preferred implementation of the above would be:
ptruep0.d, vl4// { 1, 0, 1, 0, ... } when used as p0.s
sel res, p0, y, x
This will also be useful for the default VL-agnostic mode when implementing
support for 2-operation SLP.
[Bug target/88838] [SVE] Use 32-bit WHILELO in LP64 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88838 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-14 CC||ktkachov at gcc dot gnu.org Version|unknown |9.0 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug rtl-optimization/88796] -fstack-protector* kills RTL DSE opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88796 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Mon Jan 14 12:01:01 2019 New Revision: 267916 URL: https://gcc.gnu.org/viewcvs?rev=267916&root=gcc&view=rev Log: PR rtl-optimization/88796 * emit-rtl.h (struct rtl_data): Add stack_protect_guard_decl field. * cfgexpand.c (stack_protect_prologue): Initialize crtl->stack_protect_guard_decl. * function.c (stack_protect_epilogue): Use it instead of calling targetm.stack_protect_guard again. * dse.c (check_mem_read_rtx): Ignore MEM_VOLATILE_P reads from MEMs with MEM_EXPR equal to crtl->stack_protect_guard or crtl->stack_protect_guard_decl. * config/i386/i386.c (ix86_stack_protect_guard): Set TREE_THIS_VOLATILE on the returned MEM_EXPR. * gcc.target/i386/pr88796.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr88796.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/config/i386/i386.c trunk/gcc/dse.c trunk/gcc/emit-rtl.h trunk/gcc/function.c trunk/gcc/testsuite/ChangeLog
[Bug c/88662] Document trap representations of _Bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662 --- Comment #11 from Jonathan Wakely --- I disagree. Once it's documented, people will rely on it and scream if it changes. Caveats about something maybe changing in future don't help. If it's documented to behave one way today, people will depend on that. It seems you already know what the behaviour is today, so how would documenting it but saying "this might change tomorrow!" help you? It tells you nothign you don't already know.
[Bug c/30475] assert(int+100 > int) optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 --- Comment #61 from Marian --- Thanks for your reply > The GCC 8 Changes page[*] says -Wstrict-overflow is deprecated (even if it is > supposed to still work) and recommends to use > -fsanitize=signed-integer-overflow to get a run-time warning, which does > catch this. I think using run-time warnings will miss a lot of bugs, compared to compile time warnings. I assume that in production builds that the run-time warnings will be disabled for performance reasons. I also assume that singed integer overflows will not "normally" happen, e.g. only when an adversary is abusing the bug in the integer overflow detection. So unless unit tests are explicitly checking if the signed integer overflow detection code does work properly, the run-time checks will never trigger. Even when production builds would have run time warnings enabled, those warnings would not stop an adversary in exploiting the integer overflow detection. I would greatly appreciate if the GCC developer could reconsider depreciating -Wstrict-overflow. Kind regards, Marian
[Bug libstdc++/88840] New: [9 Regression] std::allocator::construct signature might be ill-formed now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88840
Bug ID: 88840
Summary: [9 Regression] std::allocator::construct signature
might be ill-formed now
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
struct X {
X(int);
};
constexpr bool nothrow =
noexcept(std::allocator().construct(std::declval()));
That construct() call would ill-formed, because the type isn't default
constructible, but until recently it was possible to query whether it could
throw or not. With current trunk the declaration includes an
exception-specification, which makes it ill-formed:
In file included from
/home/jwakely/gcc/9/include/c++/9.0.0/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
from
/home/jwakely/gcc/9/include/c++/9.0.0/bits/allocator.h:46,
from /home/jwakely/gcc/9/include/c++/9.0.0/memory:63,
from construct.cc:1:
/home/jwakely/gcc/9/include/c++/9.0.0/ext/new_allocator.h: In instantiation of
'void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
X; _Args = {}; _Tp = X]':
construct.cc:7:83: required from here
/home/jwakely/gcc/9/include/c++/9.0.0/ext/new_allocator.h:145:20: error: no
matching function for call to 'X::X()'
145 | noexcept(noexcept(::new((void *)__p)
|^~
146 |_Up(std::forward<_Args>(__args)...)))
|~~~
construct.cc:4:3: note: candidate: 'X::X(int)'
4 | X(int);
| ^
construct.cc:4:3: note: candidate expects 1 argument, 0 provided
construct.cc:3:8: note: candidate: 'constexpr X::X(const X&)'
3 | struct X {
|^
construct.cc:3:8: note: candidate expects 1 argument, 0 provided
construct.cc:3:8: note: candidate: 'constexpr X::X(X&&)'
construct.cc:3:8: note: candidate expects 1 argument, 0 provided
We could constrain the declaration with SFINAE, but the program would still be
ill-formed (you still can't ask if the construct() call would throw, because
the declaration would be SFINAE'd out).
[Bug libstdc++/88840] [9 Regression] std::allocator::construct signature might be ill-formed now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88840 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-14 CC||glisse at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I think this started with r265485. I don't think there's anything we can do about this, and the code is arguably bad anyway, so maybe just INVALID?
[Bug libstdc++/88840] [9 Regression] std::allocator::construct signature might be ill-formed now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88840 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug fortran/43136] Excess copy-in/copy-out with character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43136 --- Comment #3 from Thomas Koenig --- Hm, maybe one could simply remove the substring during resolution.
[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #42 from Richard Biener ---
(In reply to rguent...@suse.de from comment #41)
> On Wed, 9 Jan 2019, rsandifo at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
> >
> > --- Comment #38 from rsandifo at gcc dot gnu.org > gnu.org> ---
> > Created attachment 45392 [details]
> > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45392&action=edit
> > patch that changes get_ref_base_and_extent for bare SSA_NAMEs
> >
> > (In reply to Wilco from comment #37)
> > > (In reply to rsand...@gcc.gnu.org from comment #35)
> > > > Yeah, the expr.c patch makes the original testcase work, but we still
> > > > fail
> > > > for:
> > >
> > > That's the folding in ccp1 after inlining, which will require a similar
> > > fix.
> > > There are likely more places that need to be fixed to handle the 'short'
> > > bit
> > > types.
> >
> > Yeah, seems like a can of worms.
> >
> > The expr.c approach treats a reference to an N-bit integer in an
> > M>N-bit mode is relative to M rather than N (i.e. it's relative
> > to the addressable storage.) So maybe the point this goes wrong
> > is when we ask for get_ref_base_and_extent on a bare 30-bit SSA_NAME
> > (no component accesses) and get back an offset of 0. If everything's
> > relative to the addressable storage then maybe it should be 2 for
> > big-endian?
Btw, get_inner_reference should be changed the same way, likewise
eventually get_addr_base_and_unit_offset.
> > The attached patch does that and seems to pass all three tests
> > in the PR so far. I'll give a spin overnight just in case
> > it's at least vaguely sensible.
>
> I considered this. I guess we need to document this somewhere
> though. Incidentially the GIMPLE verifier already does
>
> if (!AGGREGATE_TYPE_P (TREE_TYPE (op))
> && maybe_gt (size + bitpos,
>tree_to_poly_uint64 (TYPE_SIZE (TREE_TYPE
> (op)
> {
> error ("position plus size exceeds size of referenced object
> in "
> "BIT_FIELD_REF");
> return true;
> }
>
>
> so it uses TYPE_SIZE and not TYPE_PREICISON to verify the bounds of
> the BIT_FIELD_REF access.
>
> That said we should probably have exhaustive testing on this.
> Maybe simply try to add GIMPLE testcases exercising the
> BIT_FIELD_REF of bit-precision entities case.
>
> I also wonder whether for the GIMPLE checking we want to verify
> that for bit-precision OP the extracted range is within what
> is valid (which depends on endianess then?).
[Bug target/87018] Boostrap problems on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87018 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Thomas Koenig --- Since other people seem to have no problem, and I'm not going to look at this in the medium future, let's unclutter the bug database.
[Bug target/88839] [SVE] Poor implementation of blend-like permutes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88839 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-14 CC||ktkachov at gcc dot gnu.org Version|unknown |9.0 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. I see: f: ptrue p0.s, vl8 adrpx2, .LANCHOR0 ld1wz1.s, p0/z, [x1] add x2, x2, :lo12:.LANCHOR0 ld1wz0.s, p0/z, [x0] ld1wz2.s, p0/z, [x2] mov z3.d, z2.d tbl z0.s, z0.s, z2.s sub z3.s, z3.s, #8 tbl z1.s, z1.s, z3.s orr z0.d, z0.d, z1.d st1wz0.s, p0, [x8] ret
[Bug libstdc++/88840] [9 Regression] std::allocator::construct signature might be ill-formed now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88840 --- Comment #2 from Jonathan Wakely --- LLVM seems to hit a case where this matters, and I'm not sure if it's invalid yet: https://bugzilla.opensuse.org/show_bug.cgi?id=1121591 The __use_relocate member of std::vector will check the exception-specification without checking if the expression is even valid at all: #if __cplusplus >= 201103L static constexpr bool __use_relocate = noexcept(std::__relocate_a(std::declval(), std::declval(), std::declval(), std::declval<_Tp_alloc_type&>())); #endif If something depends on that boolean in a context where it isn't going to relocate, we might get an error from the ill-formed signature. We might want to only check that noexcept expression if the type is move constructible.
[Bug c/88662] Document trap representations of _Bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662 --- Comment #12 from gnzlbg --- > I disagree. Once it's documented, people will rely on it and scream if it > changes. Caveats about something maybe changing in future don't help. If it's > documented to behave one way today, people will depend on that. That's fair. > It seems you already know what the behaviour is today If you tell me that my thoughts about how this currently works are correct then that documents current behavior, and my code will depend on this. > so how would documenting it but saying "this might change tomorrow!" help > you? It tells you nothign you don't already know. If this was documented somewhere for a particular version of GCC, when my code is compiled with that particular GCC version, I could check inputs for invalid _Bools in my programs and abort reliably without triggering undefined behavior. If this is not documented anywhere, I can at best write code that "maybe aborts or maybe has undefined behavior". I find the difference very significant.
[Bug libstdc++/88840] [9 Regression] std::allocator::construct signature might be ill-formed now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88840 --- Comment #3 from Marc Glisse --- (In reply to Jonathan Wakely from comment #0) > We could constrain the declaration with SFINAE, but the program would still > be ill-formed (you still can't ask if the construct() call would throw, > because the declaration would be SFINAE'd out). Normally, a user should first check if the operation is valid, and only then check if it throws. The nothrow traits are kind of supposed to do that for you I think (except that there isn't one for allocator::construct). (In reply to Jonathan Wakely from comment #2) > The __use_relocate member of std::vector will check the > exception-specification without checking if the expression is even valid at > all: I think I already hit and fixed some very similar problem (found by the testsuite) while writing this patch, but it is indeed quite possible that the issue still exists. It is possible to imagine a type being relocatable but not movable, although we may not be ready to support that. It should be possible to define __use_relocate more lazily so it is only looked at if we call reserve, push_back, some function that requires it.
[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #24 from Richard Biener ---
On GCC testcases one large group of MEMs only disambiguated through
base_alias_check is disambiguations agains DSEs group_info->base_mem
which is BLKmode mems based on some "base" pointer. This base_mem
lacks a MEM_EXPR but I think it shouldn't be difficult to add one,
like with (completely lacking sanity testing):
diff --git a/gcc/dse.c b/gcc/dse.c
index 389c52d4284..098c77165de 100644
--- a/gcc/dse.c
+++ b/gcc/dse.c
@@ -1097,6 +1097,7 @@ canon_address (rtx mem,
{
machine_mode address_mode = get_address_mode (mem);
rtx mem_address = XEXP (mem, 0);
+ tree mem_expr = MEM_EXPR (mem);
rtx expanded_address, address;
int expanded;
@@ -1165,6 +1166,9 @@ canon_address (rtx mem,
&& const_or_frame_p (address))
{
group_info *group = get_group_info (address);
+ if (!MEM_EXPR (group->base_mem)
+ && mem_expr)
+ set_mem_expr (group->base_mem, get_base_address (mem_expr));
if (dump_file && (dump_flags & TDF_DETAILS))
{
btw, the disambiguations like
(mem/c:SI (symbol_ref:DI ("g") [flags 0x2] ) [1 g+0
S4 A32])
vs. (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
are handled through REG_BASE_VALUE which assigns 'sp' (address:DI -1).
I believe we should be working towards adding proper MEM_EXPRs to more
places and simply make find_base_term more conservative which means
simplifying the PLUS/MINUS cases.
[Bug rtl-optimization/88796] -fstack-protector* kills RTL DSE opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88796 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for GCC9+.
[Bug ipa/88755] [9 Regression] ICE in compute_fn_summary, at ipa-fnsummary.c:2513 since r267601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88755 --- Comment #2 from Martin Liška --- and: $ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.eh/catch3p.C --param uninlined-thunk-insns=2062717165 -Og during IPA pass: inline /home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.eh/catch3p.C: At global scope: /home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.eh/catch3p.C:117:1: internal compiler error: in estimate_size_after_inlining, at ipa-inline-analysis.c:272 117 | } | ^ 0x705b89 estimate_size_after_inlining(cgraph_node*, cgraph_edge*) /home/marxin/Programming/gcc/gcc/ipa-inline-analysis.c:272 0x1799c09 caller_growth_limits /home/marxin/Programming/gcc/gcc/ipa-inline.c:186 0x1799c09 can_inline_edge_by_limits_p /home/marxin/Programming/gcc/gcc/ipa-inline.c:428 0x179f0ea inline_small_functions /home/marxin/Programming/gcc/gcc/ipa-inline.c:1852 0x179f0ea ipa_inline /home/marxin/Programming/gcc/gcc/ipa-inline.c:2528 0x179f0ea execute /home/marxin/Programming/gcc/gcc/ipa-inline.c:2936
[Bug libstdc++/77776] C++17 std::hypot implementation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #10 from Matthias Kretz --- Experience from testing my simd implementation: I had failures (2 ULP deviation from long double result) when using auto __xx = abs(__x); auto __yy = abs(__y); auto __zz = abs(__z); auto __hi = max(max(__xx, __yy), __zz); auto __l0 = min(__zz, max(__xx, __yy)); auto __l1 = min(__yy, __xx); __l0 /= __hi; __l1 /= __hi; auto __lo = __l0 * __l0 + __l1 * __l1; return __hi * sqrt(1 + __lo); Where the failures occur depends on wether FMA instructions are used. I have observed only 1 ULP deviation from long double with my algorithm (independent of FMAs). Here are two data points that seem challenging: hypot(0x1.965372p+125f, 0x1.795c92p+126f, 0x1.d0fc96p+125f) -> 0x1.e79366p+126f hypot(0x1.235f24p+125f, 0x1.5b88f4p+125f, 0x1.d57828p+124f) -> 0x1.feaa26p+125f
[Bug target/88794] [9 Regression] fixupimm intrinsics are unusable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88794 --- Comment #1 from Wei Xiao --- My change (r265827) is based on the latest SDM (Intel® 64 and IA-32 Architectures Software Developer Manuals) which is incorrect for the fixupimm intrinsics. I'm preparing a patch to fix it.
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #5 from dominik.stras...@onespin-solutions.com --- ASAN from git crashes like this. Looks like a double fault. SignalHandler_Unix.h is in my application's code. I've attached ASAN's debug output where I removed all messages talking about poisoning/unpoisoning as they look unrelated. #5 0x7f6fd264c005 in SYSTEM::handleSignalForThread (t=140117893179136) at SignalHandler_Unix.h:412 #6 0x7f6fd264c57f in SYSTEM::gBadSignalHandler (signalNr=11, info=0x7f6fbd3fb070, ctx=0x7f6fbd3faf40) at SignalHandler_Unix.h:478 #7 #8 __asan::GetCurrentThread () at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:415 #9 0x7f6ffa37c58d in __asan_handle_no_return () at ../../../../gcc-git/libsanitizer/asan/asan_rtl.cc:538 #10 0x7f6fd264c04e in SYSTEM::handleSignalForThread (t=140117893179136) at SignalHandler_Unix.h:423 #11 0x7f6fd264c57f in SYSTEM::gBadSignalHandler (signalNr=11, info=0x7f6fbd3fbd70, ctx=0x7f6fbd3fbc40) at SignalHandler_Unix.h:478 #12 #13 GetCurrentThread () at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:415 #14 __asan::GetCurrentTidOrInvalid () at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:429 #15 0x7f6ffa37a1ea in __asan::ReportGenericError (pc=140118247917729, bp=bp@entry=140117893172896, sp=sp@entry=140117893172888, addr=105827994255744, is_write=is_write@entry=false, access_size=access_size@entry=8, exp=0, fatal=true) at ../../../../gcc-git/libsanitizer/asan/asan_report.cc:459 #16 0x7f6ffa37aea8 in __asan::__asan_report_load8 (addr=) at ../../../../gcc-git/libsanitizer/asan/asan_rtl.cc:119 #17 0x7f6fd264c8a1 in SYSTEM::gBadSignalHandler (signalNr=11, info=0x7f6fbd3fd630, ctx=0x7f6fbd3fd500) at SignalHandler_Unix.h:502 #18 #19 __asan::AsanThread::SetThreadStackAndTls (this=this@entry=0x7f6fbc552000, options=) at ../../../../gcc-git/libsanitizer/asan/asan_thread.h:80 #20 0x7f6ffa37e619 in __asan::AsanThread::Init (this=this@entry=0x7f6fbc552000, options=options@entry=0x0) at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:223 #21 0x7f6ffa37ea64 in __asan::AsanThread::ThreadStart (this=0x7f6fbc552000, os_id=5519, signal_thread_is_registered=0x7f6fc29da978) at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:244 #22 0x7f6fd150de25 in start_thread () from /lib64/libpthread.so.0 #23 0x7f6fd01dcbad in clone () from /lib64/libc.so.6
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #6 from dominik.stras...@onespin-solutions.com --- Created attachment 45426 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45426&action=edit ASAN debug output
[Bug middle-end/88587] ICE in expand_debug_locations, at cfgexpand.c:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88587
--- Comment #8 from Martin Liška ---
> It's quite strange that following is fine:
>
> $ cat pr88587-2.c
> __attribute__((target("default"))) void a() {
> __attribute__((__vector_size__(4 * sizeof(float int b = {};
> }
>
> __attribute__((target("sse2"))) void a2() {
> __attribute__((__vector_size__(4 * sizeof(float int b = {};
> }
>
> $ gcc -c -m32 -mno-sse -O -g pr88587-2.c
>
> I'll investigate how precisely the debug insn looks like in both situations.
I was wrong, this also fails, so not target_clone attribute related:
$ cat ~/Programming/testcases/pr88587-2.c
__attribute__((target("default"),always_inline)) void a() {
__attribute__((__vector_size__(4 * sizeof(float int b = {};
}
__attribute__((target("sse2"))) void a2() {
a ();
__attribute__((__vector_size__(4 * sizeof(float int b = {};
}
$ gcc ~/Programming/testcases/pr88587-2.c -c -m32 -mno-sse -O -g
/home/marxin/Programming/testcases/pr88587-2.c:1:55: warning: always_inline
function might not be inlinable [-Wattributes]
__attribute__((target("default"),always_inline)) void a() {
^
during RTL pass: expand
/home/marxin/Programming/testcases/pr88587-2.c: In function ‘a2’:
/home/marxin/Programming/testcases/pr88587-2.c:5:38: internal compiler error:
in expand_debug_locations, at cfgexpand.c:5403
__attribute__((target("sse2"))) void a2() {
^~
0x76996fea __libc_start_main
../csu/libc-start.c:308
The ICE is very old, starting from GCC 4.8.0. Before that target attribute was
not known yet.
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #7 from dominik.stras...@onespin-solutions.com --- I canse it plays a role: I am running on a CentOS Linux release 7.5.1804 which has kernel version 3.10.0-862.11.6.el7.x86_64 and glibc glibc-2.17-222.el7.i686
[Bug middle-end/88587] ICE in expand_debug_locations, at cfgexpand.c:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88587
--- Comment #9 from Martin Liška ---
> I think the canonical way of re-computing DECL_MODE would be to re-layout
> decls since that also updates RTL if that was already set. There's
> relayout_decl for this which is for example called from omp-simd-clone.c
> and the vectorizer.
That's fine, however it eventually calls
SET_DECL_MODE (decl, TYPE_MODE (type));
which calls vector_type_mode (const_tree t)
and
if (VECTOR_MODE_P (mode)
&& (!targetm.vector_mode_supported_p (mode)
|| !have_regs_of_mode[mode]))
{
scalar_int_mode innermode;
/* For integers, try mapping it to a same-sized scalar mode. */
if (is_int_mode (TREE_TYPE (t)->type_common.mode, &innermode))
{
poly_int64 size = (TYPE_VECTOR_SUBPARTS (t)
* GET_MODE_BITSIZE (innermode));
scalar_int_mode mode;
if (int_mode_for_size (size, 0).exists (&mode)
&& have_regs_of_mode[mode]) <--- HERE
return mode;
}
return BLKmode;
}
HERE we return false. Do you know how current_function influences
int_mode_for_size and (or) have_regs_of_mode?
[Bug middle-end/88587] ICE in expand_debug_locations, at cfgexpand.c:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88587
--- Comment #10 from Martin Liška ---
(In reply to Martin Liška from comment #9)
> > I think the canonical way of re-computing DECL_MODE would be to re-layout
> > decls since that also updates RTL if that was already set. There's
> > relayout_decl for this which is for example called from omp-simd-clone.c
> > and the vectorizer.
>
> That's fine, however it eventually calls
> SET_DECL_MODE (decl, TYPE_MODE (type));
> which calls vector_type_mode (const_tree t)
>
> and
>
> if (VECTOR_MODE_P (mode)
> && (!targetm.vector_mode_supported_p (mode)
> || !have_regs_of_mode[mode]))
> {
> scalar_int_mode innermode;
>
> /* For integers, try mapping it to a same-sized scalar mode. */
> if (is_int_mode (TREE_TYPE (t)->type_common.mode, &innermode))
> {
> poly_int64 size = (TYPE_VECTOR_SUBPARTS (t)
>* GET_MODE_BITSIZE (innermode));
> scalar_int_mode mode;
> if (int_mode_for_size (size, 0).exists (&mode)
> && have_regs_of_mode[mode]) <--- HERE
> return mode;
> }
>
> return BLKmode;
> }
>
> HERE we return false. Do you know how current_function influences
> int_mode_for_size and (or) have_regs_of_mode?
ok, happens here:
#0 ix86_conditional_register_usage () at
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:4802
#1 0x00ed04a0 in init_reg_sets_1 () at
/home/marxin/Programming/gcc/gcc/reginfo.c:270
#2 0x00f68b61 in target_reinit () at
/home/marxin/Programming/gcc/gcc/toplev.c:2009
#3 0x01a9f336 in save_target_globals () at
/home/marxin/Programming/gcc/gcc/target-globals.c:86
#4 0x01373dbc in ix86_set_current_function (fndecl=) at
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:5768
#5 0x00baa150 in invoke_set_current_function_hook
(fndecl=) at
/home/marxin/Programming/gcc/gcc/function.c:4629
#6 0x00bb1175 in invoke_set_current_function_hook (fndecl=) at /home/marxin/Programming/gcc/gcc/function.c:4613
#7 set_cfun (new_cfun=, force=) at
/home/marxin/Programming/gcc/gcc/function.c:4653
[Bug other/88841] New: Missed optimization transforming cascading ||s into a bit select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88841
Bug ID: 88841
Summary: Missed optimization transforming cascading ||s into a
bit select
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
It seems around GCC 7 an optimization was added turning multiple comparisons of
a small range into a bit-select. This optimization seems to be sensitive to the
ordering of the comparisons, which seems like a missed opportunity.
On x86_64 GCCs 7 and above (tested with trunk 9.0 too) with -O2 :
---snip
bool isspc_1(char c)
{
return c == ' '
|| c == '\n'
|| c == '\r'
|| c == '\t';
}
bool isspc_2(char c)
{
return c == ' '
|| c == '\r'
|| c == '\n'
|| c == '\t';
}
--- end snip (see https://godbolt.org/z/ovB_Oz )
...the isspc_2 is optimized using the bit selection optimization, but the
isspc_1 is not. The only difference is the order of the comparisons. It's not
clear to me which is actually faster, but my instinct is the results of these
two functions should be the same code.
[Bug other/88842] New: missing optimization CSE, reassociation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88842 Bug ID: 88842 Summary: missing optimization CSE, reassociation Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: ptdrnvqd at 10mail dot org Target Milestone: --- from retweet danluu ↓ https://twitter.com/johnregehr/status/923682400676093952 not every day you run across a … easy optimization missing from all of LLVM, GCC, and Intel CC… ↓ http://lists.llvm.org/pipermail/llvm-dev/2017-October/118476.html [llvm-dev] [PATCH/RFC] Modifying reassociate for improved CSE: … perf gains >> “…several people asked if this is safe; here's how LLVM safely reassociates >> addition with undefined signed overflow…” i dont know to what degree is track their development/findings or was this only llvm-side >> “… to convince another person that reassociate is a safe pass…” also may this apply outside of -ffast-math? for GCC?
[Bug c++/84849] Ambiguous resolution of braze initializer list to a class with explicit constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84849 --- Comment #7 from ensadc at mailnesia dot com --- (In reply to Zhihao Yuan from comment #6) > Here is a possibly related case: > > [...] I think this is a different bug. GCC thinks the implicitly-deleted move assignment operator `pair& pair::operator=(pair&&)` is a candidate for the assignment, which causes ambiguity with `operator=(value_type&&)` (where value_type = pair). But as part of resolution of CWG 1402, [class.copy.assign] specifies that "A defaulted move assignment operator that is defined as deleted is ignored by overload resolution".
[Bug other/88842] missing optimization CSE, reassociation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88842 --- Comment #1 from ptdrnvqd at 10mail dot org --- from retweet danluu ↓ https://twitter.com/johnregehr/status/923682400676093952 not every day you run across a … easy optimization missing from all of LLVM, GCC, and Intel CC… ↓ http://lists.llvm.org/pipermail/llvm-dev/2017-October/118476.html [llvm-dev] [PATCH/RFC] Modifying reassociate for improved CSE: … perf gains >> “…several people asked if this is safe; here's how LLVM safely reassociates >> addition with undefined signed overflow…” i dont know to what degree is track their development/findings or was this only llvm-side >> “… to convince another person that reassociate is a safe pass…” also may this apply outside of -ffast-math? for GCC? also i dont know what version, it was over a year ago
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #8 from Martin Liška --- (In reply to dominik.strasser from comment #7) > I canse it plays a role: > I am running on a CentOS Linux release 7.5.1804 > which has kernel version 3.10.0-862.11.6.el7.x86_64 > and glibc glibc-2.17-222.el7.i686 Well, to be honest the glibc is very old. Note that sanitizer are intercepting glibc calls and there are some issues with compatibility. So please, try your application on a new system. I would recommend e.g. https://software.opensuse.org/distributions/tumbleweed I can help with the system. Can you provide what kind of dependencies your application has?
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #9 from Martin Liška --- (In reply to dominik.strasser from comment #5) > ASAN from git crashes like this. Looks like a double fault. Yes, SEGFAULT happens right in the sanitizer code that's responsible for creation of a thread. Thus I suspect some incompatibility with glibc. > SignalHandler_Unix.h is in my application's code. > I've attached ASAN's debug output where I removed all messages talking about > poisoning/unpoisoning as they look unrelated.
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 Martin Liška changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #10 from Martin Liška --- (In reply to Дилян Палаузов from comment #9) > Yes, $(libdir)/bfd-plugins is a location automatically scanned by > ar/nm/ranlib. > > The question is, why GCC’s “make install” does not put there its linker > plugin. Looks at what we do in SUSE, you can have multiple packages of gcc (like gcc7, gcc8). But there's a packages 'gcc' that's responsible for creation of the following symlink: /usr/lib/bfd-plugins/liblto_plugin.so.0.0.0 -> /usr/lib64/gcc/x86_64-suse-linux/8/liblto_plugin.so.0.0.0 so then nm,ranlib,.. is relying on the 'system' compiler. > > As long as nobody installs the linker plugins under $(libdir)/bfd-plugins, > how are program ./configure’s supposed to be written in a way, that LTO > works with both Clang and GCC? Richi can you please elaborate on that?
[Bug fortran/88810] gcc/fortran/dependency.c:2200: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #3 from David Malcolm --- (In reply to kargl from comment #1) > Paul > > 'svn blame' points a finger at you with r212486. > Does this section of code ring a bell. I'm I reading r212486 correctly, the previous version of the code already had a duplicated condition: both copies of the duplicated condition were updated in r212486 from: if (reverse && reverse[n] == GFC_ENABLE_REVERSE) to: if (reverse && reverse[m] == GFC_ENABLE_REVERSE) I *think* the duplicated condition was introduced by r174302 (but I'm no expert on this code).
[Bug target/83531] Build broken on macOS 10.13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531 MCCCS changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #2 from MCCCS --- The issue is caused by `os/availability.h` or `AvailabilityInternal.h`. Instead of `API_AVAILABLE`, only `__API_AVAILABLE` is defined (Clang defines both) This is also the cause of a few failing tests (g++.dg/other/darwin-cfstring1.C for example)
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #10 from dominik.stras...@onespin-solutions.com --- Looking at the backtrace, the effects are very different between gcc 7.4 and 9.0. Making it work on a different glibc wouldn't help for me. CentOs 7.5 == RHEL 7.5 which is the latest "commercial" Linux system. What could we do to make it work?
[Bug bootstrap/88843] New: [9 Regression] make: Circular s-attr-common <- insn-conditions.md dependency dropped.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88843 Bug ID: 88843 Summary: [9 Regression] make: Circular s-attr-common <- insn-conditions.md dependency dropped. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- On x86-64, r267904 gave [hjl@gnu-cfl-1 gcc]$ pwd /export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc [hjl@gnu-cfl-1 gcc]$ make -j12 make: Circular s-attr-common <- insn-conditions.md dependency dropped. [hjl@gnu-cfl-1 gcc]$
[Bug c/88822] Strange inconsistency between types of qualified rvalues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88822 --- Comment #1 from joseph at codesourcery dot com --- If an rvalue's type (or, for that matter, an lvalue's type) is observed with _Generic, the qualifiers should be consistently dropped. If a type is observed with typeof, qualifiers need to be kept in some cases for compatibility. That's definitely the case with lvalues (because of use of typeof for defining aliases); I doubt it's the case for at least these rvalues. If a type is observed in the text of a diagnostic, there are of course no compatibility requirements on whether qualifiers are present or not; it's a question of what's most helpful for the user (and for the message about the assignment, I don't think the qualifiers are helpful even for lvalues, given that the RHS has gone through lvalue-to-rvalue conversion). (For _Atomic, the reference to p3 gets an explicit atomic_load applied by the compiler in its internal representation before the &* are applied, hence the qualifiers having been removed there.)
[Bug tree-optimization/88844] New: poor range info for number of loop iterations with a known upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88844
Bug ID: 88844
Summary: poor range info for number of loop iterations with a
known upper bound
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The number of iterations of the loop below is bounded by the size of i so the
value of n on loop exit is in the range [0, 4] but get_range_info() reports it
as [0, +INF]. As a result, the if statement is not eliminated.
void f (unsigned i)
{
unsigned n = 0;
while (i) {
i >>= 4;
++n;
}
if (n > sizeof i)
__builtin_abort ();
}
[Bug bootstrap/88843] [9 Regression] make: Circular s-attr-common <- insn-conditions.md dependency dropped.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88843 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Jakub Jelinek --- I've mistakenly committed also the t-i386 change in r267850 when I meant to commit just the Makefile.in change. Reverted in r267914.
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=88844
Summary|[9 Regression] Maybe|overly aggressive
|misleading |-Werror=format-overflow for
|-Werror=format-overflow |printf since r265648
|since r265648 |
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
The warning can be reproduced in the (over)simplified test case below. There,
it isn't strictly incorrect -- the upper bound of the width does allow the
output to exceed INT_MAX. But it arguably is overly pedantic.
The root cause in the readelf.i test case is the same: the width the warning
sees is unbounded. But the warning there is a false positive because the width
is clearly bounded. The width is computed in a loop like the one in pr88844
where GCC should be but is unable to determine the maximum number of iterations
(bounded by the size of the integer argument). As a result of the width's
upper bound being unknown it is taken as INT_MAX.
Short of examining the loop and computing the range itself there isn't much the
warning code can do to compensate for the poor range info it relies on. What
it could and maybe should do is avoid using the upper bound at level 1 and
instead use the lower bound.
GCC 8 issues the same warning for calls to sprintf. It doesn't check printf
and fprintf, so it doesn't diagnose the Binutils test case. r265648 extended
the checking to those functions and exposed the underlying issues. As a
result, even though I agree that the warning is overly aggressive, I don't
consider this bug a regression. Let me look into relaxing it.
$ cat pr88835.c && gcc -O2 -S -Wall -fdump-tree-printf-return-value=/dev/stdout
pr88835.c
void f (int n, int i)
{
if (n < 4)
n = 4;
if (i < 4)
i = 4;
__builtin_printf (" %*i", n, i);
}
;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)
pr88835.c:8: __builtin_printf: objsize = 18446744073709551615, fmtstr = " %*i"
Directive 1 at offset 0: " ", length = 1
Result: 1, 1, 1, 1 (1, 1, 1, 1)
Directive 2 at offset 1: "%*i", width in range [4, 2147483647]
pr88835.c: In function ‘f’:
pr88835.c:8:23: warning: ‘%*i’ directive output between 4 and 2147483647 bytes
may cause result to exceed ‘INT_MAX’ [-Wformat-overflow=]
8 | __builtin_printf (" %*i", n, i);
| ^~~
pr88835.c:8:21: note: directive argument in the range [4, 2147483647]
8 | __builtin_printf (" %*i", n, i);
| ^~
Result: 4, 2147483647, 2147483647, 2147483647 (5, 2147483648, 2147483648,
2147483648)
Directive 3 at offset 4: "", length = 1
f (int n, int i)
{
[local count: 1073741824]:
n_4 = MAX_EXPR ;
i_2 = MAX_EXPR ;
__builtin_printf (" %*i", n_4, i_2);
return;
}
[Bug rtl-optimization/88845] New: ICE in lra_set_insn_recog_data, at lra.c:1010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88845
Bug ID: 88845
Summary: ICE in lra_set_insn_recog_data, at lra.c:1010
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
The following ICEs for me with trunk, GCC 8 and GCC 7:
bergner@pike:~$ cat bug.i
struct a {
unsigned b;
float c;
};
void
foo (void)
{
float e;
struct a f;
e = f.c;
__asm__("" : : "f"(e));
}
bergner@pike:~$ gcc -O2 -S bug.i
bug.i: In function ‘foo’:
bug.i:12:1: internal compiler error: in lra_set_insn_recog_data, at lra.c:1010
}
^
[Bug target/88682] new test case c-c++-common/pr51628-10.c fails starting with its introduction in r267313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88682 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #5 from Steve Ellcey --- It looks like this test is violating strict aliasing. If I compile with -fno-strict-aliasing then it works. I think pointing p.i (type __int128_t) to something of type unaligned_int128_t is a standards violation in C or C++ but I am not a language lawyer. FYI: I get the same behavior with C or C++ on aarch64. It works with -O1 on aarch64 but fails with -O2 and the difference is the ordering of loads and stores.
[Bug rtl-optimization/88845] ICE in lra_set_insn_recog_data, at lra.c:1010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88845
--- Comment #1 from Peter Bergner ---
After IRA, we have the following RTL with pseudo 124 being assigned to r9,
which does not meet the "f" constraint required by the inline asm:
(insn 6 5 7 2 (set (reg:SI 124)
(const_int 0 [0])) "pr88845.i":10:5 494 {*movsi_internal1}
(expr_list:REG_EQUIV (const_int 0 [0])
(nil)))
(insn 7 6 12 2 (parallel [
(asm_operands/v ("") ("") 0 [
(subreg:SF (reg:SI 124) 0)
]
[
(asm_input:SF ("f") pr88845.i:11)
]
[] pr88845.i:11)
(clobber (reg:SI 76 ca))
]) "pr88845.i":11:3 -1
(expr_list:REG_DEAD (reg:SI 124)
(expr_list:REG_UNUSED (reg:SI 76 ca)
(nil
LRA then generates the following:
(insn 6 5 14 2 (set (reg:SI 124)
(const_int 0 [0])) "pr88845.i":10:5 494 {*movsi_internal1}
(expr_list:REG_EQUIV (const_int 0 [0])
(nil)))
(insn 14 6 7 2 (set (reg:SF 125)
(subreg:SF (reg:SI 124) 0)) "pr88845.i":11:3 -1
(nil))
(insn 7 14 12 2 (parallel [
(asm_operands/v ("") ("") 0 [
(reg:SF 125)
]
[
(asm_input:SF ("f") pr88845.i:11)
]
[] pr88845.i:11)
(clobber (reg:SI 76 ca))
]) "pr88845.i":11:3 -1
(expr_list:REG_DEAD (reg:SI 124)
(expr_list:REG_UNUSED (reg:SI 76 ca)
(nil
...and we ICE in lra_set_insn_recog_data when handling the reload insn 14.
[Bug rtl-optimization/88846] New: [9 Regression] pr69776-2.c failure on 32 bit AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88846 Bug ID: 88846 Summary: [9 Regression] pr69776-2.c failure on 32 bit AIX Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org CC: bergner at gcc dot gnu.org, segher at gcc dot gnu.org Target Milestone: --- Aliasing / LRA bug after combine.c change. r265397 .f: lwz 10,LC..2(2) lwz 9,0(3) lfd 0,0(10) stfd 0,0(4) stw 9,0(3) blr r265398 .f: lwz 9,LC..2(2) lfd 0,0(9) stfd 0,0(4) blr -maix64 .f: lwa 9,0(3) ld 10,LC..2(2) lfd 0,0(10) stfd 0,0(4) stw 9,0(3) blr
[Bug rtl-optimization/88846] [9 Regression] pr69776-2.c failure on 32 bit AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88846 David Edelsohn changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-14 Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug rtl-optimization/88846] [9 Regression] pr69776-2.c failure on 32 bit AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88846
--- Comment #2 from David Edelsohn ---
(insn 9 2 7 2 (set (reg:DF 125)
(mem/u/c:DF (reg/f:SI 124) [0 S8 A64])) "pr69776-2.c":11:7 503
{*movdf_hardfloat32}
(expr_list:REG_DEAD (reg/f:SI 124)
(expr_list:REG_EQUIV (mem:DF (reg:SI 127) [2 *qd_4(D)+0 S8 A32])
(nil
the actual insn has the read as alias set 0
so aliasing anything
but, the REG_EQUIV has set 2
and LRA uses that here
that REG_EQUIV is put there by IRA (during the IRA pass, anyway)
the reason you don't get an REG_EQUIV added on linux is there already is one
(for the 0.0 in there; on AIX we don't have that for some reason)
dse1 has put it there (a REG_EQUAL actually)
[Bug c++/88263] ICE in coverage_begin_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88263 --- Comment #7 from Martin Liška --- Author: marxin Date: Mon Jan 14 18:40:34 2019 New Revision: 267921 URL: https://gcc.gnu.org/viewcvs?rev=267921&root=gcc&view=rev Log: Fix location of tls_wrapper_fn (PR gcov-profile/88263). 2019-01-14 Martin Liska PR gcov-profile/88263 * decl2.c (get_tls_wrapper_fn): Use DECL_SOURCE_LOCATION as location of the TLS wrapper. 2019-01-14 Martin Liska PR gcov-profile/88263 * g++.dg/gcov/pr88263-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/gcov/pr88263-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836 --- Comment #31 from Gary Mills --- When I built gcc-7 with even more configuration options, including --enable-initfini-array, I got this segmentation fault on SPARC hardware: configure:3662: checking for suffix of object files configure:3684: /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/xgcc -B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/ -B/usr/gcc/7/sparc-sun-solaris2.11/bin/ -B/usr/gcc/7/sparc-sun-solaris2.11/lib/ -isystem /usr/gcc/7/sparc-sun-solaris2.11/include -isystem /usr/gcc/7/sparc-sun-solaris2.11/sys-include -c -g -O2 -mno-app-regs conftest.c >&5 conftest.c: In function 'main': conftest.c:11:1: internal compiler error: Segmentation Fault main () ^~~~ conftest.c:11:1: internal compiler error: Abort xgcc: internal compiler error: Abort (program cc1) This is a known problem, and an old one. The --enable-initfini-array option is not shown in the help output from gcc-7 configure. When I did a subsequent build without that option, I got a successful build. It's quite possible that this option was the source of all the problems.
[Bug target/88638] [9 Regression] FAIL: *string-format-1.* on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88638 --- Comment #5 from Martin Sebor --- Author: msebor Date: Mon Jan 14 18:44:00 2019 New Revision: 267922 URL: https://gcc.gnu.org/viewcvs?rev=267922&root=gcc&view=rev Log: PR target/88638 - FAIL: fsf-nsstring-format-1.s on darwin gcc/c-family/ChangeLog: PR target/88638 * c-attribs.c (positional_argument): Call valid_format_string_type_p and issue errors if it fails. * c-common.h (valid_format_string_type_p): Declare. * c-format.c (valid_stringptr_type_p): Rename... (valid_format_string_type_p): ...to this and make extern. (handle_format_arg_attribute): Adjust to new name. (check_format_string): Same. gcc/testsuite/ChangeLog: PR target/88638 * gcc.dg/format/attr-8.c: New test. * gcc.dg/darwin-cfstring-format-1.c: Adjust diagnostics. * gcc.dg/format/attr-3.c: Same. * obj-c++.dg/fsf-nsstring-format-1.mm: Same. * objc.dg/fsf-nsstring-format-1.m: Same. gcc/ChangeLog: PR target/88638 * doc/extend.texi (Darwin Format Checks): Clarify. Added: trunk/gcc/testsuite/gcc.dg/format/attr-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/c-family/c-common.h trunk/gcc/c-family/c-format.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/darwin-cfstring-format-1.c trunk/gcc/testsuite/gcc.dg/format/attr-3.c trunk/gcc/testsuite/obj-c++.dg/fsf-nsstring-format-1.mm trunk/gcc/testsuite/objc.dg/fsf-nsstring-format-1.m
[Bug target/88638] [9 Regression] FAIL: *string-format-1.* on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88638 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed via r267922.
[Bug c++/88263] ICE in coverage_begin_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88263 Martin Liška changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Fixed now.
[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836 --- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #31 from Gary Mills --- > When I built gcc-7 with even more configuration options, including > --enable-initfini-array, I got this segmentation fault on SPARC hardware: [...] > conftest.c:11:1: internal compiler error: Abort > xgcc: internal compiler error: Abort (program cc1) > > This is a known problem, and an old one. The --enable-initfini-array option > is > not shown in the help output from gcc-7 configure. When I did a subsequent > build without that option, I got a successful build. It's quite possible that > this option was the source of all the problems. As I'd mentioned before, this doesn't astonish me in the least. It took quite a bit of work for and with the Solaris linker engineers to get that support right in ld and the configure test to pass. If you're forcing that support when the test fails, it's quite likely that something is not quite right with Illumos ld's support (which was only added independently after Oracle closed down OpenSolaris).
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #11 from Martin Liška --- (In reply to dominik.strasser from comment #10) > Looking at the backtrace, the effects are very different between gcc 7.4 and > 9.0. Making it work on a different glibc wouldn't help for me. CentOs 7.5 == > RHEL 7.5 which is the latest "commercial" Linux system. What could we do to > make it work? Hm, still, the glibc is really quite old. Anyway, let's try more debugging: - using the GCC trunk, I would open the application in gdb and step through GetThreadStackAndTls, please report which line triggers the signal (handled by your app)? You can build libsanitizer with -O0 which will make debugging more easier - you can maybe build newer glibc, install it to a different location and then use something like LD_PRELOAD to test newer GCC - you can also -fsanitize=undefined, or -fsanitize=thread in order to test whether other sanitizer work - if you trust me, you can contact me personally and provide access to a system where I can do a debugging Anyway, I would be happy to help, but it's not so easy without a reproducer ;)
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714 --- Comment #11 from Jakub Jelinek --- If I add __attribute__((optimize (0))) to: static unsigned do_rpo_vn (function *fn, edge entry, bitmap exit_bbs, bool iterate, bool eliminate) and recompile stage2 tree-ssa-sccvn.o + relink stage2 cc1, then sort.i is the same between stage1/cc1 and stage2/cc1. ../stage1-gcc/cc1plus tree-ssa-sccvn.ii -quiet -mtune=cortex-a9 -mfloat-abi=hard -mfpu=vfpv3-d16 -mtls-dialect=gnu -marm -march=armv7-a+fp -g -gtoggle -O2 -fno-PIE -fno-checking -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-ipa-ra -o tree-ssa-sccvn.s compiled tree-ssa-sccvn.ii without that optimize (0) attribute still works differently from stage1/cc1. Let me attach tree-ssa-sccvn.ii and tree-ssa-sccvn.s.
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714 --- Comment #12 from Jakub Jelinek --- Created attachment 45427 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45427&action=edit tree-ssa-sccvn.ii.xz Preprocessed source
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714 --- Comment #13 from Jakub Jelinek --- Created attachment 45428 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45428&action=edit tree-ssa-sccvn.s.xz And resulting (bad) assembly
