[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468 --- Comment #15 from Romain Geissler --- Hi, This latest patch seems to fix the occurences I have in my own code. Thanks ;) Cheers, Romain
[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582 Martin Liška changed: What|Removed |Added Known to work||7.3.0 Target Milestone|--- |8.0 Known to fail||8.0
[Bug c++/84582] New: [8 Regression] Rejected valid C++ code since r257961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582
Bug ID: 84582
Summary: [8 Regression] Rejected valid C++ code since r257961
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
It's isolated from Firefox, hope it's a valid code:
$ cat RegExp.ii
template class a {
static const long b = 0;
static const unsigned c = (b);
};
$ g++ RegExp.ii
RegExp.ii:3:31: error: non-constant in-class initialization invalid for static
member ‘a< >::c’
static const unsigned c = (b);
^
RegExp.ii:3:31: note: (an out of class initialization is required)
[Bug preprocessor/84583] New: -fdirectives-only does not handle CRLF properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84583 Bug ID: 84583 Summary: -fdirectives-only does not handle CRLF properly Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: boris at kolpackov dot net Target Milestone: --- Created attachment 43515 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43515&action=edit reproducing source code The attached archive contains foo.c (as well as foo.p and foo.i, for reference) that if preprocessed with -fdirectives-only on Windows (for example, using the MinGW build of GCC) produces incorrect result: gcc.exe -E -fdirectives-only -o foo.p foo.c gcc.exe -E -fpreprocessed -fdirectives-only -x c foo.p >foo.i foo.c:7:16: warning: missing terminating " character foo.c:9:30: warning: missing terminating " character It appears that in the first invocation GCC replaces each LF character with the CRLF sequence thus ending up with CRCRLF sequences. Will be happy to test a patch.
[Bug target/84575] [8 regression] gcc.target/i386/pr84309.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84575 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Tue Feb 27 08:44:48 2018 New Revision: 258030 URL: https://gcc.gnu.org/viewcvs?rev=258030&root=gcc&view=rev Log: PR target/84575 * gcc.target/i386/pr84309.c: Add -mno-avx2 to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr84309.c
[Bug target/84575] [8 regression] gcc.target/i386/pr84309.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84575 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Fixed.
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #23 from Dmitry G. Dyachenko --- (In reply to Martin Liška from comment #20) ... > Isn't that > an old data file you forgot to remove? After rebuild all and re-run myproject' tests I can confirm 1) r257859 FAIL 2) r257859 + patch from c#14 PASS 3) there are NO "stamp mismatch with notes file" from c#17 Thank you, Martin!
[Bug fortran/46783] [OOP] TRANSFER with polymorphic MOLD=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46783 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING CC||vehre at gcc dot gnu.org --- Comment #3 from Dominique d'Humieres --- > Updated link > > http://mailman.j3-fortran.org/pipermail/j3/2010-December/004026.html Broken again!-( And I cannot find anything relevant in https://mailman.j3-fortran.org/doc/year/10 AFAICT the situation has not changed in F2018. What should we do with this PR?
[Bug libstdc++/84580] Equality and relational ops for containers behave differently in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84580
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-02-27
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely ---
This change would meet the standard's requirement that a != b is equivalent to
!(a == b)
--- a/libstdc++-v3/include/debug/vector
+++ b/libstdc++-v3/include/debug/vector
@@ -725,7 +725,7 @@ namespace __debug
inline bool
operator!=(const vector<_Tp, _Alloc>& __lhs,
const vector<_Tp, _Alloc>& __rhs)
-{ return __lhs._M_base() != __rhs._M_base(); }
+{ return !(__lhs == __rhs); }
template
inline bool
It would change the behaviour for this program:
#include
#include
struct foo { };
bool operator!=(std::vector const& v1, std::vector const& v2)
{ return &v1 != &v2; }
int main()
{
__gnu_debug::vector v1, v2;
assert(v1 != v2);
}
Currently the operator!= for debug vectors calls the program-defined overload
for std::vectors, but with the patch above it would call operator== for debug
vectors which calls the standard operator== for std::vectors. This is probably
OK, the program above is pathologically contrived, and meeting the standard
requirements when _GLIBCXX_DEBUG is defined is more important, so that
_GLIBCXX_DEBUG doesn't change semantics.
[Bug c++/84578] [6/7/8 Regression] ICE with flexible array member and constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84578 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.5
[Bug tree-optimization/84584] New: [8 Regression] [graphite] ICE: Segmentation fault (in dominated_by_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84584
Bug ID: 84584
Summary: [8 Regression] [graphite] ICE: Segmentation fault (in
dominated_by_p)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20180225 snapshot (r257975) ICEs when compiling the following
snippet w/ -O1 (-O2, -O3, -Ofast) -fgraphite-identity -fno-tree-loop-im:
int q3, w1;
void
bw (int b8)
{
const int sd = 2;
int mc;
for (mc = 0; mc < sd; ++mc)
{
ik:
for (w1 = 0; w1 < sd; ++w1)
++b8;
}
for (q3 = 0; q3 < sd; ++q3)
{
}
goto ik;
}
% gcc-8.0.0-alpha20180225 -O1 -fgraphite-identity -fno-tree-loop-im -c
w8fja3ap.c
during GIMPLE pass: graphite
w8fja3ap.c: In function 'bw':
w8fja3ap.c:4:1: internal compiler error: Segmentation fault
bw (int b8)
^~
0xc9d7bf crash_signal
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/toplev.c:325
0x8f73e9 dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def
const*)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/dominance.c:1118
0x1465a71 bb_in_region
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/sese.h:124
0x1465a71 bb_in_sese_p
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/sese.h:134
0x1465a71 loop_in_sese_p
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/sese.h:159
0x1465a71 add_loop_constraints
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/graphite-sese-to-poly.c:747
0x14660e5 build_iteration_domains
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/graphite-sese-to-poly.c:852
0x146667f build_poly_scop(scop*)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/graphite-sese-to-poly.c:1215
0x1457f40 graphite_transform_loops()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/graphite.c:406
0x1458470 graphite_transforms
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/graphite.c:475
0x1458470 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/graphite.c:552
[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82982 --- Comment #5 from Arseny Solokha --- (In reply to Will Schmidt from comment #4) > Tried to re-create locally, I've gotten two ICE's using the provided > testcode snippet, neither look quite like the originally reported issue. You are right. I also cannot reproduce the original issue anymore w/ r257975.
[Bug libgomp/84466] [8 regression] libgomp.graphite/force-parallel-8.c fails starting with r257723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84466
--- Comment #4 from Richard Biener ---
So the issue is
for (i = 0; i < N; i++)
{
y[i] = i;
for (j = 0; j < N; j++)
{
if (j > 500)
{
x[i][j] = i + j + 3;
y[j] = i*j + 10;
^^^
here we now verify that we can instantiate i*j + 10 at this point which
is (int) {10, +, {0, +, 1}_3}_4 and that fails the graphite_can_represent_scev
test because of
case POLYNOMIAL_CHREC:
/* Check for constant strides. With a non constant stride of
'n' we would have a value of 'iv * n'. Also check that the
initial value can represented: for example 'n * m' cannot be
represented. */
gcc_assert (loop_in_sese_p (get_loop (cfun,
CHREC_VARIABLE (scev)), scop));
if (!evolution_function_right_is_integer_cst (scev)
|| !graphite_can_represent_init (scev))
return false;
given CHREC_RIGHT is {0, +, 1}_3 and not an INTEGER_CST.
I think with graphite_can_represent_scev I used the wrong tool (it is supposed
to guard what extract_affine handles). Testing a patch.
[Bug c++/84426] [8 Regression] ICE with conflicting class member names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84426 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.0
[Bug c++/84423] [6/7/8 Regression] [concepts] ICE with invalid using declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84423 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |6.5
[Bug tree-optimization/84427] [8 Regression] gcc ICE at -O3 on x86_64-linux-gnu in compute_antic, at tree-ssa-pre.c:2356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84427 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED Version|unknown |8.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #2 from Richard Biener --- Mine.
[Bug target/70490] __atomic_load_n(const __int128 *, ...) generates CMPXCHG16B with no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70490
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
--- Comment #7 from torvald at gcc dot gnu.org ---
(In reply to Michael Poole from comment #0)
> When compiling for x86-64 with the -mcx16 flag, there is no diagnostic for
> code like this:
>
> #include
> __int128 test(void)
> {
> const void *ptr = mmap(0, 4096, PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0);
> const __int128 *p_v = (const __int128 *)ptr;
> return __atomic_load_n(p_v, __ATOMIC_SEQ_CST);
> }
>
> The CMPXCHG16B instruction that is generated unconditionally attempts to
> write to the address, which causes a fault at runtime. When
> __atomic_load_n() uses that instruction, it seems prudent to reject a const
> pointer as the first argument.
I guess we haven't spelled that out in the docs, but the thought is that one
would use the __atomic builtins like one would use C11/C++11 atomics. In that
world, only "address-free" atomic types are guaranteed to work when mapped from
another process, for example, and only lock-free types are address-free. (That
doesn't quite cover all cases, such as when making process-private read-only,
but it gives at least some idea of what's the intent.)
Users should ensure that the particular type is lock-free (or that atomic ops
on that type are) to know that it's safe to use atomic loads on read-only
memory. The most recent GCC shouldn't declare the types to be lock-free just
because cmpxchg16b is available.
It might still use it under the covers, but the fact that it's not lock-free
indicates that the implementation is not just native atomic operations as
supported by the hardware, but something different.
I guess we need to spell this out in the docs.
[Bug c++/84430] [7 Regression] ICE with #pragma omp simd in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84430 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582 --- Comment #1 from Marek Polacek --- We have (unsigned int) (long int) *(const long int &) &b and cxx_constant_value -> maybe_constant_init_1 doesn't evaluate it now: 5154 if (!is_nondependent_static_init_expression (t)) 5155 /* Don't try to evaluate it. */; and that CONVERT_EXPR isn't is_nondependent_static_init_expression.
[Bug c++/84585] New: internal compiler error: in get_local_decls, at cp/name-lookup.c:3654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84585
Bug ID: 84585
Summary: internal compiler error: in get_local_decls, at
cp/name-lookup.c:3654
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at gmail dot com
Target Milestone: ---
This (invalid) program:
template b() {[](auto = template <;{a c(auto
When compiled with:
xgcc -x c++ -std=c++14 -O3 -c -
Gives this output:
:1:25: error: ISO C++ forbids declaration of 'b' with no type
[-fpermissive]
: In function 'int b()':
:1:38: error: a template declaration cannot appear at block scope
:1:49: error: expected ')' before '{' token
: In lambda function:
:1:54: internal compiler error: in get_local_decls, at
cp/name-lookup.c:3654
0xe15de7 get_local_decls()
/home/vegard/git/gcc/gcc/cp/name-lookup.c:3653
0xe8421c synthesize_implicit_template_parm
/home/vegard/git/gcc/gcc/cp/parser.c:39013
0xf2b5cd cp_parser_simple_type_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:16966
0xf1f5ad cp_parser_type_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:16786
0xf8520a cp_parser_decl_specifier_seq
/home/vegard/git/gcc/gcc/cp/parser.c:13573
0xfb3e8d cp_parser_parameter_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:21440
0xfb67da cp_parser_parameter_declaration_list
/home/vegard/git/gcc/gcc/cp/parser.c:21252
0xfb9470 cp_parser_parameter_declaration_clause
/home/vegard/git/gcc/gcc/cp/parser.c:21173
0xf555ef cp_parser_direct_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19926
0xf9b858 cp_parser_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19800
0xf9bb2e cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19326
0xfa2a97 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13009
0xfa8c88 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12827
0xfab154 cp_parser_declaration_statement
/home/vegard/git/gcc/gcc/cp/parser.c:12420
0xef6e13 cp_parser_statement
/home/vegard/git/gcc/gcc/cp/parser.c:10869
0xefb1eb cp_parser_statement_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:11218
0xfcca31 cp_parser_lambda_body
/home/vegard/git/gcc/gcc/cp/parser.c:10632
0xfcca31 cp_parser_lambda_expression
/home/vegard/git/gcc/gcc/cp/parser.c:10137
0xf31764 cp_parser_primary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:5257
0xf7373b cp_parser_postfix_expression
/home/vegard/git/gcc/gcc/cp/parser.c:7026
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-27 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582
--- Comment #2 from Jakub Jelinek ---
Given:
class C {
static const long b = 0;
static const unsigned c = (b);
};
class D {
static const long b = 0;
static const unsigned c = b;
};
template class A {
static const long b = 0;
static const unsigned c = (b);
};
template class B {
static const long b = 0;
static const unsigned c = b;
};
we only reject the A case.
For D and B there is just INTEGER_CST, and for C and A we have:
(unsigned int) (long int) *(const long int &) &b
because of the parens.
The reason why it is accepted outside of template and not inside of it is that
cxx_constant_init calls is_nondependent_static_init_expression which calls
instantiation_dependent_expression_p and that is true in A::c.
[Bug libfortran/84439] call to backtrace fails after about 6000 iterations (32-bit executable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84439
Richard Biener changed:
What|Removed |Added
CC||iant at google dot com
Version|4.8.5 |7.3.1
--- Comment #2 from Richard Biener ---
Confirmed. With glibc 2.22 I get into
9 calls to backtrace()
Could not print backtrace: mmap: Cannot allocate memory
#0 0x7f7a4717268a
#1 0x4008c8
#2 0x40082f
#3 0x400814
#4 0x4007f9
#5 0x4007de
#6 0x400907
#7 0x40094a
#8 0x7f7a466816d4
#9 0x400718
#10 0x
* calls to backtrace()
Could not print backtrace: mmap: Cannot allocate memory
#0 0x7f7a4717268a
#1 0x4008c8
#2 0x40082f
#3 0x400814
#4 0x4007f9
#5 0x4007de
#6 0x400907
#7 0x40094a
#8 0x7f7a466816d4
#9 0x400718
#10 0x
while with glibc 2.26 I get
...
Could not print backtrace: mmap: Cannot allocate memory
#0 0x7f928d0a750a
#1 0x4008a8
#2 0x40080f
#3 0x4007f4
#4 0x4007d9
#5 0x4007be
#6 0x4008e4
#7 0x400927
#8 0x7f928c54ff49
#9 0x4006f9
#10 0x
4857 calls to backtrace()
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
I think the issue lies within libgfortran show_backtrace which does
lbstate = backtrace_create_state (NULL, __gthread_active_p (),
error_callback, NULL);
for each call to backtrace (). There doesn't seem to be a corresponding
backtrace_free_state API so we leak whatever is allocated here. Ian?
I suppose a workaround would be to make lbstate static and only initialize
it if NULL.
Index: libgfortran/runtime/backtrace.c
===
--- libgfortran/runtime/backtrace.c (revision 258030)
+++ libgfortran/runtime/backtrace.c (working copy)
@@ -135,11 +135,12 @@ full_callback (void *data, uintptr_t pc,
void
show_backtrace (bool in_signal_handler)
{
- struct backtrace_state *lbstate;
+ static struct backtrace_state *lbstate;
struct mystate state = { 0, false, in_signal_handler };
- lbstate = backtrace_create_state (NULL, __gthread_active_p (),
- error_callback, NULL);
+ if (!lbstate)
+lbstate = backtrace_create_state (NULL, __gthread_active_p (),
+ error_callback, NULL);
if (lbstate == NULL)
return;
note the above is wrong when the __gthread_active_p () state changes.
Ian, I suppose there should be an API to deallocate the state?
[Bug libfortran/84439] call to backtrace fails after about 6000 iterations (32-bit executable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84439 Richard Biener changed: What|Removed |Added Status|WAITING |NEW
[Bug driver/84440] unrecognized command line option '-Wno-format-invalid-specifier'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84440 Richard Biener changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Richard Biener --- gcc tells you when warning which switch you can use to disable the diagnostics. There's a whole family of -Wformat-* options.
[Bug c/84563] GCC interpretation of C11 atomics (DR 459)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563 torvald at gcc dot gnu.org changed: What|Removed |Added CC||torvald at gcc dot gnu.org --- Comment #3 from torvald at gcc dot gnu.org --- This is not a bug, see https://gcc.gnu.org/ml/gcc/2018-02/msg00224.html for further discussion.
[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582 --- Comment #3 from Marek Polacek --- It looks like we shouldn't skip the evaluation when ALLOW_NON_CONSTANT is false, similarly to the CONSTANT_CLASS_P case: @@ -5137,10 +5147,10 @@ maybe_constant_init_1 (tree t, tree decl, bool allow_non_constant) t = TREE_OPERAND (t, 1); if (TREE_CODE (t) == TARGET_EXPR) t = TARGET_EXPR_INITIAL (t); - if (!is_nondependent_static_init_expression (t)) + if (allow_non_constant + && (!is_nondependent_static_init_expression (t) + || CONSTANT_CLASS_P (t))) /* Don't try to evaluate it. */; - else if (CONSTANT_CLASS_P (t) && allow_non_constant) -/* No evaluation needed. */; else t = cxx_eval_outermost_constant_expr (t, allow_non_constant, false, decl); if (TREE_CODE (t) == TARGET_EXPR)
[Bug middle-end/84443] powerpc suboptimal code generation (shrink wrap unlikely path) for Linux spinlocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84443
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target||powerpc
Component|tree-optimization |middle-end
--- Comment #1 from Richard Biener ---
Note that volatiles are not optimized and thus by having
typedef struct {
volatile unsigned int slock;
} arch_spinlock_t;
you might pessimize things. The code looks heavily dependent on inline asms
and
inlining so it's a bit hard to analyze as well.
[Bug debug/84456] [8 regression] gcc.dg/guality/pr49888.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84456 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/84470] test for address of member being null not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84470
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-02-27
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
Hmm, is p->a valid to compute if p is NULL? Is it valid to compute p->b if p
is NULL for
struct A { char a[4]; char b[4]; };
?
Because you say "could" in
if (p->a == 0) // could only be true when p is null
__builtin_abort (); // can be eliminated
which implies it would invoke undefined behavior?
ISTR we still want to not break old offsetof implementations using &(T
*)0->member
style computation?
But yes, wrapping rules say that &p->m is never NULL if m is not a member
at offset zero. See tree_single_nonzero_warnv_p for ADDR_EXPR handling.
[Bug c++/84471] Instruction reordering happens in lambdas even with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84471 --- Comment #2 from Richard Biener --- Which means either locations the FE assigns to trees are off or the gimplifier produces stmts with such locations.
[Bug c++/84585] [6/7/8 Regression] internal compiler error: in get_local_decls, at cp/name-lookup.c:3654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84585
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Keywords||error-recovery
Last reconfirmed||2018-02-27
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
Summary|internal compiler error: in |[6/7/8 Regression] internal
|get_local_decls, at |compiler error: in
|cp/name-lookup.c:3654 |get_local_decls, at
||cp/name-lookup.c:3654
Target Milestone|--- |6.5
--- Comment #1 from Jakub Jelinek ---
Started to ICE with r208624.
Slightly tweaked testcase:
template void b() {[](auto = template <;{a c(auto){}}}
[Bug driver/84440] unrecognized command line option '-Wno-format-invalid-specifier'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84440 --- Comment #2 from Stas Sergeev --- (In reply to Richard Biener from comment #1) > gcc tells you when warning which switch you can use to disable the > diagnostics. --- warning: unknown conversion type character 'P' in format [-Wformat=] --- This [-Wformat=] doesn't give me any clue. What does this mean? > There's a whole family of -Wformat-* options. But I can't find -Wno-format-unknown-specifier, am I missing something?
[Bug c++/84576] [6/7/8 Regression] g++: internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84576 Jakub Jelinek changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4 CC||jakub at gcc dot gnu.org Target Milestone|--- |6.5 Summary|g++: internal compiler |[6/7/8 Regression] g++: |error: Segmentation fault |internal compiler error: |(program cc1plus) |Segmentation fault (program ||cc1plus) --- Comment #2 from Jakub Jelinek --- Started to ICE in between r152207 and r152360, seems endless recursion in dump_* while trying to print some diagnostics.
[Bug c++/84576] [6/7/8 Regression] g++: internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84576 --- Comment #3 from Jakub Jelinek --- BTW, when using creduce, if the original is valid or has just one error or something similar, please try to write the script such that it will not confirm a reduction which has also other errors, otherwise you end up with testcases like this which have just too many errors in it.
[Bug target/84482] 437.leslie3d regresses on Haswell and SandyBridge at -O3 and -Ofast with generic march and tuning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84482 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Would be interesting to see differences in -fopt-info-vec between those two revisions given it looks vectorizer cost model related?
[Bug tree-optimization/84485] [6/7 Regression] Vectorising zero-stride rmw operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84485 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-27 Target Milestone|--- |6.5 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- But that rev. should have a fix that made us consider using runtime alias check at all? That part could be backported and this loop not vectorized.
[Bug fortran/84538] [8 Regression] Array of derived type elements incorrectly accessed in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84538 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- This changed behavior with r251949.
[Bug c++/84586] New: Incorrect acess checking with inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84586
Bug ID: 84586
Summary: Incorrect acess checking with inheritance
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dllmain at yandex dot ru
Target Milestone: ---
Created attachment 43516
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43516&action=edit
preprocessed source(in version which cause error)
Consider the code:
#include
#ifdef USING_SIMPLE_BASE
#define BASE base
#else
#ifdef USING_DIFFERENT_NAME
#define NAME type_
#else
#define NAME type
#endif
#define BASE tuple_element_t<0,std::tuple>>
#endif
//Simple trait for replacement of nested name
template struct tuple_element
:private std::tuple_element::type
{
using NAME = typename std::tuple_element::type;
};
template
using tuple_element_t = typename tuple_element::NAME;
template struct base { protected: using type = int; };
template struct derived :private BASE { using BASE::type; };
int main() { return derived::type(0); }
It fails to compile until 'USING_SIMPLE_BASE' or 'USING_DIFFERENT_NAME' macros
would be defined:
$ g++ -xc++ -std=c++14 -pedantic-errors -DUSING_SIMPLE_BASE -o/dev/null
test.cxx
$ #build success
$ g++ -xc++ -std=c++14 -pedantic-errors -DUSING_DIFFERENT_NAME -o/dev/null
test.cxx
$ #build success
$ g++ -xc++ -std=c++14 -pedantic-errors -o/dev/null test.cxx
test.cxx: In function 'int main()':
test.cxx:27:35: error: 'using type = int' is protected within this context
int main() { return derived::type(0); }
^~~~
test.cxx:23:61: note: declared protected here
template struct base { protected: using type = int; };
^
In all cases 'derived' inherits 'base', so 'base::type' is available in context
of 'derived' class. Using declaration in public section of 'derived' do
'derived<>::type' available in global context. However, g++ not accepts all
variants of code.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
Also error is reproductable on g++ version 7.2.0(Ubuntu 7.2.0-1ubuntu1~16.04).
Clang 3.8 behaves similary
[Bug c++/84576] [6/7/8 Regression] g++: internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84576 --- Comment #4 from Vegard Nossum --- (In reply to Jakub Jelinek from comment #3) > BTW, when using creduce, if the original is valid or has just one error or > something similar, please try to write the script such that it will not > confirm a reduction which has also other errors, otherwise you end up with > testcases like this which have just too many errors in it. Thanks, I will try to do this in the future. I believe the original had only one error.
[Bug c++/84426] [8 Regression] ICE with conflicting class member names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84426 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug tree-optimization/84486] [7/8 Regression] code hoisting removes alignment assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84486 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Keywords||missed-optimization Last reconfirmed||2018-02-27 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|code hoisting removes |[7/8 Regression] code |alignment assumption|hoisting removes alignment ||assumption Target Milestone|--- |7.4 --- Comment #1 from Richard Biener --- Confirmed. We're just hoisting the __builtin_assume_aligned call here but when inserting it we do not apply its effect to the LHS. That's originally done by the CCP pass only btw. but there's no further CCP instance after PRE. Note PRE cannot easily transfer possibly conditional information along with the expressions it moves. The easiest fix^Whack would be to special-case BUILTIN_ASSUME_ALIGNED when inserting the hoisted call in create_expression_by_pieces...
[Bug fortran/84487] [8 Regression] Large rodate section increase in 465.tonto with r257233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P4 Version|unknown |8.0 Target Milestone|--- |8.0
[Bug c++/84492] [8 Regression] ICE with statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84492 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/84496] [6/7 Regression] Internal compiler error with lambda, static and auto since r236615
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84496 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 Known to work||8.0.1
[Bug tree-optimization/84503] [7 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 Richard Biener changed: What|Removed |Added Known to work||8.0.1 Target Milestone|8.0 |7.4
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #9 from Richard Biener --- unaligned loads from non-aggregates should be fully supported these days even on strict-align targets where they will result in bitfield extracts.
[Bug c++/84586] Incorrect acess checking with inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84586
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-02-27
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Reduced and fixed to compile with clang:
namespace std {
using size_t = decltype(sizeof(0));
template struct tuple { };
template struct tuple_element;
template struct tuple_element<0, tuple> { using type = T; };
}
#ifdef USING_SIMPLE_BASE
#define BASE base
#else
#ifdef USING_DIFFERENT_NAME
#define NAME type_
#else
#define NAME type
#endif
#define BASE tuple_element_t<0,std::tuple>>
#endif
//Simple trait for replacement of nested name
template struct tuple_element
:private std::tuple_element::type
{
using NAME = typename std::tuple_element::type;
};
template
using tuple_element_t = typename tuple_element::NAME;
template struct base { protected: using type = int; };
template struct derived :private BASE { using typename BASE::type;
};
int main() { return derived::type(0); }
[Bug tree-optimization/84512] [8 Regression] Missed optimization: should be precalculated in compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84512 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Version|tree-ssa|8.0 Keywords||missed-optimization Last reconfirmed||2018-02-27 Blocks||53947 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|Missed optimization: should |[8 Regression] Missed |be precalculated in |optimization: should be |compile-time|precalculated in ||compile-time Target Milestone|--- |8.0 --- Comment #1 from Richard Biener --- Confirmed. This is another case where we vectorize one loop but not the other and DOM doesn't handle removing vector loads against scalar stores. Later store-merging aggregates the stores but nothig performs CSE after it. The vectorizer decides that vectorizing the reduction is profitable while vectorizing the init is not: t.c:4:3: note: Cost model analysis: Vector inside of loop cost: 68 Vector prologue cost: 8 Vector epilogue cost: 128 Scalar iteration cost: 16 Scalar outside cost: 0 Vector outside cost: 136 prologue iterations: 0 epilogue iterations: 2 t.c:4:3: note: cost model: the vector iteration cost = 68 divided by the scalar iteration cost = 16 is greater or equal to the vectorization factor = 4. t.c:4:3: note: not vectorized: vectorization not profitable. With -fno-vect-cost-model we vectorize both loops and optimize the function like clang does. The issue with the cost model here is that for the scalar iteration cost we end up using builtin_vectorization_cost () while for the vector cost we use add_stmt_cost. Only the latter makes a difference between the different kind of operations. I have a patch. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/84587] New: [8 Regression] Local variable initializer goes out of scope since r247793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84587
Bug ID: 84587
Summary: [8 Regression] Local variable initializer goes out of
scope since r247793
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jason at gcc dot gnu.org,
mpolacek at gcc dot gnu.org
Target Milestone: ---
Starting from the mentioned revision:
$ cat /tmp/snippet.cc
#include
#include
template
class ArrayView
{
public:
using size_t = std::size_t;
constexpr ArrayView(const std::initializer_list& v)
: m_pointer(v.begin()), m_size(v.size()) {}
[[gnu::always_inline]]
constexpr T& operator[](size_t n) const { return *(m_pointer + n); }
private:
T* m_pointer;
size_t m_size;
};
int main()
{
ArrayView a = {'a', 'b', 'c'};
return a[0];
}
$ g++ -g /tmp/snippet.cc -fsanitize=address -std=c++11 && ./a.out
=
==3792==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7fffda70 at pc 0x00400af9 bp 0x7fffda30 sp 0x7fffda28
READ of size 1 at 0x7fffda70 thread T0
#0 0x400af8 in main /tmp/snippet.cc:26
#1 0x76186f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
#2 0x4007d9 in _start (/home/marxin/Programming/testcases/a.out+0x4007d9)
Address 0x7fffda70 is located in stack of thread T0 at offset 32 in frame
#0 0x400895 in main /tmp/snippet.cc:23
This frame has 3 object(s):
[32, 35) '' <== Memory access at offset 32 is inside this variable
[96, 112) 'a'
[160, 176) ''
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope /tmp/snippet.cc:26 in main
Shadow bytes around the buggy address:
0x10007fff7af0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007fff7b40: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1[f8]f2
0x10007fff7b50: f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 f2 f2 f2 f8 f8
0x10007fff7b60: f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
0x10007fff7b70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==3792==ABORTING
-fdump-tree-gimple:
GCC 7:
g++-7 /tmp/snippet.cc -fdump-tree-gimple=/dev/stdout
int main() ()
{
int D.3323;
{
struct ArrayView a;
try
{
a.m_pointer = &._18;
a.m_size = 3;
_1 = ArrayView::operator[] (&a, 0);
_2 = *_1;
D.3323 = (int) _2;
return D.3323;
}
finally
{
a = {CLOBBER};
}
}
D.3323 = 0;
return D.3323;
}
GCC 8:
g++ /tmp/snippet.cc -fdump-tree-gimple=/dev/stdout
main ()
{
const struct initializer_list D.3377;
const char D.3376[3];
int D.3403;
{
struct ArrayView a;
try
{
D.3376[0] = 97;
D.3376[1] = 98;
D.3376[2] = 99;
try
{
D.3377._M_array = &D.3376;
D.3377._M_len = 3;
try
{
ArrayView::ArrayView (&a, &D.3377);
}
finally
{
D.3377 = {CLOBBER};
}
}
finally
{
D.3376 = {CLOBBER};
}
_1 = ArrayView::operator[] (&a, 0);
_2 = *_1;
D.3403 = (int) _2;
return D.3403;
}
finally
{
a = {CLOBBER};
}
}
D.3403 = 0;
return D.3403;
}
[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582
--- Comment #4 from Marek Polacek ---
...with that we get the original ICE in PR84325 back:
internal compiler error: unexpected expression ‘(const
seconds){operator""_s<'1', '0'>()}’ of kind implicit_conv_expr
constexpr static inline seconds time_to_wait{10_s};
so that's another bug that needs to be fixed while at this.
[Bug c++/84587] [8 Regression] Local variable initializer goes out of scope since r247793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84587 --- Comment #1 from Martin Liška --- I forgot to mention that the revision was fix for PR70167.
[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582 Marek Polacek changed: What|Removed |Added Priority|P3 |P1
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #24 from Martin Liška --- (In reply to Dmitry G. Dyachenko from comment #23) > (In reply to Martin Liška from comment #20) > ... > > Isn't that > > an old data file you forgot to remove? > > After rebuild all and re-run myproject' tests I can confirm > 1) r257859 FAIL > 2) r257859 + patch from c#14 PASS > 3) there are NO "stamp mismatch with notes file" from c#17 > > Thank you, Martin! Thanks for testing, let me send the patch to mailing list.
[Bug c++/84588] New: internal compiler error: Segmentation fault (contains_struct_check())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588
Bug ID: 84588
Summary: internal compiler error: Segmentation fault
(contains_struct_check())
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at gmail dot com
Target Milestone: ---
This program:
struct a {
void b() {}
void c(auto = [] {
if (a a(int auto){})
;
}) {}
};
Invoked with:
xgcc -x c++ -std=c++14 -O3 -c -
Gives this output:
: In lambda function:
:4:17: error: two or more data types in declaration of 'parameter'
: At global scope:
:2:12: error: template definition of non-template 'void a::b()'
:2:12: internal compiler error: Segmentation fault
0x3138779 crash_signal
/home/vegard/git/gcc/gcc/toplev.c:325
0xf8f2f4 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/vegard/git/gcc/gcc/tree.h:3245
0xf8f2f4 cp_parser_ctor_initializer_opt_and_function_body
/home/vegard/git/gcc/gcc/cp/parser.c:21725
0xf98da5 cp_parser_function_definition_after_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:26648
0xf9b06c cp_parser_late_parsing_for_member
/home/vegard/git/gcc/gcc/cp/parser.c:27529
0xf14765 cp_parser_class_specifier_1
/home/vegard/git/gcc/gcc/cp/parser.c:22676
0xf1fcbb cp_parser_class_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:22702
0xf1fcbb cp_parser_type_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:16708
0xf8520a cp_parser_decl_specifier_seq
/home/vegard/git/gcc/gcc/cp/parser.c:13573
0xfa0d60 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12882
0xfa8c88 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12827
0xffb8d5 cp_parser_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12724
0xff298b cp_parser_declaration_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:12600
0xff3fb3 cp_parser_translation_unit
/home/vegard/git/gcc/gcc/cp/parser.c:4559
0xff3fb3 c_parse_file()
/home/vegard/git/gcc/gcc/cp/parser.c:38820
0x15a0525 c_common_parse_file()
/home/vegard/git/gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/84515] missed optimization: expected loop merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84515 Richard Biener changed: What|Removed |Added CC||law at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Note we don't do loop merging here but final value replacement does it's job. What is missing is jump-threading the two loop header copy checks count/2 != 0 and i < count if that is easily possible. So we end up with if (count/2 != 0) g += count/2; # tem = PHI if (count > tem) g += count - tem; those loop header checks also stand in the way of loop fusion (well, it's not classical fusion given the different iteration spaces). Not sure why DOM doesn't consider threading the above. Eventually it's a very special phiopt opportunity as well (but late phiopt runs too late). [local count: 118111601]: _20 = count_11(D) >> 1; if (_20 != 0) goto ; [89.00%] else goto ; [11.00%] [local count: 105119325]: [local count: 118111600]: # i_22 = PHI <_20(3), 0(2)> if (count_11(D) > i_22) note phiopt already does PHI i_22 reduced for COND_EXPR in block 2 to _20. so we end up with [local count: 118111600]: # i_22 = PHI <_20(3), _20(2)> if (count_11(D) > i_22) goto ; [89.00%] but nothing simplifies it further on GIMPLE. Note that of course count_11(D) > count_11(D) >> 1 isn't always true.
[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #17 from H.J. Lu --- Fixed for GCC 8.
[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 84148, which changed state. Bug 84148 Summary: CET shouldn't be enabled in 32-bit run-time libraries by default https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libfortran/84439] call to backtrace fails after about 6000 iterations (32-bit executable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84439 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #3 from Ian Lance Taylor --- Yes, the intended use is certainly to create the state once per program. Each time you create a new state and use it for a backtrace the code does a bunch of initialization work reading the debug info. Much better to do that only once. Plus there is the memory leak problem. That said, yes, there should be a function to free a state. But this code should really change to create the state once anyhow, if at all possible.
[Bug c++/79802] Conflicting declaration with function pointers/types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79802 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-27 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed, but this seems to have been fixed on trunk by r251438
[Bug c++/84516] bitfield temporaries > 32-bits have wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84516 Richard Biener changed: What|Removed |Added Keywords||rejects-valid, wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-27 Version|unknown |7.3.1 Ever confirmed|0 |1
[Bug preprocessor/84517] [8 Regression] "string literal"__FILE__ no longer accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84517 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |8.0
[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84528 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/84533] [7 Regression] ICE with duplicate enum value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84533 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||8.0 Target Milestone|--- |7.4
[Bug target/84534] [8 regression] several powerpc test cases fail starting with r257915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84534 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Target Milestone|--- |8.0
[Bug c++/84536] [7/8 Regression] ICE with non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84536 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |7.4
[Bug c++/84540] [6/7 Regression] ICE with alignas in variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84540 Richard Biener changed: What|Removed |Added Known to work||8.0 Version|unknown |7.3.1 Target Milestone|--- |6.5 Known to fail|8.0 |
[Bug fortran/84546] [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84546 Richard Biener changed: What|Removed |Added Target Milestone|8.0 |7.4
[Bug c++/57401] 'Conflicting declaration' involving using declaration and dependent name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57401 Jonathan Wakely changed: What|Removed |Added Known to work||4.7.4, 4.8.3, 4.9.0 Version|unknown |4.9.0 Target Milestone|--- |4.9.0 Known to fail||4.7.3, 4.8.2 --- Comment #2 from Jonathan Wakely --- Fixed for 4.9.0 by r207407 which was also backported to 4.8.3 and 4.7.4
[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Is that an optimized f951?
[Bug tree-optimization/84552] [8 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84552 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-27 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/84589] New: Failure to diagnose conflicting declaration of struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84589
Bug ID: 84589
Summary: Failure to diagnose conflicting declaration of struct
Product: gcc
Version: 8.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: ---
void stat(struct stat*) { }
namespace ns
{
using ::stat;
struct stat { };
}
This should be ill-formed, because the function declaration also adds "struct
stat" to the global namespace, so the using-declaration adds that to ns, and
defining struct ns::stat should conflict.
Clang says:
using.cc:6:3: error: declaration conflicts with target of using declaration
already in scope
struct stat { };
^
using.cc:1:18: note: target of using declaration
void stat(struct stat*) { }
^
using.cc:5:11: note: using declaration
using ::stat;
^
1 error generated.
and EDG says:
"using.cc", line 6: error: class "stat" cannot be defined in the current scope
struct stat { };
^
1 error detected in the compilation of "using.cc".
[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434
--- Comment #18 from Dominique d'Humieres ---
> After several people including have gone down rabbit
> holes trying to fix this bug, I have found a patch!
The patch at https://gcc.gnu.org/ml/fortran/2018-02/msg00181.html fixes several
tests in this PR, but not the ones in comment 14
f951: internal compiler error: Segmentation fault: 11
and comment 15
end
internal compiler error: in output_constructor_regular_field, at varasm.c:5031
In addition, I don't understand why
type t
character :: z
end type t
type(t), parameter :: s(5) = t('a')
type b
character :: y(5) = transfer('abcde', s(1)%z)
end type
type(b) :: zz
print *, zz
print *, s(1)%z
end
prints
a
a
Should not it be
abcde
a
?
[Bug tree-optimization/84552] [8 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84552
--- Comment #2 from Richard Biener ---
Probably related to us doing SCEV analysis w/o updating SSA form but
follow_copies_to_constant and degenerate_phi_result not honoring that.
The following would fix this:
Index: gcc/tree-scalar-evolution.c
===
--- gcc/tree-scalar-evolution.c (revision 258030)
+++ gcc/tree-scalar-evolution.c (working copy)
@@ -280,6 +280,7 @@ along with GCC; see the file COPYING3.
#include "params.h"
#include "tree-ssa-propagate.h"
#include "gimple-fold.h"
+#include "tree-into-ssa.h"
static tree analyze_scalar_evolution_1 (struct loop *, tree);
static tree analyze_scalar_evolution_for_address_of (struct loop *loop,
@@ -1545,7 +1546,9 @@ follow_copies_to_constant (tree var)
gimple *def = SSA_NAME_DEF_STMT (res);
if (gphi *phi = dyn_cast (def))
{
- if (tree rhs = degenerate_phi_result (phi))
+ if (name_registered_for_update_p (gimple_phi_result (phi)))
+ break;
+ else if (tree rhs = degenerate_phi_result (phi))
res = rhs;
else
break;
[Bug c++/84558] [6/7 Regression] ICE with invalid constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84558 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||8.0
[Bug c++/84590] New: -fsanitize=undefined internal compiler error: tree check: expected constructor, have target_expr in split_nonconstant_init_1, at cp/typeck2.c:629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84590
Bug ID: 84590
Summary: -fsanitize=undefined internal compiler error: tree
check: expected constructor, have target_expr in
split_nonconstant_init_1, at cp/typeck2.c:629
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at gmail dot com
Target Milestone: ---
Input:
void a() {
struct {
char b;
} c {
~220 << 0
};
}
Compiled with:
xgcc -x c++ -std=c++14 -O3 -fsanitize=undefined -c -
Output:
: In function 'void a()':
:5:10: warning: narrowing conversion of '(, (-221 <<
0))' from 'int' to 'char' inside { } [-Wnarrowing]
:6:3: internal compiler error: tree check: expected constructor, have
target_expr in split_nonconstant_init_1, at cp/typeck2.c:629
0x65e898 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/vegard/git/gcc/gcc/tree.c:9327
0x1416f79 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/vegard/git/gcc/gcc/tree.h:3132
0x1416f79 split_nonconstant_init_1
/home/vegard/git/gcc/gcc/cp/typeck2.c:628
0x142680d split_nonconstant_init(tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/cp/typeck2.c:753
0xb44f78 check_initializer
/home/vegard/git/gcc/gcc/cp/decl.c:6380
0xbd8b3e cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/vegard/git/gcc/gcc/cp/decl.c:7034
0xf9dd85 cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19665
0xfa2a97 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13009
0xfa8c88 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12827
0xfab154 cp_parser_declaration_statement
/home/vegard/git/gcc/gcc/cp/parser.c:12420
0xef6e13 cp_parser_statement
/home/vegard/git/gcc/gcc/cp/parser.c:10869
0xefb1eb cp_parser_statement_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:11218
0xefbc8a cp_parser_compound_statement
/home/vegard/git/gcc/gcc/cp/parser.c:11172
0xf8fb9b cp_parser_function_body
/home/vegard/git/gcc/gcc/cp/parser.c:21712
0xf8fb9b cp_parser_ctor_initializer_opt_and_function_body
/home/vegard/git/gcc/gcc/cp/parser.c:21747
0xf98da5 cp_parser_function_definition_after_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:26648
0xf9f305 cp_parser_function_definition_from_specifiers_and_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:26565
0xf9f305 cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19436
0xfa2a97 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13009
0xfa8c88 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12827
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Version:
xgcc (GCC) 8.0.1 20180204 (experimental)
built from git fdae6180ad24fa6303fa046114f3e4b66b8db34d
Version 7.3.0 don't seem to be affected AFAICS. gcc trunk on godbolt.org (8.0.1
20180227) gives:
: In function 'void a()':
:5:10: warning: narrowing conversion of '(, (-221
<< 0))' from 'int' to 'char' inside { } [-Wnarrowing]
~220 << 0
~^~~~
:6:3: internal compiler error: tree check: expected constructor, have
target_expr in split_nonconstant_init_1, at cp/typeck2.c:629
};
^
mmap: Invalid argument
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
Test case was reduced using C-Reduce. There is no error without
-fsanitize=undefined.
[Bug fortran/84591] New: Compiling gfortran.dg/bind_c_usage_10.f03 with -fdefault-integer-8 gives errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84591 Bug ID: 84591 Summary: Compiling gfortran.dg/bind_c_usage_10.f03 with -fdefault-integer-8 gives errors Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Target Milestone: --- Compiling gfortran.dg/bind_c_usage_10.f03 with -fdefault-integer-8 gives errors: /opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:66:31: integer(c_int) function func4() 1 Error: FUNCTION result func4 can't be of type INTEGER(4) in FUNCTION func4 at (1) /opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:59:31: integer(c_int) function func3() bind(c, name="myFunc3") 1 Error: FUNCTION result func3 can't be of type INTEGER(4) in FUNCTION func3 at (1) /opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:52:31: integer(c_int) function func2() 1 Error: FUNCTION result func2 can't be of type INTEGER(4) in FUNCTION func2 at (1) /opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:45:31: integer(c_int) function func1() bind(c, name="myFunc1") 1 Error: FUNCTION result func1 can't be of type INTEGER(4) in FUNCTION func1 at (1) (1) I don't understand why there are these errors. (2) I didn't find a way to silence them.
[Bug fortran/84591] Compiling gfortran.dg/bind_c_usage_10.f03 with -fdefault-integer-8 gives errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84591 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-27 Blocks||32770 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I have forgotten to say that I see this behavior from 4.3.1 up to trunk (8.0). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770 [Bug 32770] [Meta-bug] -fdefault-integer-8 issues
[Bug c++/84590] [7/8 Regression] -fsanitize=undefined internal compiler error: tree check: expected constructor, have target_expr in split_nonconstant_init_1, at cp/typeck2.c:629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84590 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-27 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |7.4 Summary|-fsanitize=undefined|[7/8 Regression] |internal compiler error:|-fsanitize=undefined |tree check: expected|internal compiler error: |constructor, have |tree check: expected |target_expr in |constructor, have |split_nonconstant_init_1, |target_expr in |at cp/typeck2.c:629 |split_nonconstant_init_1, ||at cp/typeck2.c:629 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/84587] [8 Regression] Local variable initializer goes out of scope since r247793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84587
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Jason Merrill ---
The testcase has undefined behavior; the initializer_list array only lives
until the end of the initialization of 'a'.
11.6.4p6: The array has the same lifetime as any other temporary object (15.2),
except that initializing an initializer_list object from the array extends the
lifetime of the array exactly like binding a reference to a temporary.
15.2p6.9: A temporary object bound to a reference parameter in a function call
(8.5.1.2) persists until the completion of the full-expression containing the
call.
The code can be fixed by explicitly extending the initializer_list lifetime,
e.g.
std::initializer_list il = {'a', 'b', 'c'};
ArrayView a (il);
[Bug c++/84590] [7/8 Regression] -fsanitize=undefined internal compiler error: tree check: expected constructor, have target_expr in split_nonconstant_init_1, at cp/typeck2.c:629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84590 --- Comment #2 from Marek Polacek --- Started with r238559. I can take a look later.
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #25 from Martin Liška --- Author: marxin Date: Tue Feb 27 14:11:08 2018 New Revision: 258033 URL: https://gcc.gnu.org/viewcvs?rev=258033&root=gcc&view=rev Log: Make groups more generic (PR gcov-profile/84548). 2018-02-27 Martin Liska PR gcov-profile/84548 * gcov.c (process_file): Allow partial overlap and consider it also as group functions. (output_lines): Properly calculate range of lines for a group. 2018-02-27 Martin Liska PR gcov-profile/84548 * g++.dg/gcov/pr84548.C: New test. Added: trunk/gcc/testsuite/g++.dg/gcov/pr84548.C Modified: trunk/gcc/ChangeLog trunk/gcc/gcov.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/84562] -faggressive-loop-optimizations makes decisions based on weak data structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Richard Biener --- Note I think all cases are on the border of being invalid. In C++ the ODR forbids interposition with "different" objects. You simply have to ensure to provide compatible definitions when interposing others.
[Bug c++/58993] incorrectly accept access of protected member method from derived class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58993
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2013-11-05 00:00:00 |2018-2-27
--- Comment #5 from Jonathan Wakely ---
Warning-free testcase:
class base {
private:
void foo() { }
};
template
struct bar : public base {
void test() {
(void) &base::foo; // should be rejected
}
};
template <>
struct bar : public base {
void test() {
// &base::foo; // correctly rejected
}
};
int main() {
bar().test();
bar().test();
}
Still accepted by trunk.
Clang says:
58993.cc:9:23: error: 'foo' is a private member of 'base'
(void) &base::foo; // should be rejected
^
58993.cc:3:10: note: declared private here
void foo() { }
^
1 error generated.
and EDG says:
"58993.cc", line 9: error: function "base::foo" (declared at line 3) is
inaccessible
(void) &base::foo; // should be rejected
^
detected during instantiation of "void bar::test() [with T=int]"
at line 21
1 error detected in the compilation of "58993.cc".
[Bug c++/84587] [8 Regression] Local variable initializer goes out of scope since r247793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84587
--- Comment #3 from Martin Liška ---
(In reply to Jason Merrill from comment #2)
> The testcase has undefined behavior; the initializer_list array only lives
> until the end of the initialization of 'a'.
>
> 11.6.4p6: The array has the same lifetime as any other temporary object
> (15.2), except that initializing an initializer_list object from the array
> extends the lifetime of the array exactly like binding a reference to a
> temporary.
>
> 15.2p6.9: A temporary object bound to a reference parameter in a function
> call (8.5.1.2) persists until the completion of the full-expression
> containing the call.
>
> The code can be fixed by explicitly extending the initializer_list lifetime,
> e.g.
>
> std::initializer_list il = {'a', 'b', 'c'};
> ArrayView a (il);
Thank you Jason for nice clarification ;)
[Bug c++/84578] [6/7/8 Regression] ICE with flexible array member and constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84578 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 --- Comment #38 from Eric Botcazou --- > This is a symlink to /home/eric/build/gcc/mips-linux/pr83496.c which > does not work on most people's machines ;-) It didn't really work on mine either after all so I quickly changed it. ;-)
[Bug lto/84579] __gnu_lto_v1 should be removed when linking with -fno-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579 Richard Biener changed: What|Removed |Added Keywords||lto Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. This isn't easy to do given only the linker can. When using GNU ld one might be able to use filter objects or some custom linker scripts but don't hold your breath. I'd rather like to see those common symbols to die completely - though that's equally hard given they have been hardcoded into binutils meanwhile... Using ELF notes or simply keying on section names should be possible as well. It's only the non-linker-plugin path which uses nm to look for objects with LTO bytecode that might be harder to fix (well, use readelf or similar tools or simply use a simple-object handler).
[Bug tree-optimization/84584] [8 Regression] [graphite] ICE: Segmentation fault (in dominated_by_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84584 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-27 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Bah, mine.
[Bug c++/84590] [7/8 Regression] -fsanitize=undefined internal compiler error: tree check: expected constructor, have target_expr in split_nonconstant_init_1, at cp/typeck2.c:629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84590 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug preprocessor/84517] [8 Regression] "string literal"__FILE__ no longer accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84517 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #1 from Jonathan Wakely --- Patch posted to https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01503.html
[Bug fortran/40142] integer constants not promoted with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40142 Dominique d'Humieres changed: What|Removed |Added Resolution|WONTFIX |FIXED --- Comment #4 from Dominique d'Humieres --- This has been fixed since at least 4.8.5 (still present in 4.3.6).
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #26 from Martin Liška --- Fixed.
[Bug libgomp/84466] [8 regression] libgomp.graphite/force-parallel-8.c fails starting with r257723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84466 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug libgomp/84466] [8 regression] libgomp.graphite/force-parallel-8.c fails starting with r257723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84466 --- Comment #6 from Richard Biener --- Author: rguenth Date: Tue Feb 27 14:45:46 2018 New Revision: 258035 URL: https://gcc.gnu.org/viewcvs?rev=258035&root=gcc&view=rev Log: 2018-02-27 Richard Biener PR tree-optimization/84466 * graphite-scop-detection.c (scop_detection::stmt_simple_for_scop_p): Adjust last change to less strictly validate use operands. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-scop-detection.c
[Bug lto/84592] New: [openacc] lto1: ICE in input_varpool_node, at lto-cgraph.c:1424: for CSWTCH symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84592
Bug ID: 84592
Summary: [openacc] lto1: ICE in input_varpool_node, at
lto-cgraph.c:1424: for CSWTCH symbol
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Consider the following openacc testcase:
...
/* { dg-additional-options "-ftree-switch-conversion" } */
#include
#pragma acc routine seq
static int __attribute__((noinline)) foo (int n)
{
switch (n & 3)
{
case 0: return 4;
case 1: return 3;
case 2: return 2;
default:
return 1;
}
}
int
main (void)
{
int n[1];
n[1] = 4;
#pragma acc parallel copy(n)
{
n[0] = foo (n[0]);
}
printf ("n: %d\n", n[0]);
return 0;
}
...
When compiling this (by copying it into
libgomp/testsuite/libgomp.oacc-c-c++-common), we run into:
...
lto1: internal compiler error: in input_varpool_node, at lto-cgraph.c:1424^M
0x959ebb input_varpool_node^M
gcc/lto-cgraph.c:1422^M
0x959ebb input_cgraph_1^M
gcc/lto-cgraph.c:1544^M
0x959ebb input_symtab()^M
gcc/lto-cgraph.c:1858^M
0x5aceac read_cgraph_and_symbols^M
gcc/lto/lto.c:2891^M
0x5aceac lto_main()^M
gcc/lto/lto.c:3356^M
...
When running lto1 using gdb we find the node we're processing is:
...
(gdb) call debug_generic_expr ( node.decl )
CSWTCH.4
...
The CSWTCH.4 is a symbol introduced by -ftree-switch-conversion. If we use
-fno-tree-switch-conversion there's no ICE.
[Bug c++/84593] New: internal compiler error: Segmentation fault (non_type_check())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84593
Bug ID: 84593
Summary: internal compiler error: Segmentation fault
(non_type_check())
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at gmail dot com
Target Milestone: ---
Input:
struct a {
int x;
int c = 0;
int &b;
} c = {};
Output:
$ xgcc -x c++ -std=c++14 -O3 -c -
:5:8: error: member 'a::b' is uninitialized reference
:5:8: internal compiler error: Segmentation fault
0x3138779 crash_signal
/home/vegard/git/gcc/gcc/toplev.c:325
0x1414ec4 non_type_check(tree_node*, char const*, int, char const*)
/home/vegard/git/gcc/gcc/tree.h:3310
0x1414ec4 picflag_from_initializer
/home/vegard/git/gcc/gcc/cp/typeck2.c:1230
0x141b813 process_init_constructor_record
/home/vegard/git/gcc/gcc/cp/typeck2.c:1531
0x141b813 process_init_constructor
/home/vegard/git/gcc/gcc/cp/typeck2.c:1712
0x141b813 digest_init_r
/home/vegard/git/gcc/gcc/cp/typeck2.c:1147
0x14279ca digest_init_flags(tree_node*, tree_node*, int, int)
/home/vegard/git/gcc/gcc/cp/typeck2.c:1192
0x14279ca store_init_value(tree_node*, tree_node*, vec**, int)
/home/vegard/git/gcc/gcc/cp/typeck2.c:814
0xb44f78 check_initializer
/home/vegard/git/gcc/gcc/cp/decl.c:6380
0xbd8b3e cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/vegard/git/gcc/gcc/cp/decl.c:7034
0xf9dd85 cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19665
0xfa2a97 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13009
0xfa8c88 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12827
0xffb8d5 cp_parser_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12724
0xff298b cp_parser_declaration_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:12600
0xff3fb3 cp_parser_translation_unit
/home/vegard/git/gcc/gcc/cp/parser.c:4559
0xff3fb3 c_parse_file()
/home/vegard/git/gcc/gcc/cp/parser.c:38820
0x15a0525 c_common_parse_file()
/home/vegard/git/gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Version:
xgcc (GCC) 8.0.1 20180204 (experimental)
built from git fdae6180ad24fa6303fa046114f3e4b66b8db34d
Version 7.3.0 don't seem to be affected AFAICS. gcc trunk on godbolt.org (8.0.1
20180227) gives:
:5:8: error: member 'a::b' is uninitialized reference
} c = {};
^
:5:8: internal compiler error: Segmentation fault
mmap: Invalid argument
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
Test case was reduced by C-Reduce.
[Bug c++/84593] [6/7/8 Regression] internal compiler error: Segmentation fault (non_type_check())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84593 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-27 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.5 Summary|internal compiler error:|[6/7/8 Regression] internal |Segmentation fault |compiler error: |(non_type_check()) |Segmentation fault ||(non_type_check()) Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/84562] -faggressive-loop-optimizations makes decisions based on weak data structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562 Jan Nordholz changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Jan Nordholz --- Hi, sorry for reopening, but I don't think the comment properly addresses the bug report. a) This is not about C++ - the example is pure C, and weak definitions are an established mechanism. b) I don't see how the overriding of a weak 'const int y' with a strong 'const int y' might count as an "incompatible definition". The implicit-sized arrays might be a different story, true, but I can't see how you've refuted my first example. I understand that this is probably a minor issue, as weak objects are probably only used by a minority of developers. Still, gcc silently generates buggy code which could only be prevented by either 1. moving the weak definition into a different compilation unit than (all) the code that uses it or 2. by compiling at less than -O2. If you consider this too low-prio, I'd gladly try to whip up a patch myself if I find the time.
