[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631 --- Comment #33 from amker at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #31) > The test also fails on PowerPC, the 2 IVs are kept by ivopts. On targets like ARM, the biv(i) is eliminated with biv(p). PowerPC is different, it only supports pre-increment addressing mode, so GIV(p-4) is selected for the array reference. GCC now is conservative in iv elimination by only considering original BIV and nowrapping IVs. Related code is in function iv_elimination_compare_lt as below: /* We need to know that the candidate induction variable does not overflow. While more complex analysis may be used to prove this, for now just check that the variable appears in the original program and that it is computed in a type that guarantees no overflows. */ cand_type = TREE_TYPE (cand->iv->base); if (cand->pos != IP_ORIGINAL || !nowrap_type_p (cand_type)) return false; Another place we can improve.
[Bug ipa/63566] [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63566 --- Comment #14 from Jakub Jelinek --- Even with all the committed patches I don't see any change on the #c5 testcase, which in 4.9 used regparm(3) calling convention e.g. for f1 and f2, but with current trunk still uses regparm(0).
[Bug libffi/64894] libffi does not work for ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64894 Andrew Pinski changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2015-02/msg00507.ht ||ml Last reconfirmed||2015-02-09 Ever confirmed|0 |1
[Bug tree-optimization/54000] [4.8/4.9 Regression] Performance breakdown for gcc-4.{6,7} vs. gcc-4.5 using std::vector in matrix vector multiplication (IVopts / inliner)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54000
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Known to work||5.0
Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression]
|Performance breakdown for |Performance breakdown for
|gcc-4.{6,7} vs. gcc-4.5 |gcc-4.{6,7} vs. gcc-4.5
|using std::vector in matrix |using std::vector in matrix
|vector multiplication |vector multiplication
|(IVopts / inliner) |(IVopts / inliner)
--- Comment #14 from Richard Biener ---
Btw, with trunk (gcc 5) I see
.L13:
movsd (%rdx), %xmm1
xorl%eax, %eax
.L12:
movsd -8(%rcx,%rax), %xmm0
mulsd (%rsi,%rax), %xmm0
addq$8, %rax
cmpq$24, %rax
addsd %xmm0, %xmm1
movsd %xmm1, (%rdx)
jne .L12
addq$8, %rdx
addq$8, %rcx
addq$24, %rsi
cmpq%rdi, %rdx
jne .L13
thus maybe even better than 4.5.
GCC 4.9 produces
.L17:
leaq(%r8,%rdx), %rcx
movsd 8(%rdi,%rdx), %xmm1
xorl%eax, %eax
addq%r9, %rcx
.L14:
movsd -8(%rcx,%rax), %xmm0
mulsd (%rsi,%rax), %xmm0
addq$8, %rax
cmpq$24, %rax
addsd %xmm0, %xmm1
movsd %xmm1, 8(%rdi,%rdx)
jne .L14
addq$8, %rdx
addq$24, %rsi
cmpq$1016, %rdx
jne .L17
it might be again inliner changes that trigger the better behavior of course.
So - fixed in GCC 5. Not sure how to produce a testcase that reliably
tracks good behavior here. IVOPTs dumping should be improved somewhat.
[Bug tree-optimization/54000] [4.8 Regression] Performance breakdown for gcc-4.{6,7} vs. gcc-4.5 using std::vector in matrix vector multiplication (IVopts / inliner)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54000
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work||4.9.0
Resolution|--- |FIXED
Target Milestone|4.8.5 |4.9.0
Summary|[4.8/4.9 Regression]|[4.8 Regression]
|Performance breakdown for |Performance breakdown for
|gcc-4.{6,7} vs. gcc-4.5 |gcc-4.{6,7} vs. gcc-4.5
|using std::vector in matrix |using std::vector in matrix
|vector multiplication |vector multiplication
|(IVopts / inliner) |(IVopts / inliner)
--- Comment #15 from Richard Biener ---
Timing-wise GCC 4.9 looks good as well. With GCC 4.8 the testcase takes
2:30 to execute while with 4.9 1:09 and with GCC 5 finally 1:06. GCC 4.9
also chooses a single IV for the innermost loop.
Declaring fixed.
[Bug target/63679] [5 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #25 from Richard Biener --- No, aarch64 still commits the initializer to memory so the patch doesn't help it for the testcase in the end. It still improves things a bit. I'm quite sure we can't fix this in a target independent way for GCC 5, thus the only chance is to make aarch64 not commit the initializer to memory. That is also the real regression (aarch64 changed to commit the initializer to memory). aarch64 is secondary target only thus this missed-optimization shouldn't block the release.
[Bug target/64979] New: S/390: va_list overflow area pointer is not setup due to stdarg optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64979
Bug ID: 64979
Summary: S/390: va_list overflow area pointer is not setup due
to stdarg optimization
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Created attachment 34699
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34699&action=edit
Experimental fix
The following testcase aborts when compiled with at least -O1:
#include
extern void abort (void);
void __attribute__((noinline))
bar(int msgno, va_list *args)
{
int i;
for (i = 0; i < 10; i++)
if (i != va_arg(*args, int))
abort ();
}
void __attribute__((noinline))
foo(int msgno, ...)
{
va_list args;
int nargs;
va_start(args, msgno);
nargs = va_arg(args, int);
bar(msgno, (va_list *)((nargs == 0) ? ((void *)0) : &args));
}
int main(void)
{
foo(100 /* msgno */,
1 /* nargs - part of vararg list */,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9);
return 0;
}
It is present since we enabled stdarg optimization in the S/390 backend:
https://gcc.gnu.org/ml/gcc-patches/2005-05/msg02429.html
The field __overfloat_arg_area in the va_list struct is not set up if the
va_arg expansions in the current function are found not to exceed the number of
argument registers. This fails with the testcase since the va_list pointer is
passed to another function - still needing that field.
The final patch will include the testcase.
[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 Richard Biener changed: What|Removed |Added Target Milestone|5.0 |4.9.3
[Bug target/63679] [5 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #26 from Jakub Jelinek --- I'd say it is a bug in the backend, if you want to override some expansion, you'd better add some target hook for that, rather than messing up with MOVE_BY_PIECES and setting it to clearly bogus values.
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #19 from Yuri Rumyantsev --- Andrew! Could you please try modified test-case (test1.c) which is attached. Thanks.
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #20 from Yuri Rumyantsev --- Created attachment 34700 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34700&action=edit another test-case
[Bug ipa/64858] [5 Regression] Libreoffice build failure caused by ICF crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64858 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed in r220531.
[Bug fortran/64980] New: [5.0 regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 Bug ID: 64980 Summary: [5.0 regression] ICE in trans-expr.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Created attachment 34701 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34701&action=edit File that triggers the ICE The following code leads to internal compiler error with the message: $ gfortran -c muli_trapezium.f90 muli_trapezium.f90:139:0: (node%get_d_value() / 2 - node%get_r_value_array ())) 1 internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:1954 muli_trapezium.f90:139:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) I'm using gcc 5.0 (svn revision 220505).
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 Frédéric Buclin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-09 CC||fche at redhat dot com Ever confirmed|0 |1 --- Comment #2 from Frédéric Buclin --- (In reply to Markus Trippelsdorf from comment #1) > Would it be possible to lift the restriction on account creation > after the update? This decision doesn't belong to me. CC'ing Frank.
[Bug ipa/64813] [5 Regression] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64813 --- Comment #16 from Martin Liška --- Hello. Sorry for delay, I was away last week. Following patch should prevent a creation of return values for cases where the called function is noreturn. May I ask you for testing on a darwin machine? Thanks, Martin
[Bug ipa/64813] [5 Regression] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64813 --- Comment #17 from Martin Liška --- Created attachment 34702 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34702&action=edit Suggested patch
[Bug ipa/64978] [5 Regression] ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64978
--- Comment #3 from Markus Trippelsdorf ---
trippels@gcc2-power8 makeconv % cat msgfmt.ii
typedef enum
{
} UErrorCode;
class A
{
virtual A *m_fn1 () const;
};
class B : A
{
B (const B &);
A *m_fn1 () const;
class PluralSelectorProvider
{
public:
PluralSelectorProvider ();
} pluralProvider;
PluralSelectorProvider ordinalProvider;
void m_fn2 (const B &, UErrorCode &);
};
UErrorCode a;
B::B (const B &p1) { m_fn2 (p1, a); }
A *
B::m_fn1 () const
{
B (*this);
}
void
B::m_fn2 (const B &, UErrorCode &)
{
for (;;)
m_fn1 ();
}
trippels@gcc2-power8 makeconv % cat reldtfmt.ii
typedef enum
{
} UErrorCode;
namespace icu_52
{
class UnicodeString
{
public:
UnicodeString (int);
};
}
enum UDateFormatStyle
{
};
namespace icu_52
{
class Locale;
class RelativeDateFormat
{
RelativeDateFormat (UDateFormatStyle, UDateFormatStyle, const Locale &,
UErrorCode &);
void m_fn1 ();
};
class MessageFormat
{
public:
MessageFormat (const UnicodeString &, UErrorCode &);
};
RelativeDateFormat::RelativeDateFormat (UDateFormatStyle, UDateFormatStyle,
const Locale &, UErrorCode &)
{
m_fn1 ();
}
UErrorCode a;
void
RelativeDateFormat::m_fn1 ()
{
MessageFormat (0, a);
}
}
trippels@gcc2-power8 makeconv % g++ -fPIC -flto -O3 -fvisibility=hidden
-std=c++11 -c msgfmt.ii
trippels@gcc2-power8 makeconv % g++ -fPIC -flto -O3 -fvisibility=hidden
-std=c++11 -c reldtfmt.ii
trippels@gcc2-power8 makeconv %
/home/trippels/gcc_test/usr/local/bin/../lib/gcc/../../libexec/gcc/powerpc64-unknown-linux-gnu/5.0.0/lto1
-quiet -fwpa msgfmt.o reldtfmt.o
lto1: internal compiler error: in ipcp_verify_propagated_values, at
ipa-cp.c:1060
0x10d1bbef ipcp_verify_propagated_values()
../../gcc/gcc/ipa-cp.c:1060
0x10d1dcfb ipcp_propagate_stage
../../gcc/gcc/ipa-cp.c:2761
0x10d1dcfb ipcp_driver
../../gcc/gcc/ipa-cp.c:4410
0x10d1dcfb execute
../../gcc/gcc/ipa-cp.c:4505
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug fortran/64674] [OOP] ICE in ASSOCIATE with class array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64674 --- Comment #3 from Dominique d'Humieres --- Likely a duplicate of pr56386.
[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386 --- Comment #4 from Dominique d'Humieres --- pr64674 is likely a duplicate of this pr.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #3 from Frank Ch. Eigler --- If the spammer problem is brought under better control with bz5, sure.
[Bug tree-optimization/54000] [4.8 Regression] Performance breakdown for gcc-4.{6,7} vs. gcc-4.5 using std::vector in matrix vector multiplication (IVopts / inliner)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54000 --- Comment #16 from Richard Biener --- Author: rguenth Date: Mon Feb 9 11:51:05 2015 New Revision: 220536 URL: https://gcc.gnu.org/viewcvs?rev=220536&root=gcc&view=rev Log: 2015-02-09 Richard Biener PR tree-optimization/54000 * tree-ssa-looo-ivopts.c: Include tree-vectorizer.h. (struct ivopts_data): Add loop_loc member. (tree_ssa_iv_optimize_loop): Dump loop location. (create_new_ivs): Likewise, also dump number of IVs generated. * g++.dg/tree-ssa/ivopts-3.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/ivopts-3.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug target/58757] Advertise the lack of denormal support on alpha without -mieee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58757 --- Comment #5 from uros at gcc dot gnu.org --- Author: uros Date: Mon Feb 9 11:53:26 2015 New Revision: 220537 URL: https://gcc.gnu.org/viewcvs?rev=220537&root=gcc&view=rev Log: PR target/58757 * gcc.dg/c11-true_min-1.c: Xfail execution for alpha*-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/c11-true_min-1.c
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #29 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #28) > (In reply to Jan Hubicka from comment #27) > > Does the following patch fix the problem? > > Yes! Full regtest is underway but this particular FAIL is fixed. Thanks. Completed now, with no regressions for cris-elf.
[Bug fortran/64980] [5.0 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-09 CC||janus at gcc dot gnu.org Target Milestone|--- |5.0 Summary|[5.0 regression] ICE in |[5.0 Regression] ICE in |trans-expr.c|trans-expr.c Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Here is a reduced test case, which is enough to trigger the ICE: module muli_trapezium implicit none type :: muli_trapezium_t integer::dim=0 end type type, extends (muli_trapezium_t) :: muli_trapezium_node_class_t end type contains pure function get_d_value_array (this) result (subarray) class(muli_trapezium_t), intent(in) :: this real, dimension(this%dim) :: subarray end function subroutine set_d_integral (this, subarray) class(muli_trapezium_t), intent(inout) :: this real, intent(in), dimension(0:this%dim-1) :: subarray end subroutine subroutine muli_trapezium_list_integrate () class(muli_trapezium_node_class_t), pointer :: node call set_d_integral ( node, get_d_value_array(node) ) ! ICE end subroutine end module Backtrace: 0x6b8df3 gfc_conv_component_ref /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:1954 0x6b8f4a conv_parent_component_references /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:2020 0x6c3633 gfc_conv_variable /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:2209 0x6c0cba gfc_conv_expr(gfc_se*, gfc_expr*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:6882 0x6c22ba gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*, gfc_expr*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:3849 0x699bf8 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*, gfc_array_spec*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:794 0x6bf118 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:5347 0x6c0737 gfc_conv_function_expr /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:5938 0x6c0c9a gfc_conv_expr(gfc_se*, gfc_expr*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:6874 0x6a67b3 gfc_add_loop_ss_code /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:2560 0x6a7385 gfc_conv_loop_setup(gfc_loopinfo*, locus*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:4711 0x6a4f5b gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:6689 0x6a857e gfc_conv_array_parameter(gfc_se*, gfc_expr*, bool, gfc_symbol const*, char const*, tree_node**) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:7184 0x6bc89b gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:4843 0x6eec1e gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-stmt.c:419 0x69590c trans_code /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans.c:1728 0x6b6723 gfc_generate_function_code(gfc_namespace*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:5842 0x6979d1 gfc_generate_module_code(gfc_namespace*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans.c:2021 0x651915 translate_all_program_units /home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:5328 0x651915 gfc_parse_file() /home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:5538
[Bug target/63679] [5 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #27 from Tejas Belagod ---
We'd want to scalarize this early preferably in SRA as it gives a chance to
passes like vectorization to vectorize more loops. I checked that
sra-max-scalarization-Osize{-Ospeed} had no effect on scalarizing 'a = *.LC0'
and that's one of the cost functions that affects scalarization. Also, isn't it
difficult to decide scalarization of aggregates based on how it might be
optimized in the future passes as accurately predicting the transformations it
could go through in subsequent passes is not easy?
[Bug fortran/64980] [5.0 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 --- Comment #2 from janus at gcc dot gnu.org --- Slightly further reduced: implicit none type :: muli_trapezium_t integer::dim=0 end type type, extends (muli_trapezium_t) :: muli_trapezium_node_class_t end type class(muli_trapezium_node_class_t), pointer :: node print *,get_d_value_array(node)! ICE contains function get_d_value_array (this) result (subarray) class(muli_trapezium_t), intent(in) :: this real, dimension(this%dim) :: subarray end function end
[Bug sanitizer/64981] New: [5.0 regression] -fsanitize=address cant expand __builtin_ia32_rdtsc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64981
Bug ID: 64981
Summary: [5.0 regression] -fsanitize=address cant expand
__builtin_ia32_rdtsc
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
r216735 PASS
r216827 FAIL
r220528 FAIL
$ cat a.c
int main()
{
__builtin_ia32_rdtsc();
return 0;
}
$ /usr/local/gcc_current/bin/gcc -fsanitize=address -S a.c && grep rdtsc a.s
call__builtin_ia32_rdtsc
$ ~/bin/gcc_216735/bin/gcc -fsanitize=address -S a.c && grep rdtsc a.s
rdtsc
$ ~/bin/gcc_216827/bin/gcc -fsanitize=address -S a.c && grep rdtsc a.s
call__builtin_ia32_rdtsc
[Bug target/63347] [5 regression] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #11 from Bernd Schmidt --- (Sorry about the delay, vacation) Current trunk has SCHED_GROUP_P code in prune_ready_list. That seems to have been added a year later, so it may have failed to get into a release or two. Git revisions are (at leat) 38d8f4bbb3cd8e99a8b8423cc7b19be338a1073a ca5e50e427e0401c45bfa93046ace7d3e6719c4b
[Bug fortran/61138] [4.8/4.9/5 Regression] Wrong code with pointer-bounds remapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61138 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2015-02/msg00531.ht ||ml Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #7 from Mikael Morin --- Patch: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00531.html
[Bug ipa/64978] [5 Regression] ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64978 Alexander Klimov changed: What|Removed |Added CC||alserkli at inbox dot ru --- Comment #4 from Alexander Klimov --- Created attachment 34703 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34703&action=edit gzipped source code that gives same ICE The same ICE trace 0x127f05a ipcp_verify_propagated_values() /gcc/gcc/ipa-cp.c:1060 0x1280b92 ipcp_propagate_stage /gcc/gcc/ipa-cp.c:2761 0x1280b92 ipcp_driver /gcc/gcc/ipa-cp.c:4410 0x1280b92 execute /gcc/gcc/ipa-cp.c:4505 during compilation of root with g++ (GCC) 5.0.0 20150209 $ g++ -O2 -std=c++11 -c VTableBuilder.ii /root/interpreter/llvm/src/tools/clang/lib/AST/VTableBuilder.cpp:3491:1: internal compiler error: in ipcp_verify_propagated_values, at ipa-cp.c:1060 This does not give an ICE on GCC 20150120.
[Bug fortran/64980] [5.0 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 Dominique d'Humieres changed: What|Removed |Added CC||edlinger at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Dominique d'Humieres --- This appeared between revisions r218570 (2014-12-10, compiles) and r218658 (2014-12-12, ICE). Possible candidates are r218584 (pr60718) and r218630 (pr42108), likely r218584. The other commits in the range are for the error handling machinery.
[Bug target/63679] [5 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #28 from rguenther at suse dot de ---
On Mon, 9 Feb 2015, belagod at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
>
> --- Comment #27 from Tejas Belagod ---
> We'd want to scalarize this early preferably in SRA as it gives a chance to
> passes like vectorization to vectorize more loops. I checked that
> sra-max-scalarization-Osize{-Ospeed} had no effect on scalarizing 'a = *.LC0'
because SRA can't scalarize 'a = *.LC0'. But yes, ideally we'd change
gimplification to never decompose initializers but have SRA do it.
But that's of course not a GCC 5 thing.
It has the advantage of splitting the initialization only when it is
(likely) profitable and otherwise leave it to the target to decide
how to expand the initialization (and it opens up the possibility
to directly use a constant-pool entry if the data is readonly).
> and that's one of the cost functions that affects scalarization. Also,
> isn't it difficult to decide scalarization of aggregates based on how it
> might be optimized in the future passes as accurately predicting the
> transformations it could go through in subsequent passes is not easy?
Of course.
[Bug sanitizer/64981] [5.0 regression] -fsanitize=address cant expand __builtin_ia32_rdtsc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64981 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-09 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 34704 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34704&action=edit gcc5-pr64981.patch Untested fix.
[Bug ipa/64813] [5 Regression] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64813
--- Comment #18 from Dominique d'Humieres ---
> May I ask you for testing on a darwin machine?
I have bootstrapped revision r220534 with the patch. AFAICT the patch fixes the
failures reported in this PR (tested with
make -k check RUNTESTFLAGS="conformance.exp=2.cc
--target_board=unix'{-m32,-m64}'"
and
make -k check RUNTESTFLAGS="conformance.exp=4.cc
--target_board=unix'{-m32,-m64}'").
However I see the following regression (for both -m32 and -m64)
FAIL: 22_locale/conversions/string/2.cc execution test
The error is
Assertion failed: (werr == woutput), function test01, file
/opt/gcc/work/libstdc++-v3/testsuite/22_locale/conversions/string/2.cc, line
49.
Abort
Full regtesting scheduled later today.
[Bug c++/64948] Lambda reference capture initialization in template function creates segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64948 Andrea Azzarone changed: What|Removed |Added CC||andrea.azzarone at canonical dot c ||om --- Comment #1 from Andrea Azzarone --- Created attachment 34705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34705&action=edit Proposed fix to allow the use of enable_if for UDLs.
[Bug target/63679] [5 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #29 from Tejas Belagod ---
(In reply to rguent...@suse.de from comment #28)
> On Mon, 9 Feb 2015, belagod at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
> >
> > --- Comment #27 from Tejas Belagod ---
> > We'd want to scalarize this early preferably in SRA as it gives a chance to
> > passes like vectorization to vectorize more loops. I checked that
> > sra-max-scalarization-Osize{-Ospeed} had no effect on scalarizing 'a =
> > *.LC0'
>
> because SRA can't scalarize 'a = *.LC0'. But yes, ideally we'd change
> gimplification to never decompose initializers but have SRA do it.
> But that's of course not a GCC 5 thing.
>
> It has the advantage of splitting the initialization only when it is
> (likely) profitable and otherwise leave it to the target to decide
> how to expand the initialization (and it opens up the possibility
> to directly use a constant-pool entry if the data is readonly).
Which cost function(s) control this profitability of early splitting?
[Bug libgcc/61309] cilk-plus tests fail with: hidden symbol `__cpu_model' in /x/gcc/testsuite/g++/../../libgcc.a(cpuinfo.o) is referenced by DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61309 --- Comment #2 from John Marino --- FYI, this is still happening. So if/when DragonFly features libgcc_s from 5.0 in base, these errors will go away? If so, doesn't that imply the linking is making assumptions it should not make?
[Bug fortran/64980] [5.0 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin --- This cures it: Index: trans-expr.c === --- trans-expr.c(révision 220514) +++ trans-expr.c(copie de travail) @@ -4537,6 +4537,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * fsym->attr.optional && e->expr_type == EXPR_VARIABLE); } +#if 0 else if (e->ts.type == BT_CLASS && fsym && fsym->ts.type == BT_CLASS && !CLASS_DATA (fsym)->as @@ -4587,6 +4588,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * } } else +#endif gfc_conv_expr_reference (&parmse, e); /* Catch base objects that are not variables. */ So yes, r218584 is the cause. The problem comes from the interface mapping machinery, which locally changes THIS from class MULTI_TRAPEZIUM_T to MULTI_TRAPEZIUM_NODE_CLASS_T in the call get_d_value_array(node). The code from r218584 creates a temporary using the declared type MULTI_TRAPEZIUM_T, which doesn't match what interface mapping expects.
[Bug target/63679] [5 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #30 from rguenther at suse dot de ---
On Mon, 9 Feb 2015, belagod at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
>
> --- Comment #29 from Tejas Belagod ---
> (In reply to rguent...@suse.de from comment #28)
> > On Mon, 9 Feb 2015, belagod at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
> > >
> > > --- Comment #27 from Tejas Belagod ---
> > > We'd want to scalarize this early preferably in SRA as it gives a chance
> > > to
> > > passes like vectorization to vectorize more loops. I checked that
> > > sra-max-scalarization-Osize{-Ospeed} had no effect on scalarizing 'a =
> > > *.LC0'
> >
> > because SRA can't scalarize 'a = *.LC0'. But yes, ideally we'd change
> > gimplification to never decompose initializers but have SRA do it.
> > But that's of course not a GCC 5 thing.
> >
> > It has the advantage of splitting the initialization only when it is
> > (likely) profitable and otherwise leave it to the target to decide
> > how to expand the initialization (and it opens up the possibility
> > to directly use a constant-pool entry if the data is readonly).
>
> Which cost function(s) control this profitability of early splitting?
See gimplify_init_constructor and callees.
[Bug middle-end/64909] [4.8/5 regression] Missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64909
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||kyukhin at gcc dot gnu.org
Blocks||53947
--- Comment #3 from Jakub Jelinek ---
I'm with H.J. here, can't reproduce any kind of code you are showing, the loop
is normally vectorized.
But, what can we see there is that for e.g. -O3 -mavx we choose vectorization
factor of 8, which is based on the fact that there are 16-bit and 32-bit types
used in the loop, and before AVX2 we can mostly use V4SImode and V8HImode.
Compared to that, clang vectorizes it probably with vectorization factor 4
instead of 8, and as the loop has constant 12 iterations, doing it that way is
beneficial.
So, perhaps the question is why slp after cunroll hasn't vectorized the
unrolled scalar tail loop with vectorization factor 4.
pr64909.c:8:11: note: not vectorized: not enough data-refs in basic block.
Although it is true that for HImode we indeed can't fill the V8HImode, it is
only used immediately in an extension, which normally looks like:
vect__4.7_30 = MEM[(short unsigned int *)vectp_a.6_27];
vect__5.8_31 = [vec_unpack_lo_expr] vect__4.7_30;
vect__5.8_32 = [vec_unpack_hi_expr] vect__4.7_30;
so all we'd need is the ability to emit a V4HImode load followed solely by
vec_unpack_lo_expr from it instead of both vec_unpack_{lo,hi}_expr.
[Bug ipa/64813] [5 Regression] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64813 --- Comment #19 from Dominique d'Humieres --- > However I see the following regression (for both -m32 and -m64) > > FAIL: 22_locale/conversions/string/2.cc execution test It is pr64797 and not a regression due to the patch.
[Bug ipa/64982] New: [5 Regression] Many g++ failures on x86_64-apple-darwin14 with -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64982
Bug ID: 64982
Summary: [5 Regression] Many g++ failures on
x86_64-apple-darwin14 with -m32.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: fxcoudert at gcc dot gnu.org, howarth at bromo dot
med.uc.edu,
hubicka at gcc dot gnu.org, iains at gcc dot gnu.org
Host: x86_64-apple-darwin14
Target: x86_64-apple-darwin14
Build: x86_64-apple-darwin14
At revision r220526 there are many g++ failures on x86_64-apple-darwin14 with
-m32: see https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00974.html.
Revision r220506 is OK. The ICEs are of the kind
/opt/gcc/_clean/gcc/testsuite/g++.dg/abi/covariant2.C:29:28: internal compiler
error: Segmentation fault: 11
c6* c24::f6() { return 0; }
^
and the backtrace is
* thread #1: tid = 0x6290629, 0x000100679ae7
cc1plus`cgraph_node::function_symbol(this=,
availability=0x) + 71 at cgraph.c:3129, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
frame #0: 0x000100679ae7
cc1plus`cgraph_node::function_symbol(this=,
availability=0x) + 71 at cgraph.c:3129
3126
3127 while (node->thunk.thunk_p)
3128{
-> 3129 node = node->callees->callee;
3130 if (availability)
3131{
3132 enum availability a;
(lldb) bt
* thread #1: tid = 0x6290629, 0x000100679ae7
cc1plus`cgraph_node::function_symbol(this=,
availability=0x) + 71 at cgraph.c:3129, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
* frame #0: 0x000100679ae7
cc1plus`cgraph_node::function_symbol(this=,
availability=0x) + 71 at cgraph.c:3129
frame #1: 0x000100eb8281
cc1plus`ix86_function_regparm(type=0x000142776a80, decl=0x000142777bd0)
+ 305 at i386.c:5774
frame #2: 0x000100eba687
cc1plus`x86_can_output_mi_thunk((null)=, (null)=,
vcall_offset=-16, function=0x000142777bd0) + 55 at i386.c:42800
frame #3: 0x00010019c0f8
cc1plus`use_thunk(thunk_fndecl=0x000142777e58, emit_p=) + 1416
at method.c:422
frame #4: 0x0001001b7ddd
cc1plus`emit_associated_thunks(fn=) + 509 at semantics.c:4031
frame #5: 0x0001001b828b
cc1plus`expand_or_defer_fn(fn=0x000142777288) + 59 at semantics.c:4122
frame #6: 0x00010014aed8
cc1plus`cp_parser_function_definition_after_declarator(parser=0x000142767000,
inline_p=) + 248 at parser.c:23481
frame #7: 0x00010014be27 cc1plus`cp_parser_init_declarator + 3207 at
parser.c:23385
frame #8: 0x00010014d54e
cc1plus`cp_parser_simple_declaration(parser=0x000142767000,
function_definition_allowed_p=true, maybe_range_for_decl=0x) +
558 at parser.c:11601
frame #9: 0x00010014d904
cc1plus`cp_parser_block_declaration(parser=0x000142767000,
statement_p=) + 116 at parser.c:11475
frame #10: 0x0001001568ca
cc1plus`cp_parser_declaration(parser=0x000142767000) + 394 at
parser.c:11372
frame #11: 0x000100156b7d
cc1plus`cp_parser_declaration_seq_opt(parser=0x000142767000) + 125 at
parser.c:11258
frame #12: 0x000100156ed2 cc1plus`c_parse_file() + 22 at parser.c:4109
frame #13: 0x000100156ebc cc1plus`c_parse_file() + 604
frame #14: 0x0001002a1e76 cc1plus`c_common_parse_file() + 246 at
c-opts.c:1052
frame #15: 0x000100b6921c cc1plus`compile_file + 44 at toplev.c:594
frame #16: 0x000100fe6507 cc1plus`toplev::main(int, char**) + 1288 at
toplev.c:2066
frame #17: 0x000100fe5fff cc1plus`toplev::main(this=,
argc=4, argv=0x7fff5fbff328) + 719
frame #18: 0x000100fe720c cc1plus`main(argc=,
argv=) + 44 at main.c:39
[Bug ipa/64982] [5 Regression] Many g++ failures on x86_64-apple-darwin14 with -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64982 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-09 Ever confirmed|0 |1
[Bug testsuite/64983] New: Incomplete summary when regtesting with dejagnu 1.5.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64983 Bug ID: 64983 Summary: Incomplete summary when regtesting with dejagnu 1.5.2. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr
[Bug middle-end/64909] [4.8/5 regression] Missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64909 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- I think that SLP doesn't consider this kind of operation (in loops it wouldn't help and the non-loop case has not many cases that exceed those handled by the loop code). Any standalone testcase only showing the BB SLP opportunity? That is, non-loop code from the start?
[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/64927] [4.8 Regression] Surprising error with -Wsurprising (-Wall) and TRANSFER + C_ASSOCIATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.8.5 Summary|[4.7/4.8 Regression]|[4.8 Regression] Surprising |Surprising error with |error with -Wsurprising |-Wsurprising (-Wall) and|(-Wall) and TRANSFER + |TRANSFER + C_ASSOCIATED |C_ASSOCIATED
[Bug debug/64935] [5 Regression] compare debug failure during building of Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/64930] [5 regression] FAIL: gcc.target/powerpc/atomic-p7.c scan-assembler-times isync 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 --- Comment #1 from Richard Biener --- smells like wrong-code?
[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 changed: What|Removed |Added Keywords||memory-hog Component|other |middle-end Known to work||4.4.7 Target Milestone|--- |4.8.5 Summary|Inordinate cpu time and |[4.8/4.9/5 Regression] |memory usage in "phase opt |Inordinate cpu time and |and generate" with |memory usage in "phase opt |-ftest-coverage |and generate" with |-fprofile-arcs |-ftest-coverage ||-fprofile-arcs --- Comment #7 from Richard Biener --- Given from the description I suppose that non-profiling/coverage mode is fine.
[Bug c/64964] -D_FORTIFY_SOURCE=2 passes incorrect length to _chk functions in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64964 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 64715 ***
[Bug c++/64956] [5 Regression] __GXX_ABI_VERSION needs a proper definition for the 5.x releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64956 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-09 Target Milestone|--- |5.0 Summary|__GXX_ABI_VERSION needs a |[5 Regression] |proper definition for the |__GXX_ABI_VERSION needs a |5.x releases|proper definition for the ||5.x releases Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[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 changed: What|Removed |Added CC||nszabolcs at gmail dot com --- Comment #6 from Richard Biener --- *** Bug 64964 has been marked as a duplicate of this bug. ***
[Bug c++/64956] [5 Regression] __GXX_ABI_VERSION needs a proper definition for the 5.x releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64956 --- Comment #2 from Jakub Jelinek --- Well, -fabi-version=0 (which is the default now) has always behaved that way. The question is if we want to change that or not.
[Bug fortran/64980] [5 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Summary|[5.0 Regression] ICE in |[5 Regression] ICE in |trans-expr.c|trans-expr.c
[Bug middle-end/64966] [5 Regression] -fcompare-debug failure with -O -fschedule-insns --param=max-sched-ready-insns=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64966 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/64979] S/390: va_list overflow area pointer is not setup due to stdarg optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64979 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target||s390-linux Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-09 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug ipa/64978] [5 Regression] ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64978 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug testsuite/64983] Incomplete summary when regtesting with dejagnu 1.5.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64983 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-09 CC||howarth at bromo dot med.uc.edu, ||iains at gcc dot gnu.org, ||mrs at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- With dejagnu 1.5.1, the summary looks like ... === g++ tests === Running target unix/-m32 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++11 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++14 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++98 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/pch/pch.C -O2 -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/pch.C -O2 assembly comparison WARNING: program timed out. FAIL: g++.dg/tm/pr47573.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/tm/pr47573.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/tm/pr47573.C -std=gnu++98 (test for excess errors) === g++ Summary for unix/-m32 === # of expected passes88065 # of unexpected failures8 # of expected failures320 # of unsupported tests3647 Running target unix/-m64 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++11 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++14 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++98 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/pch/pch.C -O2 -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/pch.C -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/pch.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/pch.C -g assembly comparison FAIL: g++.dg/pch/pch.C -O2 -g assembly comparison WARNING: program timed out. FAIL: g++.dg/tm/pr47573.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/tm/pr47573.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/tm/pr47573.C -std=gnu++98 (test for excess errors) === g++ Summary for unix/-m64 === # of expected passes89465 # of unexpected failures11 # of expected failures320 # of unsupported tests3888 === g++ Summary === # of expected passes177530 # of unexpected failures19 # of expected failures640 # of unsupported tests7535 /opt/gcc/build_w/gcc/testsuite/g++/../../xg++ version 5.0.0 20150207 (experimental) [trunk revision 220502p20] (GCC) ... as in https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00877.html. With dejagnu 1.5.2, it looks like ... === g++ tests === Running target unix/-m32 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++11 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++14 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++98 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/tm/pr47573.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/tm/pr47573.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/tm/pr47573.C -std=gnu++98 (test for excess errors) === g++ Summary for unix/-m32 === # of expected passes20311 # of expected failures61 # of unsupported tests62 Running target unix/-m64 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++11 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++14 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/debug/dwarf2/imported-decl-2.C -std=gnu++98 scan-assembler-times ascii "0".*ascii "0".*DIE .0x[0-9a-f]*. DW_TAG_imported_declaration 1 FAIL: g++.dg/tm/pr47573.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/tm/pr47573.C
[Bug sanitizer/64981] [5 regression] -fsanitize=address cant expand __builtin_ia32_rdtsc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64981 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0 Summary|[5.0 regression]|[5 regression] |-fsanitize=address cant |-fsanitize=address cant |expand __builtin_ia32_rdtsc |expand __builtin_ia32_rdtsc
[Bug middle-end/64909] [4.8/5 regression] Missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64909
--- Comment #5 from Jakub Jelinek ---
E.g.
unsigned short a[32];
unsigned int b[32];
void
foo ()
{
b[0] = a[0];
b[1] = a[1];
b[2] = a[2];
b[3] = a[3];
}
will do, or b[0] = a[0] + 5; b[1] = a[1] + 5; b[2] = a[2] + 5; b[3] = a[3] + 5;
and similar.
[Bug target/64979] [4.8/4.9/5 Regression] stdarg optimization not able to find escape sites in phi nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64979 Jakub Jelinek changed: What|Removed |Added Target|s390-linux | CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.5 Summary|S/390: va_list overflow |[4.8/4.9/5 Regression] |area pointer is not setup |stdarg optimization not |due to stdarg optimization |able to find escape sites ||in phi nodes
[Bug ipa/64982] [5 Regression] Many g++ failures on x86_64-apple-darwin14 with -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64982 --- Comment #1 from howarth at bromo dot med.uc.edu --- Author: hubicka Date: Sun Feb 8 21:08:44 2015 New Revision: 220521 URL: https://gcc.gnu.org/viewcvs?rev=220521&root=gcc&view=rev Log: PR ipa/63566 * ipa-visibility.c (cgraph_node::non_local_p): Accept aliases. (cgraph_node::local_p): Remove thunk related FIXME. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-visibility.c might be a likely suspect.
[Bug middle-end/64909] [4.8/5 regression] Missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64909
--- Comment #6 from Richard Biener ---
(In reply to Jakub Jelinek from comment #5)
> E.g.
> unsigned short a[32];
> unsigned int b[32];
>
> void
> foo ()
> {
> b[0] = a[0];
> b[1] = a[1];
> b[2] = a[2];
> b[3] = a[3];
> }
>
> will do, or b[0] = a[0] + 5; b[1] = a[1] + 5; b[2] = a[2] + 5; b[3] = a[3] +
> 5;
> and similar.
So it first of all boils down to the vectorizer not handling vectors of
different
size (V4HI and V4SI) at the same time. The same thing happens when you
vectorize
double<->int conversion (for which there is already a bug somewhere). For loop
vectorization this usually causes unnecessary unrolling (though that may be
profitable in the end).
[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 changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-02-09
Ever confirmed|0 |1
--- Comment #8 from Richard Biener ---
Ok, so the memory is used by out-of-SSA it seems
#5 0x00c9eebc in coalesce_ssa_name ()
at /space/rguenther/src/svn/gcc-4_9-branch/gcc/tree-ssa-coalesce.c:1330
1330 graph = build_ssa_conflict_graph (liveinfo);
(gdb) p *cl->list.htab
$10 = {entries = 0x2b19b30, size = 524287, n_elements = 77146, n_deleted = 0,
searches = 122189, collisions = 6508, size_prime_index = 16}
where we malloc(!) 77146 entries of size 12.
But of course bad is the conflict graph with 76063 bitmaps eating up around
1GB of memory for the first testcase (and function
___H__23__23_u8vector_2d__3e_object).
That's likely caused by the change to more aggressively coalesce anonymous
SSA names.
[Bug c++/64948] Lambda reference capture initialization in template function creates segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64948 --- Comment #2 from Andrea Azzarone --- (In reply to Andrea Azzarone from comment #1) > Created attachment 34705 [details] > Proposed fix to allow the use of enable_if for UDLs. Sorry this patch was for a different bug report. Please delete it if possible.
[Bug c++/64959] SFINAE in UDLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64959 Andrea Azzarone changed: What|Removed |Added CC||andrea.azzarone at canonical dot c ||om --- Comment #1 from Andrea Azzarone --- Created attachment 34706 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34706&action=edit Proposed fix to allow the use of enable_if for UDLs.
[Bug fortran/57284] [OOP] ICE with find_array_spec for polymorphic arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57284 --- Comment #3 from Lorenz Hüdepohl --- Any progress on this one? 4.9.2 still produces the error: > ~/sys/stow/gcc-4.9.2/bin/gfortran --version GNU Fortran (GCC) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING > ~/sys/stow/gcc-4.9.2/bin/gfortran minimal.f90 minimal.f90:10.9: program p 1 Internal Error at (1): find_array_spec(): unused as(1)
[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 changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- It seems that loop invariant motion is responsible for most of the abnormals, thus -fno-tree-loop-im restores performance. The loop LIM detects is of style : (header) # ___fp_3(ab) = PHI <___fp_41(4), ___fp_5(21)> # ___r1_7(ab) = PHI <___r1_42(4), ___r1_9(21)> # ___r2_11(ab) = PHI <___r2_43(4), ___r3_17(21)> # ___r3_19(ab) = PHI <___r3_44(4), ___r3_23(21)> # ___r4_25 = PHI <___r4_45(4), ___r4_26(21)> # gotovar.17_29 = PHI <_51(4), _69(21)> goto gotovar.17_29; ... : (latch) _67 = ___pc_1 + 15; _68 = (void * *) _67; _69 = *_68; PROF_edge_counter_142 = __gcov0.___H_object_2d__3e_u8vector[14]; PROF_edge_counter_143 = PROF_edge_counter_142 + 1; __gcov0.___H_object_2d__3e_u8vector[14] = PROF_edge_counter_143; goto ; not sure if we should artificially limit such loops. LIM doesn't account for the (compile-time) cost of needing very many PHIs when rewriting the store-motion vars into SSA form (but it could in theory estimate by taking into account the CFG structure of the "loop"). Let's see if we can first generate a smaller testcase to illustrate the issue. Mine for now.
[Bug debug/63572] [5 Regression] ICF breaks user debugging experience
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572 --- Comment #10 from Martin Liška --- As Cary Countant wrote me, gold's ICF has never implemented support for call site tables in GDB. Moreover, when Jakub designed the new call site tags, the design hasn't been changed. In last 4 years, there still hasn't been any demand for it. Well, I would at least implement emission of a separate DW_TAG_subprogram DIE with correct DW_AT_abstract_origin. As I have no experience with debug info, may I ask Jakub for a hint where to start and how to properly do it?
[Bug sanitizer/64984] New: [5 Regression] ICE in check_noexcept_t with ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64984
Bug ID: 64984
Summary: [5 Regression] ICE in check_noexcept_t with ubsan
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
With this test program I get an ICE.
--
#include
class Type
{
public:
Type();
virtual ~Type();
bool operator<(const Type &) const;
};
int main()
{
std::map map;
map[Type()] = 0;
}
g++ --version
g++ (GCC) 5.0.0 20150203 (experimental)
g++ -fsanitize=undefined -std=gnu++11 -c test.cpp
In file included from /opt/gcc/gcc-trunk/include/c++/5.0.0/bits/move.h:57:0,
from /opt/gcc/gcc-trunk/include/c++/5.0.0/bits/stl_pair.h:59,
from
/opt/gcc/gcc-trunk/include/c++/5.0.0/bits/stl_algobase.h:64,
from /opt/gcc/gcc-trunk/include/c++/5.0.0/bits/stl_tree.h:63,
from /opt/gcc/gcc-trunk/include/c++/5.0.0/map:60,
from test.cpp:1:
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits: In instantiation of ‘struct
std::__is_nt_constructible_impl’:
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits:137:12: required from
‘struct std::__and_,
std::__is_nt_constructible_impl >’
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits:1174:12: required from
‘struct std::is_nothrow_constructible’
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits:1205:12: required from
‘struct std::__is_nothrow_move_constructible_impl’
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits:1211:12: required from
‘struct std::is_nothrow_move_constructible’
/opt/gcc/gcc-trunk/include/c++/5.0.0/tuple:367:7: required from ‘constexpr
std::_Tuple_impl<_Idx, _Head>::_Tuple_impl(std::_Tuple_impl<_Idx, _Head>&&)
[with long unsigned int _Idx = 0ul; _Head = Type&&]’
/opt/gcc/gcc-trunk/include/c++/5.0.0/tuple:976:70: required from
‘std::tuple<_Elements&& ...> std::forward_as_tuple(_Elements&& ...) [with
_Elements = {Type}]’
/opt/gcc/gcc-trunk/include/c++/5.0.0/bits/stl_map.h:500:27: required from
‘std::map<_Key, _Tp, _Compare, _Alloc>::mapped_type& std::map<_Key, _Tp,
_Compare, _Alloc>::operator[](std::map<_Key, _Tp, _Compare,
_Alloc>::key_type&&) [with _Key = Type; _Tp = int; _Compare = std::less;
_Alloc = std::allocator >; std::map<_Key, _Tp,
_Compare, _Alloc>::mapped_type = int; std::map<_Key, _Tp, _Compare,
_Alloc>::key_type = Type]’
test.cpp:15:15: required from here
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits:1162:12: internal compiler
error: Segmentation fault
struct __is_nt_constructible_impl<_Tp, _Arg>
^
0xa89c7f crash_signal
../../gcc/gcc/toplev.c:383
0x69ea1b check_noexcept_r
../../gcc/gcc/cp/except.c:1162
0xc6b254 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set*))
../../gcc/gcc/tree.c:11086
0xc6b438 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set*))
../../gcc/gcc/tree.c:11390
0xc6ca18 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set*))
../../gcc/gcc/tree.c:11416
0x69e7cf expr_noexcept_p(tree_node*, int)
../../gcc/gcc/cp/except.c:1255
0x69e922 finish_noexcept_expr(tree_node*, int)
../../gcc/gcc/cp/except.c:1240
0x61e2ee tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14880
0x61b6ab tsubst_expr
../../gcc/gcc/cp/pt.c:14383
0x61c63c tsubst_template_arg
../../gcc/gcc/cp/pt.c:9692
0x626839 tsubst_template_args
../../gcc/gcc/cp/pt.c:10242
0x623544 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:10439
0x617771 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11894
0x631c69 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:9260
0x631c69 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9673
0x68aa5d complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:146
0x68aaff complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:158
0x608d09 xref_basetypes(tree_node*, tree_node*)
../../gcc/gcc/cp/decl.c:12493
0x63116e instantiate_class_template_1
../../gcc/gcc/cp/pt.c:9279
0x63116e instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9673
[Bug sanitizer/64984] [5 Regression] ICE in check_noexcept_t with ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64984 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-09 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. Seems to be a bug in the vptr checking; -std=gnu++11 -fsanitize=vptr ICEs, -std=gnu++11 -fsanitize=undefined -fno-sanitize=vptr compiles ok.
[Bug fortran/64980] [5 Regression] ICE in trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980 --- Comment #5 from Mikael Morin --- (In reply to Mikael Morin from comment #4) > This cures it: Another way to cure it: Index: trans-expr.c === --- trans-expr.c(révision 220514) +++ trans-expr.c(copie de travail) @@ -3783,10 +3783,6 @@ gfc_apply_interface_mapping_to_expr (gfc_interface expr->symtree = sym->new_sym; else if (sym->expr) gfc_replace_expr (expr, gfc_copy_expr (sym->expr)); -/* Replace base type for polymorphic arguments. */ -if (expr->ref && expr->ref->type == REF_COMPONENT -&& sym->expr && sym->expr->ts.type == BT_CLASS) - expr->ref->u.c.sym = sym->expr->ts.u.derived; } /* ...and to subexpressions in expr->value. */
[Bug libgcc/61309] cilk-plus tests fail with: hidden symbol `__cpu_model' in /x/gcc/testsuite/g++/../../libgcc.a(cpuinfo.o) is referenced by DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61309 --- Comment #3 from Kai-Uwe Eckhardt --- Hello John, > FYI, this is still happening. > So if/when DragonFly features libgcc_s from 5.0 in base, these errors will go > away? To be honest I am not quite sure, but I think it is not the presence of libgcc_s.so itself but the presence of __cpu_model within. Mabey a linker script similar to the one in PR 40134 would help. > If so, doesn't that imply the linking is making assumptions it should not > make? Cilk is Linux centric in other places as as well, so I wouldn't wonder. I don't have a Linux system at hand right now to compare the defined symbols. Actually I am giving up on gcc and NetBSD. I have tried to push some changes upstream but gcc has become too complex for my skills and the number of upstream NetBSD developers is too low. Good luck with Dragonfly. Kind regards, Kai-Uwe
[Bug ipa/64982] [5 Regression] Many g++ failures on x86_64-apple-darwin14 with -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64982 --- Comment #2 from howarth at bromo dot med.uc.edu --- Actually reverting... Author: hubicka Date: Sun Feb 8 21:04:41 2015 New Revision: 220520 URL: https://gcc.gnu.org/viewcvs?rev=220520&root=gcc&view=rev Log: PR ipa/63566 * i386.c (ix86_function_regparm): Look through aliases to see if callee is local and optimized. (ix86_function_sseregparm): Likewise; also use target's SSE math settings; error out instead of silently generating wrong code on mismatches. (init_cumulative_args): Look through aliases. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c eliminates the ICEs in g++.dg/abi/covariant2.C at -m32 on x86_64-apple-darwin14. Probably related to the absence of alias support on darwin.
[Bug target/64377] nios2 compile error in options-save.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377 --- Comment #20 from Martin Liška --- Can I please ask someone to confirm that the patch works and mark this issue as resolved?
[Bug sanitizer/64984] [5 Regression] ICE in check_noexcept_t with ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64984 --- Comment #2 from Jakub Jelinek --- I'll have a look tomorrow.
[Bug target/64377] nios2 compile error in options-save.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377 Joel Sherrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #21 from Joel Sherrill --- (In reply to Martin Liška from comment #20) > Can I please ask someone to confirm that the patch works and mark this issue > as resolved? As reported above, I built the toolset and RTEMS but have no target to test on. I am going to close it. Sandra was testing on hardware so it is safe to safe she got by this as well.
[Bug ipa/64978] [5 Regression] ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64978
--- Comment #5 from Markus Trippelsdorf ---
Reduced testcase for comment 4:
trippels@gcc20 test % cat VTableBuilder.ii
class A {
public:
A(int, int);
};
class B {
public:
void m_fn1(bool, const int *, int &);
unsigned m_fn2();
};
namespace {
class C {
B &VTables;
void m_fn3(A, unsigned, const int *, int &);
public:
int VFTableBuilder_VisitedBases;
B VFTableBuilder_VTables;
C() : VTables(VFTableBuilder_VTables) {
m_fn3(A(0, 0), 0, 0, VFTableBuilder_VisitedBases);
}
};
}
int a;
void C::m_fn3(A, unsigned, const int *, int &) {
for (;;)
1 ? VTables.m_fn2() : 0;
}
void B::m_fn1(bool, const int *, int &) { C(); }
unsigned B::m_fn2() { m_fn1(0, 0, a); }
trippels@gcc20 test % g++ -O2 -c VTableBuilder.ii
VTableBuilder.ii:29:39: internal compiler error: in
ipcp_verify_propagated_values, at ipa-cp.c:1060
[Bug ipa/64978] [5 Regression] ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64978
--- Comment #6 from Markus Trippelsdorf ---
IPA lattices after constant propagation, before gcc_unreachable:
Lattices:
Node: void {anonymous}::C::m_fn3(A, unsigned int, const int*, int&)/10:
param [0]: TOP
ctxs: VARIABLE
Alignment unusable
AGGS VARIABLE
Node: unsigned int B::m_fn2()/6:
param [0]: BOTTOM
ctxs: BOTTOM
Alignment unusable
AGGS BOTTOM
Node: void B::m_fn1(bool, const int*, int&)/5:
param [0]: BOTTOM
ctxs: BOTTOM
Alignment unusable
AGGS BOTTOM
param [1]: BOTTOM
ctxs: BOTTOM
Alignment unusable
AGGS BOTTOM
param [2]: BOTTOM
ctxs: BOTTOM
Alignment unusable
AGGS BOTTOM
param [3]: BOTTOM
ctxs: BOTTOM
Alignment unusable
AGGS BOTTOM
Node: {anonymous}::C::C()/1:
param [0]: VARIABLE
ctxs: VARIABLE
Alignment 16, misalignment 0
AGGS VARIABLE
[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64670 --- Comment #7 from Tobias Burnus --- (In reply to Tobias Burnus from comment #6) > Created attachment 34628 [details] > Updated test case (part 2/2): [aux file] Missed to state: This file 'implements' the "class LogListener" - however, the generated .o file contains no symbols. Using an explicit. #pragma implementation doesn't change the result.
[Bug lto/64693] [5 Regression] PCH failed with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64693 --- Comment #7 from Martin Liška --- (In reply to H.J. Lu from comment #6) > A patch is posted at > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02108.html Hello. I've just finished more sensitive patch for the issue and I've just restarted profiled bootstrap. Tomorrow, I'm going to send new version of the patch. Thanks, Martin
[Bug target/64979] [4.8/4.9/5 Regression] stdarg optimization not able to find escape sites in phi nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64979 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Mon Feb 9 17:01:36 2015 New Revision: 220543 URL: https://gcc.gnu.org/viewcvs?rev=220543&root=gcc&view=rev Log: PR target/64979 * tree-stdarg.c (pass_stdarg::execute): Scan phi node args for va_list escapes. * gcc.dg/tree-ssa/stdarg-7.c: New test. * gcc.c-torture/execute/pr64979.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr64979.c trunk/gcc/testsuite/gcc.dg/tree-ssa/stdarg-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-stdarg.c
[Bug ipa/64813] [5 Regression] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64813 --- Comment #20 from Dominique d'Humieres --- Full regtesting just completed. Unless pr64982 and https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00550.html are masking some latent bug introduced by the patch, it does not seem to introduce any regression. Thanks.
[Bug ada/64985] New: Default Scalar Storage Order Fails when an address is associated with a record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64985 Bug ID: 64985 Summary: Default Scalar Storage Order Fails when an address is associated with a record Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: daniel.merrill at psware dot com CC: ebotcazou at gcc dot gnu.org Created attachment 34707 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34707&action=edit Addresses failure when default scalar storage order is set. The ada compiler crashes when trying to link a record which contains an address and is set to a different scalar storage order than the default. Example code to reproduce the problem included.
[Bug fortran/64986] New: class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Bug ID: 64986 Summary: class_to_type_4.f90: valgrind error: Invalid read/write of size 8 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com /ssd/uros/gcc-build/gcc/gfortran -B /ssd/uros/gcc-build/gcc -B /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libgfortran/ -L /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libgfortran/.libs/ -L /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libquadmath/.libs/ -O2 -g class_to_type_4.f90 $ valgrind ./a.out ==991== Memcheck, a memory error detector ==991== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==991== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==991== Command: ./a.out ==991== ==991== Invalid read of size 8 ==991==at 0x401F8F: MAIN__ (class_to_type_4.f90:58) ==991==by 0x40076C: main (class_to_type_4.f90:63) ==991== Address 0x51afcb8 is 8 bytes inside a block of size 104 free'd ==991==at 0x4A07CE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==991==by 0x401F8E: MAIN__ (class_to_type_4.f90:58) ==991==by 0x40076C: main (class_to_type_4.f90:63) ==991== ==991== Invalid write of size 8 ==991==at 0x401FAB: MAIN__ (class_to_type_4.f90:58) ==991==by 0x40076C: main (class_to_type_4.f90:63) ==991== Address 0x51afcb8 is 8 bytes inside a block of size 104 free'd ==991==at 0x4A07CE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==991==by 0x401F8E: MAIN__ (class_to_type_4.f90:58) ==991==by 0x40076C: main (class_to_type_4.f90:63) ==991==
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Uroš Bizjak changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #1 from Uroš Bizjak --- The testcase is from PR63205, CC author.
[Bug fortran/63205] [OOP] Wrongly rejects type = class (for identical declared type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205 --- Comment #12 from Uroš Bizjak --- Reopening, something is wrong with the testcase:(In reply to Paul Thomas from comment #11) > Fixed on trunk, aka 5.0.0 The added testcase fails with valgrind due to memory errors, please see PR64986.
[Bug fortran/63205] [OOP] Wrongly rejects type = class (for identical declared type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205 Uroš Bizjak changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #13 from Uroš Bizjak --- (In reply to Paul Thomas from comment #11) Reopening.
[Bug other/63513] Error to build gcc loaded from svn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63513 Andrew Pinski changed: What|Removed |Added Target||x86_64-apple-darwin13.4.0 Status|UNCONFIRMED |WAITING Last reconfirmed||2015-02-09 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Does this happen still? I know other folks have built a compiler for x86_64-apple-darwin13.4.0 natively.
[Bug target/60159] improve code for conditional sibcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60159 Andrew Pinski changed: What|Removed |Added Target||i?86-*-* x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-09 Component|rtl-optimization|target Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- This is a target specific bug because most other targets don't have the range for their conditional branches compared to their normal jumps. Confirmed.
[Bug bootstrap/60244] GCC-trunk rev.207809, Segmentation fault when executing ".../xgcc -dumpspecs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60244 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-02-09 Ever confirmed|0 |1 --- Comment #6 from Andrew Pinski --- Does this still happen?
[Bug target/63652] [AArch64_be] vzip/vuzp tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63652 --- Comment #1 from Andrew Pinski --- Hasn't this been fixed or at least the patch submitted to fix them?
[Bug ipa/64982] [5 Regression] Many g++ failures on x86_64-apple-darwin14 with -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64982 --- Comment #3 from Jan Hubicka --- Hmm, I see. The problem is that asm_out.can_output_mi_thunk now needs to walk alias to know what ABI the callee function uses and aliases are not analyzed at this point. I solved similar issue in cgraphunit, I think we can safely move that diagnostics there.
[Bug ada/64985] Default Scalar Storage Order Fails when an address is associated with a record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64985 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-09 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Confirmed, but please do _not_ use this pragma, it's essentially untested and is guaranteed to be a disaster performance-wise...
[Bug other/63492] bconfig.h or config.h for gencondmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63492 Andrew Pinski changed: What|Removed |Added Severity|critical|normal --- Comment #2 from Andrew Pinski --- Can you expand on what you think is going wrong here? genconditions.c is compiled for the build machine. it outputs C code that is then compiled. Which macros do you think genconditions.c is getting incorrect?
[Bug other/63492] bconfig.h or config.h for gencondmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63492 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-02-09 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Can you expand on what you think is going wrong here? genconditions.c is compiled for the build machine. it outputs C code that is then compiled. Which macros do you think genconditions.c is getting incorrect?
[Bug middle-end/63451] bad location for the condition in for-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63451 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-09 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/64987] New: alignas(N) (and __attribute__(__aligned__(N))) ignored on enum specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64987
Bug ID: 64987
Summary: alignas(N) (and __attribute__(__aligned__(N))) ignored
on enum specifiers
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Testcase:
enum alignas(16) E {};
E e;
GCC fails to align 'e' to 16 bytes.
The same issue exists for __attribute__((__aligned__(16))), which the
documentation suggests should work.
[Bug c++/63693] ICE c-opts.c:1067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63693 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-09 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.; still ICEs as of today.
