[Bug c++/69850] New: [6 Regression] unnecessary -Wnonnull-compare warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
Bug ID: 69850
Summary: [6 Regression] unnecessary -Wnonnull-compare warning
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
trippels@gcc2-power8 status % cat cmp_set.ii
class shared_count {
public:
~shared_count() { delete this; }
};
class A {
shared_count pn;
};
class B {
public:
B(bool);
A m_message;
};
void fn1(B) { fn1(0); }
trippels@gcc2-power8 status % g++ -Wall -O2 -c cmp_set.ii
cmp_set.ii: In destructor ‘shared_count::~shared_count()’:
cmp_set.ii:3:32: warning: nonnull argument ‘this’ compared to NULL
[-Wnonnull-compare]
~shared_count() { delete this; }
^
[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850 --- Comment #1 from Markus Trippelsdorf --- Obviously started with r233472.
[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-02-17 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Can you still reproduce this? I've succeeded with several profiledbootstraps on s390x-linux as well as s390-linux.
[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241 --- Comment #31 from Jakub Jelinek --- (In reply to Markus Trippelsdorf from comment #30) > On IRC someone pointed to a new variant (huge Boost testcase): That looks unrelated to this PR, it is not about missing lhs in a call that returns non-POD, but it is ICE during expansion of some weirdo assignment statement. So IMHO it should be tracked separately.
[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241 Markus Trippelsdorf changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #32 from Markus Trippelsdorf --- I've opened PR69851.
[Bug c++/69851] New: [6 Regression] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851
Bug ID: 69851
Summary: [6 Regression] ICE: in assign_temp, at function.c:961
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
markus@x4 tmp % cat subprocess.ii
namespace std {
template struct integral_constant {
static constexpr _Tp value = 0;
};
template struct conditional;
template struct __or_;
template
struct __or_<_B1, _B2> : conditional<_B2>::type {};
template struct is_enum : integral_constant
{};
template struct remove_reference;
template struct remove_reference<_Tp &> { typedef _Tp type; };
template struct decay {
typedef typename remove_reference<_Tp>::type type;
};
template struct conditional { typedef is_enum type; };
template struct _Head_base { _Head _M_head_impl; };
template struct _Tuple_impl;
template
struct _Tuple_impl<_Idx, _Head, _Tail...> : _Tuple_impl<1, _Tail...>,
_Head_base<_Head> {
_Tuple_impl(_Tuple_impl &) = default;
_Tuple_impl(_Tuple_impl &&__in) : _Tuple_impl(__in) {}
};
template
struct _Tuple_impl<_Idx, _Head> {};
template struct tuple : _Tuple_impl<0, _Elements...>
{};
template struct _Bind;
template
struct _Bind<_Functor(_Bound_args...)> {
tuple<_Bound_args...> _M_bound_args;
};
template ::type>
using __is_socketlike = __or_, is_enum<_Tp2>>;
template struct _Bind_helper {
typedef _Bind::type...)> type;
};
template
typename _Bind_helper<__is_socketlike<_Func>::value, _BoundArgs...>::type
bind(_Func &&, _BoundArgs &&...);
struct _Any_data {
template _Tp _M_access() const;
};
enum _Manager_operation {};
template struct function;
struct _Function_base {
template struct _Base_manager {
static bool _M_manager(_Any_data &, const _Any_data &__source,
_Manager_operation) {
_Functor(*__source._M_access<_Functor *>());
}
};
typedef bool (*_Manager_type)(_Any_data &, const _Any_data &,
_Manager_operation);
_Manager_type _M_manager;
};
template struct _Function_handler;
template
struct _Function_handler<_Res(_ArgTypes...), _Functor>
: _Function_base::_Base_manager<_Functor> {};
template
struct function<_Res(_ArgTypes...)> : _Function_base {
template using _Requires = int;
template ,
typename = _Requires>
function(_Functor);
_Res operator()(_ArgTypes...);
};
template
template
function<_Res(_ArgTypes...)>::function(_Functor) {
_M_manager = _Function_handler<_Res(), _Functor>::_M_manager;
}
}
struct Option {
Option(Option &);
};
using std::bind;
using std::function;
struct Subprocess {};
using InputFileDescriptors = Subprocess;
using OutputFileDescriptors = int;
void defaultClone(Option setup) {
InputFileDescriptors stdinfds;
OutputFileDescriptors stdoutfds, envp;
function)> clone = 0;
int pipes = clone(bind(envp, setup, stdinfds, stdoutfds, pipes));
}
markus@x4 tmp % g++ -c subprocess.ii
subprocess.ii: In copy constructor ‘std::_Tuple_impl<_Idx, _Head, _Tail
...>::_Tuple_impl(std::_Tuple_impl<_Idx, _Head, _Tail ...>&) [with long
unsigned int _Idx = 0ul; _Head = Option; _Tail = {Subprocess, int, int}]’:
subprocess.ii:21:3: internal compiler error: in assign_temp, at function.c:961
_Tuple_impl(_Tuple_impl &) = default;
^~~
0xa51353 assign_temp(tree_node*, int, int)
../../gcc/gcc/function.c:961
0x9e9e25 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10408
0x9f9048 expand_normal
../../gcc/gcc/expr.h:262
0x9f9048 store_field
../../gcc/gcc/expr.c:6679
0x9f4c7d expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5021
0x8e79de expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3606
0x8e79de expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3702
0x8e9e88 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5708
0x8efe96 execute
../../gcc/gcc/cfgexpand.c:6323
[Bug rtl-optimization/69609] block reordering consumes an inordinate amount of time, REE consumes much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609
--- Comment #7 from David Binderman ---
(In reply to Richard Biener from comment #6)
> Maybe sth as simple as
>
> Index: gcc/bb-reorder.c
> ===
> --- gcc/bb-reorder.c(revision 233262)
> +++ gcc/bb-reorder.c(working copy)
> @@ -889,6 +889,7 @@ bb_to_key (basic_block bb)
>
>/* Prefer blocks whose predecessor is an end of some trace
> or whose predecessor edge is EDGE_DFS_BACK. */
> + if (EDGE_COUNT (bb->preds) <= 8)
>FOR_EACH_EDGE (e, ei, bb->preds)
> {
>if ((e->src != ENTRY_BLOCK_PTR_FOR_FN (cfun)
>
> or precomputing whether a BB has abnormal preds and disabling the trace in
> that case (or somehow sorting the edge vectors so that abnormal edges
> come last so we can stop at the first abnormal edge).
I tried this patch and it changes compile time from something
more than ten minutes to 1m57s.
More than five times faster looks good to go to me.
[Bug c++/69851] [6 Regression] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-02-17
CC||jakub at gcc dot gnu.org
Target Milestone|--- |6.0
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Reduced testcase:
template
struct A { T a; };
template
struct B;
template
struct B : B<1, U...>, A
{
B (B &) = default;
B (B &&__in) : B(__in) {}
};
template
struct B {};
struct C { C (C &); };
struct D {};
void
foo (B<0, C, D, int, int> a)
{
B<0, C, D, int, int> b (a);
}
[Bug c/28901] -Wunused-variable ignores unused const initialised variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 Panu Matilainen changed: What|Removed |Added CC||pmatilai at laiskiainen dot org --- Comment #26 from Panu Matilainen --- (In reply to Josh Triplett from comment #23) > Please don't attach this to -Wextra; instead, please consider making it a > -Wconst-unused-variable=2 or similar. Otherwise, projects using static > const values in header files would get a massive pile of additional > warnings, typically all false positives. > > In a main file, this makes sense and likely has relatively few false > positives; the most common false positive would involve defining something > only used in ifdef'd code, and even then tagging it with > __attribute__((unused)) (Linux's __maybe_unused) seems correct. > > However, in a header file, any use of static const to define constants for a > project will almost certainly get this warning, unless every single user of > that header file (directly or indirectly) uses every constant (or unless the > header itself does). Silently throwing away the unused constants seems like > the right thing to do there. Seconded, +100, amen. On main files warning on unused junk is certainly useful but static const is commonly and deliberately used in headers (eg for arrays such as in comment #18) and now produces unhelpful false positives. In case somebody really wants to see the warnings from headers too, something like -Wconst-unused-variable=2 sounds fine but it should not be a default. Just as a random data point: out of the three projects I've so far compiled with gcc 6 (on fedora rawhide), two have false positives from static const arrays in headers. The other one has them by the dozen.
[Bug c++/69851] [6 Regression] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC||jason at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Started with r228704, with ICEs like
pr69851.C: In copy constructor ‘B::B(B&) [with long
unsigned int N = 0ul; T = C; U = {D, int, int}]’:
pr69851.C:8:3: internal compiler error: in store_field, at expr.c:6637
B (B &) = default;
^
0xbc7f2a store_field
../../gcc/expr.c:6637
0xbc1947 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5017
and in r232167 that changed to the current
pr69851.C: In copy constructor ‘B::B(B&) [with long
unsigned int N = 0ul; T = C; U = {D, int, int}]’:
pr69851.C:8:3: internal compiler error: in assign_temp, at function.c:961
B (B &) = default;
^
0xc80dc7 assign_temp(tree_node*, int, int)
../../gcc/function.c:961
0xc263d2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10411
0xc1bc42 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/expr.c:7946
0xc03c84 expand_normal
../../gcc/expr.h:262
0xc17a0c store_field
../../gcc/expr.c:6678
0xc4 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5020
In any case, this is on the
this_2(D)->D.2344 = _5(D)->D.2344;
assignment where both the lhs and rhs are TREE_ADDRESSABLE typed fields 5 bytes
long (i.e. without padding), while the actual type is 8 bytes long (with
padding).
Do we want a memcpy/memmove like assignment in this case, something else?
As the assignment is without padding, during expansion we chose to
store_bit_field it, but that means the rhs is evaluated using expand_normal,
i.e. with NULL target, and that wants to create a temporary, because the type
of the COMPONENT_REF is the type including padding, but the FIELD_DECL without
padding.
[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #3 from Dominik Vogt --- Building the source Rpm you sent us (to build the Ada compiler) has the same problem with profiledbootstrap, building on Fedora 20 (maybe other distros too). I'll try to isolate the problem.
[Bug rtl-optimization/69609] block reordering consumes an inordinate amount of time, REE consumes much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609
--- Comment #8 from Richard Biener ---
Created attachment 37718
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37718&action=edit
patch
The attached patch implements a simple caching mechanism which reduces time
(checking enabled but with -fno-checking) from
reorder blocks : 260.53 (80%) usr 0.37 (27%) sys 261.80 (80%) wall
432597 kB (58%) ggc
TOTAL : 323.98 1.38 328.14
745950 kB
to
reorder blocks : 135.46 (71%) usr 0.12 ( 9%) sys 135.70 (71%) wall
432597 kB (58%) ggc
TOTAL : 190.60 1.29 192.10
745950 kB
I'm going to see whether bb_to_key is still the issue (the resetting of cached
key could be made smarter, updating the value from the edge that changed).
Still the above is a reasonable improvement given we have
FOR_EACH_EDGE (e, ei, bb->succs)
{
if (e == best_edge
|| e->dest == EXIT_BLOCK_PTR_FOR_FN (cfun)
|| bb_visited_trace (e->dest))
continue;
key = bb_to_key (e->dest);
where bb_to_key does FOR_EACH_EDGE (e, ei, bb->preds).
Yup. Even with the patch bb_to_key is still taking 67% of the compile time
(according to perf).
[Bug rtl-optimization/69609] block reordering consumes an inordinate amount of time, REE consumes much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609 --- Comment #9 from Richard Biener --- Created attachment 37719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37719&action=edit updated patch Ok, this implements max frequency caching. reorder blocks : 1.03 ( 2%) usr 0.08 ( 7%) sys 1.08 ( 2%) wall 432597 kB (58%) ggc TOTAL : 55.67 1.1956.99 745934 kB hah.
[Bug rtl-optimization/69609] block reordering consumes an inordinate amount of time, REE consumes much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609 Richard Biener changed: What|Removed |Added CC||stevenb.gcc at gmail dot com --- Comment #10 from Richard Biener --- Top offender is now df live&initialized regs: 12.06 (21%) usr 0.00 ( 0%) sys 12.10 (21%) wall 0 kB ( 0%) ggc PRE : 15.53 (27%) usr 0.29 (26%) sys 15.83 (27%) wall 793 kB ( 0%) ggc with perf reporting 11.95% cc1 cc1[.] df_live_bb_local_compute(unsigned int) 6.69% cc1 cc1[.] compute_transp(rtx_def const*, int, simple_ 4.44% cc1 cc1[.] df_worklist_dataflow(dataflow*, bitmap_head 3.10% cc1 cc1[.] df_simulate_one_insn_forwards(basic_block_d 2.99% cc1 cc1[.] bitmap_set_bit(bitmap_head*, int) I suspect the DF part is PRE as well. PRE already has some limiting on CFG complexity that appearantly doesn't trigger here. See gcse_or_cprop_is_too_expensive. OTOH we still call df_analyze before checking that (oops?!).
[Bug tree-optimization/69353] [6 Regression] [graphite] ICE: verify_gimple failed (error: non-trivial conversion at assignment) w/ -O2 (-O3) -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69353
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-02-17
CC||ktkachov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on aarch64 as well.
I've seen the same ICE with a different testcase at -O3 -floop-interchange
int a, b, c, e;
short d;
void
fn1 ()
{
for (; b; b++)
{
char f = c = 2;
for (; c <= 6; c++)
++f;
if ((2 && a) >= f)
;
else
{
short *g = &d;
*g = e = 0;
}
}
}
mycrash.c: In function 'fn1':
mycrash.c:4:1: error: incompatible types in PHI argument 1
fn1 ()
^~~
short int
int
d_lsm.10_23 = PHI
mycrash.c:4:1: error: incompatible types in PHI argument 0
short int
int
d_lsm.10_54 = PHI
mycrash.c:4:1: error: non-trivial conversion at assignment
int
short int
# .MEM_51 = VDEF <.MEM_50>
e = d_lsm.10_54;
mycrash.c:4:1: internal compiler error: verify_gimple failed
0xb52ad6 verify_gimple_in_cfg(function*, bool)
$TOP/gcc/tree-cfg.c:5125
0xa45cba execute_function_todo
$TOP/gcc/passes.c:1958
0xa45ec5 do_per_function
$TOP/gcc/passes.c:1645
0xa4600d execute_todo
$TOP/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 --- Comment #20 from Richard Biener --- Given the relevance of AVX512 for the GCC 6 lifetime I'd rather not revert the CSE change and penaltize ARM. If we can come up with a good fix for the x86 backend now or in GCC 7 time we can backport that to GCC 6 later as well. So ... XFAIL?
[Bug target/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69331 Maxim Kuvyrkov changed: What|Removed |Added Target|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu ||aarch64-linux-gnu ||arm-linux-gnueabihf CC||clyon at gcc dot gnu.org, ||mkuvyrkov at gcc dot gnu.org --- Comment #3 from Maxim Kuvyrkov --- I'm also seeing this testcase (20_util/shared_ptr/thread/default_weaktoshared.cc) failing on arm-linux-gnueabihf with 50% chance. I have, so far, not seen this testcase fail on arm-linux-gnueabi (soft-float vs hard-float target). I've also seen and a similar testcase (tr1/2_general_utilities/shared_ptr/thread/default_weaktoshared.cc) fail intermittently on aarch64-linux-gnu (again, hard-float target) with the same diagnostic: *** Error in `/tmp/default_weaktoshared.exe.7512': double free or corruption (fasttop): 0x26628a50 ***
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 --- Comment #21 from Kirill Yukhin --- I am going to fix the issue in v7 for sure. But from current point of view this is going to be great pattern refactoring and hence patch will be thousands of lines. If this might be ported - I can put an XFAIL on the tests
[Bug bootstrap/69757] OpenBSD requires -fPIC to build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69757 --- Comment #7 from Edd Barrett --- Just to follow this up. I did manage to get GCC bootstrapped by taking a subset of Pascal Stumpf's patches from OpenBSD ports. Effectively these patches enable PIE and PIC by default on OpenBSD, which seems to be required on amd64 at least. I'm not 100% certain why OpenBSD requires this, but I'm guessing that some code outside of gcc (a static library perhaps) that was compiled with PIE is always included when C compiling programs, thus forcing the requirement of PIE(?). I'm attaching the patches I distilled out of Pascal's patch set. I wonder if it would be a good idea to add a configure flag --enable-always-pie (or some such), which builds a GCC which always emits PIE executables? Cheers
[Bug bootstrap/69757] OpenBSD requires -fPIC to build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69757 --- Comment #8 from Edd Barrett --- Created attachment 37720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37720&action=edit Patches used to bootstrap GCC on OpenBSD/amd64.
[Bug ipa/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #35 from Richard Biener --- So ... too late for GCC 6 I guess.
[Bug target/69833] Warning during bootstrap of --with-build-config=bootstrap-asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69833 --- Comment #7 from Martin Liška --- Created attachment 37721 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37721&action=edit Reduced test-case
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #55 from Richard Biener --- Current GCC 6 numbers: -O1 -g var-tracking dataflow : 89.37 (60%) usr 0.09 (23%) sys 89.53 (59%) wall 11542 kB ( 3%) ggc var-tracking emit : 47.70 (32%) usr 0.05 (13%) sys 47.81 (32%) wall 4546 kB ( 1%) ggc TOTAL : 150.06 0.39 150.60 441618 kB and 580MB peak memory use -O2 PRE : 11.41 (40%) usr 0.01 ( 3%) sys 11.43 (39%) wall 921 kB ( 0%) ggc integrated RA : 4.78 (17%) usr 0.09 (26%) sys 4.86 (17%) wall 14129 kB ( 4%) ggc TOTAL : 28.84 0.3429.21 375189 kB and 820MB peak memory use -O3 load CSE after reload : 30.42 (49%) usr 0.02 ( 6%) sys 30.46 (49%) wall 0 kB ( 0%) ggc TOTAL : 62.08 0.3262.47 415741 kB and 700MB peak memory use
[Bug middle-end/37448] cannot compile big function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448 --- Comment #52 from Richard Biener --- Even at -O1 the inliner degenerates (and var-tracking gives up if you enable -g) ipa inlining heuristics : 260.14 (84%) usr 0.50 (23%) sys 260.91 (84%) wall 102217 kB (10%) ggc
[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850 Richard Biener changed: What|Removed |Added Keywords||diagnostic Priority|P3 |P1 CC||jakub at gcc dot gnu.org Target Milestone|--- |6.0
[Bug objc/69844] [6 Regression] Possibly bogus error: unknown type name in ObjC code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69844 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 Summary|Possibly bogus error: |[6 Regression] Possibly |unknown type name in ObjC |bogus error: unknown type |code|name in ObjC code
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #56 from Sergei Steshenko --- "-O2 ... and 820MB peak memory use" vs "-O3 ... and 700MB peak memory use" - according to my common sense -O3 is stronger than -02 optimization, and one should expect greater memory use. So, can the above be an indication of yet another bug ? I.e. -O3 in reality does not do something it is supposed to do while -O2 does this ?
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 --- Comment #22 from Jakub Jelinek --- Created attachment 37722 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37722&action=edit gcc6-pr69671.patch Actually, on a closer look, I believe the only problem are the patterns that use a vector_move_operand "0C" inside of vec_select with only constants as the parallel's operands. Because fwprop is able to propagate constants into instructions (thus undo the CSE effect), but doesn't do anything on these, because it also simplifies them, so instead of the expected say (vec_select:V4QI (const_vector:V16QI [ (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) ]) (parallel [ (const_int 0 [0]) (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 3 [0x3]) ])) we get in there simplified: (const_vector:V4QI [ (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) ]) So, by adding extra patterns for that simplification fwprop is able to do its job even if CSE did a better job.
[Bug rtl-optimization/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 Richard Biener changed: What|Removed |Added Keywords||ra, wrong-code Component|regression |rtl-optimization Target Milestone|--- |4.9.4 Summary|[regression] Lra deletes|[4.9/5/6 Regression] Lra |EH_REGION |deletes EH_REGION --- Comment #2 from Richard Biener --- I assume regression from when s390 switched to LRA (4.9).
[Bug lto/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607 --- Comment #22 from vries at gcc dot gnu.org --- updated patch with testcase from comment 17-19: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01156.html .
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #57 from rguenther at suse dot de --- On Wed, 17 Feb 2016, sergstesh at yahoo dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 > > --- Comment #56 from Sergei Steshenko --- > "-O2 ... and 820MB peak memory use" vs "-O3 ... and 700MB peak memory use" - > according to my common sense -O3 is stronger than -02 optimization, and one > should expect greater memory use. > > So, can the above be an indication of yet another bug ? I.e. -O3 in reality > does not do something it is supposed to do while -O2 does this ? More like -O3 cleans up the code due to stronger optimization before the memory-hogging part comes in and thus that one needs less memory do to its work.
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 --- Comment #23 from rguenther at suse dot de --- On Wed, 17 Feb 2016, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 > > --- Comment #22 from Jakub Jelinek --- > Created attachment 37722 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37722&action=edit > gcc6-pr69671.patch > > Actually, on a closer look, I believe the only problem are the patterns that > use a vector_move_operand "0C" inside of vec_select with only constants as the > parallel's operands. Because fwprop is able to propagate constants into > instructions (thus undo the CSE effect), but doesn't do anything on these, > because it also simplifies them, so instead of the expected say > (vec_select:V4QI (const_vector:V16QI [ > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > ]) > (parallel [ > (const_int 0 [0]) > (const_int 1 [0x1]) > (const_int 2 [0x2]) > (const_int 3 [0x3]) > ])) > we get in there simplified: > (const_vector:V4QI [ > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > (const_int 0 [0]) > ]) > So, by adding extra patterns for that simplification fwprop is able to do its > job even if CSE did a better job. Of course then I wonder why we didn't simplify this in the first place when generating RTL and need to wait for forwprop ... But yes, sounds like the easiest way to go forward.
[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709 --- Comment #4 from Matthias Klose --- still seen today; normal bootstrap works.
[Bug c++/69852] New: std::vector out of bounds access does not crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69852
Bug ID: 69852
Summary: std::vector out of bounds access does not crash
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adtieni at gmail dot com
Target Milestone: ---
#include
#include
#include
int main() {
std::vector words(6);
std::vector words2;
std::cout << "Before assignment: size " << words.size() << " capacity " <<
words.capacity() << std::endl;
words = words2;
std::cout << "After assignment: size " << words.size() << " capacity " <<
words.capacity() << std::endl;
words[1] = "I should crash here";
std::cout << "I did not crash. Words contains:" << std::endl;
for (auto& el : words) {
std::cout << el << ' ';
}
}
Ran both
$ clang++ -v -std=c++14 -Wall -Wextra -pedantic -pthread test_vector.cpp
clang version 3.7.1 (tags/RELEASE_371/final)
$ g++ -v -std=c++14 -Wall -Wextra -pedantic -pthread test_vector.cpp
GNU C++14 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
Outputs:
Before assignment: size 6 capacity 6
After assignment: size 0 capacity 6
I did not crash. Words contains:
[Bug libstdc++/69853] New: An inheriting constructor of the class that inherited std::tuple isn't called correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69853
Bug ID: 69853
Summary: An inheriting constructor of the class that inherited
std::tuple isn't called correctly
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redboltz at gmail dot com
Target Milestone: ---
Code
#include
template
struct my_tuple : std::tuple {
// inheriting constructor
using std::tuple::tuple;
};
int main() {
std::tuple st;
my_tuple mt(st);
}
Compiler version
$ /home/kondo/local/usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/kondo/local/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/home/kondo/local/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 6.0.0 20160217 (experimental) (GCC)
Git (git://gcc.gnu.org/git/gcc.git) hash
commit 0d85ea34a029adf4c3c31edaf8a317905d852faa
Environment
$ uname -a
Linux archboltz 4.3.3-2-ARCH #1 SMP PREEMPT Wed Dec 23 20:09:18 CET 2015 x86_64
GNU/Linux
Error log
$ /home/kondo/local/usr/local/bin/g++ -std=c++11 test.cpp
test.cpp: In function ‘int main()’:
test.cpp:11:24: error: no matching function for call to
‘my_tuple::my_tuple(std::tuple&)’
my_tuple mt(st);
^
test.cpp:4:8: note: candidate: constexpr my_tuple::my_tuple()
struct my_tuple : std::tuple {
^~~~
test.cpp:4:8: note: candidate expects 0 arguments, 1 provided
test.cpp:6:33: note: candidate: template::value,
int>::_ConstructibleTuple() && std::_TC::value,
int>::_ImplicitlyConvertibleTuple()) && (1ul >= 1)), bool>::type
> constexpr my_tuple::my_tuple(const int&)
using std::tuple::tuple;
^
test.cpp:6:33: note: template argument deduction/substitution failed:
test.cpp:11:24: note: cannot convert ‘st’ (type ‘std::tuple’) to type
‘const int&’
my_tuple mt(st);
^
test.cpp:6:33: note: candidate: template::value,
int>::_ConstructibleTuple() && (! std::_TC::value, int>::_ImplicitlyConvertibleTuple())) && (1ul >= 1)),
bool>::type > constexpr my_tuple::my_tuple(const int&)
using std::tuple::tuple;
^
test.cpp:6:33: note: template argument deduction/substitution failed:
test.cpp:11:24: note: cannot convert ‘st’ (type ‘std::tuple’) to type
‘const int&’
my_tuple mt(st);
^
test.cpp:6:33: note: candidate: template::_MoveConstructibleTuple<_UElements ...>() && std::_TC<(1ul == sizeof...
(_UElements)), int>::_ImplicitlyMoveConvertibleTuple<_UElements ...>()) && (1ul
>= 1)), bool>::type > constexpr
my_tuple::my_tuple(_UElements&& ...)
using std::tuple::tuple;
^
test.cpp:6:33: note: template argument deduction/substitution failed:
In file included from test.cpp:1:0:
/home/kondo/local/usr/local/include/c++/6.0.0/tuple:619:21: error: no type
named ‘type’ in ‘struct std::enable_if’
bool>::type=true>
^~~~
/home/kondo/local/usr/local/include/c++/6.0.0/tuple:619:21: note: invalid
template non-type parameter
test.cpp:6:33: note: candidate: template::_MoveConstructibleTuple<_UElements ...>() && (! std::_TC<(1ul ==
sizeof... (_UElements)), int>::_ImplicitlyMoveConvertibleTuple<_UElements
...>())) && (1ul >= 1)), bool>::type > constexpr
my_tuple::my_tuple(_UElements&& ...)
using std::tuple::tuple;
^
test.cpp:6:33: note: template argument deduction/substitution failed:
In file included from test.cpp:1:0:
/home/kondo/local/usr/local/include/c++/6.0.0/tuple:629:21: error: no type
named ‘type’ in ‘struct std::enable_if’
bool>::type=false>
^
/home/kondo/local/usr/local/include/c++/6.0.0/tuple:629:21: note: invalid
template non-type parameter
test.cpp:6:33: note: candidate: template::_ConstructibleTuple<_UElements ...>() && std::_TC<(1ul == sizeof...
(_UElements)), int>::_ImplicitlyConvertibleTuple<_UElements ...>()) &&
std::_TC<(std::is_same<_Dummy, void>::value && (1ul == 1)),
int>::_NonNestedTuple&>()), bool>::type
> constexpr my_tuple::my_tuple(const std::tuple<_Elements ...>&)
using std::tuple::tuple;
^
test.cpp:6:33: note: template argument deduction/substitution failed:
In file included from test.cpp:1:0:
/home/kondo/local/usr/local/include/c++/6.0.0/tuple:650:21: error: no type
named ‘type’ in ‘struct st
[Bug rtl-optimization/69752] Reload removing instruction with side-effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69752 --- Comment #5 from Bernd Schmidt --- Author: bernds Date: Wed Feb 17 13:03:44 2016 New Revision: 233491 URL: https://gcc.gnu.org/viewcvs?rev=233491&root=gcc&view=rev Log: Backport PR69752 fix from mainline. PR rtl-optimization/69752 * ira.c (update_equiv_regs): When looking for more than a single SET, also take other side effects into account. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ira.c
[Bug c/69522] [4.9/5 Regression] gcc hangs on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69522 --- Comment #11 from Bernd Schmidt --- Author: bernds Date: Wed Feb 17 13:10:59 2016 New Revision: 233492 URL: https://gcc.gnu.org/viewcvs?rev=233492&root=gcc&view=rev Log: Backport use-after-free fix for PR69522. c/ PR c/69522 * c-parser.c (c_parser_braced_init): New arg outer_obstack. All callers changed. If nested_p is true, use it to call finish_implicit_inits. * c-tree.h (finish_implicit_inits): Declare. * c-typeck.c (finish_implicit_inits): New function. Move code from ... (push_init_level): ... here. (set_designator, process_init_element): Call finish_implicit_inits. testsuite/ PR c/69522 gcc.dg/pr69522.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr69522.c Modified: branches/gcc-5-branch/gcc/c/ChangeLog branches/gcc-5-branch/gcc/c/c-parser.c branches/gcc-5-branch/gcc/c/c-tree.h branches/gcc-5-branch/gcc/c/c-typeck.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-17 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 37723 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37723&action=edit gcc6-pr69850.patch Untested fix. Another possibility is to STRIP_NOPS and if it is this, set ifexp to integer_one_node. But we need the TREE_NO_WARNING stuff anyway, because e.g. in function with nonnull parameter other than this, that at some point is changed, the comparison would be still desirable and valid.
[Bug c/69522] [4.9/5 Regression] gcc hangs on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69522 --- Comment #12 from Bernd Schmidt --- Author: bernds Date: Wed Feb 17 13:13:08 2016 New Revision: 233493 URL: https://gcc.gnu.org/viewcvs?rev=233493&root=gcc&view=rev Log: Backport PR69522 use-after-free fix. c/ PR c/69522 * c-parser.c (c_parser_braced_init): New arg outer_obstack. All callers changed. If nested_p is true, use it to call finish_implicit_inits. * c-tree.h (finish_implicit_inits): Declare. * c-typeck.c (finish_implicit_inits): New function. Move code from ... (push_init_level): ... here. (set_designator, process_init_element): Call finish_implicit_inits. testsuite/ PR c/69522 gcc.dg/pr69522.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr69522.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/c/c-parser.c branches/gcc-4_9-branch/gcc/c/c-tree.h branches/gcc-4_9-branch/gcc/c/c-typeck.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug c++/69826] problem with cilkplus pragma and preprocessor variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826 --- Comment #3 from collette --- I downloaded gcc-5.3.0 from the gnu ftp server. The example code compiles fine. So, this is a problem with the fedora gcc version (labelled 5.3.1).
[Bug rtl-optimization/69752] Reload removing instruction with side-effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69752 Bernd Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Bernd Schmidt --- Fixed everywhere.
[Bug target/69532] FAIL: gcc.target/arm/{vect-,}fmaxmin.c execution test on armv7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69532 --- Comment #6 from davids at gcc dot gnu.org --- Author: davids Date: Wed Feb 17 13:16:31 2016 New Revision: 233494 URL: https://gcc.gnu.org/viewcvs?rev=233494&root=gcc&view=rev Log: 2016-02-17 David Sherwood gcc/testsuite: PR target/69532 * gcc.target/arm/fmaxmin.c: Change effective target to arm_v8_neon_hw. * gcc.target/arm/vect-fmaxmin.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/fmaxmin.c trunk/gcc/testsuite/gcc.target/arm/vect-fmaxmin.c
[Bug c/69522] [4.9/5 Regression] gcc hangs on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69522 Bernd Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Bernd Schmidt --- Fixed everywhere.
[Bug target/69532] FAIL: gcc.target/arm/{vect-,}fmaxmin.c execution test on armv7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69532 davids at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from davids at gcc dot gnu.org --- Fixed tests to use *_hw instead of *_ok.
[Bug c++/69826] problem with cilkplus pragma and preprocessor variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826 --- Comment #4 from collette --- The following bug has been filled on fedora bugtracker: https://bugzilla.redhat.com/show_bug.cgi?id=1309321 This kind of code is used in the cbc solver (version 2.9.7 - with aboca level 4 enable) from the coin-or project: http://www.coin-or.org/download/source/Cbc/Cbc-2.9.7.tgz
[Bug regression/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 Dominik Vogt changed: What|Removed |Added Component|rtl-optimization|regression --- Comment #3 from Dominik Vogt --- Bisecting fails to identify the exacty commit. It's broken in this commit, and the commits before fail to build Ada executalbes because they don't find the Ada library. It probably does not matter; the problem is present since at least 21st of February, 2013. PR bootstrap/56258 * doc/invoke.texi (-fdump-rtl-pro_and_epilogue): Use @item instead of @itemx. * gnat-style.texi (@title): Remove @hfill. * projects.texi: Avoid line wrapping inside of @pxref or @xref. * doc/cp-tools.texinfo (Virtual Machine Options): Use just one @gccoptlist instead of 3 separate ones. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@196196 138bc75d-0d04-0410-96
[Bug rtl-optimization/56069] [4.9/5/6 Regression] RA pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #12 from Bernd Schmidt --- Looking at this.
[Bug target/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69161 --- Comment #23 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Wed Feb 17 13:39:30 2016 New Revision: 233495 URL: https://gcc.gnu.org/viewcvs?rev=233495&root=gcc&view=rev Log: [ARM] PR target/69161: Don't ignore mode when matching comparison operator in cstore-like patterns PR target/69161 * config/arm/predicates.md (arm_comparison_operator_mode): New predicate. * config/arm/arm.md (*mov_scc): Use arm_comparison_operator_mode instead of arm_comparison_operator. (*mov_negscc): Likewise. (*mov_notscc): Likewise. * config/arm/thumb2.md (*thumb2_mov_scc): Likewise. (*thumb2_mov_negscc): Likewise. (*thumb2_mov_negscc_strict_it): Likewise. (*thumb2_mov_notscc): Likewise. (*thumb2_mov_notscc_strict_it): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/config/arm/predicates.md trunk/gcc/config/arm/thumb2.md
[Bug target/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69161 --- Comment #24 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Wed Feb 17 13:42:35 2016 New Revision: 233496 URL: https://gcc.gnu.org/viewcvs?rev=233496&root=gcc&view=rev Log: [AArch64] PR target/69161: Don't use special predicate for CCmode comparisons in expressions that require matching modes PR target/69161 * config/aarch64/predicates.md (aarch64_comparison_operator_mode): New predicate. (aarch64_comparison_operator): Break overly long line into two. (aarch64_comparison_operation): Likewise. * config/aarch64/aarch64.md (cstorecc4): Use aarch64_comparison_operator_mode instead of aarch64_comparison_operator. (cstore4): Likewise. (aarch64_cstore): Likewise. (*cstoresi_insn_uxtw): Likewise. (cstore_neg): Likewise. (*cstoresi_neg_uxtw): Likewise. * gcc.c-torture/compile/pr69161.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr69161.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md trunk/gcc/config/aarch64/predicates.md trunk/gcc/testsuite/ChangeLog
[Bug target/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69161 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #25 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/69852] std::vector out of bounds access does not crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69852
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jonathan Wakely ---
Your program has undefined behaviour, so you are wrong to expect it to crash,
anything can happen. Please read http://c-faq.com/ansi/experiment.html
If you want the error to be noticed then compile with -D_GLIBCXX_DEBUG to
enable additional checking, which produces:
Before assignment: size 6 capacity 6
After assignment: size 0 capacity 6
/home/jwakely/gcc/6/include/c++/6.0.0/debug/vector:415:
Error: attempt to subscript container with out-of-bounds index 1, but
container only holds 0 elements.
Objects involved in the operation:
sequence "this" @ 0x0x7ffed6157160 {
type = std::__debug::vector, std::allocator >,
std::allocator,
std::allocator > > >;
}
Aborted (core dumped)
[Bug libstdc++/69853] An inheriting constructor of the class that inherited std::tuple isn't called correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69853 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-17 CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Ville Voutilainen --- I'll see what I can do.
[Bug c++/69826] problem with cilkplus pragma and preprocessor variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- This compiles just fine, unless -save-temps is used. Therefore, do you have say ccache installed? Just get rid of it... Fixing the preprocessing for #define CILK_FOR_GRAINSIZE 128 #pragma cilk grainsize =CILK_FOR_GRAINSIZE is very easy, but if there is no whitespace between grainsize (which is not supposed to be macro expanded) and =, then it is still not expanded.
[Bug target/65313] Compilation error in lto profiledbootstrap on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313 --- Comment #5 from Bill Schmidt --- What's the status here? Did Jakub's patch fix the underlying problem, or does this still need investigation?
[Bug c++/69826] problem with cilkplus pragma and preprocessor variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826 --- Comment #6 from collette --- Yes, I use ccache. Thanks for the highlight ...
[Bug rtl-optimization/69609] block reordering consumes an inordinate amount of time, REE consumes much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609 --- Comment #11 from Jeffrey A. Law --- The PRE/GCSE limits were changed between gcc-5 and gcc-6 to allow it to run on larger CFGs such as this, but without totally blowing up. So I don't consider the PRE/GCSE bump a regression, a conscious decision to try harder to optimize functions with these painful CFGs.
[Bug c++/69826] problem with cilkplus pragma and preprocessor variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-17 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Jakub Jelinek --- Created attachment 37724 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37724&action=edit gcc6-pr69826.patch I've mislooked, even that case works fine now.
[Bug target/65313] Compilation error in lto profiledbootstrap on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- My patch just avoids the #c2 warning false positive by reorganizing the code a little bit, nothing else.
[Bug middle-end/49899] ICE when redeclaring a static function as weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49899 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #2 from Nick Clifton --- I have proposed the patch on the gcc-patches list: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01180.html
[Bug middle-end/69854] New: [6 regression] ICE: tree check: expected class 'constant', have 'binary' (plus_expr) in generic_simplify_65, at generic-match.c:3110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69854 Bug ID: 69854 Summary: [6 regression] ICE: tree check: expected class 'constant', have 'binary' (plus_expr) in generic_simplify_65, at generic-match.c:3110 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- Created attachment 37725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37725&action=edit test case gcc -frounding-math -Ofast -c t.c t.c: In function 'acos': t.c:62:1: internal compiler error: tree check: expected class 'constant', have 'binary' (plus_expr) in generic_simplify_65, at generic-match.c:3110 } ^ 0xda99d7 tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) S/gcc/tree.c:9688 0x5b706c tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) S/gcc/tree.h:3129 0x5b706c generic_simplify_65 B/gcc/generic-match.c:3110 0xf20cf5 generic_simplify_PLUS_EXPR B/gcc/generic-match.c:9662 0xf4213d generic_simplify(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) B/gcc/generic-match.c:25902 0x84b7be fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) S/gcc/fold-const.c:9235 0x856eaa fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) S/gcc/fold-const.c:12451 0xd3a29f find_tail_calls S/gcc/tree-tailcall.c:561 0xd39bff find_tail_calls S/gcc/tree-tailcall.c:442 0xd3ae51 tree_optimize_tail_calls_1 S/gcc/tree-tailcall.c:982 Please submit a full bug report, with preprocessed source if appropriate. gcc version 6.0.0 20160217 (experimental) (GCC) i can reproduce it on arm, aarch64 and x86_64 with the attached test case. (found while building acos.c in musl libc with CFLAGS+=-Ofast, the test case is preprocessed and somewhat cleaned up, it's target independent)
[Bug c++/69855] New: Missing diagnostic for overload that only differs by return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855
Bug ID: 69855
Summary: Missing diagnostic for overload that only differs by
return type
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
The following code intended to create a local mutex but instead declared a
function:
#include
std::mutex& get();
void f()
{
std::lock_guard(get());
// oops! mutex not locked
}
But this should be invalid, because get() is already declared in the enclosing
scope and the return type is not the same. By failing to diagnose this error we
allow the code above to compile and run without locking the mutex.
Reduced:
struct mutex { };
mutex& get();
struct guard {
guard(mutex&) { }
};
void f()
{
guard(get());
}
Clang says:
ww.cc:12:9: error: functions that differ only in their return type cannot be
overloaded
guard(get());
^
ww.cc:4:8: note: previous declaration is here
mutex& get();
~~ ^
1 error generated.
EDG says:
"ww.cc", line 12: error: declaration is incompatible with previous "get"
(declared at line 4)
guard(get());
^
1 error detected in the compilation of "ww.cc".
[Bug middle-end/69854] [6 regression] ICE: tree check: expected class 'constant', have 'binary' (plus_expr) in generic_simplify_65, at generic-match.c:3110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69854 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-17 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed, mine.
[Bug middle-end/69854] [6 regression] ICE: tree check: expected class 'constant', have 'binary' (plus_expr) in generic_simplify_65, at generic-match.c:3110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69854
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed as well.
Reduced testcase at -frounding-math -Ofast on aarch64
double fn1() {
double w, s = fn1() - 6.12323399573676603587e17;
return 1.57079632679489655800e00 - (s + w);
}
[Bug c++/69855] Missing diagnostic for overload that only differs by return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-02-17
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Without the redundant parentheses we get another common mistake, trying to call
a default constructor for a local variable, but declaring a function:
struct mutex { };
mutex& get();
struct guard {
guard(mutex&) { }
};
void f()
{
guard get();
}
This is semantically identical to the previous version, but is also accepted
silently by G++.
Clang not only diagnoses the error, but has a fixit hint in case the intention
was to declare a local variable (which is useful for when the function
declaration doesn't conflict with an earlier one):
ww.cc:12:12: warning: empty parentheses interpreted as a function declaration
[-Wvexing-parse]
guard get();
^~
ww.cc:12:12: note: remove parentheses to declare a variable
guard get();
^~
ww.cc:12:9: error: functions that differ only in their return type cannot be
overloaded
guard get();
~ ^
ww.cc:4:8: note: previous declaration is here
mutex& get();
~~ ^
1 warning and 1 error generated.
[Bug tree-optimization/69776] [4.9/5 Regression] Wrong optimization with aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69776 --- Comment #11 from Richard Biener --- Now hopefully fixed on trunk.
[Bug testsuite/69586] [6 Regression] FAIL: gcc.dg/uninit-21.c for target defaulting to short enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Feb 17 14:51:27 2016 New Revision: 233497 URL: https://gcc.gnu.org/viewcvs?rev=233497&root=gcc&view=rev Log: 2016-02-17 Richard Biener PR testsuite/69586 * gcc.dg/uninit-21.c: Add -fno-short-enums. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/uninit-21.c
[Bug c++/69363] ICE when doing a pragma simd reduction with max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69363 iverbin at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #5 from iverbin at gcc dot gnu.org --- Waiting for stage1: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01183.html
[Bug libfortran/69856] New: libgfortran/intrinsics/ctime.c:59: order of evaluation problem ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69856 Bug ID: 69856 Summary: libgfortran/intrinsics/ctime.c:59: order of evaluation problem ? Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- trunk/libgfortran/intrinsics/ctime.c:59]: (error) Expression '__builtin_classify_type(localtime_r(&timev,
[Bug c++/55203] No unused warning for variables of non-trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #10 from Jonathan Wakely --- Doc patch posted to https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01184.html
[Bug rtl-optimization/69609] block reordering consumes an inordinate amount of time, REE consumes much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Known to work||6.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|6.0 |--- --- Comment #13 from Richard Biener --- Fixed on trunk. Keeping open for a backport to GCC 5.
[Bug rtl-optimization/69609] block reordering consumes an inordinate amount of time, REE consumes much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609 --- Comment #12 from Richard Biener --- Author: rguenth Date: Wed Feb 17 14:57:58 2016 New Revision: 233498 URL: https://gcc.gnu.org/viewcvs?rev=233498&root=gcc&view=rev Log: 2016-02-17 Richard Biener PR rtl-optimization/69609 * bb-reorder.c (struct bbro_basic_block_data): Add priority member. (find_traces_1_round): When ending a trace update cached priority of successors. (bb_to_key): Use cached priority when available. (copy_bb): Initialize cached priority. (reorder_basic_blocks_software_trace_cache): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/bb-reorder.c
[Bug target/65313] Compilation error in lto profiledbootstrap on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313 --- Comment #7 from Bill Schmidt --- OK, thanks. We'll get somebody looking at this, then.
[Bug target/65313] Compilation error in lto profiledbootstrap on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Markus Trippelsdorf --- I think this bug can be closed. Martin Liška's problem is long fixed. And Martin Sebor's issue is tracked elsewhere.
[Bug c++/69851] [6 Regression] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851 --- Comment #4 from Jakub Jelinek --- (In reply to Jason Merrill from comment #3) > (In reply to Jakub Jelinek from comment #2) > > Do we want a memcpy/memmove like assignment in this case, something else? > > memcpy, yes. Why isn't that the default for whole bytes in memory, anyway? No idea. I guess at least for GCC 6 it might be safest to just hack up expand_assignment to expand TREE_ADDRESSABLE assignment that way (just ones with weirdo sizes, which would otherwise go into store_field, or all?).
[Bug c++/69851] [6 Regression] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851 --- Comment #3 from Jason Merrill --- (In reply to Jakub Jelinek from comment #2) > Do we want a memcpy/memmove like assignment in this case, something else? memcpy, yes. Why isn't that the default for whole bytes in memory, anyway?
[Bug target/69857] New: gcc/config/arm/arm.c:15949: return in strange place ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857
Bug ID: 69857
Summary: gcc/config/arm/arm.c:15949: return in strange place ?
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
[trunk/gcc/config/arm/arm.c:15949]: (style) Statements following return, break,
continue, goto or throw will never be executed.
Source code is
else if (TARGET_ARM)
{
return false;
int regno = REGNO (operands[0]);
if (!peep2_reg_dead_p (4, operands[0]))
{
svn blame says
197530 gretay else if (TARGET_ARM)
197530 gretay {
197530 gretay return false;
197530 gretay int regno = REGNO (operands[0]);
197530 gretay if (!peep2_reg_dead_p (4, operands[0]))
197530 gretay {
[Bug middle-end/69537] [6 Regression] Incorrect -Wmaybe-uninitialized warning with enum variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69537 Bug 69537 depends on bug 69586, which changed state. Bug 69586 Summary: [6 Regression] FAIL: gcc.dg/uninit-21.c for target defaulting to short enum https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug testsuite/69586] [6 Regression] FAIL: gcc.dg/uninit-21.c for target defaulting to short enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug target/69857] gcc/config/arm/arm.c:15949: return in strange place ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||arm Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-17 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- That does look strange. Worth looking into
[Bug middle-end/69845] [4.9/5/6 Regression] Expression getting incorrectly optimized after being rewritten by compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69845 --- Comment #6 from Jakub Jelinek --- I believe the bug is in extract_muldiv_1, what it does for PLUS_EXPR/MINUS_EXPR looks inherently unsafe, unless it changes the operation to be actually performed in a type with defined overflow and then cast back.
[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69848 --- Comment #3 from alahay01 at gcc dot gnu.org --- The standard way of dealing with condition reductions like this is to ignore the contents of the "if" statement and produce a lot of code to deal with the general case (it creates two vectors - one full of indexes and one full of results). In the code, this is where STMT_VINFO_VEC_REDUCTION_TYPE is set to COND_REDUCTION in tree-vect-loop.c. We have an optimisation of this for when the code is "if (a[b]) c=b" which bypasses most of the code produced by the general case. In the code, this is where STMT_VINFO_VEC_REDUCTION_TYPE is set to INTEGER_INDUC_COND_REDUCTION tree-vect-loop.c. I haven't figured out what the generated asm should look like for this issue, but I think we'll need a further vect_reduction_type case (CONST_COND_REDUCTION ??) which is checked for at the same point as INTEGER_INDUC_COND_REDUCTION (just after the "If we have a condition reduction, see if we can simplify it further." comment).
[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #39 from alalaw01 at gcc dot gnu.org --- Created attachment 37726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37726&action=edit Proposed patch (without flag). Here's a prototype patch, that sets TYPE_SIZE to NULL_TREE but leaves DECL_SIZE intact. For the moment I'm applying this universally, rather than gating under a flag, to ease testing check-fortran. Only gfortran.dg/gomp/appendix-a/a.24.1.f90 fails; in practice I think it's OK just to not use the new code in conjunction with -fopenmp. On AArch64, it fixes the 416.gamess issue, and allows compiling 416.gamess without the -fno-aggressive-loop-optimizations previously required. Also bootstraps and passes check-gcc check-fortran check-g++, on aarch64 and x86_64, except as noted above. I expect to add a Fortran-only flag to gate the trans-common.c changes before taking this to gcc-patches@ . The worry is that while many cases in the mid-end were happy with a null TYPE_SIZE, I still had to patch up a couple, so the worry is I might not have got them all. (Indeed, omp-low.c had too many!) I'm not sure this is any worse than adding a new flag to the decl (indicating that the DECL_SIZE is not to be trusted) and then trying to find all the cases where the DECL_SIZE is wrongly relied upon - with the latter approach, the compiler would generate invalid code, rather than "failing fast". Thoughts welcome!
[Bug libfortran/69651] [6 Regession] Usage of unitialized pointer io/list_read.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651 --- Comment #14 from Jerry DeLisle --- Author: jvdelisle Date: Wed Feb 17 16:48:57 2016 New Revision: 233500 URL: https://gcc.gnu.org/viewcvs?rev=233500&root=gcc&view=rev Log: 2016-02-17 Jerry DeLisle PR libgfortran/69651 * io/list_read.c (push_char4): Fix the pointer usage for xrealloc. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug libgomp/69858] New: OpenACC no free memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69858
Bug ID: 69858
Summary: OpenACC no free memory
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: oliveriandrea at gmail dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Hi,
i have compiled GCC SNAPSHOT 20160214 with nvpt-offload support.
i have tested it with this code
/***/
#include
#define N 20
#define vl 1024
int main(void) {
double pi = 0.0f;
long long i;
double t;
#pragma acc data copyout(pi)
{
#pragma acc parallel vector_length(vl)
#pragma acc loop gang worker vector reduction(+:pi) private(t)
for (i=0; i
[Bug c/28901] -Wunused-variable ignores unused const initialised variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 --- Comment #27 from Manuel López-Ibáñez --- (In reply to Mark Wielaard from comment #21) > Although in C a static const is not really like a #define I suspect that > there are cases where they are used as such in header files. If that is the > major reason for why there are people opposed to the warning then what we > could do is hide such (non-)usage of static const variables from header > files behind -Wextra and only explicitly warn for static const variable > defined (and then not used) in the main file. We should not use -Wextra in this way, because after seeing the warning, it is not apparent to the user which option controls it. (That is, the same warning option printed in the output behaves differently when -Wextra is given). My suggestion is to never warn if declared in a header. If an extra option is desired (whether enabled by -Wextra or explicitly), then it would be better to call it something like Wunused-any-const-variable, because the meaning of numeric values are not apparent (and they do not play nicely with -Werror=). Note that it is trivial to find all unused static const variables in your headers: Just preprocess the file, remove line info and compile with -Wunused. > + || filename_cmp (main_input_filename, > +DECL_SOURCE_FILE (decl)) == 0))) Better use MAIN_FILE_P(DECL_SOURCE_LOCATION (decl)) Whoever wants to see this fixed, should hurry up before GCC 6 closes.
[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- (In reply to Jakub Jelinek from comment #2) > Created attachment 37723 [details] > gcc6-pr69850.patch > > Untested fix. Another possibility is to STRIP_NOPS and if it is this, set > ifexp to integer_one_node. But we need the TREE_NO_WARNING stuff anyway, > because e.g. in function with nonnull parameter other than this, that at > some point is changed, the comparison would be still desirable and valid. Aren't compiler-generated expressions marked with ARTIFICIAL or some such? In any case, setting TREE_NO_WARNING for compiler-generated expressions seems the right thing to do. I'd suggest to add "-Wnonnul-compare" explicitly to the testcase, otherwise it may start silently failing if -Wall stops enabling the warning.
[Bug libfortran/69651] [6 Regession] Usage of unitialized pointer io/list_read.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651 --- Comment #15 from Jerry DeLisle --- Author: jvdelisle Date: Wed Feb 17 17:34:58 2016 New Revision: 233501 URL: https://gcc.gnu.org/viewcvs?rev=233501&root=gcc&view=rev Log: 2016-02-17 Jerry DeLisle PR libgfortran/69651 * io/list_read.c (push_char4): Fix the pointer usage for xrealloc. Modified: branches/gcc-5-branch/libgfortran/ChangeLog branches/gcc-5-branch/libgfortran/io/list_read.c
[Bug middle-end/17308] nonnull attribute not as useful as it could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- (In reply to Mark Wielaard from comment #11) > This part has now been implemented: > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00626.html And updated in https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01103.html
[Bug libstdc++/69853] An inheriting constructor of the class that inherited std::tuple isn't called correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69853
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|SUSPENDED
--- Comment #2 from Ville Voutilainen ---
The fix for http://cplusplus.github.io/LWG/lwg-active.html#2549 breaks
this code. But that breakage looks sane, because it prevents implicit
base-to-derived conversions that create temporaries. Consider the following
code,
which is valid on 5.x but ill-formed on 6:
#include
#include
using std::tuple;
template struct mytuple : tuple
{
using tuple::tuple;
};
void f(const mytuple& ft)
{
std::cout << "address of ft: " << (void*)(&ft) << std::endl;
}
int main()
{
tuple t;
std::cout << "address of t: " << (void*)(&t) << std::endl;
f(t);
}
I'll add this as additional motivation for LWG 2549. Suspending the bug for
now, until LWG gives guidance.
[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #40 from Jerry DeLisle --- Do you have a reduced test case of the Fortran code we can look at? I am concerned that you are changing things to accommodate invalid Fortran. I don't have 416.gamess to look at. I do see your suggested patch touches the Fortran frontend. Maybe it needs to be put behind -std=legacy? I assume the "(without flag)" means you intend to do something like that?
[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #41 from Wilco --- (In reply to Jerry DeLisle from comment #40) > Do you have a reduced test case of the Fortran code we can look at? See comment 13/14, the same common array is declared with different sizes in various places. > I am concerned that you are changing things to accommodate invalid Fortran. > I don't have 416.gamess to look at. I do see your suggested patch touches > the Fortran frontend. Since SPEC does not want to change the invalid Fortran, GCC will have to accomodate for it somehow. > Maybe it needs to be put behind -std=legacy? > > I assume the "(without flag)" means you intend to do something like that? Yes, but it was suggested that -std=legacy wasn't the right flag in comment 35...
[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499 --- Comment #3 from Gerhard Steinmetz --- Yet another example : $ cat z4.f90 module m class(*) :: z select type (x => z) end
[Bug fortran/69859] New: ICE on incomplete character declaration statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69859 Bug ID: 69859 Summary: ICE on incomplete character declaration statement Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With an incomplete declaration : $ cat z1.f90 program p type t character x y end type end $ gfortran-6 z1.f90 z1.f90:3:17: character x y 1 Error: Syntax error in data declaration at (1) f951: internal compiler error: gfc_is_constant_expr(): Unknown expression type --- Whereas, without embedding in type : $ cat z2.f90 program p character x y end $ gfortran-6 z2.f90 z2.f90:2:14: character x y 1 Error: Syntax error in data declaration at (1) # no ICE
[Bug fortran/69859] ICE on incomplete character declaration statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69859 --- Comment #1 from Gerhard Steinmetz --- Some other variants : $ cat z3.f90 program p type t character a , character b = character c : character d + character e . character f % !... end type end $ cat z5.f90 program p type t character, allocatable :: x(:) y(:) end type end $ gfortran-6 z3.f90 #... Error: Syntax error in data declaration at (1) f951: internal compiler error: gfc_is_constant_expr(): Unknown expression type
[Bug fortran/69859] ICE on incomplete character declaration statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69859 --- Comment #2 from Gerhard Steinmetz --- A bit different : $ cat z7.f90 program p type t character(2), allocatable :: a(*) character(*), allocatable :: b(2) character(*), allocatable :: c(*) end type end $ gfortran-6 z7.f90 #... Error: Allocatable component of structure at (1) must have a deferred shape f951: internal compiler error: gfc_is_constant_expr(): Unknown expression type
[Bug fortran/69860] New: ICE on missing end apostrophe with character(kind=4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69860 Bug ID: 69860 Summary: ICE on missing end apostrophe with character(kind=4) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With a missing end apostrophe : $ cat z1.f90 program p character(len=2, kind=4) :: a = 'aa', b = 'bb end $ gfortran-6 -g z1.f90 z1.f90:2:46: character(len=2, kind=4) :: a = 'aa', b = 'bb 1 Error: Unterminated character constant beginning at (1) f951: internal compiler error: gfc_is_constant_expr(): Unknown expression type For some other compile options, error message may depend on $LANG etc.
[Bug fortran/69860] ICE on missing end apostrophe with character(kind=4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69860 --- Comment #1 from Gerhard Steinmetz --- No ICE if "kind=4" is changed to "kind=1" : $ cat z2.f90 program p character(len=2, kind=1) :: a = 'aa', b = 'bb end $ gfortran-6 -g z2.f90 z2.f90:2:46: character(len=2, kind=1) :: a = 'aa', b = 'bb 1 Error: Unterminated character constant beginning at (1)
[Bug fortran/69861] New: ICE on declaring class parameter array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69861
Bug ID: 69861
Summary: ICE on declaring class parameter array
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gerhard.steinmetz.fort...@t-online.de
Target Milestone: ---
A code snippet with a parameter array :
$ cat z1.f90
program p
type t
character :: c
end type
class(t), parameter :: z(2) = t('a')
print *, z%c
end
$ gfortran-6 z1.f90
z1.f90:6:0:
print *, z%c
internal compiler error: in insert_component_ref, at fortran/class.c:86
[Bug fortran/69861] ICE on declaring class parameter array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69861
--- Comment #1 from Gerhard Steinmetz
---
Whereas, with a scalar parameter :
$ cat z2.f90
program p
type t
character :: c
end type
class(t), parameter :: z = t('a')
print *, z%c
end
$ gfortran-6 z2.f90
$ a.out
a
# no error
[Bug c++/69842] [6 Regression] Parameter deduction in polymorphic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69842 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-17 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
