[Bug tree-optimization/69353] New: [6 Regression] [graphite] ICE: verify_gimple failed (error: non-trivial conversion at assignment) w/ -O2 (-O3) -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69353
Bug ID: 69353
Summary: [6 Regression] [graphite] ICE: verify_gimple failed
(error: non-trivial conversion at assignment) w/ -O2
(-O3) -floop-nest-optimize
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: spop at gcc dot gnu.org
Target Milestone: ---
1. gcc-6.0.0-alpha20160117 ICEs when compiling the following reduced snippet w/
-O2 (-O3) -floop-nest-optimize:
int eh, el, oz, pc;
unsigned int ta;
void
tb(void)
{
ta = (pc != 0);
if (ta != 0)
while (pc < 0) {
int ku = (eh != 0);
for (el = 0; el < 2; ++el)
oz = el;
if (ku != (el ^ 1))
eh = ta;
++pc;
}
}
% x86_64-pc-linux-gnu-gcc-6.0.0-alpha20160117 -c -O2 -floop-nest-optimize
uqaj0uxw.c
uqaj0uxw.c: In function 'tb':
uqaj0uxw.c:5:1: error: incompatible types in PHI argument 1
tb(void)
^~
_Bool
int
eh_lsm.13_3 = PHI <0(4), eh_lsm.12_30(12)>
uqaj0uxw.c:5:1: error: incompatible types in PHI argument 0
_Bool
int
eh_lsm.13_52 = PHI
uqaj0uxw.c:5:1: error: non-trivial conversion at assignment
int
_Bool
# .MEM_50 = VDEF <.MEM_49>
eh = eh_lsm.13_52;
uqaj0uxw.c:5:1: internal compiler error: verify_gimple failed
2. Replacing an expression "oz = el;" w/ "pc = el;" demonstrates another error
during GIMPLE verification:
n5rzdu1s.c: In function 'tb':
n5rzdu1s.c:5:1: error: mismatching comparison operand types
tb(void)
^~
int
_Bool
if (eh_lsm.12_11 != 0)
n5rzdu1s.c:5:1: internal compiler error: verify_gimple failed
[Bug bootstrap/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-19 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Markus Trippelsdorf --- Also happens with a plain profiledbootstrap without bootstrap-lto.
[Bug libstdc++/69354] New: std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354
Bug ID: 69354
Summary: std::thread doesn't support move-only callable objects
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: anthony.ajw at gmail dot com
Target Milestone: ---
Created attachment 37390
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37390&action=edit
move_only_thread.cpp
Trying to construct a std::thread with a move-only function object produces a
compilation failure in tuple. This should compile OK.
The attached example fails with the error message below:
In file included from /usr/include/c++/5/functional:55:0,
from /usr/include/c++/5/thread:39,
from move_only_thread.cpp:1:
/usr/include/c++/5/tuple: In instantiation of ‘struct std::_Head_base<0ul,
MoveOnly, true>’:
/usr/include/c++/5/tuple:339:12: required from ‘struct std::_Tuple_impl<0ul,
MoveOnly>’
/usr/include/c++/5/tuple:463:11: required from ‘class std::tuple’
/usr/include/c++/5/functional:1534:39: required from ‘struct
std::_Bind_simple’
/usr/include/c++/5/thread:137:59: required from
‘std::thread::thread(_Callable&&, _Args&& ...) [with _Callable = MoveOnly;
_Args = {}]’
move_only_thread.cpp:16:31: required from here
/usr/include/c++/5/tuple:64:17: error: ‘constexpr std::_Head_base<_Idx, _Head,
true>::_Head_base(const std::_Head_base<_Idx, _Head, true>&) [with long
unsigned int _Idx = 0ul; _Head = MoveOnly]’ declared to take const reference,
but implicit declaration would take non-const
constexpr _Head_base(const _Head_base&) = default;
[Bug bootstrap/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352
--- Comment #4 from Jan Smets ---
compile with : -xc -c pr69352.best -w -o /dev/null -O1
$ cat pr69352.best
typedef enum {
REG_HSTRH,
REG_HSTRL,
REG_HFAERH,
REG_HFAERL,
REG_HIMRH,
REG_HIMRL,
REG_HCMRH,
REG_HCMRL,
REG_HADDRH,
REG_HADDRL,
REG_HGPRH,
REG_HGPRL,
REG_HWRBFSRH,
REG_HRBCF,
REG_MAX
} DLLA;
a[][REG_MAX];
b, c, d, e, f, g, h, i;
fn1(p1) {
unsigned j;
int k = 0, l;
DLLA m;
if (h)
m = REG_HWRBFSRH;
else
m = REG_HRBCF;
if (a[p1][m])
l = fn1;
a[p1][i] = l;
while (c) {
if (b) {
if (f)
k = 1;
fn2();
}
for (; d;)
j++;
}
while (c) {
if (a[p1][REG_HWRBFSRH]) {
if (g)
k = 1;
j++;
}
c = e;
}
return k;
}
[Bug bootstrap/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352
--- Comment #5 from Jakub Jelinek ---
Reproduces with -O1 on x86_64-linux too. Slightly cleaned up testcase:
int a[10][14], b, c, d, e, f, g, h, i;
void bar (void);
int
foo (int x)
{
unsigned j;
int k = 0, l;
int m;
if (h)
m = 12;
else
m = 13;
if (a[x][m])
l = (long) foo;
a[x][i] = l;
while (c)
{
if (b)
{
if (f)
k = 1;
bar ();
}
for (; d;)
j++;
}
while (c)
{
if (a[x][12])
{
if (g)
k = 1;
j++;
}
c = e;
}
return k;
}
[Bug tree-optimization/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352 Andrew Pinski changed: What|Removed |Added Keywords||build, ice-on-valid-code Component|bootstrap |tree-optimization Target Milestone|--- |6.0
[Bug tree-optimization/69353] [6 Regression] [graphite] ICE: verify_gimple failed (error: non-trivial conversion at assignment) w/ -O2 (-O3) -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69353 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0
[Bug middle-end/69347] [6 regression] excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69347 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0
[Bug tree-optimization/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- Mine.
[Bug tree-optimization/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352
--- Comment #7 from Jakub Jelinek ---
There are various bugs in the r232508 change.
The
gcc_assert (sz0 == sz1);
gcc_assert (max0 == max1);
gcc_assert (rev0 == rev1);
asserts are clearly bogus, while for compatible type I bet size will be always
the same, maximum size can be arbitrary (it will be either equal to size, then
it is a fixed access, or it will be larger, then it is a variable access), and
the reverse stuff looks weird (e.g. I think the lack of
REF_REVERSE_STORAGE_ORDER testing in operand_equal_p is a bug). For a variable
access, even if you remove the above max{0,1} assert, I think you would happily
equate say a[i] and a[j] ARRAY_REFs, because they have the same off (likely 0)
and max (likely size of array in bits). Another problem I see in the
return equal_mem_array_ref_p (expr0->ops.single.rhs,
expr1->ops.single.rhs)
|| operand_equal_p (expr0->ops.single.rhs,
expr1->ops.single.rhs, 0);
case; under some conditions you decide to hash the MEM_REF/ARRAY_REFs as
MEM_REF , hash of base, offset and size, so you should use the same conditions
to decide if you use equal_mem_array_ref_p or operand_equal_p, using the other
one if you hashed it differently will just lead to hard to maintain randomness
- the expressions are hashed using one property, and so the other equality
function depends only on whether they happen to appear in the same hash bucket
anyway or not, usually not. Fixing this should fix also the variable accesses
- you'd then try to use the get_ref_base_and_extent stuff only for the fixed
accesses and use operand_equal_p otherwise. Plus, I'm not sure in what places
this hashing is used, I'm worried you might hash MEM_REFs with different alias
types for the accesses as equal, which for some uses might be fine, if you are
not trying to replace one with another etc., but for other cases it might lead
to wrong-code.
CCing Eric on whether REF_REVERSE_STORAGE_ORDER should be checked in
operand_equal_p and whether TYPE_REVERSE_STORAGE_ORDER doesn't have to be
tested in useless_type_conversion_p (perhaps the latter is ok, if it is not
possible for two aggregates with the same TYPE_CANONICAL to have different
TYPE_REVERSE_STORAGE_ORDER).
[Bug lto/69133] [6 Regression] LTO segfault in lto_get_decl_name_mapping() on 483.xalancbmk with -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69133 --- Comment #7 from prathamesh3492 at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #5) > The problem seems to be that cgraph_node::get_untransformed_body checks > presence of body by DECL_RESULT which is NULL for thunks. Rest of places > seems to check for DECL_ARGUMENTS. Thanks for pointing out. I was wondering why this ICE'd only with -flto-partition=none and not with other partitioning methods ? For the test-case, with partitioning enabled, get_untransformed_body () was called only once per node. Or is this issue irrelevant to partitioning ? Thanks, Prathamesh > > I am testing: > Index: cgraph.c > === > --- cgraph.c(revision 232466) > +++ cgraph.c(working copy) > @@ -3305,10 +3295,11 @@ cgraph_node::get_untransformed_body (voi >size_t len; >tree decl = this->decl; > > - if (DECL_RESULT (decl)) > + /* Check if body is already there. */ > + if (!DECL_ARGUMENTS (decl)) > return false; > > - gcc_assert (in_lto_p); > + gcc_assert (in_lto_p && !DECL_RESULT (decl)) > >timevar_push (TV_IPA_LTO_GIMPLE_IN);
[Bug tree-optimization/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> There are various bugs in the r232508 change.
> The
> gcc_assert (sz0 == sz1);
> gcc_assert (max0 == max1);
> gcc_assert (rev0 == rev1);
> asserts are clearly bogus, while for compatible type I bet size will be
> always the same, maximum size can be arbitrary (it will be either equal to
> size, then it is a fixed access, or it will be larger, then it is a variable
> access), and the reverse stuff looks weird (e.g. I think the lack of
> REF_REVERSE_STORAGE_ORDER testing in operand_equal_p is a bug). For a
> variable access, even if you remove the above max{0,1} assert, I think you
> would happily equate say a[i] and a[j] ARRAY_REFs, because they have the
> same off (likely 0) and max (likely size of array in bits). Another problem
> I see in the
> return equal_mem_array_ref_p (expr0->ops.single.rhs,
> expr1->ops.single.rhs)
> || operand_equal_p (expr0->ops.single.rhs,
> expr1->ops.single.rhs, 0);
> case; under some conditions you decide to hash the MEM_REF/ARRAY_REFs as
> MEM_REF , hash of base, offset and size, so you should use the same
> conditions to decide if you use equal_mem_array_ref_p or operand_equal_p,
> using the other one if you hashed it differently will just lead to hard to
> maintain randomness - the expressions are hashed using one property, and so
> the other equality function depends only on whether they happen to appear in
> the same hash bucket anyway or not, usually not. Fixing this should fix
> also the variable accesses - you'd then try to use the
> get_ref_base_and_extent stuff only for the fixed accesses and use
> operand_equal_p otherwise. Plus, I'm not sure in what places this hashing
> is used, I'm worried you might hash MEM_REFs with different alias types for
> the accesses as equal, which for some uses might be fine, if you are not
> trying to replace one with another etc., but for other cases it might lead
> to wrong-code.
See the patch I posted which fixes the variable index issue. operand_equal_p
should always work but yes, for compile-time things may be improved (I
originally suggested to use the SCCVN memory ref storing/hashing and I guess
we should try to commonize this for GCC 7).
As DOM is never materializing memory refs but just replace it with an
earlier result the alias thing is not an issue - it might just end up
hiding undefined behavior.
> CCing Eric on whether REF_REVERSE_STORAGE_ORDER should be checked in
> operand_equal_p and whether TYPE_REVERSE_STORAGE_ORDER doesn't have to be
> tested in useless_type_conversion_p (perhaps the latter is ok, if it is not
> possible for two aggregates with the same TYPE_CANONICAL to have different
> TYPE_REVERSE_STORAGE_ORDER).
On the REF_REVERSE_STORAGE_ORDER issue I have no idea. I suppose we should
compare it for equality rather than asserting its equality.
[Bug middle-end/69347] [6 regression] excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69347 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/69328] [6 Regression] ice in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1379 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69328 --- Comment #6 from Richard Biener --- Looks good - can you take this bug then?
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-01-19
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
std::thread is doing the right thing, the problem is definitely in tuple:
#include
struct MoveOnly
{
MoveOnly(MoveOnly&) =delete;
MoveOnly& operator=(MoveOnly&) =delete;
MoveOnly(MoveOnly&& ){}
MoveOnly(){}
};
std::tuple t{ MoveOnly{} };
[Bug target/68015] ICE in s390_emit_compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68015 Andreas Krebbel changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andreas Krebbel --- Fixed per comment 3
[Bug bootstrap/58035] LRA: S/390: Ada bootstrap fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58035 Andreas Krebbel changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andreas Krebbel --- I can't say what change fixed this for us but Ada bootstraps fine with GCC 5 and head.
[Bug lto/69133] [6 Regression] LTO segfault in lto_get_decl_name_mapping() on 483.xalancbmk with -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69133 --- Comment #8 from Jan Hubicka --- Well, -flto-partition=none does bot IPA optimization and codegen in one run. In this case the body was once read by ipa-cp to duplicate the thunk and second time by expand_thunk. With other methods the streaming happened in between that hides the problem.
[Bug tree-optimization/69353] [6 Regression] [graphite] ICE: verify_gimple failed (error: non-trivial conversion at assignment) w/ -O2 (-O3) -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69353 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c++/69355] New: Wrong results with -O1 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355
Bug ID: 69355
Summary: Wrong results with -O1 optimization
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andreas.hilti at hotmail dot com
Target Milestone: ---
Consider the following program: It reads in a Vector, normalizes it, and
outputs it.
typedef tvmet::Vector Vector;
int main(){
Vector v1;
v1 = 1,2,3;
Vector r;
r = v1/norm2(v1);
std::cout << r;
}
The compiler version is:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-default-libstdcxx-abi=gcc4-compatible --with-isl
--enable-libmpx --enable-gnu-indirect-function --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
With -O1, it results in the incorrect result:
g++ -O1 mytest.cpp -I../include -save-temps
(no output)
(the preprocessed file is attached)
./a.out
[
inf, inf, inf
]
With -O0, it results in the correct result:
g++ -O0 mytest.cpp -I../include
(no output)
./a.out
[
0.267261, 0.534522, 0.801784
]
The same behaviour can also be observed using g++ 5.2.1.
With g++ 4.8.4 and 4.9.2, it leads to the correct result with -O1 and -O0.
P.S. This is my first bug report; I'm sorry if I anything is wrong/missing.
[Bug target/69305] [5/6 Regression] wrong code with -O and int128 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69305 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #11 from Nick Clifton --- Created attachment 37391 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37391&action=edit Extended adddi3_compare pattern (In reply to Richard Henderson from comment #10) > Mine. oops - I had just started looking at this one too. :-) I have uploaded a possible patch, although I have not got very far in testing it yet. Maybe it will be of some use ? Cheers Nick
[Bug c++/69355] Wrong results with -O1 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355 --- Comment #1 from Andreas Hiltebrand --- Created attachment 37392 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37392&action=edit the preprocessed file The attachment was slightly too large, you can download it from: https://www.dropbox.com/s/trtu01978cb4hsi/mytest.ii?dl=0
[Bug debug/68860] [6 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16 arg1 == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860 Jakub Jelinek changed: What|Removed |Added Target Milestone|6.0 |7.0 --- Comment #8 from Jakub Jelinek --- The testcase is fixed for non-LTO, for LTO it is more work, so stage1 material.
[Bug tree-optimization/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352
--- Comment #9 from alalaw01 at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> There are various bugs in the r232508 change.
> The
> gcc_assert (sz0 == sz1);
> gcc_assert (max0 == max1);
> gcc_assert (rev0 == rev1);
> asserts are clearly bogus, while for compatible type I bet size will be
> always the same, maximum size can be arbitrary (it will be either equal to
> size, then it is a fixed access, or it will be larger, then it is a variable
> access), and the reverse stuff looks weird (e.g. I think the lack of
> REF_REVERSE_STORAGE_ORDER testing in operand_equal_p is a bug). For a
> variable access, even if you remove the above max{0,1} assert, I think you
> would happily equate say a[i] and a[j] ARRAY_REFs, because they have the
> same off (likely 0) and max (likely size of array in bits). Another problem
> I see in the
> return equal_mem_array_ref_p (expr0->ops.single.rhs,
> expr1->ops.single.rhs)
> || operand_equal_p (expr0->ops.single.rhs,
> expr1->ops.single.rhs, 0);
> case; under some conditions you decide to hash the MEM_REF/ARRAY_REFs as
> MEM_REF , hash of base, offset and size, so you should use the same
> conditions to decide if you use equal_mem_array_ref_p or operand_equal_p,
Agreed, yes. That would fix the bogus asserts, right - we would then only use
equal_mem_array_ref_p if size==max_size.
> Plus, I'm not sure in what places this hashing
> is used, I'm worried you might hash MEM_REFs with different alias types for
> the accesses as equal, which for some uses might be fine, if you are not
> trying to replace one with another etc., but for other cases it might lead
> to wrong-code.
I think it should be OK to ignore differences in alias type for DOM
optimizations etc., indeed, which is where this was intended.
[Bug c++/69355] Wrong results with -O1 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355 Jonathan Wakely changed: What|Removed |Added Attachment #37392|0 |1 is obsolete|| --- Comment #2 from Jonathan Wakely --- Created attachment 37393 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37393&action=edit preprocessed source Preprocessed source from the dropbox link attached. There's a wonderful thing called compression.
[Bug c++/68767] [6 regression] spurious warning: null argument where non-null required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68767 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jakub Jelinek --- Fixed.
[Bug middle-end/61225] [5/6 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2
[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- So, any progress on this? Or shall we just xfail the test?
[Bug c++/66858] [6 Regression] FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison on aarch64-none-elf, arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66858 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Could you please preprocess (without pch) system-2.Hs and replace its content temporarily with the preprocessed source and see if you can still reproduce it? If yes, can you please attach it?
[Bug c++/68782] [6 regression] bad reference member formed with constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68782 --- Comment #5 from Jakub Jelinek --- Note, I gave up on this PR, so if Jason or somebody more familiar with C++ FE than myself could pick it up, it would be greatly appreciated.
[Bug c++/69355] Wrong results with -O1 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355 --- Comment #3 from Andreas Hiltebrand --- I'm sorry. I did not zip it as the guidelines said explicitly: What we do not want [...] An attached archive (tar, zip, shar, whatever) containing all (or some :-) of the above. and the preprocessed file is mentioned above. Thanks for fixing it.
[Bug c++/66858] [6 Regression] FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison on aarch64-none-elf, arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66858 --- Comment #4 from ktkachov at gcc dot gnu.org --- It passes today on arm-none-eabi and aarch64-none-elf. John, does it still fail on hppa64?
[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||mark at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- So, if what we care about here is solely debug info size and canonicalization of the order and amount of DW_TAG_atomic_type/DW_TAG_restrict_type/DW_TAG_volatile_type/DW_TAG_const_type DIEs for the same non-qualified type, we could perhaps just optimize it later, in one of the numerous walks over the DIE tree. Perhaps just if we see one of these 4 DIEs, and the referenced DIE has the same parent, just move all the qualified variants next to the underlying unqualified type, and then once they are all moved there, figure out what qualified variants we have, determine how to get fewest possible qualified DIEs for the non-qualified type, and build new qualified DIEs if needed and adjust them, and for the ones that should be replaced by others perhaps use a new die_struct bit to tell that all references should be rewritten to refer to some other DIE (and unlink them from the tree), then in another walk adjust all references to so marked DIEs. Mark/Jason, does that sound reasonable to you?
[Bug c++/69355] Wrong results with -O1 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-19 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- I suspect there's a dangling reference somewhere, but there are no relevant warnings or ubsan or valgrind errors, so confirming.
[Bug middle-end/69347] [6 regression] excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69347 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- r228739 takes 18m40s for me (unoptimized build), while 736 only 2m14s (roughly the same as 5.1-ish).
[Bug lto/69133] [6 Regression] LTO segfault in lto_get_decl_name_mapping() on 483.xalancbmk with -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69133 --- Comment #9 from Jan Hubicka --- Author: hubicka Date: Tue Jan 19 11:57:41 2016 New Revision: 232552 URL: https://gcc.gnu.org/viewcvs?rev=232552&root=gcc&view=rev Log: PR lto/69133 * cgraphunit.c (cgraph_node::expand_thunk): When forcing gimple assume that the node has body. * cgraph.c (cgraph_node::get_untransformed_body): Use gimple_body_p check. * g++.dg/lto/pr69133_0.C: New testcase. * g++.dg/lto/pr69133_1.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/pr69133_0.C trunk/gcc/testsuite/g++.dg/lto/pr69133_1.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug lto/69136] [6 Regression] ICE in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c:991
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69136 --- Comment #5 from Jan Hubicka --- Author: hubicka Date: Tue Jan 19 11:59:58 2016 New Revision: 232553 URL: https://gcc.gnu.org/viewcvs?rev=232553&root=gcc&view=rev Log: PR lto/69136 * lto-symtab.c (lto_symtab_prevailing_virtual_decl): Abstract decls have no assemblernames. * g++.dg/torture/pr69136.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr69136.C Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-symtab.c trunk/gcc/testsuite/ChangeLog
[Bug web/69356] New: Wrong description of compound literals for scalar types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69356 Bug ID: 69356 Summary: Wrong description of compound literals for scalar types Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: christian.brauner at mailbox dot org Target Milestone: --- In section 6.26 Compound Literals of the gcc manual it is stated that "Compound literals for scalar types and union types are also allowed, but then the compound literal is equivalent to a cast." Which is either wrong or at least misleading. A cast does not yield an lvalue whereas a compound literal for scalar types does. So either this line should go into a little more detail as to how compound literals for scalar types and unions are equivalent to casts or the subclause "but then the compound literal is equivalent to a cast" should be dropped.
[Bug web/69356] Wrong description of compound literals for scalar types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69356 Christian Brauner changed: What|Removed |Added Keywords||documentation URL||https://gcc.gnu.org/onlined ||ocs/gcc/Compound-Literals.h ||tml --- Comment #1 from Christian Brauner --- The rationale behind this can be found in section 6.5.2.5 [Compound literals] of the C-standard (http://www.iso-9899.info/n1570.html) in Footnote 99: "Footnote 99) Note that this differs from a cast expression. For example, a cast specifies a conversion to scalar types or void only, and the result of a cast expression is not an lvalue."
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> MoveOnly(MoveOnly&) =delete;
This is not caused by the faxct it's move-only, but by the unconventional
non-const parameter on the deleted copy constructor. If it's a const reference
then move-only types work as expected (and as widely tested in the testsuite!)
I'm tempted to call it a core defect that the defaulted copy constructor
doesn't just get deleted here:
struct MoveOnly
{
MoveOnly(MoveOnly&) =delete;
MoveOnly(MoveOnly&& ){}
MoveOnly(){}
};
struct D : MoveOnly {
D(const D&) = default;
D(D&&) = default;
D() = default;
};
The base class has a deleted copy ctor, so who cares that the derived class
defaults it with a different signature, it should just delete it in the derived
class too. However, 12.8 [class.copy] p11 (11.2) doesn't apply here.
[Bug c++/69355] Wrong results with -O1 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Started to output inf with r214748.
[Bug middle-end/69347] [6 regression] excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69347 --- Comment #3 from Markus Trippelsdorf --- Manual git-bisect on gcc112 points to the same revision: r228739.
[Bug go/69357] New: libgo refers to _end in a non-weak way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69357
Bug ID: 69357
Summary: libgo refers to _end in a non-weak way
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: rguenth at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
bfd has
/* A symbol from a library loaded via DT_NEEDED of some
other library is referenced by a regular object.
Add a DT_NEEDED entry for it. Issue an error if
--no-add-needed is used and the reference was not
a weak one. */
if (old_bfd != NULL
&& (elf_dyn_lib_class (abfd) & DYN_NO_NEEDED) != 0)
{
(*_bfd_error_handler)
(_("%B: undefined reference to symbol '%s'"),
old_bfd, name);
bfd_set_error (bfd_error_missing_dso);
goto error_free_vers;
}
and with -static-libgo you get a reference to _end from malloc.o from
runtime/malloc.goc:
void
runtime_mallocinit(void)
{
byte *p, *p1;
uintptr arena_size, bitmap_size, spans_size, p_size;
extern byte _end[];
which uses a non-weak reference to this "magic" symbol marking the end of the
BSS section.
Unfortunately all shlibs provide this symbol as well so if you do
gccgo-5 -lsomelib -static-libgo
the you get sth like the following from ld:
libgo.a(malloc.o): undefined reference to symbol '_end'
libselinux.so: error adding symbols: DSO missing from command line
bfd source suggests to make the _end reference in libgo weak.
[Bug go/69357] libgo refers to _end in a non-weak way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69357 --- Comment #1 from Richard Biener --- Btw, might be an interesting interaction between --no-add-needed and --as-needed as well (--as-needed is used by default by us). But that would point to a linker issue. No testcase - this was observed when compiling docker 1.8.3 with GCC 5 and gccgo on s390x with -static-libgo (plus --as-needed, --no-add-needed is the default AFAIK). But it might be "easy" to create an artificial testcase that fails the same way. Anyway, the _end reference is surely weird (given the shared libgo will provide it itself).
[Bug lto/69133] [6 Regression] LTO segfault in lto_get_decl_name_mapping() on 483.xalancbmk with -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69133 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jan Hubicka --- Fixed.
[Bug lto/69136] [6 Regression] ICE in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c:991
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69136 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jan Hubicka --- Fixed.
[Bug sanitizer/68824] [6 Regression] libtsan is missing the __interceptor___tls_get_addr symbol without bumping the soname
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68824 --- Comment #10 from Dmitry Vyukov --- Submitted in: http://llvm.org/viewvc/llvm-project?view=revision&revision=258119
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354 --- Comment #3 from Anthony Williams --- I hadn't noticed I had omitted the const! Surely the intent of 12.8p11.2 is that if you can't actually copy the bases and/or members with the specified signature then the defaulted copy constructor is deleted? Are you going to file the DR or shall I? Potential core defect aside, I still think this class should work with std::thread, as it fits the MoveConstructible requirement.
[Bug c++/69355] [5/6 Regression] Wrong results with -O1 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Known to work||4.9.3 Target Milestone|--- |5.4 Summary|Wrong results with -O1 |[5/6 Regression] Wrong |optimization|results with -O1 ||optimization Known to fail||5.3.0, 6.0
[Bug rtl-optimization/68955] [6 Regression] wrong code at -O3 on x86-64-linux-gnu in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68955 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Tue Jan 19 12:34:45 2016 New Revision: 232554 URL: https://gcc.gnu.org/viewcvs?rev=232554&root=gcc&view=rev Log: PR rtl-optimization/68955 PR rtl-optimization/64557 * dse.c (record_store, check_mem_read_rtx): Don't call get_addr here. Fix up formatting. * alias.c (get_addr): Handle VALUE +/- CONST_SCALAR_INT_P. * gcc.dg/torture/pr68955.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr68955.c Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/dse.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/64557] get_addr in true_dependence_1 cannot handle VALUE inside an expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Tue Jan 19 12:34:45 2016 New Revision: 232554 URL: https://gcc.gnu.org/viewcvs?rev=232554&root=gcc&view=rev Log: PR rtl-optimization/68955 PR rtl-optimization/64557 * dse.c (record_store, check_mem_read_rtx): Don't call get_addr here. Fix up formatting. * alias.c (get_addr): Handle VALUE +/- CONST_SCALAR_INT_P. * gcc.dg/torture/pr68955.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr68955.c Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/dse.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/68955] [6 Regression] wrong code at -O3 on x86-64-linux-gnu in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68955 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed.
[Bug target/69345] [6 Regression] 459.GemsFDTD regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69345 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-19 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- Ok, so as expected there are a few missed CSEs because of the wrong-code fix. For examle in UPML.F90 upmlupdatee, upmlupdateh and some more functions and in NFT.F90 for fre1 / fre3 plus in fourier_transf.F90 starting with pre (though that looks like spurious differences). That is after I removed differences stemming from restoring SSA info only after eliminate () (which eventually copies that to the leader). That's not 100% safe I think because of the redundant store removal we perform there which dispatches to SCCVN again. In fact I don't see how we can safely "interleave" those two. Adjusting the points-to/range-info adjusting code to use the "saved" info is a bit ugly :/ But the missed CSEs seem to be the reason for the slowdown as even with the range-info things "fixed" r232401 is 9 seconds slower (330s vs. 321s). Will have to try reducing a testcase and see what can be done here.
[Bug middle-end/68832] FAIL: gcc.c-torture/execute/alias-2.c -O1 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68832 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jan Hubicka --- Should be fixed by the following commit: 2016-01-14 Jan Hubicka * alias.c (compare_base_symbol_refs): New function. (rtx_equal_for_memref_p, base_alias_check, memrefs_conflict_p): Use it.
[Bug sanitizer/68824] [6 Regression] libtsan is missing the __interceptor___tls_get_addr symbol without bumping the soname
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68824 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Tue Jan 19 12:45:54 2016 New Revision: 232555 URL: https://gcc.gnu.org/viewcvs?rev=232555&root=gcc&view=rev Log: PR sanitizer/68824 * tsan/tsan_interceptors.cc (NEED_TLS_GET_ADDR, __tls_get_addr, InitializeInterceptors): Cherry pick upstream r258119. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/tsan/tsan_interceptors.cc
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354 --- Comment #4 from Jonathan Wakely --- (In reply to Anthony Williams from comment #3) > I hadn't noticed I had omitted the const! It took me a while to spot it too! > Surely the intent of 12.8p11.2 is that if you can't actually copy the bases > and/or members with the specified signature then the defaulted copy > constructor is deleted? One would think so, yes. > Are you going to file the DR or shall I? I'll do so. > Potential core defect aside, I still think this class should work with > std::thread, as it fits the MoveConstructible requirement. Yes, I tried to find a way to declare this INVALID but couldn't find one :-) The fact we use std::tuple in std::thread is purely an implementation detail and any limitation in our tuple shouldn't prevent valid uses of std::thread.
[Bug lto/61886] [4.9/5/6 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 Jan Hubicka changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #58 from Jan Hubicka --- Fixed.
[Bug sanitizer/68824] [6 Regression] libtsan is missing the __interceptor___tls_get_addr symbol without bumping the soname
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68824 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed.
[Bug ipa/65797] [5/6 regression] IPA ICF causes function to be emitted with no debug line info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797 --- Comment #12 from Jan Hubicka --- OK, I wonder if the patch attached in Commment #8 (i.e. outputting debug info for the wrapper) seems preferred solution? we probably can either commit it or not and leave this to the general PR that ipa-icf messes up backtraces.
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354 Ville Voutilainen changed: What|Removed |Added Status|NEW |ASSIGNED CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com --- Comment #5 from Ville Voutilainen --- I'll see what I can do. :)
[Bug target/69129] [6 Regression] ICE in get_attr_got, at config/mips/mips.md:694 on mips-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69129 Paul Hua changed: What|Removed |Added CC||paul.hua.gm at gmail dot com --- Comment #4 from Paul Hua --- The bug same as pr69012 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012
[Bug lto/61886] [4.9/5/6 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 Richard Biener changed: What|Removed |Added Known to work||6.0 Target Milestone|4.9.4 |6.0 Known to fail|5.0 |5.3.0 --- Comment #59 from Richard Biener --- For GCC 6 only though.
[Bug rtl-optimization/47992] ICE: SIGSEGV in ira_reuse_stack_slot (ira-color.c:2887) with -fweb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47992 Bernd Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Bernd Schmidt --- Patch committed as r232556.
[Bug ipa/66223] [5/6 Regression] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223
--- Comment #8 from Jan Hubicka ---
Well, if you rely on undefined behaviour, you should not be surprised when your
program breaks with optimization. I am testing the following patch:
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 232555)
+++ ipa-devirt.c(working copy)
@@ -2326,6 +2326,14 @@ referenced_from_vtable_p (struct cgraph_
}
return found;
}
+static bool
+is_cxa_pure_virtual_p (tree target)
+{
+ return target && TREE_CODE (TREE_TYPE (target)) != METHOD_TYPE
+&& DECL_NAME (target)
+&& !strcmp (IDENTIFIER_POINTER (DECL_NAME (target)),
+"__cxa_pure_virtual");
+}
/* If TARGET has associated node, record it in the NODES array.
CAN_REFER specify if program can refer to the target directly.
@@ -2341,11 +2349,12 @@ maybe_record_node (vec &
{
struct cgraph_node *target_node, *alias_target;
enum availability avail;
+ bool pure_virtual = is_cxa_pure_virtual_p (target);
- /* cxa_pure_virtual and __builtin_unreachable do not need to be added into
+ /* __builtin_unreachable do not need to be added into
list of targets; the runtime effect of calling them is undefined.
Only "real" virtual methods should be accounted. */
- if (target && TREE_CODE (TREE_TYPE (target)) != METHOD_TYPE)
+ if (target && TREE_CODE (TREE_TYPE (target)) != METHOD_TYPE &&
!pure_virtual)
return;
if (!can_refer)
@@ -2388,6 +2397,7 @@ maybe_record_node (vec &
??? Maybe it would make sense to be more aggressive for LTO even
elsewhere. */
if (!flag_ltrans
+ && !pure_virtual
&& type_in_anonymous_namespace_p (DECL_CONTEXT (target))
&& (!target_node
|| !referenced_from_vtable_p (target_node)))
@@ -2401,6 +2411,20 @@ maybe_record_node (vec &
{
gcc_assert (!target_node->global.inlined_to);
gcc_assert (target_node->real_symbol_p ());
+ /* Only add pure virtual if it is the only possible target. This way
+we will preserve the diagnostics about pure virtual called in many
+cases without disabling optimization in other. */
+ if (pure_virtual)
+ {
+ if (nodes.length ())
+ return;
+ }
+ /* If we found a real target, take away cxa_pure_virtual. */
+ else if (!pure_virtual && nodes.length () == 1
+ && is_cxa_pure_virtual_p (nodes[0]->decl))
+ nodes.pop ();
+ if (pure_virtual && nodes.length ())
+ return;
if (!inserted->add (target))
{
cached_polymorphic_call_targets->add (target_node);
which attempts to preserve the call to cxa_pure_virtual in cases it is cheap to
do so (i.e. we know it is the only target of the call).
It is still more expensive to call cxa_pure_virtual compared to
bulitin_unreachable. I will try to get some stats on firefox how often it
matters in practice.
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354 --- Comment #6 from Jonathan Wakely --- We can't even partially specialize the _Head_base type on whether the element type is M(M&) or M(const M&) because we can't detect which signature has been deleted by using something like is_constructible.
[Bug tree-optimization/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352 --- Comment #10 from Richard Biener --- Author: rguenth Date: Tue Jan 19 13:19:01 2016 New Revision: 232557 URL: https://gcc.gnu.org/viewcvs?rev=232557&root=gcc&view=rev Log: 2016-01-19 Richard Biener PR tree-optimization/69352 * tree-ssa-scopedtables.c (avail_expr_hash): Check for size == -1. (equal_mem_array_ref_p): Constrain size and max size properly. Compare the reverse flag. * gcc.dg/torture/pr69352.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr69352.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-scopedtables.c
[Bug tree-optimization/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug debug/65779] [5/6 Regression] undefined local symbol on powerpc [regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 --- Comment #16 from Jakub Jelinek --- Author: jakub Date: Tue Jan 19 13:21:04 2016 New Revision: 232558 URL: https://gcc.gnu.org/viewcvs?rev=232558&root=gcc&view=rev Log: PR debug/65779 * shrink-wrap.c: Include valtrack.h. (move_insn_for_shrink_wrap): Add DEBUG argument. If MAY_HAVE_DEBUG_INSNS, call dead_debug_add on DEBUG_INSNs in between insn and where it will be moved to. Call dead_debug_insert_temp. (prepare_shrink_wrap): Adjust caller. Call dead_debug_local_init first and dead_debug_local_finish at the end. For uses and defs bitmap, handle all regs in between REGNO and END_REGNO, not just the first one. * gcc.dg/pr65779.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr65779.c Modified: trunk/gcc/ChangeLog trunk/gcc/shrink-wrap.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/66223] [5/6 Regression] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223 --- Comment #9 from Jakub Jelinek --- I think it is a bad idea to pessimize code just because it might be invoking undefined behavior. I'd really do this only if the user asked for that, and IMHO such a switch is flag_sanitize & SANITIZE_UNREACHABLE (or we could add -fsanitize=pure-virtual, part of -fsanitize=undefined), which would just disable such optimizations (i.e. unless proven pure virtual might not be called, don't remove it from the candidates).
[Bug debug/65779] [5 Regression] undefined local symbol on powerpc [regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 Jakub Jelinek changed: What|Removed |Added Summary|[5/6 Regression] undefined |[5 Regression] undefined |local symbol on powerpc |local symbol on powerpc |[regression]|[regression] --- Comment #17 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/69336] Constant value not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69336 --- Comment #6 from Richard Biener --- Author: rguenth Date: Tue Jan 19 13:27:11 2016 New Revision: 232559 URL: https://gcc.gnu.org/viewcvs?rev=232559&root=gcc&view=rev Log: 2016-01-19 Richard Biener PR tree-optimization/69336 * tree-ssa-scopedtables.c (avail_expr_hash): Handle all handled components with get_ref_base_and_extent. (equal_mem_array_ref_p): Adjust. * g++.dg/tree-ssa/pr69336.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-scopedtables.c
[Bug tree-optimization/69336] Constant value not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69336 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.0 Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed on trunk.
[Bug tree-optimization/67755] [5 Regression] Bad edge probability/block freqency for tree jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67755 --- Comment #10 from Bill Schmidt --- Hi Jeff, I think we would appreciate having this backported to 5 so it can be fixed in those distro releases that ship 5. This caused a significant drop in an important benchmark for us. Thanks!
[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59759 --- Comment #14 from Gereon Kremer --- I upgraded to 5.3 and sure enough, the bug still fires: $ g++ --version g++ (GCC) 5.3.0 Test_GCC.cpp: In substitution of ‘template void f(const A*) [with T = ]’: Test_GCC.cpp:25:7: required from here Test_GCC.cpp:25:7: internal compiler error: in unify, at cp/pt.c:18727 f(map);
[Bug tree-optimization/69358] New: [6 regression] internal compiler error: in equal_mem_array_ref_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69358
Bug ID: 69358
Summary: [6 regression] internal compiler error: in
equal_mem_array_ref_p
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
I see it starting from r232508.
>cat test.i
int a, b;
int c[1][4];
int fn1() {
int i, j, d;
j = 0;
for (; j < 4; j++)
for (; i; i++)
c[i][j] = a;
for (; i; i++) {
j = 0;
for (; j < 2; j++)
d = c[i][d] = c[i][j];
j = 0;
for (; j < 4; j++)
b = a;
}
}
>gcc -O2 -S test.i
test.i: In function 'fn1':
test.i:3:5: internal compiler error: in equal_mem_array_ref_p, at
tree-ssa-scopedtables.c:271
int fn1() {
^~~
0x1007f55 equal_mem_array_ref_p
/export/users/ienkovic/issues/avx-512/gcc/gcc/tree-ssa-scopedtables.c:271
0x10081d6 hashable_expr_equal_p
/export/users/ienkovic/issues/avx-512/gcc/gcc/tree-ssa-scopedtables.c:310
0x10097b3 expr_elt_hasher::equal(expr_hash_elt* const&, expr_hash_elt* const&)
/export/users/ienkovic/issues/avx-512/gcc/gcc/tree-ssa-scopedtables.c:747
0xf47a36 hash_table::find_slot_with_hash(expr_hash_elt* const&, unsigned int,
insert_option)
/export/users/ienkovic/issues/avx-512/gcc/gcc/hash-table.h:873
0xf47bc1 hash_table::find_slot(expr_hash_elt*
const&, insert_option)
/export/users/ienkovic/issues/avx-512/gcc/gcc/hash-table.h:414
0xf46e4e lookup_avail_expr
/export/users/ienkovic/issues/avx-512/gcc/gcc/tree-ssa-dom.c:2018
0xf45677 eliminate_redundant_computations
/export/users/ienkovic/issues/avx-512/gcc/gcc/tree-ssa-dom.c:1460
0xf46763 optimize_stmt
/export/users/ienkovic/issues/avx-512/gcc/gcc/tree-ssa-dom.c:1863
0xf4534a dom_opt_dom_walker::before_dom_children(basic_block_def*)
/export/users/ienkovic/issues/avx-512/gcc/gcc/tree-ssa-dom.c:1368
0x16bad82 dom_walker::walk(basic_block_def*)
/export/users/ienkovic/issues/avx-512/gcc/gcc/domwalk.c:265
0xf4390e execute
/export/users/ienkovic/issues/avx-512/gcc/gcc/tree-ssa-dom.c:613
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug tree-optimization/69359] New: Warn about constant comparisons between pointers and arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69359
Bug ID: 69359
Summary: Warn about constant comparisons between pointers and
arrays
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
This code fragment should result in a warning because p < a can never be true.
int *f (int *);
int g (void)
{
int a[3];
int *p = f (a);
return p < a;
}
This variant is even more clear:
int f (void);
int g (void)
{
int a[3];
int *p = a + f ();
return p < a;
}
Even for the following test case, it makes sense to warn because p <= a is
equivalent to p == a:
int f (void);
int g (void)
{
int a[3];
int *p = a + f ();
return p <= a;
}
(Observed with GCC 5.3 and trunk from a week ago.)
I set the component to tree-optimization; a purely type-based implementation in
the C/C++ front ends could make sense as well (although it would miss cases
where the array variable has already decayed to a pointer).
[Bug tree-optimization/69358] [6 regression] internal compiler error: in equal_mem_array_ref_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69358 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- . *** This bug has been marked as a duplicate of bug 69336 ***
[Bug tree-optimization/69336] Constant value not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69336 Jakub Jelinek changed: What|Removed |Added CC||ienkovich at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- *** Bug 69358 has been marked as a duplicate of this bug. ***
[Bug target/69129] [6 Regression] ICE in get_attr_got, at config/mips/mips.md:694 on mips-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69129 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #5 from Nick Clifton --- Hi Guys, I was able to reproduce the bug as specified. It turns out that there is a race condition in mips_compute_frame which can result in fields in the frame structure being used before they are initialised. I have submitted a possible patch for review here: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01407.html Cheers Nick
[Bug c++/68586] [6 Regression] Enum template parameter wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68586 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Tue Jan 19 14:02:40 2016 New Revision: 232562 URL: https://gcc.gnu.org/viewcvs?rev=232562&root=gcc&view=rev Log: PR c++/68586 * constexpr.c (clear_cv_cache): New. * cp-gimplify.c (clear_fold_cache): New. * cp-tree.h (clear_cv_cache, clear_fold_cache): Declare. * decl.c (finish_enum_value_list): Call them. * g++.dg/cpp0x/enum30.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/enum30.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/68586] [6 Regression] Enum template parameter wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68586 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Should be fixed.
[Bug target/69345] [6 Regression] 459.GemsFDTD regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69345 --- Comment #5 from Richard Biener --- Created attachment 37394 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37394&action=edit patch for testing I am testing the attached. It seems to fix the regression.
[Bug target/69135] [5/6 Regression][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69135 --- Comment #5 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue Jan 19 14:30:23 2016 New Revision: 232566 URL: https://gcc.gnu.org/viewcvs?rev=232566&root=gcc&view=rev Log: [ARM] PR target/69135: Mark ARMv8 vcvt instructions as unconditional PR target/69135 * config/arm/vfp.md (lsi2): Set "conds" attribute to unconditional. Remove %? from output template. * gcc.target/arm/pr69135_1.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr69135_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/vfp.md trunk/gcc/testsuite/ChangeLog
[Bug c++/66858] [6 Regression] FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison on aarch64-none-elf, arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66858 --- Comment #5 from dave.anglin at bell dot net --- On 2016-01-19 6:38 AM, ktkachov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66858 > > --- Comment #4 from ktkachov at gcc dot gnu.org --- > It passes today on arm-none-eabi and aarch64-none-elf. > John, does it still fail on hppa64? It passed on hppa64. Dave
[Bug c++/68965] [5/6 Regression] `-Wunused-parameter` is reported in variadic lambda or function using sizeof...(xs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68965 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Tue Jan 19 14:37:49 2016 New Revision: 232569 URL: https://gcc.gnu.org/viewcvs?rev=232569&root=gcc&view=rev Log: PR c++/68965 * pt.c (tsubst_copy): Mark elements in expanded vector as used. * g++.dg/cpp1y/parameter-pack-1.C: New test. * g++.dg/cpp1y/parameter-pack-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/parameter-pack-1.C trunk/gcc/testsuite/g++.dg/cpp1y/parameter-pack-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/66858] [6 Regression] FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison on aarch64-none-elf, arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66858 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Jakub Jelinek --- Therefore WORKSFORME then.
[Bug jit/68446] [6 Regression] jit testsuite failures seen inside dwarf2out.c:gen_producer_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68446 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Should be fixed as of r232567; marking as fixed.
[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68513 --- Comment #13 from Jan Smets --- I don't think is fixed in 5.x-branch
[Bug middle-end/66877] [6 Regression] FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_over_widening_pattern: detected" 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66877
--- Comment #4 from Richard Biener ---
For some reason you get widening shifts recognized while I get them not
supported by the HW (with the cross at -O2 -ftree-vectorize). -mfpu=neon
doesn't help.
I still can't reproduce your dump file with
/space/rguenther/src/svn/trunk3/configure --target=arm-none-eabi
gcc> /cc1 -quiet t.c -O2 -ftree-vectorize -fdump-tree-vect-details
-fno-vect-cost-model -fno-common -mfpu=neon -march=armv7-a
please advise further.
Also you might want to try if guarding the check with { target !
vect_widen_shift } and adding a variant for vect_widen_shift to scan for 1
occurence fixes the
testcase. That would make sense to me.
[Bug jit/68446] [6 Regression] jit testsuite failures seen inside dwarf2out.c:gen_producer_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68446 --- Comment #7 from David Malcolm --- Author: dmalcolm Date: Tue Jan 19 14:35:16 2016 New Revision: 232567 URL: https://gcc.gnu.org/viewcvs?rev=232567&root=gcc&view=rev Log: Fix memory chunk corruption for opts_obstack (PR jit/68446) gcc/ChangeLog: PR jit/68446 * gcc.c (driver::decode_argv): Add call to init_opts_obstack before init_options_struct. * opts.c (init_opts_obstack): Remove idempotency. (init_options_struct): Replace call to init_opts_obstack with a gcc_assert to verify that it has already been called. * toplev.c (toplev::main): Add call to init_opts_obstack before calls to init_options_struct. (toplev::finalize): Move cleanup of opts_obstack next to cleanup of save_decoded_options, clearing the latter, and save_decoded_options_count. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c trunk/gcc/opts.c trunk/gcc/toplev.c
[Bug middle-end/66178] [4.9/5/6 Regression] Another label as values ICE in gen_reg_rtx, at emit-rtl.c:1059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66178 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #7 from Bernd Schmidt --- Investigating.
[Bug middle-end/66877] [6 Regression] FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_over_widening_pattern: detected" 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66877 --- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) > For some reason you get widening shifts recognized while I get them not > supported by the HW (with the cross at -O2 -ftree-vectorize). -mfpu=neon > doesn't help. > > I still can't reproduce your dump file with > > /space/rguenther/src/svn/trunk3/configure --target=arm-none-eabi > gcc> /cc1 -quiet t.c -O2 -ftree-vectorize -fdump-tree-vect-details > -fno-vect-cost-model -fno-common -mfpu=neon -march=armv7-a > Can you try adding -mfloat-abi=hard to the command line?
[Bug target/65161] ICE: in vec<_haifa_insn_data, va_heap, vl_embed>::operator[], at vec.h:736 with -O3 -fselective-scheduling2 -mtune=slm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65161 Andrey Belevantsev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||abel at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Andrey Belevantsev --- Fixed since 5.0 and works for 4.9 (no offending code there).
[Bug rtl-optimization/52203] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7136 with -fsel-sched-pipelining -fselective-scheduling2 and other custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52203 Andrey Belevantsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Andrey Belevantsev --- Works since 4.8, 4.7 is not maintained.
[Bug target/69135] [5/6 Regression][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69135 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from ktkachov at gcc dot gnu.org --- Fixed on trunk and GCC 5.
[Bug c++/69355] [5/6 Regression] Wrong results with -O1 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355
--- Comment #6 from Jakub Jelinek ---
--- pr69355.ii 2016-01-19 13:00:26.772400572 +0100
+++ pr69355-1.ii2016-01-19 15:54:26.790557524 +0100
@@ -30334,10 +30334,17 @@ namespace std __attribute__ ((__visibili
# 4 "mytest.cpp"
typedef tvmet::Vector Vector;
+__attribute__((noinline, noclone)) Vector
+foo (Vector v1)
+{
+ Vector r;
+ r = v1/norm2(v1);
+ return r;
+}
+
int main(){
Vector v1;
v1 = 1,2,3;
- Vector r;
- r = v1/norm2(v1);
+ Vector r = foo(v1);
std::cout << r;
}
narrows it down a little bit further, happens also with -fno-strict-aliasing,
somewhere during early inlining the operator/ starts ignoring the passed in
long double rhs argument. Looking further.
[Bug target/69135] [5/6 Regression][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69135 --- Comment #6 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue Jan 19 15:02:15 2016 New Revision: 232570 URL: https://gcc.gnu.org/viewcvs?rev=232570&root=gcc&view=rev Log: [ARM] PR target/69135: Mark ARMv8 vcvt instructions as unconditional Backport from mainline 2016-01-19 Kyrylo Tkachov PR target/69135 * config/arm/vfp.md (lsi2): Set "conds" attribute to unconditional. Remove %? from output template. * gcc.target/arm/pr69135_1.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/pr69135_1.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/arm/vfp.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/68753] PowerPC: double precision reciprocal estimate missed optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68753 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-19 Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- For double precision what? Because of the number of iterations required for double precision, it's not clear that this truly is a win for sqrt. Double precision __builtin_recip and __builtin_rsqrt are available.
[Bug middle-end/66877] [6 Regression] FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_over_widening_pattern: detected" 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66877 --- Comment #6 from rguenther at suse dot de --- On Tue, 19 Jan 2016, ktkachov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66877 > > --- Comment #5 from ktkachov at gcc dot gnu.org --- > (In reply to Richard Biener from comment #4) > > For some reason you get widening shifts recognized while I get them not > > supported by the HW (with the cross at -O2 -ftree-vectorize). -mfpu=neon > > doesn't help. > > > > I still can't reproduce your dump file with > > > > /space/rguenther/src/svn/trunk3/configure --target=arm-none-eabi > > gcc> /cc1 -quiet t.c -O2 -ftree-vectorize -fdump-tree-vect-details > > -fno-vect-cost-model -fno-common -mfpu=neon -march=armv7-a > > > > Can you try adding -mfloat-abi=hard to the command line? Thanks, that way it works. Just figured I can't test if the suggested testsuite addition works though.
[Bug c++/69220] Internal error with array of negative size and initializers for it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69220 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- This was fixed in r230081: commit d5a9b16d1a96dbeae92cfb2acc1ba023dcef0eb0 Author: msebor Date: Tue Nov 10 02:23:34 2015 + PR c++/67913 - new expression with negative size not diagnosed PR c++/67927 - array new expression with excessive number of elements not diagnosed I don't think we'll want to backport this, so closing.
