[Bug target/65459] New: munaligned-access still produce split access codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65459
Bug ID: 65459
Summary: munaligned-access still produce split access codes
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ma.jiang at zte dot com.cn
Hi all,
The munaligned-access option on ARM can not stop gcc from producing split
access codes. A very simple test
char mt[20];
void main()
{
void *mm=(mt[1]);
*(( int *)mm)=4;
}
compiled with -O2 -munaligned-access could reproduce this problem.As we can
see,*(( int *)mm)=4; cause gcc to emit 4 strb instructions not a unaligned
stw .
In my opinion, this bug is caused by the SLOW_UNALIGNED_ACCESS macro,which is
defined to be 1 in arm.h. It is very strange that the munaligned-access option
can affect neither SLOW_UNALIGNED_ACCESS nor STRICT_ALIGNMENT. On PPC,the
mstrict-align can affect STRICT_ALIGNMENT， and SLOW_UNALIGNED_ACCESS is
determined by STRICT_ALIGNMENT, ALIGN, and MODE(args of the
SLOW_UNALIGNED_ACCESS macro). This is a good example for ARM, I think.
[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org --- Created attachment 35050 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35050action=edit one.o.000i.cgraph: -fdump-ipa-cgraph for the LTO step for the unpatched GCC (r221482) (In reply to Jan Hubicka from comment #8, #9 and #10) First, I can still reproduce the issue with the unpatched GCC. In addition, the big program also compiles successfully with -fno-ipa-icf. Regarding ld: As /usr/bin/ld is very old, that's with the current ld from the binutils-gdb GIT (via GCC's --with-plugin-ld=) - it fails identical when I replace the ld.bfd by ld.gold. Regarding -fdump-ipa-cgraph: If you prefer the dump of a patched version, please tell me. Regarding the patch in comment 8 (with ExTERNAL typo fixed): Unfortunately, it doesn't solve the problem - I still get the same ICE. Regarding the patch in comment 9: I had to change alias to alias_item due to ../../gcc/ipa-icf.c:1779:22: error: ‘alias’ was not declared in this scope if (DECL_EXTERNAL (alias-decl)) but afterwards: It no longer has an ICE!
[Bug rtl-optimization/65078] [5 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65078 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Mar 18 10:58:32 2015 New Revision: 221485 URL: https://gcc.gnu.org/viewcvs?rev=221485root=gccview=rev Log: PR target/65078 * config/i386/sse.md (movsi/movdi - vec_extract_*_0 splitter): New. * gcc.target/i386/pr65078-1.c: New test. * gcc.target/i386/pr65078-2.c: New test. * gcc.target/i386/pr65078-3.c: New test. * gcc.target/i386/pr65078-4.c: New test. * gcc.target/i386/pr65078-5.c: New test. * gcc.target/i386/pr65078-6.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr65078-1.c trunk/gcc/testsuite/gcc.target/i386/pr65078-2.c trunk/gcc/testsuite/gcc.target/i386/pr65078-3.c trunk/gcc/testsuite/gcc.target/i386/pr65078-4.c trunk/gcc/testsuite/gcc.target/i386/pr65078-5.c trunk/gcc/testsuite/gcc.target/i386/pr65078-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Alexandre Oliva from comment #9)
(In reply to Jeffrey A. Law from comment #7)
OK, but why does this make such a difference in the final result. Ie, what
happens as we get into RTL.
Err, I covered that bit in my description: we emit a number of copies, each
with a new BB of its own. The additional pseudo survives all the way to the
end, and so do the copies, which is enough to explain the additional stack
slot. Further rearrangement of code also follows from the additional blocks.
(In reply to Andrew Macleod from comment #8)
most of these kinds of restrictions were rooted in some kind of
rationale... usually from examining an issue of some sort and introducing
the restriction to avoid it.
This one was added by
https://gcc.gnu.org/ml/gcc-patches/2012-08/msg00517.html
The description mentions out-of-SSA coalescing, but not copyrename
coalescing, which is what this is about. Since there were not anonymous SSA
names before, the introduced condition would necessarily not be met, so it
effectively reduced the amount of copyrename coalescing without any
rationale AFAICT.
Richi, do you happen to have any insight as to why you changed copyrename to
avoid coalescing rootless ssa names?
Because coalescing them doesn't do anything. copyrename coalescing
assigns the same underlying DECL to SSA names, thus makes SSA_NAME_VAR
the same. But when both SSA_NAME_VARs are NULL this won't do anything.
So the effect of the patch was rather that there are now way less SSA names
with SSA_NAME_VAR != NULL. In particular all the pass created ones
(with no relation to user declared variables). It didn't make sense to
apply copyrename to those (copyrename is to have better debug info in the end,
sth which should be provided by debug stmts today).
Reverting it doesn't seem to have any
ill effects on code correctness (unlike allowing coalescing between rooted
and rootless vars during out-of-ssa, in gimple_can_coalesce_p, which breaks
codegen badly, though I haven't dug into why). I'll attach a patch I'm
testing to that effect momentarily.
So I'd say the patch can't make a difference - it at most can end up
re-writing the type of an SSA name and then having followup effects
in out-of-SSA coalescing? For some odd reason we are ignoring some
type differences in copyrename coalescing.
But - how does either root1 or root2 end up non-zero at
/* Set the root variable of the partition to the better choice, if there is
one. */
if (!ign2 root2)
replace_ssa_name_symbol (partition_to_var (map, p3), root2);
else if (!ign1 root1)
replace_ssa_name_symbol (partition_to_var (map, p3), root1);
else
gcc_unreachable ();
? That is, the only effect of your patch is to do partiton_union? Ah,
and then go to:
/* Now one more pass to make all elements of a partition share the same
root variable. */
for (x = 1; x num_ssa_names; x++)
{
part_var = partition_to_var (map, x);
if (!part_var)
continue;
var = ssa_name (x);
if (SSA_NAME_VAR (var) == SSA_NAME_VAR (part_var))
continue;
if (debug)
{
fprintf (debug, Coalesced );
print_generic_expr (debug, var, TDF_SLIM);
fprintf (debug, to );
print_generic_expr (debug, part_var, TDF_SLIM);
fprintf (debug, \n);
}
stats.coalesced++;
replace_ssa_name_symbol (var, SSA_NAME_VAR (part_var));
}
and wreck SSA names type (and debug identifier) only? That really sounds
bogus.
The correct fix would be to allow the kind of type differences copyrename
coalescing allows also in out-of-SSA coalescing.
That is, I don't see how the patch makes sense.
[Bug ada/65451] gnat bug: Storage_Error stack overflow or erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451 --- Comment #4 from John Marino gnugcc at marino dot st --- Created attachment 35054 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35054action=edit gzipped archive of matreshka source files I created a tarball of the source files rather than concatenate. I thought that would be more flexible.
[Bug ada/65451] [5 regression] compiler crash on volatile access type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-aux-dragonfly4.1 | Status|WAITING |ASSIGNED Host|x86_64-aux-dragonfly4.1 | Target Milestone|--- |5.0 Summary|gnat bug: Storage_Error |[5 regression] compiler |stack overflow or erroneous |crash on volatile access |memory access |type Build|x86_64-aux-dragonfly4.1 | --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Thanks, fixing...
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #18 from Alexandre Oliva aoliva at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #14) So, forgive me, but is -DOPT supposed to be the good or the bad code? It's the good one. As noted in comment 12, I had that backwards in comment 6. (In reply to Richard Biener from comment #15) Because coalescing them doesn't do anything. copyrename coalescing assigns the same underlying DECL to SSA names, thus makes SSA_NAME_VAR the same. But when both SSA_NAME_VARs are NULL this won't do anything. This may be true when you look at only one pair of SSA names, but when you have 2 such candidate pairs involving one common SSA name, it can, and it does make a difference, as described in comment 6. (In reply to Richard Biener from comment #16) And as I analyzed in comment #3 we chose the now different coalescing because it is more profitable (to the cost analysis we perform in out-of-SSA coalescing). No, we don't even *consider* the coalescing performed in the -DOPT case, because, as noted in comment 13, the SSA names ended up with different base names, because copyrename wouldn't give them the same base name. (In reply to Richard Biener from comment #17) To add to all this - IMHO copyrename should go That's fine with me. Yes, out-of-SSA coalescing could be changed to allow coalescing of SSA names with a user-DECL and anonymous SSA names (or SSA names with a DECL_IGNORED_P decl). But that will make the conflict graph much larger(?). Ok, I'll give that a shot tomorrow (I'll be away for the whole day today). might happen that we end up coalescing things in a way that there ends up being no DECL for a register and thus we lose in debug quality (not sure if we could compensate by inserting debug stmts on the edges to compensate for that - we couldn't do that if it requires splitting the edge). I'm not concerned about that. Any debug stmts needed to make this work will already be in place, after the actual assignments, and after early PHI nodes. Sure, edge insertions might separate the copies from the debug stmts inserted after the PHI nodes, but ultimately the bindings should take care of it. So to avoid wrong debug we'd have to always coalesce to an anonymous entity With debug stmts, we don't care what the base names are any more. All the info we need (for tracked auto variables) is in the debug stmts.
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- And as I analyzed in comment #3 we chose the now different coalescing because it is more profitable (to the cost analysis we perform in out-of-SSA coalescing). So the fix, if any, is there (or in the code maintaining edge frequencies).
[Bug tree-optimization/65450] [4.9/5 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #35053|0 |1 is obsolete|| Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35055 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35055action=edit gcc5-pr65450.patch And now with the reduced testcase, going to bootstrap/regtest it now.
[Bug tree-optimization/65458] parloops transforms omp-thread functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65458 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-18 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Agreed.
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Note the vectorizer has a slight preference to align stores.
[Bug fortran/65457] ICE in libgfortran/ieee/ieee_arithmetic.F90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65457
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
When I look at tree.h:3346, I do not understand why the
operand check failed. From the message it appears that
__i==2 and TREE_OPERAND_LENGTH (__u)==4:
inline tree *
tree_operand_check (tree __t, int __i,
const char *__f, int __l, const char *__g)
{
const_tree __u = EXPR_CHECK (__t);
if (__i 0 || __i = TREE_OPERAND_LENGTH (__u))
tree_operand_check_failed (__i, __u, __f, __l, __g);
return CONST_CAST_TREE (__u)-exp.operands[__i];
}
Could it be, that this is not a fortran bug but a C++ compiler bug?
[Bug tree-optimization/65460] parloops transforms offloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65460 --- Comment #1 from vries at gcc dot gnu.org --- Created attachment 35052 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35052action=edit tentative patch
[Bug rtl-optimization/65078] [5 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65078 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now.
[Bug tree-optimization/65460] New: parloops transforms offloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65460 Bug ID: 65460 Summary: parloops transforms offloaded functions Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org The offload variant of PR65458 - parloops transforms omp-thread functions. AFAIU, running the parloops pass on the host version of offloaded functions, may as well speed up as degrade performance. It's probably best to disable parloops for offloaded functions, at least until we do a targeted exercise to speed up host execution of offloaded functions.
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #20 from Alexandre Oliva aoliva at gcc dot gnu.org --- (In reply to Alexandre Oliva from comment #18) No, we don't even *consider* the coalescing performed in the -DOPT case, because, as noted in comment 13, the SSA names ended up with different base names, because copyrename wouldn't give them the same base name. (In reply to Richard Biener from comment #17) To add to all this - IMHO copyrename should go That's fine with me. Yes, out-of-SSA coalescing could be changed to allow coalescing of SSA names with a user-DECL and anonymous SSA names (or SSA names with a DECL_IGNORED_P decl). But that will make the conflict graph much larger(?). Not only that: unless we allow also coalescing between different SSA names in out-of-ssa, we'll lose optimizations that copyrename would have enabled out-of-SSA to make, because the removed copyrename won't have assigned the same base name to otherwise unrelated SSA names that out-of-SSA won't even consider for coalescing. Now *this* might make the conflict graph explode in size.
[Bug target/65408] powerpc64 function argument passing may access invalid memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408 --- Comment #6 from Alan Modra amodra at gmail dot com --- Code quality for both powerpc64le and x86_64 looks passable for the testcase here and other structs with at least one int field (ie. when the struct size is a multiple of 4, and alignment is 4). You get DImode loads followed by an SImode load if the struct isn't a multiple of 8 in size. Code quality does suffer a little for big-endian since any SImode load at the end of the struct needs to be shifted, whereas a DImode loading past the end of the struct needs no shifting. For cases where the struct size isn't a multiple of 4, code quality certainly does suffer, worst case being a struct of size 7 that would now be loaded by 7 byte loads.. Should we care more about that than a segfault in real-world user code? Hmm. Answering my own question, I guess that since pr36043 is nearly seven years old, we don't care too much about segfaults!
[Bug tree-optimization/65460] parloops transforms offloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65460 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-18 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/65458] parloops transforms omp-thread functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65458 --- Comment #1 from vries at gcc dot gnu.org --- Created attachment 35051 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35051action=edit tentative patch
[Bug lto/65243] [5 Regression] lto1 ICE (segfault) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65243 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #7 from David Binderman dcb314 at hotmail dot com --- (In reply to Jan Hubicka from comment #6) I also occasionally see this dwarf2out ICE when buliding firefox with debug info. I see this also on x86_64-unknown-linux-gnu
[Bug target/65408] powerpc64 function argument passing may access invalid memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Note that code quality is an issue here as well. Cases to consider are
struct test obj;
void foo()
{
func (obj);
}
and
void foo()
{
struct test obj;
func (obj);
}
and
void foo (struct test obj)
{
func (obj);
}
where we might (or might not) be sure that there is at least one 'int' mapped
after 'obj' (not for the global var case at least - but I'm less sure about
the other two cases (red zone? return address?))
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #19 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 18 Mar 2015, aoliva at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #18 from Alexandre Oliva aoliva at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #14)
So, forgive me, but is -DOPT supposed to be the good or the bad code?
It's the good one. As noted in comment 12, I had that backwards in comment 6.
(In reply to Richard Biener from comment #15)
Because coalescing them doesn't do anything. copyrename coalescing
assigns the same underlying DECL to SSA names, thus makes SSA_NAME_VAR
the same. But when both SSA_NAME_VARs are NULL this won't do anything.
This may be true when you look at only one pair of SSA names, but when you
have
2 such candidate pairs involving one common SSA name, it can, and it does make
a difference, as described in comment 6.
(In reply to Richard Biener from comment #16)
And as I analyzed in comment #3 we chose the now different coalescing
because
it is more profitable (to the cost analysis we perform in out-of-SSA
coalescing).
No, we don't even *consider* the coalescing performed in the -DOPT case,
because, as noted in comment 13, the SSA names ended up with different base
names, because copyrename wouldn't give them the same base name.
(In reply to Richard Biener from comment #17)
To add to all this - IMHO copyrename should go
That's fine with me.
Yes, out-of-SSA coalescing could be changed to allow coalescing of SSA names
with a user-DECL and anonymous SSA names (or SSA names with a DECL_IGNORED_P
decl). But that will make the conflict graph much larger(?).
Ok, I'll give that a shot tomorrow (I'll be away for the whole day today).
might happen that we end up coalescing things in a way
that there ends up being no DECL for a register and thus we lose in debug
quality (not sure if we could compensate by inserting debug stmts on the
edges to compensate for that - we couldn't do that if it requires splitting
the edge).
I'm not concerned about that. Any debug stmts needed to make this work will
already be in place, after the actual assignments, and after early PHI nodes.
Sure, edge insertions might separate the copies from the debug stmts inserted
after the PHI nodes, but ultimately the bindings should take care of it.
So to avoid wrong debug we'd have to always coalesce to an anonymous
entity
With debug stmts, we don't care what the base names are any more. All the
info
we need (for tracked auto variables) is in the debug stmts.
But we do not always have debug stmts!
int bar (int b)
{
int i;
if (b 7)
i = b / 3;
else
return b * 4;
return i;
}
is a testcase for what I am thinking of. Hmm. For some reason
into-SSA inserts a debug stmt, creating an extra copy _5 = i_4?!
bb 2:
if (b_2(D) 7)
goto bb 3;
else
goto bb 4;
bb 3:
i_4 = b_2(D) / 3;
# DEBUG i = i_4
_5 = i_4;
goto bb 5;
bb 4:
_3 = b_2(D) * 4;
bb 5:
# _1 = PHI _3(4), _5(3)
so indeed we shouldn't lose anything here. But are you sure
that we are never using REG_EXPR for debug? With
-fno-var-tracking-assignments for sure we do (I suppose we don't care),
at least var-tracking.c does look at REG_EXPR.
[Bug fortran/65450] [4.9/5 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #35047|0 |1 is obsolete|| --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35053 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35053action=edit gcc5-pr65450.patch Updated (but this time untested except on the testcase) patch, that tries to preserve the alignment info in DR_PTR_INFO from DR_MISALIGNMENT. Will see if it is possible to reduce the testcase somewhat.
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org --- To add to all this - IMHO copyrename should go - it's purpose was to have more SSA names with user-decls and thus debug info for them. This should now be dealt with debug insns (in a way better and correct way). Yes, out-of-SSA coalescing could be changed to allow coalescing of SSA names with a user-DECL and anonymous SSA names (or SSA names with a DECL_IGNORED_P decl). But that will make the conflict graph much larger(?). The decision past then was to retain previous behavior which wouldn't have coalesced this case (because the DECL of the now anonymous SSA name was different). In theory we could just go for it, hoping the conflict graph will not get much larger. But it might happen that we end up coalescing things in a way that there ends up being no DECL for a register and thus we lose in debug quality (not sure if we could compensate by inserting debug stmts on the edges to compensate for that - we couldn't do that if it requires splitting the edge). Not sure if always coalescing to the variable with the user-decl won't make debug info wrong, like in bb1: _1 = 2 * _3; goto bb 3; bb2: i_4 = 5 / _3; bb3: _3 = PHI i_4 (2), _1 (1) if we coalesce to _1 to i_4 then the expression 2 * _3 will be computed to a register with decl 'i'. So to avoid wrong debug we'd have to always coalesce to an anonymous entity - but that would lose the association of 'i' to 5 / _3 in bb2 unless we manage to compensate for that somehow with debug-insns we magically emit during RTL expansion.
[Bug c++/65340] [5 Regression] [C++14]ICE in mark_used, at decl2.c:5040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65340 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Mar 18 10:31:24 2015 New Revision: 221483 URL: https://gcc.gnu.org/viewcvs?rev=221483root=gccview=rev Log: 2015-03-18 Paolo Carlini paolo.carl...@oracle.com PR c++/65340 * call.c (build_over_call): Pass the tsubst_flags_t argument to mark_used. * decl2.c (mark_used): Inline the require_deduced_type call and guard the error call. 2015-03-18 Paolo Carlini paolo.carl...@oracle.com PR c++/65340 * g++.dg/cpp1y/pr65340.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr65340.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/65340] [5 Regression] [C++14]ICE in mark_used, at decl2.c:5040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65340 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug tree-optimization/65440] pass_lim misses support for predicated code motion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65440 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-18 Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. We might already have a bug for this...
[Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Priority|P3 |P2
[Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491 --- Comment #15 from Andrew Stubbs ams at gcc dot gnu.org --- Yeah, I've not managed to come up with a better solution, so I think I'll just revert the patch, for now. :-(
[Bug target/65222] [5 Regression] -mtune= or -march=: Not all options not documented: slm, knl, shanghai, istanbul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65222 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- knl is now documented, slm (and various others) intentionally not documented, shanghai and instanbul not even supported -march=/-mtune= options.
[Bug tree-optimization/65450] [4.9/5 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Mar 18 13:54:12 2015 New Revision: 221490 URL: https://gcc.gnu.org/viewcvs?rev=221490root=gccview=rev Log: PR tree-optimization/65450 * tree-vect-data-refs.c (vect_duplicate_ssa_name_ptr_info): New function. (vect_create_addr_base_for_vector_ref, vect_create_data_ref_ptr): Use it instead of duplicate_ssa_name_ptr_info. * gfortran.dg/pr65450.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr65450.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65443 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-18 Ever confirmed|0 |1 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- parloops needs a _lot_ of TLC! Confirmed.
[Bug tree-optimization/65450] [4.9/5 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- I think DR_PTR_INFO is indeed for the base object and was supposed to preserve points-to-info only. Patch looks ok.
[Bug target/28586] thowing exception before main() leads to crash on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from David Edelsohn dje at gcc dot gnu.org --- Is this now is fixed?
[Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- So perhaps we just can't warn for your testcase, if we can't detect it reliably.
[Bug ipa/65432] [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65432 --- Comment #5 from Martin Liška marxin at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #4) (In reply to Martin Liška from comment #3) Created attachment 35057 [details] Suggested patch I guess the problem is caused by missing xstdup_for_dump wrappers. Can you please Markus test for me the patch? The patch fixes the issue. Thanks. Thanks. I'm going to send the patch to mailing list.
[Bug fortran/65419] incorrect sibcalls to libgomp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419 --- Comment #2 from cesar at gcc dot gnu.org --- Created attachment 35058 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35058action=edit __builtin_GOACC_data_end Sorry, I thought I included this test case. Anyway, the !$acc data regions is associated with two libgomp calls, __builtin_GOACC_data_start and __builtin_GOACC_data_end. Basically, as the control enters an acc data region, all of the variables specified inside a data clause get transferred over to the accelerator. At the end of the data region, GOACC_data_end transfers the data back to the host as necessary. No arguments are passed to GOACC_data_end. Instead the runtime maintains a stack of data regions because they are permitted to nest, and GOACC_data_end decreases the reference count on all of the variables pushed on that stack and transfers the data back to the host as necessary. Did we specify the builtin function for GOACC_data_end wrong, or is there an inherent weakness in the sibling call analysis?
[Bug middle-end/64928] [4.8/4.9/5 Regression] Inordinate cpu time and memory usage in phase opt and generate with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Yes, -r should be honored by the appropriate resolution info (not _IR_ONLY). Thus you have to treat that conservatively. Otherwise you can create a testcase that fails with the final link and the other strong definition in a shared library.
[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 --- Comment #12 from Martin Liška marxin at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #11) Created attachment 35050 [details] one.o.000i.cgraph: -fdump-ipa-cgraph for the LTO step for the unpatched GCC (r221482) (In reply to Jan Hubicka from comment #8, #9 and #10) First, I can still reproduce the issue with the unpatched GCC. In addition, the big program also compiles successfully with -fno-ipa-icf. Regarding ld: As /usr/bin/ld is very old, that's with the current ld from the binutils-gdb GIT (via GCC's --with-plugin-ld=) - it fails identical when I replace the ld.bfd by ld.gold. Regarding -fdump-ipa-cgraph: If you prefer the dump of a patched version, please tell me. Regarding the patch in comment 8 (with ExTERNAL typo fixed): Unfortunately, it doesn't solve the problem - I still get the same ICE. Regarding the patch in comment 9: I had to change alias to alias_item due to ../../gcc/ipa-icf.c:1779:22: error: ‘alias’ was not declared in this scope if (DECL_EXTERNAL (alias-decl)) but afterwards: It no longer has an ICE! Hello. What's your target where you have the PR? I'm also unable to reproduce the issue. Even with BFD. Thanks, Martin
[Bug target/65222] [5 Regression] -mtune= or -march=: Not all options not documented: slm, knl, shanghai, istanbul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65222 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-18 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/65337] [5 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/65426] Recognize byte-swaps when writing to buffers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65426 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-18 Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- stores are not yet supported by the pass. And I think this bug has a duplicate.
[Bug target/65421] inefficient code returning float aggregates on powepc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65421 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-18 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/65424] gcc does not recognize byte swaps implemented as loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65424 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-18 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. The idea was unrolling would expose it (but we don't unroll these kind of loops before swap detection).
[Bug tree-optimization/65425] code optimization leads to spurious FP exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65425 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 35056 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35056action=edit incomplete patch
[Bug c/65461] New: -Warray-bounds warnings in the linux kernel (free_area_init_nodes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65461
Bug ID: 65461
Summary: -Warray-bounds warnings in the linux kernel
(free_area_init_nodes)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Hello.
After reducing following test case, I see false positive VRP warning for:
enum zone_type {
ZONE_NORMAL,
ZONE_MOVABLE,
__MAX_NR_ZONES
};
unsigned long arch_zone_lowest_possible_pfn[2];
unsigned long arch_zone_highest_possible_pfn[2];
void __next_mem_pfn_range(int *a, unsigned long *b, unsigned long *c, int *d);
void free_area_init_nodes(unsigned long *max_zone_pfn) {
unsigned long start_pfn, end_pfn;
int i, nid;
for (i = 1; i 2; i++) {
if (i == ZONE_MOVABLE)
continue;
arch_zone_lowest_possible_pfn[i] = arch_zone_highest_possible_pfn[i-1];
}
for (i = -1; i = 0; __next_mem_pfn_range(i, start_pfn, end_pfn, nid))
{}
}
testcase.i: In function ‘free_area_init_nodes’:
testcase.i:18:74: warning: array subscript is below array bounds
[-Warray-bounds]
arch_zone_lowest_possible_pfn[i] =
arch_zone_highest_possible_pfn[i-1];
Well, it looks the issue is similar (duplicate) to PR1006, but maybe it worth
for analysis.
VPR dump shows following code:
Value ranges after VRP:
.MEM_1: VARYING
.MEM_2: VARYING
.MEM_3: VARYING
i.0_6: VARYING
_7: [-INF(OVF), -1]
_8: VARYING
i.1_10: [-2147483647, 2]
i.0_13: VARYING
i.0_19: [1, 1] EQUIVALENCES: { i.0_6 i.0_21 } (2 elements)
i.0_20: [-INF, 0] EQUIVALENCES: { i.0_6 i.0_21 } (2 elements)
i.0_21: [-INF, 1] EQUIVALENCES: { i.0_6 } (1 elements)
For:
free_area_init_nodes (long unsigned int * max_zone_pfn)
{
int nid;
int i;
long unsigned int end_pfn;
long unsigned int start_pfn;
int i.0_6;
int _7;
long unsigned int _8;
int i.1_10;
int i.0_13;
bb 2:
i = 1;
goto bb 6;
bb 3:
if (i.0_6 == 1)
goto bb 5;
else
goto bb 4;
bb 4:
_7 = i.0_6 + -1;
_8 = arch_zone_highest_possible_pfn[_7];
arch_zone_lowest_possible_pfn[i.0_6] = _8;
bb 5:
i.1_10 = i.0_6 + 1;
i = i.1_10;
bb 6:
i.0_6 = i;
if (i.0_6 = 1)
goto bb 3;
else
goto bb 7;
bb 7:
i = -1;
goto bb 9;
bb 8:
__next_mem_pfn_range (i, start_pfn, end_pfn, nid);
bb 9:
i.0_13 = i;
if (i.0_13 = 0)
goto bb 8;
else
goto bb 10;
bb 10:
start_pfn ={v} {CLOBBER};
end_pfn ={v} {CLOBBER};
i ={v} {CLOBBER};
nid ={v} {CLOBBER};
return;
}
Thanks,
Martin
[Bug ipa/65432] [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65432 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Martin Liška from comment #3) Created attachment 35057 [details] Suggested patch I guess the problem is caused by missing xstdup_for_dump wrappers. Can you please Markus test for me the patch? The patch fixes the issue. Thanks.
[Bug middle-end/65449] -fstrict-volatile-bitfields affects volatile pointer dereference and produce wrong codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449 --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Hi Richard, the invalid/different code for -O2 -fstrict-volatile-bitfields will be fixed with my proposed patch, because the misalignedness of mm should be visible at -O2 and prevent the strict_volatile bitfields path to be entered. Could you give your OK to the latest version? see https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00817.html Thanks Bernd.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- The culprit basically refactors things and in the process screws code-generation with sreals?
[Bug tree-optimization/65207] [5 regression] performance: tree level loop optimization does not peel SpecCPU href loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65207
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
That is, I'm talking about
/* If there is call on a hot path through the loop, then
there is most probably not much to optimize. */
else if (size.num_non_pure_calls_on_hot_path)
{
if (dump_file (dump_flags TDF_DETAILS))
fprintf (dump_file, Not unrolling loop %d:
contains call and code would grow.\n,
loop-num);
return false;
*** This bug has been marked as a duplicate of bug 59967 ***
[Bug tree-optimization/59967] [4.8/4.9/5 Regression] Performance regression from 4.7.x to 4.8.x (loop not unrolled)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59967 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||krebbel at gcc dot gnu.org --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 65207 has been marked as a duplicate of this bug. ***
[Bug lto/65243] [5 Regression] lto1 ICE (segfault) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65243
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|2015-03-02 00:00:00 |2015-03-18
Ever confirmed|0 |1
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
The original ICE means that in
inline hashval_t
external_ref_hasher::hash (const value_type *r)
{
dw_die_ref die = r-type;
hashval_t h = 0;
/* We can't use the address of the DIE for hashing, because
that will make the order of the stub DIEs non-deterministic. */
if (! die-comdat_type_p)
/* We have a symbol; use it to compute a hash. */
h = htab_hash_string (die-die_id.die_symbol);
die-die_id.die_symbol is NULL (I suppose).
I suppose the guard means that in non-LTO this _is_ a comdat type. But
LTO somehow demoted it?
We still lack a proper testcase.
[Bug target/54791] AIX-only: Constructors are not called in main program.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #34 from David Edelsohn dje at gcc dot gnu.org --- Is this still failing with GCC 4.9 or trunk?
[Bug lto/65243] [5 Regression] lto1 ICE (segfault) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65243 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Martin Sebor from comment #4) I can reproduce the SEGV with the same stack trace with recent trunk. Going back in time as far back as commit 8b2ddcd 7 months ago I get: lto1: internal compiler error: Segmentation fault 0x10697533 crash_signal /build/gcc-65243/trunk/gcc/toplev.c:337 0x1053f580 lto_file_decl_data_get_var_decl /build/gcc-65243/trunk/gcc/lto-streamer.h:1124 0x1053f580 lto_input_tree_ref(lto_input_block*, data_in*, function*, LTO_tags) /build/gcc-65243/trunk/gcc/lto-streamer-in.c:245 0x1053f8a3 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int) /build/gcc-65243/trunk/gcc/lto-streamer-in.c:1279 0x101b59b3 lto_read_decls /build/gcc-65243/trunk/gcc/lto/lto.c:1954 0x101b7e47 lto_file_finalize /build/gcc-65243/trunk/gcc/lto/lto.c:2207 0x101b7e47 lto_create_files_from_ids /build/gcc-65243/trunk/gcc/lto/lto.c:2217 0x101b7e47 lto_file_read /build/gcc-65243/trunk/gcc/lto/lto.c:2257 0x101b7e47 read_cgraph_and_symbols /build/gcc-65243/trunk/gcc/lto/lto.c:2960 0x101b7e47 lto_main() /build/gcc-65243/trunk/gcc/lto/lto.c:3414 ...and with commit 757abb4 the month before I get: lto1: fatal error: LTO_tags out of range: Range is 0 to 384, value is 1342177279 compilation terminated. You can't go back in time with object files only (the IL changes quite often).
[Bug tree-optimization/65450] [4.9/5 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/65432] [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65432 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||mliska at suse dot cz Target Milestone|--- |5.0
[Bug c/65461] -Warray-bounds warnings in the linux kernel (free_area_init_nodes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65461 --- Comment #1 from Martin Liška marxin at gcc dot gnu.org --- Correct link for the PR links to a different bugzilla: https://dmz-portal.mips.com/bugz/show_bug.cgi?id=1006
[Bug target/64600] [5 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org --- Assuming fixed.
[Bug testsuite/60794] 25 libstdc++ tests are missing '{ dg-require-debug-mode }'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60794 John Marino gnugcc at marino dot st changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from John Marino gnugcc at marino dot st --- report was invalid, closing.
[Bug ipa/65432] [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65432 --- Comment #3 from Martin Liška marxin at gcc dot gnu.org --- Created attachment 35057 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35057action=edit Suggested patch I guess the problem is caused by missing xstdup_for_dump wrappers. Can you please Markus test for me the patch? Thanks
[Bug tree-optimization/65442] pass_lim misses support for exit-first loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65442 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-18 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/65425] code optimization leads to spurious FP exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65425
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2015-03-18
CC||jsm28 at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
I think we have a duplicate bug for this - if-conversion transforms the loop
body to execute the log10 unconditionally:
iftmp.0_11 = log10 (_10);
iftmp.0_2 = _10 0.0 ? iftmp.0_11 : -9.e+4;
it's
static bool
if_convertible_stmt_p (gimple stmt, vecdata_reference_p refs,
bool *any_mask_load_store)
{
...
case GIMPLE_CALL:
{
tree fndecl = gimple_call_fndecl (stmt);
if (fndecl)
{
int flags = gimple_call_flags (stmt);
if ((flags ECF_CONST)
!(flags ECF_LOOPING_CONST_OR_PURE)
/* We can only vectorize some builtins at the moment,
so restrict if-conversion to those. */
DECL_BUILT_IN (fndecl))
return true;
}
return false;
which fails to check whether the call may trap.
I have a patch for that issue, but log10 is also using ATTR_NOTHROW_*
thus it is declared as never trapping. It looks like _all_ functions
will have this issue.
Then the canonical helper gimple_could_trap_p doesn't consider the _body_
of the call but only the call instruction itself. So we have to abuse
gimple_call_nothrow_p here.
I'm not sure about how to deal with this (adding another layer distinguishing
flag_trapping_math in builtins.def)?
[Bug fortran/65419] incorrect sibcalls to libgomp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Can you please provide a testcase? It looks like what keeps
void bar (int *);
void baz (void);
void foo (void)
{
int a[10];
bar (a);
baz ();
}
from using a sibcall doesn't work for you. Probably the way you declare/pass
the data to GOACC_data_start (not visible here).
[Bug target/28586] thowing exception before main() leads to crash on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586 Bug 28586 depends on bug 33704, which changed state. Bug 33704 Summary: AIX runs c++ constructors in incorrect order https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/33704] AIX runs c++ constructors in incorrect order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from David Edelsohn dje at gcc dot gnu.org --- Fixed.
[Bug target/54791] AIX-only: Constructors are not called in main program.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 Bug 54791 depends on bug 33704, which changed state. Bug 33704 Summary: AIX runs c++ constructors in incorrect order https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug c++/65398] [5 Regression] [C++11] GCC rejects constexpr variable definitions with valid initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65398 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug target/65222] [5 Regression] -mtune= or -march=: Not all options not documented: slm, knl, shanghai, istanbul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65222 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Mar 18 13:47:47 2015 New Revision: 221489 URL: https://gcc.gnu.org/viewcvs?rev=221489root=gccview=rev Log: PR target/65222 * doc/invoke.texi: Add knl as x86 -march=/-mtune= CPU type. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug ipa/65432] [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65432 --- Comment #6 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Wed Mar 18 14:16:59 2015 New Revision: 221491 URL: https://gcc.gnu.org/viewcvs?rev=221491root=gccview=rev Log: Fix PR ipa/65432 PR ipa/65432 * cgraph.c (cgraph_node::get_create): Remove unnecessary xstrdup_for_dump wrapper. * ipa-icf.c (sem_item::dump): Use symtab_node::name instead of sem_item::name. (sem_function::equals): Wrap symtab_node::name and symtab_node::asm_name with xstrdup_for_dump. (sem_variable::equals): Likewise. (sem_item_optimizer::read_section): Use symtab_node::name instead of sem_item::name. (sem_item_optimizer::parse_funcs_and_vars): Likewise. (sem_item_optimizer::merge_classes): Wrap symtab_node::name and symtab_node::asm_name with xstrdup_for_dump. (congruence_class::dump): Use symtab_node::name instead of sem_item::name. * ipa-icf.h (symtab_node::name): Remove. (symtab_node::asm_name): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/ipa-icf.c trunk/gcc/ipa-icf.h
[Bug tree-optimization/65424] gcc does not recognize byte swaps implemented as loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65424 --- Comment #2 from Robert Clausecker fuz at fuz dot su --- I'm looking forwards to a fix! This optimization is important for me.
[Bug ipa/65432] [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65432 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.0.
[Bug tree-optimization/65427] [4.8/4.9 Regression] ICE in emit_move_insn with wide vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65427 James Greenhalgh jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added CC||jgreenhalgh at gcc dot gnu.org --- Comment #5 from James Greenhalgh jgreenhalgh at gcc dot gnu.org --- The new test is causing an ICE when compiled for size on arm-none-linux-gnueabihf, though this might just be exposing something latent in the ARM back-end. Of the configure options, the only meaningful ones to trigger the ICE are those which turn on NEON support (-mfpu=neon, -mfloat-abi=hard ) ./gcc-install/bin/gcc -v -Os gcc-src/gcc/testsuite/gcc.c-torture/execute/pr65427.c -mfloat-abi=hard -mfpu=neon Using built-in specs. COLLECT_GCC=./gcc-install/bin/gcc COLLECT_LTO_WRAPPER=/work/jamgre01/gcc-install/bin/../libexec/gcc/armv7l-unknown-linux-gnueabihf/5.0.0/lto-wrapper Target: armv7l-unknown-linux-gnueabihf Configured with: /work/jamgre01//gcc-src/configure --with-cpu=cortex-a9 --with-fpu=neon-fp16 --with-mode=thumb --with-float=hard --enable-languages=c,c++,fortran --prefix=/work/jamgre01//gcc-install --with-build-config=bootstrap-time Thread model: posix gcc version 5.0.0 20150317 (experimental) (GCC) snip gcc-src/gcc/testsuite/gcc.c-torture/execute/pr65427.c: In function ‘foo’: gcc-src/gcc/testsuite/gcc.c-torture/execute/pr65427.c:17:1: internal compiler error: in process_insert_insn, at gcse.c:2174 } ^ 0x337447 process_insert_insn /work/jamgre01//gcc-src/gcc/gcse.c:2174 0x33829f insert_insn_end_basic_block /work/jamgre01//gcc-src/gcc/gcse.c:2196 0x33a073 hoist_code /work/jamgre01//gcc-src/gcc/gcse.c:3492 0x33a073 one_code_hoisting_pass /work/jamgre01//gcc-src/gcc/gcse.c:3722 0x33a073 execute_rtl_hoist /work/jamgre01//gcc-src/gcc/gcse.c:4212 0x33a073 execute /work/jamgre01//gcc-src/gcc/gcse.c:4293 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug testsuite/64032] [5 Regression] FAIL: gcc.dg/undefined-loop-2.c (test for warnings, line 18)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64032 --- Comment #7 from Andrew Stubbs ams at gcc dot gnu.org --- Author: ams Date: Wed Mar 18 14:27:13 2015 New Revision: 221492 URL: https://gcc.gnu.org/viewcvs?rev=221492root=gccview=rev Log: Fix PR64491 2015-03-18 Andrew Stubbs a...@codesourcery.com PR middle-end/64491 Revert: 2014-11-20 Andrew Stubbs a...@codesourcery.com * tree-ssa-loop-niter.c (maybe_lower_iteration_bound): Warn if a loop condition would be removed due to undefined behaviour. 2015-03-18 Andrew Stubbs a...@codesourcery.com PR middle-end/64491 Revert: 2014-11-20 Andrew Stubbs a...@codesourcery.com * gcc.dg/undefined-loop-1.c: New file. * gcc.dg/undefined-loop-2.c: New file. 2014-12-24 Andrew Stubbs a...@codesourcery.com PR testsuite/64032 * gcc.dg/undefined-loop-2.c: Don't allow GCC to optimize away the loop exits too early. Removed: trunk/gcc/testsuite/gcc.dg/undefined-loop-1.c trunk/gcc/testsuite/gcc.dg/undefined-loop-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug target/60851] [4.9/5 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2117 with -flive-range-shrinkage -mdispatch-scheduler -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851 --- Comment #9 from Uroš Bizjak ubizjak at gmail dot com --- I have a patch in testing: --cut here-- Index: recog.c === --- recog.c (revision 221482) +++ recog.c (working copy) @@ -2775,6 +2775,10 @@ constrain_operands (int strict, alternative_mask a /* Before reload, accept what reload can turn into mem. */ || (strict 0 CONSTANT_P (op)) + /* Before reload, accept a pseudo, + since LRA can turn it into mem. */ + || (targetm.lra_p () strict 0 REG_P (op) + REGNO (op) = FIRST_PSEUDO_REGISTER) /* During reload, accept a pseudo */ || (reload_in_progress REG_P (op) REGNO (op) = FIRST_PSEUDO_REGISTER))) --cut here-- The patch activates safety net recognition of pseudo regs for LRA-enabled targets. LRA is able to spill pseudos to memory to satisfy memory-only constraints, so constrain_operands should recognize this functionality. This is actually the same approach as how constants are handled a couple of lines above.
[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Martin Liška from comment #12) What's your target where you have the PR? I'm also unable to reproduce the issue. Even with BFD. Build/host/target is a CentOS 6.6 x86_64-unknown-linux-gnu system, with the GIT version of GCC installed and in the $PATH, the GIT version of binutils not in the path (neither during build nor during run). GCC is configured with: --with-plugin-ld=path to GIT version/bin/ld --enable-checking=yes --enable-languages=c,c++,fortran,lto Thus, for LTO the plugin-ld is invoked via the (implicit) -fuse-linker-plugin. The GIT version of binutils is build with /usr/bin/gcc (= 4.4) and with configure options --with-python (= nonsystem Python 2.7.8) --enable-plugins --enable-ld --enable-gold. The CentOS6 ships with glibc glibc-2.12-1.149.el6_6.5 and binutils-2.20.51.0.2-5.42.el6. Just to make sure, I have just re-bootstrapped GCC (r221491) and re-downloaded the attached files - and it still ICEs for me without the patch in comment 10.
[Bug ada/65451] [5 regression] compiler crash on volatile access type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491 --- Comment #16 from Andrew Stubbs ams at gcc dot gnu.org --- Author: ams Date: Wed Mar 18 14:27:13 2015 New Revision: 221492 URL: https://gcc.gnu.org/viewcvs?rev=221492root=gccview=rev Log: Fix PR64491 2015-03-18 Andrew Stubbs a...@codesourcery.com PR middle-end/64491 Revert: 2014-11-20 Andrew Stubbs a...@codesourcery.com * tree-ssa-loop-niter.c (maybe_lower_iteration_bound): Warn if a loop condition would be removed due to undefined behaviour. 2015-03-18 Andrew Stubbs a...@codesourcery.com PR middle-end/64491 Revert: 2014-11-20 Andrew Stubbs a...@codesourcery.com * gcc.dg/undefined-loop-1.c: New file. * gcc.dg/undefined-loop-2.c: New file. 2014-12-24 Andrew Stubbs a...@codesourcery.com PR testsuite/64032 * gcc.dg/undefined-loop-2.c: Don't allow GCC to optimize away the loop exits too early. Removed: trunk/gcc/testsuite/gcc.dg/undefined-loop-1.c trunk/gcc/testsuite/gcc.dg/undefined-loop-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491 Andrew Stubbs ams at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Andrew Stubbs ams at gcc dot gnu.org --- Patch reverted; problem fixed.
[Bug tree-optimization/65450] [4.9 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0, 5.0 Summary|[4.9/5 Regression]: |[4.9 Regression]: Unaligned |Unaligned access with -O3 |access with -O3 -mtune=k8 |-mtune=k8 | Known to fail||4.9.2 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk so far.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #4 from Jens Gustedt jens.gustedt at inria dot fr --- This is a surprising policy change that occurs a random point in time, namely where _Atomic is introduced to the C language and in addition does that in a very unituitive way. Why drop _Atomic, why keep the others. Also it doesn't look very consistent to me: on one hand you claim that it is necessary for the implementation of stdatomic.h, but that now uses __auto_type. For __auto_type the drop of qualifiers comes quite naturally since the RHS is evaluated anyhow. So basically the drop of _Atomic qualifiers by __typeof__ is a historic artefact that maybe has been needed in a short period of time for one internal use case in libatomic. Please consider changing this to a more comprehensive behavior.
[Bug libstdc++/13631] Problems in messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631 --- Comment #35 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Wed Mar 18 16:17:47 2015 New Revision: 221494 URL: https://gcc.gnu.org/viewcvs?rev=221494root=gccview=rev Log: PR libstdc++/13631 * config/locale/gnu/messages_members.cc (get_glibc_msg): Fix fallback implementation for old glibc. Fix whitespace. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/locale/gnu/messages_members.cc
[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491
--- Comment #12 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #11)
Ok, I found the difference. The problem on the external gcc112 system (ie,
the big-endian system) is that the system binutils doesn't support POWER8,
so during gcc config/build, the power8 gcc support was disabled. I
built/installed a new binutils and used that for my build and now my
external build also ICEs. Vlad can you try using my build on gcc112?
/home/bergner/gcc/build/gcc-fsf-mainline-r221324-2/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-r221324-2/gcc -O1 -m64
-mcpu=power8 -mlra -S pr63491.i
It uses /home/bergner/binutils/install/binutils-power8/bin/{as,ld}.
Yes, I reproduced it with you binaries. Thanks, Peter. The crash is in a code
concerning secondary reloads. It might take a few days to fix it.
[Bug tree-optimization/65427] [4.8/4.9 Regression] ICE in emit_move_insn with wide vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65427 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #7 from ktkachov at gcc dot gnu.org --- Keeping it open for potential backports...
[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org --- Well, the problem is that -r is the only case where we get LDPR_PREVAILING_DEF or IRONLY and the resulting symbol may be removed from the unit later. We would need a new LDPR_PREVAILING_DEF_FOR_NOW or something like that to represent the incremental nature of linking here, or we need a global flag in GCC saying if incremental linking is supposed tohappen or not.
[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- (just to explain bit more - the main difference between static and dynamic linking here is that dynamic linking never remove any definition and thus you can dissolve comdat groups)
[Bug tree-optimization/65427] [4.8/4.9 Regression] ICE in emit_move_insn with wide vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65427 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to James Greenhalgh from comment #5) The new test is causing an ICE when compiled for size on arm-none-linux-gnueabihf, though this might just be exposing something latent in the ARM back-end. Of the configure options, the only meaningful ones to trigger the ICE are those which turn on NEON support (-mfpu=neon, -mfloat-abi=hard ) As mentioned on gcc-patches, that's a separate issue. I'm testing a patch
[Bug c++/65046] [5 regression] -Wabi-tag doesn't warn about variables or function return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65046 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Wed Mar 18 18:08:29 2015 New Revision: 221497 URL: https://gcc.gnu.org/viewcvs?rev=221497root=gccview=rev Log: PR c++/65046 * config/locale/gnu/messages_members.cc (Catalog_info, Catalogs, get_catalogs): Add abi-tag. * include/ext/codecvt_specializations.h (encoding_state, encoding_char_traits): Likewise. * src/c++11/cxx11-ios_failure.cc (io_error_category): Likewise. * src/c++11/cxx11-shim_facets.cc (__any_string::operator basic_string, numpunct_shim, collate_shim, time_get_shim, moneypunct_shim, money_get_shim, money_put_shim, messages_shim): Likewise. * src/c++11/future.cc (future_error_category::message): Likewise. * src/c++11/system_error.cc (generic_error_category::message, system_error_category::message): Likewise. (__sso_string): Disable -Wabi-tag warnings. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/locale/gnu/messages_members.cc trunk/libstdc++-v3/include/ext/codecvt_specializations.h trunk/libstdc++-v3/src/c++11/cxx11-ios_failure.cc trunk/libstdc++-v3/src/c++11/cxx11-shim_facets.cc trunk/libstdc++-v3/src/c++11/future.cc trunk/libstdc++-v3/src/c++11/system_error.cc
[Bug sanitizer/65400] tsan mis-compiles inlineable C functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35059 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35059action=edit gcc5-pr65400.patch Untested fix for the first issue.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com --- (_Generic does make sure to treat its controlling expression as an rvalue, removing qualifiers including _Atomic as well as ensuring GCC's internal representation of _Noreturn as a qualifier does not affect the type resulting for expressions such as abort.)
[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 --- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org --- Ah, thanks! The patch fixed as in coment #10 is OK for mainline. We obviously should not try to do any merging of external symbols; it is pointless. We only want to calculate equivalences on these to merge non-externals referencing them. Patch is OK with the fixes and testcase.
[Bug c++/62051] [4.9/5] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Honza, can you double check this? Could be a regression. I can reproduce the error, in any case.
[Bug c++/59816] [c++11] Incorrect visibility check in template instantiation when the default constructor is a variadic template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59816 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed for 5.0. I'm adding the testcase and closing the bug.
[Bug fortran/65457] New: ICE in libgfortran/ieee/ieee_arithmetic.F90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65457 Bug ID: 65457 Summary: ICE in libgfortran/ieee/ieee_arithmetic.F90 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de libtool: compile: /home/ed/gnu/gcc-build-arm-linux-gnueabihf/./gcc/gfortran -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./gcc/ -B/home/ed/gnu/arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/bin/ -B/home/ed/gnu/arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/lib/ -isystem /home/ed/gnu/arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/include -isystem /home/ed/gnu/arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-5-20150315/libgfortran -iquote../../../gcc-5-20150315/libgfortran/io -I../../../gcc-5-20150315/libgfortran/../gcc -I../../../gcc-5-20150315/libgfortran/../gcc/config -I../.././gcc -I../../../gcc-5-20150315/libgfortran/../libgcc -I../libgcc -I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring -Wno-unused-dummy-argument -Wno-c-binding-type -ffree-line-length-0 -fallow-leading-underscore -g -O2 -c ../../../gcc-5-20150315/libgfortran/ieee/ieee_arithmetic.F90 -fPIC -o .libs/ieee_arithmetic.o ../../../gcc-5-20150315/libgfortran/ieee/ieee_arithmetic.F90:541:0: elemental real(kind=8) function IEEE_VALUE_8(X, C) result(res) ^ internal compiler error: tree check: accessed operand 3 of case_label_expr with 4 operands in make_gimple_switch_edges, at tree-cfg.c:1242 0x9ae08f tree_operand_check_failed(int, tree_node const*, char const*, int, char const*) ../../gcc-5-20150315/gcc/tree.c:9507 0x77fc57 tree_operand_check(tree_node*, int, char const*, int, char const*) ../../gcc-5-20150315/gcc/tree.h:3346 0x77fc57 make_gimple_switch_edges ../../gcc-5-20150315/gcc/tree-cfg.c:1242 0x77fc57 make_edges ../../gcc-5-20150315/gcc/tree-cfg.c:859 0x77fc57 build_gimple_cfg ../../gcc-5-20150315/gcc/tree-cfg.c:278 0x77fc57 execute_build_cfg ../../gcc-5-20150315/gcc/tree-cfg.c:387 0x77fc57 execute ../../gcc-5-20150315/gcc/tree-cfg.c:423 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [ieee_arithmetic.lo] Error 1 make[3]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf' make: *** [all] Error 2 gcc-5-20150315$ cat LAST_UPDATED Obtained from SVN: trunk revision 221440
[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0) (0x0, 0x0) if ssp is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64820 --- Comment #4 from Maxim Ostapenko chefmax at gcc dot gnu.org --- Fixed by r22145.
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Could you please post the exact compiler invocation?
[Bug target/65456] [5 Regression] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-18 Target Milestone|--- |5.0 Summary|powerpc64le autovectorized |[5 Regression] powerpc64le |copy loop missed|autovectorized copy loop |optimization|missed optimization Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Ah, I see it with -O3, -O2 is fine.
[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0) (0x0, 0x0) if ssp is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64820 Maxim Ostapenko chefmax at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Maxim Ostapenko chefmax at gcc dot gnu.org --- Fixed.
