[Bug tree-optimization/85475] [8 Regression] Compile time hog w/ -O1 -fpeel-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85475 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #2 from Richard Biener --- Mine.
[Bug tree-optimization/85475] [8 Regression] Compile time hog w/ -O1 -fpeel-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85475 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-20 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. It looks like some sort of an infinite loop. Bisection points to r258061: 2018-02-28 Richard Biener PR middle-end/84607 * genmatch.c (capture_info::walk_match): Do not mark captured expressions without operands as expr_p given they act more like predicates and should be subject to "lost tail" side-effect preserving. * gcc.dg/pr84607.c: New testcase.
[Bug tree-optimization/85475] New: [8 Regression] Compile time hog w/ -O1 -fpeel-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85475
Bug ID: 85475
Summary: [8 Regression] Compile time hog w/ -O1 -fpeel-loops
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: compile-time-hog
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-alpha20180415 snapshot (r259389) takes long (or indefinite) time to
compile the following snippet w/ -O1 (-O2) -fpeel-loops:
int
nj (int le)
{
int zb;
for (zb = 0; zb < 16; ++zb)
le += le;
return le * le;
}
% timeout 20 gcc-8.0.0-alpha20180415 -O1 -fpeel-loops -c i9xivvyu.c
zsh: exit 124 timeout 20 gcc-8.0.0-alpha20180415 -O1 -fpeel-loops -c
i9xivvyu.c
Profile captured by perf top:
41.29% cc1 [.] tree_int_cst_equal
12.86% cc1 [.] vr_values::get_value_range
11.46% cc1 [.] vrp_valueize_1
7.44% cc1 [.] gimple_simplify_MULT_EXPR
4.18% cc1 [.] integer_all_onesp
3.75% cc1 [.] integer_zerop
2.96% cc1 [.] range_int_cst_singleton_p
2.93% cc1 [.] wi::max_value
2.29% cc1 [.] range_int_cst_singleton_p
2.26% cc1 [.] gimple_simplify_233
1.44% cc1 [.] gimple_resimplify2
1.08% cc1 [.] gimple_simplify
1.03% cc1 [.] gimple_negate_expr_p
0.82% cc1 [.] maybe_push_res_to_seq
0.73% cc1 [.] tree_strip_nop_conversions
0.65% cc1 [.] tree_int_cst_equal
0.61% cc1 [.] tree_swap_operands_p
0.50% cc1 [.] real_zerop
0.41% cc1 [.] tree_swap_operands_p
0.38% cc1 [.] integer_onep
0.35% cc1 [.] real_minus_onep
0.26% cc1 [.] real_onep
0.15% cc1 [.] integer_minus_onep
0.15% cc1 [.] commutative_tree_code
[Bug c++/85474] unspecified string literal comparison accepted in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85474 Martin Sebor changed: What|Removed |Added Keywords||accepts-invalid Known to fail||5.3.0, 6.4.0, 7.3.0, 8.0 --- Comment #1 from Martin Sebor --- The test case was never rejected so it's not a regression.
[Bug c++/85474] New: unspecified string literal comparison accepted in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85474 Bug ID: 85474 Summary: unspecified string literal comparison accepted in constexpr context Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- According to [expr.const]: An expression e is a core constant expression unless the evaluation of e, following the rules of the abstract machine (4.6), would evaluate one of the following expressions: ... -- a relational (8.9) or equality (8.10) operator where the result is unspecified; That means that the following program is ill-formed and needs to be rejected with an error: $ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C constexpr bool b = "" == ""; t.C:1:26: warning: comparison with string literal results in unspecified behavior [-Waddress] constexpr bool b = "" == ""; ^~ GCC accepts the program with only a warning when it should reject it with a hard error as Clang does.
[Bug libstdc++/85466] Performance is slow when doing 'branchless' conditional style math operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466 --- Comment #14 from Daniel Elliott --- I had a response from chandler carruth on twitter, who informed me that the benchark was hoisting the computation out of the loop. So thats why clang was faster. but also he said that the noconditional version was not vectorized.
[Bug sanitizer/67308] FATAL: ThreadSanitizer: unexpected memory mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67308 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed for GCC 7.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #13 from Michael Meissner --- You can use --with-cpu=power7 as well. But if you only have power8 systems, it is better to use --with-cpu=power8. The little endian PowerPC Linux systems have a minimum cpu base level of power8, so float128 is available on that platform by default.
[Bug target/85473] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85473
--- Comment #2 from H.J. Lu ---
Something like this
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index dc80b34f302..99feb5ea629 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -37141,11 +37141,10 @@ ix86_expand_builtin (tree exp, rtx target, rtx
subtarget,
arg1 = CALL_EXPR_ARG (exp, 1);
op0 = expand_normal (arg0);
op1 = expand_normal (arg1);
- mode0 = (TARGET_64BIT ? DImode : SImode);
- op0 = force_reg (mode0, op0);
- if (!memory_operand (op1, mode0))
- op1 = gen_rtx_MEM (mode0, op1);
+ op0 = ix86_zero_extend_to_Pmode (op0);
+ if (!memory_operand (op1, XImode))
+ op1 = gen_rtx_MEM (XImode, op1);
insn = (TARGET_64BIT
? gen_movdir64b_di (op0, op1)
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index a134ca88014..d01e3c631b5 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -20697,8 +20697,8 @@
[(set_attr "type" "other")])
(define_insn "movdir64b_"
- [(unspec_volatile:SWI48[(match_operand:SWI48 0 "register_operand" "r")
- (match_operand:SWI48 1 "memory_operand")]
+ [(unspec_volatile:XI [(match_operand:P 0 "register_operand" "r")
+ (match_operand:XI 1 "memory_operand")]
UNSPECV_MOVDIR64B)]
"TARGET_MOVDIR64B"
"movdir64b\t{%1, %0|%0, %1}"
[Bug target/85473] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85473
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-04-19
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu ---
movdir64 stores 64 byte. But it doesn't show:
(define_insn "movdir64b_"
[(unspec_volatile:SWI48[(match_operand:SWI48 0 "register_operand" "r")
(match_operand:SWI48 1 "memory_operand")]
UNSPECV_MOVDIR64B)]
"TARGET_MOVDIR64B"
"movdir64b\t{%1, %0|%0, %1}"
[(set_attr "type" "other")])
Here register is used as address.
[Bug target/85473] New: internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85473
Bug ID: 85473
Summary: internal compiler error: in emit_move_insn, at
expr.c:3722
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: sebastian.peryt at intel dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-cfl-1 gcc]$ cat /tmp/x.i
extern void
_movdir64b (void * __P, const void * __Q)
{
__builtin_ia32_movdir64b (__P, __Q);
}
[hjl@gnu-cfl-1 gcc]$ ./xgcc -B./ -mx32 -mmovdir64b -mmovdiri -O2 -S /tmp/x.i
during RTL pass: expand
/tmp/x.i: In function ‘_movdir64b’:
/tmp/x.i:4:3: internal compiler error: in emit_move_insn, at expr.c:3722
__builtin_ia32_movdir64b (__P, __Q);
^~~
0xb1c92d emit_move_insn(rtx_def*, rtx_def*)
/export/gnu/import/git/sources/gcc/gcc/expr.c:3721
0xaeef45 force_reg(machine_mode, rtx_def*)
/export/gnu/import/git/sources/gcc/gcc/explow.c:666
0x14716b3 ix86_expand_builtin
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:37146
0x962514 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/export/gnu/import/git/sources/gcc/gcc/builtins.c:6648
0xb3d2f4 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/export/gnu/import/git/sources/gcc/gcc/expr.c:11004
0xb2fa7d expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/export/gnu/import/git/sources/gcc/gcc/expr.c:8231
0x9988c9 expand_expr
/export/gnu/import/git/sources/gcc/gcc/expr.h:280
0x9a13a2 expand_call_stmt
/export/gnu/import/git/sources/gcc/gcc/cfgexpand.c:2690
0x9a482d expand_gimple_stmt_1
/export/gnu/import/git/sources/gcc/gcc/cfgexpand.c:3624
0x9a4f23 expand_gimple_stmt
/export/gnu/import/git/sources/gcc/gcc/cfgexpand.c:3790
0x9a5022 expand_gimple_tailcall
/export/gnu/import/git/sources/gcc/gcc/cfgexpand.c:3836
0x9ad61d expand_gimple_basic_block
/export/gnu/import/git/sources/gcc/gcc/cfgexpand.c:5796
0x9af0ba execute
/export/gnu/import/git/sources/gcc/gcc/cfgexpand.c:6425
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #12 from Jakub Jelinek --- Or configure the big endian compiler with VSX by default, e.g. --with-cpu=power8 or similar.
[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471
--- Comment #3 from Jonathan Wakely ---
Have you read https://gcc.gnu.org/bugs/ yet?
(In reply to Andreas Otto from comment #2)
> this is not as easy because this is a non trivial SW… what I mean… to just
> use my test-case you have to setup a whole environment… the basic of a SW is
> a client/server application using a non trivial protocol…
We don't want the whole thing, we want a simple example that demonstrates the
bug you are reporting. Otherwise your report is just hearsay.
For example, here is a simple testcase which works perfectly and doesn't abort:
#include
#include
void f()
{
pthread_exit(nullptr);
}
int main()
{
std::thread t(f);
t.join();
}
Here is a testcase which calls std::terminate because the pthread_exit happens
below a noexcept function:
#include
#include
void f() noexcept
{
pthread_exit(nullptr);
}
int main()
{
std::thread t(f);
t.join();
}
But this has a different stack trace to your valgrind output:
==25626== Memcheck, a memory error detector
==25626== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==25626== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==25626== Command: ./a.out
==25626==
terminate called without an active exception
==25626==
==25626== Process terminating with default action of signal 6 (SIGABRT):
dumping core
==25626==at 0x59459FB: raise (raise.c:51)
==25626==by 0x59477FF: abort (abort.c:89)
==25626==by 0x4ECC024: __gnu_cxx::__verbose_terminate_handler()
(vterminate.cc:95)
==25626==by 0x4EC9C15: __cxxabiv1::__terminate(void (*)())
(eh_terminate.cc:47)
==25626==by 0x4EC9C60: std::terminate() (eh_terminate.cc:57)
==25626==by 0x4EC97AF: __gxx_personality_v0 (eh_personality.cc:670)
==25626==by 0x54E8FB4: _Unwind_ForcedUnwind_Phase2 (unwind.inc:175)
==25626==by 0x54E9574: _Unwind_ForcedUnwind (unwind.inc:207)
==25626==by 0x5700F0F: __pthread_unwind (unwind.c:121)
==25626==by 0x56F8754: __do_cancel (pthreadP.h:297)
==25626==by 0x56F8754: pthread_exit (pthread_exit.c:28)
==25626==by 0x400A4A: f() (th.cc:6)
==25626==by 0x4EF617E: execute_native_thread_routine (thread.cc:83)
==25626==
==25626== Process terminating with default action of signal 11 (SIGSEGV)
==25626== General Protection Fault
==25626==at 0x5A63E9C: _dl_catch_error (dl-error-skeleton.c:187)
==25626==by 0x5A63616: dlerror_run (dl-libc.c:46)
==25626==by 0x5A63616: __libc_dlclose (dl-libc.c:222)
==25626==by 0x5703C18: nptl_freeres (in /usr/lib64/libpthread-2.25.so)
==25626==by 0x5A8EF11: __libc_freeres (in /usr/lib64/libc-2.25.so)
==25626==by 0x4A286DB: _vgnU_freeres (vg_preloaded.c:77)
==25626==
==25626== HEAP SUMMARY:
==25626== in use at exit: 360 bytes in 3 blocks
==25626== total heap usage: 4 allocs, 1 frees, 73,064 bytes allocated
==25626==
==25626== LEAK SUMMARY:
==25626==definitely lost: 0 bytes in 0 blocks
==25626==indirectly lost: 0 bytes in 0 blocks
==25626== possibly lost: 288 bytes in 1 blocks
==25626==still reachable: 72 bytes in 2 blocks
==25626== suppressed: 0 bytes in 0 blocks
==25626== Rerun with --leak-check=full to see details of leaked memory
==25626==
==25626== For counts of detected and suppressed errors, rerun with: -v
==25626== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
So we need a testcase showing the problem.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #11 from Jakub Jelinek --- You need powerpc64le, big-endian doesn't support __float128.
[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440 --- Comment #10 from Dennis Clarke --- Well, current gcc 8 snapshot doesn't work : nix_$ nix_$ /usr/local/gcc8/bin/gcc --version gcc (genunix Wed Apr 18 19:16:29 GMT 2018) 8.0.1 20180415 (experimental) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. nix_$ /usr/local/gcc8/bin/gcc -m64 -mcpu=970 -o s s.c s.c:82:10: fatal error: quadmath.h: No such file or directory #include ^~~~ compilation terminated. nix_$
[Bug target/85436] [7 Regression] ICE compiling go code with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85436 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-19 Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Peter Bergner --- Confirmed. The failure is similar to that which was fixed in PR83969 and is fixed by that patch. We didn't think we needed to back port the PR83969 patch, but I see now we do. I'm testing the back port now.
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-19 Component|c++ |libstdc++ Ever confirmed|0 |1
[Bug c/10360] __alignof__(double) answer 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10360
--- Comment #12 from joseph at codesourcery dot com ---
On Wed, 11 Apr 2018, jason at gcc dot gnu.org wrote:
> The quoted passage in the documentation now reads
>
> ---
> Some machines never actually require alignment; they allow reference to any
> data type even at an odd address. For these machines, @code{__alignof__}
> reports the smallest alignment that GCC gives the data type, usually as
> mandated by the target ABI.
That change (r133271) seems incorrect in this context, as it should be the
alignment given for complete objects.
[Bug c++/85472] New: Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 Bug ID: 85472 Summary: Regex match bug Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haberg-1 at telia dot com Target Milestone: --- Created attachment 43993 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43993&action=edit The regex example mentioned in the report. In the regex "(z)((a+)?(b+)?(c))*" example at [1], also attached, applied to the string "zaacbbbcac", g++ produces a pattern #4 match as "bbb", whereas it says there it should be empty (the latter which clang++ does). 1. http://en.cppreference.com/w/cpp/regex/ecmascript
[Bug c++/69560] x86_64: alignof(uint64_t) produces incorrect results with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560 --- Comment #20 from joseph at codesourcery dot com --- I consider it part of the ABI that long long __attribute__((__aligned__(__alignof__(long long, as in the definition of max_align_t (and similarly in gnulib's max_align_t definition, for example), is 8-byte-aligned on x86.
[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471 --- Comment #2 from Andreas Otto --- this is not as easy because this is a non trivial SW… what I mean… to just use my test-case you have to setup a whole environment… the basic of a SW is a client/server application using a non trivial protocol… it is possible you send me a hint to create a better error output for you… for me it would be perfect if the GCC part of the error could be MORE specific about the real reason of the SIGABRT thanks for your work.
[Bug fortran/85448] the compiler selects the wrong subroutine because of bind(c,name=...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448 Thomas Koenig changed: What|Removed |Added Keywords||diagnostic Status|REOPENED|NEW CC||tkoenig at gcc dot gnu.org Severity|normal |enhancement --- Comment #7 from Thomas Koenig --- As quoted by Steve Lionel on c.l.f (F2008, 16.2, para 2): "The global identifier of an entity shall not be the same as the global identifier of any other entity. Furthermore, a binding label shall not be the same as the global identifier of any other global entity, ignoring differences in case." So, the code is invalid. Since this is not a constraint, the compiler can do anything it pleases. It would be nice to have an error message, though; should be straightforward to implement.
[Bug tree-optimization/85467] [8 Regression] ICE: verify_gimple failed: non-trivial conversion at assignment with -O2 -fno-tree-ccp --param=sccvn-max-scc-size=10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85467 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/85467] [8 Regression] ICE: verify_gimple failed: non-trivial conversion at assignment with -O2 -fno-tree-ccp --param=sccvn-max-scc-size=10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85467 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Thu Apr 19 19:16:18 2018 New Revision: 259507 URL: https://gcc.gnu.org/viewcvs?rev=259507&root=gcc&view=rev Log: PR tree-optimization/85467 * fold-const.c (fold_ternary_loc) : Use VECTOR_TYPE_P macro. If type is vector type, VIEW_CONVERT_EXPR the VECTOR_CST element to type. * gcc.dg/pr85467.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr85467.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #17 from Jakub Jelinek --- And, GCC offers the -fno-lifetime-dse option which will not eliminate the stores: -fno-lifetime-dse In C++ the value of an object is only affected by changes within its lifetime: when the constructor begins, the object has an indeterminate value, and any changes during the lifetime of the object are dead when the object is destroyed. Normally dead store elimination will take advantage of this; if your code relies on the value of the object storage persisting beyond the lifetime of the object, you can use this flag to disable this optimization. To preserve stores before the constructor starts (e.g. because your operator new clears the object storage) but still treat the object as dead after the destructor you, can use -flifetime-dse=1. The default behavior can be explicitly selected with -flifetime-dse=2. -flifetime-dse=0 is equivalent to -fno-lifetime-dse.
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #16 from Avi Kivity --- Sorry, of course the stores are not illegal.
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #15 from Jakub Jelinek --- The stores aren't illegal, just can't be observed in a valid program, because after the destruction the bits have indeterminate values.
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #14 from Avi Kivity --- This is a common missed optimization. A container is cleared as part of destruction, but the stores are not eliminated, even though they are illegal. If you want to access members of an object, don't destroy it.
[Bug c++/84611] [6/7 Regression] ICE in operator[], at vec.h:826 (local_class_index())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84611 Paolo Carlini changed: What|Removed |Added Summary|[6/7/8 Regression] ICE in |[6/7 Regression] ICE in |operator[], at vec.h:826|operator[], at vec.h:826 |(local_class_index()) |(local_class_index()) --- Comment #4 from Paolo Carlini --- Fixed in trunk.
[Bug c++/84611] [6/7/8 Regression] ICE in operator[], at vec.h:826 (local_class_index())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84611 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Apr 19 18:09:45 2018 New Revision: 259505 URL: https://gcc.gnu.org/viewcvs?rev=259505&root=gcc&view=rev Log: /cp 2018-04-19 Paolo Carlini PR c++/84611 * pt.c (lookup_template_class_1): Check pushtag return value for error_mark_node. /testsuite 2018-04-19 Paolo Carlini PR c++/84611 * g++.dg/parse/crash68.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/crash68.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #13 from hyrosen at mail dot com --- (In reply to Jonathan Wakely from comment #12) > The C++ standard. Specifically, [basic.life]. > > So the first memcmp call reuses the storage to create an array of unsigned > char with indeterminate values. That ends the lifetime of the X (without > calling the destructor). Then you call the destructor on an object that > already ended its lifetime, which is undefined. Then you reuse it as an > array of unsigned char again, and it still has indeterminate values. No, this is wrong. [basic.life] says (I'm using N4741): "The lifetime of an object of type T begins when: — storage with the proper alignment and size for type T is obtained..." A call to memcmp does not "obtain storage" and therefore cannot begin the lifetime of an object. More to the point, this is obviously wrong because the standard permits copying out the bytes of an object (it gives examples using memcpy in [basic.types]), and by your thesis, doing so would end the lifetime of the copied object. > the value representation of the X cannot be inspected > by memcmp, because X is not trivially copyable, and since the values are > indeterminate there is no requirement for the values written by the > destructor to be observable. I suppose. The storage itself can be inspected, though, per [basic.life]: "...after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that represents the address of the storage location... Indirection through such a pointer is permitted... when the conversion is to ... pointer to cv void and subsequently to pointer to ... cv unsigned char ...". Per [intro.execution], modifying an object is a side effect, and to me it is surprising that a compiler would choose to eliminate the effect of a side effect on storage when that effect would be observable, although I don't see the standard saying anything about how modifying objects affects their storage, so I suppose it may be permitted. As a matter of personal taste, I am extremely against a compiler eliminating code that a programmer has written unless the compiler can prove that the effects cannot be observed. I call this a fetish for optimizationism, a desire to make isolated code snippets faster by disregarding the intent of the programmer.
[Bug c/67882] surprising offsetof result on an invalid array member without diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67882
Martin Sebor changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Martin Sebor ---
The sentiment within WG14 about the question raised in comment #5 was that the
use case is invalid and the offsetof description makes it sufficiently clear.
In
struct s {
int fpr[32][1];
int fpscr;
};
offsetof(struct s, fpr[32][0])
the offsetof macro is specified to expand such that given
static struct s t;
the following evaluates to an integer constant:
&(t.fpr[32][0])
Since the t.fpr array has only 32 elements, a reference to t.fpr[32][0] is out
of bounds and thus undefined (there is no array fpr[32] and so no element 0 of
such an array). As a result, the full expression does not yield a valid
integer constant as required and a diagnostic is justified. With that I think
it's time to resolve this.
(Other questions were raised about offsetof in DR 496 but even those the
committee doesn't seem to be very interested in dealing with.)
[Bug c++/85470] [7/8 Regression] Strange error about "call to non-constexpr function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470
--- Comment #3 from Jakub Jelinek ---
--- gcc/cp/typeck2.c.jj 2018-04-19 15:57:36.765482568 +0200
+++ gcc/cp/typeck2.c2018-04-19 19:32:43.335986274 +0200
@@ -824,7 +824,9 @@ store_init_value (tree decl, tree init,
bool const_init;
value = fold_non_dependent_expr (value);
if (DECL_DECLARED_CONSTEXPR_P (decl)
- || (DECL_IN_AGGR_P (decl) && !DECL_VAR_DECLARED_INLINE_P (decl)))
+ || (DECL_CLASS_SCOPE_P (decl)
+ && DECL_INITIALIZED_IN_CLASS_P (decl)
+ && !DECL_VAR_DECLARED_INLINE_P (decl)))
{
/* Diagnose a non-constant initializer for constexpr. */
if (!require_constant_expression (value))
just changes the error, from
pr85470.C:13:75: error: call to non-‘constexpr’ function ‘static T&
StaticObject::create() [with T = int]’
to
pr85470.C:13:24: error: non-constant in-class initialization invalid for static
member ‘StaticObject::instance’
cpp0x/overflow1.C still PASSes.
[Bug other/50639] -flto=jobserver broken on large LTO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50639 --- Comment #4 from Andi Kleen --- I doubt it's fixed. It's a race so can be unstable. Especially since judging from the growing cc list other people keep seeing it It may not be something that gcc can fix, if anything it's more likely in make or in Linux.
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696 Martin Sebor changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Martin Sebor --- David, any thoughts/suggestions for how to improve things (taking into consideration comment #1)?
[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 85334, which changed state. Bug 85334 Summary: Shadow stack isn't unwound properly through signal handler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #4 from H.J. Lu --- Fixed for GCC 8.
[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 --- Comment #3 from hjl at gcc dot gnu.org --- Author: hjl Date: Thu Apr 19 17:05:39 2018 New Revision: 259502 URL: https://gcc.gnu.org/viewcvs?rev=259502&root=gcc&view=rev Log: libgcc/CET: Skip signal frames when unwinding shadow stack When -fcf-protection -mcet is used, I got FAIL: g++.dg/eh/sighandle.C (gdb) bt #0 _Unwind_RaiseException (exc=exc@entry=0x416ed0) at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:140 #1 0x77d9936b in __cxxabiv1::__cxa_throw (obj=, tinfo=0x403dd0 , dest=0x0) at /export/gnu/import/git/sources/gcc/libstdc++-v3/libsupc++/eh_throw.cc:90 #2 0x00401255 in sighandler (signo=11, si=0x7fffd6f8, uc=0x7fffd5c0) at /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:9 #3 Signal frame which isn't on shadow stack #4 dosegv () at /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:14 #5 0x004012e3 in main () at /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:30 (gdb) p frames $6 = 5 (gdb) frame count should be 4, not 5. This patch skips signal frames when unwinding shadow stack. gcc/testsuite/ PR libgcc/85334 * g++.dg/torture/pr85334.C: New test. libgcc/ PR libgcc/85334 * unwind-generic.h (_Unwind_Frames_Increment): New. * config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment): Likewise. * unwind.inc (_Unwind_RaiseException_Phase2): Increment frame count with _Unwind_Frames_Increment. (_Unwind_ForcedUnwind_Phase2): Likewise. Added: trunk/gcc/testsuite/g++.dg/torture/pr85334.C Modified: trunk/gcc/testsuite/ChangeLog trunk/libgcc/ChangeLog trunk/libgcc/config/i386/shadow-stack-unwind.h trunk/libgcc/unwind-generic.h trunk/libgcc/unwind.inc
[Bug c++/85464] [7 Regression] Wignored-qualifiers is emitted by cc1plus without diagnostics when triggered by a cast operator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85464 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Author: redi Date: Thu Apr 19 17:00:37 2018 New Revision: 259501 URL: https://gcc.gnu.org/viewcvs?rev=259501&root=gcc&view=rev Log: PR c++/85464 - missing location for -Wignored-qualifiers diagnostic * g++.dg/diagnostic/pr85464.C: New. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr85464.C Modified: trunk/gcc/testsuite/ChangeLog --- Comment #8 from Jonathan Wakely --- Fixed for 7.4
[Bug c++/85464] [7 Regression] Wignored-qualifiers is emitted by cc1plus without diagnostics when triggered by a cast operator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85464 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- Fixed for 7.4
[Bug c++/85464] [7 Regression] Wignored-qualifiers is emitted by cc1plus without diagnostics when triggered by a cast operator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85464 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Thu Apr 19 17:00:37 2018 New Revision: 259501 URL: https://gcc.gnu.org/viewcvs?rev=259501&root=gcc&view=rev Log: PR c++/85464 - missing location for -Wignored-qualifiers diagnostic * g++.dg/diagnostic/pr85464.C: New. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr85464.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-04-19 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Please provide a test case. https://gcc.gnu.org/bugs/
[Bug c++/85470] [7/8 Regression] Strange error about "call to non-constexpr function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-19 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- r200450 added - if (DECL_DECLARED_CONSTEXPR_P (decl)) + if (DECL_DECLARED_CONSTEXPR_P (decl) + || DECL_IN_AGGR_P (decl)) I wonder if it shouldn't have been DECL_INITIALIZED_IN_CLASS_P instead, or DECL_IN_AGGR_P (decl) && DECL_INITIALIZED_IN_CLASS_P (decl). If DECL_IN_AGGR_P (decl) check is right here, then the question is why it is set when there is the extern template line (and not otherwise).
[Bug c++/85471] New: closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471 Bug ID: 85471 Summary: closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT" Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aotto1...@t-online.de Target Milestone: --- Host: openSUSE 42.3 (x86_64) Target: openSUSE 42.3 (x86_64) Build: openSUSE 42.3 (x86_64) the c++ compiler I use: g++-7 (SUSE Linux) 7.3.1 20180307 [gcc-7-branch revision 258314] Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Problem === In one of my TEST-Cases… written for my own server-software… I close a (worker)-thread using the following code… > pthread_exit(NULL); in "C" this works fine… in "c++" I get the error from below… covered with "valgrind"… question: why I get this error in "system" code ==55315== ==55315== Process terminating with default action of signal 6 (SIGABRT) ==55315==at 0x58E7F67: raise (raise.c:55) ==55315==by 0x58E9339: abort (abort.c:78) ==55315==by 0x413FED: _Unwind_SetGR (unwind-dw2.c:273) ==55315==by 0x40763C: __gxx_personality_v0 (eh_personality.cc:712) ==55315==by 0x5FF04A4: _Unwind_ForcedUnwind_Phase2 (unwind.inc:175) ==55315==by 0x5FF0A64: _Unwind_ForcedUnwind (unwind.inc:207) ==55315==by 0x56A598F: __pthread_unwind (unwind.c:126) ==55315==by 0x569F8B4: __do_cancel (pthreadP.h:283) ==55315==by 0x569F8B4: pthread_exit (pthread_exit.c:28) ==55315==by 0x4E6AB00: libmsgque::SysExit(int, int) (sys.cc:935) ==55315==by 0x4E64E8C: libmsgque::MqSysExit(int, int) (msgque.h:5671) ==55315==by 0x4E65B05: libmsgque::MqExitP(libmsgque::MqS*, char const*, char const*) (msgque.cc:417) ==55315==by 0x404917: ccmsgque::MqC::Exit() (ccmsgque.h:409) ==55315== ==55315== HEAP SUMMARY: ==55315== in use at exit: 101,380 bytes in 63 blocks ==55315== total heap usage: 401 allocs, 338 frees, 493,733 bytes allocated ==55315== ==55315== LEAK SUMMARY: ==55315==definitely lost: 0 bytes in 0 blocks ==55315==indirectly lost: 0 bytes in 0 blocks ==55315== possibly lost: 320 bytes in 1 blocks ==55315==still reachable: 101,060 bytes in 62 blocks ==55315== suppressed: 0 bytes in 0 blocks ==55315== Rerun with --leak-check=full to see details of leaked memory ==55315== ==55315== For counts of detected and suppressed errors, rerun with: -v ==55315== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Abgebrochen (Speicherabzug geschrieben)
[Bug target/85198] long long int vector mistaken as long int vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85198 --- Comment #5 from Bill Schmidt --- OK, I see Jakub's point now. And this whole business is a big mess -- probably too late to change in 8, but we need to clean this up.
[Bug target/85397] -mcet -fcf-protection doesn't work with label in nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85397 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #6 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 85397, which changed state. Bug 85397 Summary: -mcet -fcf-protection doesn't work with label in nested function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85397 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/68450] regex matching different from ECMAScript?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68450 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.4 --- Comment #3 from Jonathan Wakely --- This seems to be fixed in GCC 4.9.4, 5.4, 6.1, and any later releases.
[Bug target/85397] -mcet -fcf-protection doesn't work with label in nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85397 --- Comment #5 from hjl at gcc dot gnu.org --- Author: hjl Date: Thu Apr 19 16:36:34 2018 New Revision: 259500 URL: https://gcc.gnu.org/viewcvs?rev=259500&root=gcc&view=rev Log: i386: Add save_stack_nonlocal and restore_stack_nonlocal Define STACK_SAVEAREA_MODE to hold both shadow stack and stack pointers. Replace builtin_setjmp_setup and builtin_longjmp with save_stack_nonlocal and restore_stack_nonlocal to support both builtin setjmp/longjmp as well as non-local goto in nested functions. gcc/ PR target/85397 * config/i386/i386.h (STACK_SAVEAREA_MODE): New. * config/i386/i386.md (builtin_setjmp_setup): Removed. (builtin_longjmp): Likewise. (save_stack_nonlocal): New pattern. (restore_stack_nonlocal): Likewise. gcc/testsuite/ PR target/85397 * gcc.dg/torture/pr85397-1.c: New test. * gcc.target/i386/cet-sjlj-6a.c: Adjusted. * gcc.target/i386/cet-sjlj-6b.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr85397-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c trunk/gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c
[Bug libstdc++/61424] std::regex matches right to left, not leftmost longest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61424 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #5 from Jonathan Wakely --- I think this was fixed for gcc 5.1
[Bug c++/85470] [7/8 Regression] Strange error about "call to non-constexpr function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org Target Milestone|--- |7.4 Summary|Strange error about "call |[7/8 Regression] Strange |to non-constexpr function" |error about "call to ||non-constexpr function" --- Comment #1 from Jakub Jelinek --- This is rejected starting with r242422.
[Bug middle-end/85450] ICE: invalid types in nop conversion during GIMPLE pass: ompexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85450
--- Comment #2 from Jakub Jelinek ---
There are 4 spots, unsigned_type_for breaks for-5.c though.
There are several other spots that do use signed_type_for instead, so following
works for the testsuite:
--- gcc/omp-expand.c.jj 2018-04-16 20:35:14.663558320 +0200
+++ gcc/omp-expand.c2018-04-19 17:14:13.267424165 +0200
@@ -3501,7 +3501,12 @@ expand_omp_for_static_nochunk (struct om
t = fold_convert (itype, s0);
t = fold_build2 (MULT_EXPR, itype, t, step);
if (POINTER_TYPE_P (type))
-t = fold_build_pointer_plus (n1, t);
+{
+ t = fold_build_pointer_plus (n1, t);
+ if (!POINTER_TYPE_P (TREE_TYPE (startvar))
+ && TYPE_PRECISION (TREE_TYPE (startvar)) > TYPE_PRECISION (type))
+ t = fold_convert (signed_type_for (type), t);
+}
else
t = fold_build2 (PLUS_EXPR, type, t, n1);
t = fold_convert (TREE_TYPE (startvar), t);
@@ -3515,7 +3520,12 @@ expand_omp_for_static_nochunk (struct om
t = fold_convert (itype, e0);
t = fold_build2 (MULT_EXPR, itype, t, step);
if (POINTER_TYPE_P (type))
-t = fold_build_pointer_plus (n1, t);
+{
+ t = fold_build_pointer_plus (n1, t);
+ if (!POINTER_TYPE_P (TREE_TYPE (startvar))
+ && TYPE_PRECISION (TREE_TYPE (startvar)) > TYPE_PRECISION (type))
+ t = fold_convert (signed_type_for (type), t);
+}
else
t = fold_build2 (PLUS_EXPR, type, t, n1);
t = fold_convert (TREE_TYPE (startvar), t);
@@ -4000,7 +4010,12 @@ expand_omp_for_static_chunk (struct omp_
t = fold_convert (itype, s0);
t = fold_build2 (MULT_EXPR, itype, t, step);
if (POINTER_TYPE_P (type))
-t = fold_build_pointer_plus (n1, t);
+{
+ t = fold_build_pointer_plus (n1, t);
+ if (!POINTER_TYPE_P (TREE_TYPE (startvar))
+ && TYPE_PRECISION (TREE_TYPE (startvar)) > TYPE_PRECISION (type))
+ t = fold_convert (signed_type_for (type), t);
+}
else
t = fold_build2 (PLUS_EXPR, type, t, n1);
t = fold_convert (TREE_TYPE (startvar), t);
@@ -4014,7 +4029,12 @@ expand_omp_for_static_chunk (struct omp_
t = fold_convert (itype, e0);
t = fold_build2 (MULT_EXPR, itype, t, step);
if (POINTER_TYPE_P (type))
-t = fold_build_pointer_plus (n1, t);
+{
+ t = fold_build_pointer_plus (n1, t);
+ if (!POINTER_TYPE_P (TREE_TYPE (startvar))
+ && TYPE_PRECISION (TREE_TYPE (startvar)) > TYPE_PRECISION (type))
+ t = fold_convert (signed_type_for (type), t);
+}
else
t = fold_build2 (PLUS_EXPR, type, t, n1);
t = fold_convert (TREE_TYPE (startvar), t);
Though, I think it would be better to replace most of the signed_type_for
related to pointer types to unsigned_type_for. Not something I have time for
right now though.
[Bug c++/85470] New: Strange error about "call to non-constexpr function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85470
Bug ID: 85470
Summary: Strange error about "call to non-constexpr function"
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: officesamurai at gmail dot com
Target Milestone: ---
GCC 7 fails to compile the following code:
test.cpp
template
struct StaticObject
{
static T& create()
{
static T t;
return t;
}
static T & instance;
};
template T & StaticObject::instance = StaticObject::create();
extern template class StaticObject;
void test()
{
StaticObject::instance;
}
command line -
$ g++-7.3.0 -v
Using built-in specs.
COLLECT_GCC=g++-7.3.0
COLLECT_LTO_WRAPPER=/home/brd/soft/gcc-7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/brd/soft/gcc-7.3.0
Thread model: posix
gcc version 7.3.0 (GCC)
$ g++-7.3.0 -c test.cpp
test.cpp: In instantiation of ‘int& StaticObject::instance’:
test.cpp:19:24: required from here
test.cpp:13:75: error: call to non-constexpr function ‘static T&
StaticObject::create() [with T = int]’
template T & StaticObject::instance = StaticObject::create();
P.S. I also tried 7.1 (same error) and 6.3 (no error)
[Bug target/85381] [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85381 --- Comment #8 from Tom de Vries --- (In reply to Tom de Vries from comment #6) > Created attachment 43992 [details] > tentative patch Tested libgomp on og7 build with quadro m1200, no issues found.
[Bug c++/85464] [7 Regression] Wignored-qualifiers is emitted by cc1plus without diagnostics when triggered by a cast operator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85464 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Thu Apr 19 15:29:03 2018 New Revision: 259499 URL: https://gcc.gnu.org/viewcvs?rev=259499&root=gcc&view=rev Log: PR c++/85464 - missing location for -Wignored-qualifiers diagnostic The fix for PR c++/69733 caused a regression for conversion operators with redundant cv-qualifiers, changing an incorrect location to an unknown location. This restores it to the incorrect location (as was already done on trunk by the fix for PR c++/65775). gcc/cp: PR c++/85464 - missing location for -Wignored-qualifiers diagnostic * decl.c (grokdeclarator): If declspecs->locations[ds_type_spec] is UNKNOWN_LOCATION fall back to input_location. gcc/testsuite: PR c++/85464 - missing location for -Wignored-qualifiers diagnostic * g++.dg/diagnostic/pr85464.C: New. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/diagnostic/pr85464.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/decl.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/69733] -Wignored-qualifiers points to wrong const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69733 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Thu Apr 19 15:29:03 2018 New Revision: 259499 URL: https://gcc.gnu.org/viewcvs?rev=259499&root=gcc&view=rev Log: PR c++/85464 - missing location for -Wignored-qualifiers diagnostic The fix for PR c++/69733 caused a regression for conversion operators with redundant cv-qualifiers, changing an incorrect location to an unknown location. This restores it to the incorrect location (as was already done on trunk by the fix for PR c++/65775). gcc/cp: PR c++/85464 - missing location for -Wignored-qualifiers diagnostic * decl.c (grokdeclarator): If declspecs->locations[ds_type_spec] is UNKNOWN_LOCATION fall back to input_location. gcc/testsuite: PR c++/85464 - missing location for -Wignored-qualifiers diagnostic * g++.dg/diagnostic/pr85464.C: New. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/diagnostic/pr85464.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/decl.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/65775] Late-specified return type bypasses return type checks (qualified, function, array)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65775 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Thu Apr 19 15:29:03 2018 New Revision: 259499 URL: https://gcc.gnu.org/viewcvs?rev=259499&root=gcc&view=rev Log: PR c++/85464 - missing location for -Wignored-qualifiers diagnostic The fix for PR c++/69733 caused a regression for conversion operators with redundant cv-qualifiers, changing an incorrect location to an unknown location. This restores it to the incorrect location (as was already done on trunk by the fix for PR c++/65775). gcc/cp: PR c++/85464 - missing location for -Wignored-qualifiers diagnostic * decl.c (grokdeclarator): If declspecs->locations[ds_type_spec] is UNKNOWN_LOCATION fall back to input_location. gcc/testsuite: PR c++/85464 - missing location for -Wignored-qualifiers diagnostic * g++.dg/diagnostic/pr85464.C: New. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/diagnostic/pr85464.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/decl.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[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 85417, which changed state. Bug 85417 Summary: -fcf-protection should provide CET protection on x86 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85417 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/85417] -fcf-protection should provide CET protection on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85417 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from H.J. Lu --- Fixed for GCC 8.
[Bug target/85404] -fcf-protection -mcet doesn't work with -fleading-underscore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85404 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #3 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 85404, which changed state. Bug 85404 Summary: -fcf-protection -mcet doesn't work with -fleading-underscore https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85404 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[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 85379, which changed state. Bug 85379 Summary: Missing ENDBR in __stack_split_initialize https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85379 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libgcc/85379] Missing ENDBR in __stack_split_initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85379 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #2 from H.J. Lu --- Fixed for GCC 8.
[Bug target/85404] -fcf-protection -mcet doesn't work with -fleading-underscore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85404 --- Comment #2 from hjl at gcc dot gnu.org --- Author: hjl Date: Thu Apr 19 15:24:53 2018 New Revision: 259498 URL: https://gcc.gnu.org/viewcvs?rev=259498&root=gcc&view=rev Log: x86/cet: Properly output labels in property note section Replace ASM_OUTPUT_LABEL with fprintf so that internal labels in property note section are unchanged by -fleading-underscore. gcc/ PR target/85404 * config/i386/cet.c (file_end_indicate_exec_stack_and_cet): Replace ASM_OUTPUT_LABEL with fprintf. gcc/testsuite/ PR target/85404 * gcc.target/i386/pr85404.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr85404.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cet.c trunk/gcc/testsuite/ChangeLog
[Bug libgcc/85379] Missing ENDBR in __stack_split_initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85379 --- Comment #1 from hjl at gcc dot gnu.org --- Author: hjl Date: Thu Apr 19 15:22:27 2018 New Revision: 259497 URL: https://gcc.gnu.org/viewcvs?rev=259497&root=gcc&view=rev Log: libgcc/CET: Add _CET_ENDBR to __stack_split_initialize Program received signal SIGSEGV, Segmentation fault. __stack_split_initialize () at /export/gnu/import/git/sources/gcc/libgcc/config/i386/morestack.S:751 751 leaq-16000(%rsp),%rax # We should have at least 16K. Missing separate debuginfos, use: dnf debuginfo-install libgcc-8.0.1-0.21.0.fc28.x86_64 (gdb) disass Dump of assembler code for function __stack_split_initialize: => 0x00402858 <+0>: lea-0x3e80(%rsp),%rax 0x00402860 <+8>: mov%rax,%fs:0x70 0x00402869 <+17>:sub$0x8,%rsp 0x0040286d <+21>:mov%rsp,%rdi 0x00402870 <+24>:mov$0x3e80,%esi 0x00402875 <+29>:callq 0x401810 <__generic_morestack_set_initial_sp> 0x0040287a <+34>:add$0x8,%rsp 0x0040287e <+38>:retq End of assembler dump. (gdb) This patch adds the missing ENDBR to __stack_split_initialize. PR libgcc/85379 * config/i386/morestack.S (__stack_split_initialize): Add _CET_ENDBR. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/i386/morestack.S
[Bug target/85469] New: -mibt is unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85469 Bug ID: 85469 Summary: -mibt is unused Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: igor.v.tsimbalist at intel dot com Blocks: 81652 Target Milestone: --- Target: x86_64-*-*, i?86-*-* With r259496, now -mibt does nothing and should be removed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 [Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs
[Bug target/85417] -fcf-protection should provide CET protection on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85417 --- Comment #6 from hjl at gcc dot gnu.org --- Author: hjl Date: Thu Apr 19 15:15:04 2018 New Revision: 259496 URL: https://gcc.gnu.org/viewcvs?rev=259496&root=gcc&view=rev Log: x86: Enable -fcf-protection with multi-byte NOPs -fcf-protection -mcet can't be used with IFUNC features, like symbol multiversioning or target clone, since IBT/SHSTK are applied to the whole program and they may be disabled in some functions. But -fcf-protection is implemented with multi-byte NOPs on all 64-bit processors as well as 32-bit processors starting with Pentium Pro. If -fcf-protection requires -mcet, IFUNC features can't be used on Linux when -fcf-protection is enabled by default. This patch changes -fcf-protection to implement indirect branch and return address tracking with multi-byte NOPs. -mibt and -mshstk are changed to only enable CET built-in functions. CET tests are updated to allow -fcf-protection without -mibt, -mshstk and -mcet on x86. -fcf-protection=none are also added to tests which fail with -fcf-protection so that -fcf-protection can be added to RUNTESTFLAGS to verify -fcf-protection implementation. gcc/ PR target/85417 * config/i386/cet.c (file_end_indicate_exec_stack_and_cet): Check flag_cf_protection instead of TARGET_IBT and TARGET_SHSTK. * config/i386/i386-c.c (ix86_target_macros_internal): Also define __IBT__ and __SHSTK__ for -fcf-protection. * config/i386/i386.c (pass_insert_endbranch::gate): Don't check TARGET_IBT. (ix86_trampoline_init): Likewise. (x86_output_mi_thunk): Likewise. (ix86_notrack_prefixed_insn_p): Likewise. (ix86_option_override_internal): Don't disallow -fcf-protection. * config/i386/i386.md (rdssp): Also enable for -fcf-protection. (incssp): Likewise. (nop_endbr): Likewise. * config/i386/i386.opt (mcet): Change help message to built-in functions only. (mibt): Likewise. (mshstk): Likewise. * doc/invoke.texi: Remove -mcet, -mibt and -mshstk condition on -fcf-protection. Change -mcet, -mibt and -mshstk to only enable CET built-in functions. gcc/testsuite/ PR target/85417 * c-c++-common/attr-nocf-check-1.c: Compile with -fcf-protection=none. * c-c++-common/attr-nocf-check-3.c: Likewise. * gcc.dg/march-generic.c: Likewise. * gcc.target/i386/align-limit.c: Likewise. * gcc.target/i386/cet-notrack-icf-1.c: Likewise. * gcc.target/i386/cet-notrack-icf-3.c: Likewise. * gcc.target/i386/cet-property-2.c: Likewise. * gcc.target/i386/ret-thunk-26.c: Likewise. * c-c++-common/fcf-protection-1.c: Remove dg-error for x86 targets. * c-c++-common/fcf-protection-2.c: Likewise. * c-c++-common/fcf-protection-3.c: Likewise. * c-c++-common/fcf-protection-5.c: Likewise. * c-c++-common/fcf-protection-6.c: Likewise. * c-c++-common/fcf-protection-7.c: Likewise. * gcc.target/i386/cet-label-3.c: New test. * gcc.target/i386/cet-property-3.c: Likewise. * gcc.target/i386/cet-sjlj-7.c: Likewise. * gcc.target/i386/pr85417-1.c: Likewise. * gcc.target/i386/indirect-thunk-attr-7.c: Also expect __x86_indirect_thunk_nt_(r|e)ax * gcc.target/i386/indirect-thunk-extern-7.c: Likewise. * gcc.target/i386/pr85403.c: Remove dg-error, Added: trunk/gcc/testsuite/gcc.target/i386/cet-label-3.c trunk/gcc/testsuite/gcc.target/i386/cet-property-3.c trunk/gcc/testsuite/gcc.target/i386/cet-sjlj-7.c trunk/gcc/testsuite/gcc.target/i386/pr85417-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cet.c trunk/gcc/config/i386/i386-c.c trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/i386.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attr-nocf-check-1.c trunk/gcc/testsuite/c-c++-common/attr-nocf-check-3.c trunk/gcc/testsuite/c-c++-common/fcf-protection-1.c trunk/gcc/testsuite/c-c++-common/fcf-protection-2.c trunk/gcc/testsuite/c-c++-common/fcf-protection-3.c trunk/gcc/testsuite/c-c++-common/fcf-protection-5.c trunk/gcc/testsuite/c-c++-common/fcf-protection-6.c trunk/gcc/testsuite/c-c++-common/fcf-protection-7.c trunk/gcc/testsuite/gcc.dg/march-generic.c trunk/gcc/testsuite/gcc.target/i386/align-limit.c trunk/gcc/testsuite/gcc.target/i386/cet-notrack-icf-1.c trunk/gcc/testsuite/gcc.target/i386/cet-notrack-icf-3.c trunk/gcc/testsuite/gcc.target/i386/cet-property-2.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c trunk/gcc/testsuite/gcc.target/i386/pr85403.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-26.c
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #47 from Segher Boessenkool --- (In reply to Eric Botcazou from comment #35) > > A port does not need maintenance only for that port, and its users, but also > > for GCC itself. All ports are a cost to _all_ GCC developers. If a port is > > not maintained it has to be removed. > > Do you IBM guys have a hidden agenda to bury the left-overs of Freescale? ;-) > > The SPE port has already been moved out of the way so I don't really see the > point in further hammering it like that; there are plenty of obsolete ports > in the tree that would have to removed before this one if the above > criterion was followed to the letter. This is not about IBM. Believe it or not, but the rs6000 port maintainers *care* about older systems. I wanted to obsolete SPE support because it is a big burden, not in small part because no one maintains it. This has been going on for years and years. Big pushback; people still want SPE, they just don't want to spend work on it. Well neither do we, it's been enough. So I spent a week splitting off the port (also tested removing VSX etc.; removing unused code does not take that long; I just have no way to *test* it so that was not included). It was agreed the powerpcspe port would be maintained or it would be removed. Now a year later GCC 8 is on the horizon, and the powerpcspe port is still not maintained. And the RMs decided to give it *another* year: it is not removed but merely obsoleted.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #31 from James Kuyper Jr. --- (In reply to rguent...@suse.de from comment #29) > On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote: ... > > The relevant wording is "anywhere that a declaration of the completed type > > of > > the union is visible.", so it's unambiguously the type, not the object, > > which > > must be visible. A declaration of the completed type can be visible without > > any > > objects of that type being visible, and that's sufficient for this rule to > > apply. > > > > > ... Must the access be performed > > > using the union object, or just the union type, or neither? > > > > It says only that "it is permitted to inspect the common initial part"; it > > imposes no restrictions on how the inspection may be performed. Clearly, > > inspection through an lvalue of the union's type must be permitted, but it > > is > > also permitted to use the more indirect methods which are the subject of > > this > > bug report, simply because the standard says nothing to restrict the > > permission > > it grants to the more direct cases. > > Note I repeatedly said this part of the standard is just stupid. As a judgement call, I reserve the right to disagree with you on that point, particularly if that judgement was based primarily on the following misconception: > ... It makes > most if not all type-based alias analysis useless. How could that be true? It only applies to pairs of struct types that are the types of members of the same union, it only applies within the scope of a completed definition of that union's type, and it doesn't apply if the implementation can prove to itself that the two objects in question are not actually members of the same union object. It seems to me that the need to take this rule into consideration would come up pretty infrequently. Code which relies upon this feature to implement a C-style approximation to inheritance has been fairly common, which is precisely why the C committee decided to create this rule, to make sure such code had well-defined behavior. > Which means I'll refuse any patches implementing it in a way that affects > default behavior. A clean patch (I really can't think of any clean > approach besides forcing -fno-strict-aliasing!) with some extra flag > (well, just use -fno-strict-aliasing ...) would be fine with me. I can understanding not making this the default behavior if you feel that way; I only use gcc in fully standard-conforming mode, anyway, so that doesn't matter to me. However, personally, I would prefer it if gcc's fully-conforming mode took full advantage of all the optimization opportunities legitimately enabled by 6.5p7 (which does not include opportunities revoked by 6.5.2.3p6).
[Bug fortran/85448] the compiler selects the wrong subroutine because of bind(c,name=...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|RESOLVED|REOPENED Last reconfirmed||2018-04-19 CC|kargl at gcc dot gnu.org | Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #6 from kargl at gcc dot gnu.org --- Re-open. Remove my email address. Let someone else deal with the problem.
[Bug fortran/85448] the compiler selects the wrong subroutine because of bind(c,name=...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448 --- Comment #5 from francois.jacq at irsn dot fr --- On Thursday 19 April 2018 16:30:09 you wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448 > > --- Comment #4 from Steve Kargl > --- > > On Thu, Apr 19, 2018 at 09:07:15AM +, francois.jacq at irsn dot fr wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448 > > > > --- Comment #3 from francois.jacq at irsn dot fr --- > > Notice that this is a regression : The version 4.8.5 returns the result I > > expected... > > Or it was a bug in 4.8.5 and is now fixed. > > Now, the version where you rename odopen from m1 > to odopen_m1 is probably a bug. No : both are bugs (and probably identical). The bind clause cannot change how the procedure name "odopen" has to be considered from the Fortran side ! Intel, Oracle and Nag compilers agree with me.
[Bug target/85381] [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85381
--- Comment #7 from Tom de Vries ---
For this example:
...
#define n 1024
int
main (void)
{
#pragma acc parallel vector_length(128)
{
#pragma acc loop vector
for (int i = 0; i < n; i++)
;
#pragma acc loop vector
for (int i = 0; i < n; i++)
;
}
return 0;
}
...
we currently generate:
...
.entry main$_omp_fn$0
{
.reg.u64 %r24;
.reg.u64 %r25;
.reg.u64 %r26;
.reg.u64 %r27;
.reg.pred %r28;
{
.reg.u32%x;
mov.u32 %x, %tid.x;
setp.ne.u32 %r28, %x, 0;
}
bar.sync0;
@%r28 bra $L2;
// join 4;
// fork 4;
$L2:
bar.sync0;
ret;
}
...
so if we fix the branch around nothing problem here, we'll get back-to-back
bar.syncs again, and may run into the JIT but again.
We may wanna insert dummy ops inbetween (it would be nice if something less
heavy than a membar.cta will work).
[Bug target/85198] long long int vector mistaken as long int vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85198 --- Comment #4 from Bill Schmidt --- Ah, but vulli does have the wrong element type, when you get a little deeper. V2DI size unit-size align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x3fffb5bc5dd8 nunits:2> public static common V2DI defer-output pr85198-2.c:3:22 size unit-size align:128 warn_if_not_align:0>>
[Bug fortran/85448] the compiler selects the wrong subroutine because of bind(c,name=...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448 --- Comment #4 from Steve Kargl --- On Thu, Apr 19, 2018 at 09:07:15AM +, francois.jacq at irsn dot fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448 > > --- Comment #3 from francois.jacq at irsn dot fr --- > Notice that this is a regression : The version 4.8.5 returns the result I > expected... > Or it was a bug in 4.8.5 and is now fixed. Now, the version where you rename odopen from m1 to odopen_m1 is probably a bug.
[Bug target/85381] [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85381
--- Comment #6 from Tom de Vries ---
Created attachment 43992
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43992&action=edit
tentative patch
(In reply to Tom de Vries from comment #4)
> This looks like a JIT bug, but with this tentative patch:
> ...
> diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
> index 8c478c874bd..ac394ee1ae6 100644
> --- a/gcc/config/nvptx/nvptx.c
> +++ b/gcc/config/nvptx/nvptx.c
> @@ -4479,7 +4479,7 @@ nvptx_process_pars (parallel *par)
> threads = nvptx_mach_vector_length ();
> }
>
> - if (!empty || !is_call)
> + if (!(empty || is_call))
> {
> /* Insert begin and end synchronizations. */
> emit_insn_before (nvptx_cta_sync (barrier, threads),
> ...
> no barriers are generated, and the minimized testcase passes.
Actually, this was a bit more complicated than that.
The condition correctly identifies the situation of a call and no state
propagation as not needing barriers.
But in the case of not a call (so, fork/join), even if there's no state
propagation, we need synchronization at the end of worker and vector loops.
[ More precisely, we need it inbetween loops, but we're currently not detecting
that situation.
And even more precisely, we need it inbetween dependent loops, but we also
currently not detecting that situation. ]
This patch skips the first of the bar.syncs, keeping the one after the loop,
and that allows parallel-loop-1.c to pass with vector length 128.
[Bug rtl-optimization/85455] [8 Regression] ICE in verify_loop_structure, at cfgloop.c:1708 (error: basic block 3 should be marked irreducible)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85455 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #46 from David Edelsohn --- I understand the issues with Golang and have been raising the issue internally.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #45 from John Paul Adrian Glaubitz --- (In reply to Jakub Jelinek from comment #42) > See e.g. https://gcc.gnu.org/onlinedocs/gccint/ > https://gcc.gnu.org/onlinedocs/gccint/#toc-RTL-Representation > https://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html#Machine-Desc > https://kristerw.blogspot.cz/2017/08/writing-gcc-backend_4.html > and many others. Thank you. > Don't really know how is writing a new backend relevant to > maintaining an existing one. Well, I guess there is no documentation "How to fix an unmaintained target and bring it back into shape.", is there? Documenation which explains how to write a backend should also help fixing an existing one.
[Bug libstdc++/85466] Performance is slow when doing 'branchless' conditional style math operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466 --- Comment #13 from rguenther at suse dot de --- On Thu, 19 Apr 2018, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466 > > --- Comment #12 from Marc Glisse --- > Constant folding for nextafter seems like a useful thing to add, whatever we > say about the rest of the testcase. Indeed - looks like this and related functions are not constant folded for whatever reason...
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #44 from John Paul Adrian Glaubitz --- (In reply to David Edelsohn from comment #41) > SPE mostly is a separate architecture that happens to share many of the > basic mnemonics with PowerPC. Maintaining the SPE port was a burden to the > Power/PowerPC maintainers. As discussed in the other threads, despite years > of promises, the SPE port was not maintained, not even regular testsuite > results. The communication mostly consisted of bug reports raised a year > after the patch or release. Those are apparent mistakes made in the past. I am happy to provide testsuite results starting next week. As I said, gcc-8 is stable at the moment on real PowerPCSPE hardware. > In regard to IBM employee response to PowerPC targets older than Power8, you > said yourself that these are IBM employees. They are directed to work on > specific projects and patches. Sometimes IBM developers can become too > focused on the Power8 and later issue and include portability in their > design, but IBM also is not a general support center for all PowerPC. IBM is > a business. As with all commercially-supported Open Source projects and all > forms of work in general, some developers have broader interest in the > project and others approach it as a job. I understand how that works. No one is actually asking IBM people to fix anything if they don't want to. But I have a problem with people removing working code that people are using and then dismissing it with answers like the one I received. It would be different if project X belongs to IBM. One of such examples was that POWER5 support was forcefully removed by IBM people from Golang. They claimed that this move was urgently necessary to reduce maintenance burden. Yet all that was needed to get Golang working again on POWER5 was to revert three patches and slightly modify them. I am still rebasing it regularly without any problems.
[Bug objc/53905] -Wformat-nonliteral gives false positives with __attribute__((format(NSString,...)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53905 Eric Gallager changed: What|Removed |Added CC||iains at gcc dot gnu.org, ||mikestump at comcast dot net --- Comment #3 from Eric Gallager --- Adding objc maintainers on cc
[Bug libstdc++/85466] Performance is slow when doing 'branchless' conditional style math operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466 --- Comment #12 from Marc Glisse --- Constant folding for nextafter seems like a useful thing to add, whatever we say about the rest of the testcase.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #43 from rguenther at suse dot de --- On Thu, 19 Apr 2018, glaubitz at physik dot fu-berlin.de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 > > --- Comment #40 from John Paul Adrian Glaubitz fu-berlin.de> --- > Is there documentation like this for gcc? > > > https://llvm.org/docs/WritingAnLLVMBackend.html > > Would be very useful for people wanting to help with the old backends. The wiki has some material, a quick search finds https://gcc.gnu.org/wiki/WritingANewBackEnd not sure how useful or up-to-date it is.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #30 from Martin Sebor --- Richard, I offered to write a proposal (with Clark) to improve the rules. With the object model proposals already in the pipeline (N2223) this is a good time to review them and see if it makes sense to extend or change them to also cover this case in an acceptable way. It would be helpful if you could take some time to summarize your main concerns or suggestions for changes in this area. I can start working on the proposal for the fall 2018 WG14 meeting.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #42 from Jakub Jelinek --- See e.g. https://gcc.gnu.org/onlinedocs/gccint/ https://gcc.gnu.org/onlinedocs/gccint/#toc-RTL-Representation https://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html#Machine-Desc https://kristerw.blogspot.cz/2017/08/writing-gcc-backend_4.html and many others. Don't really know how is writing a new backend relevant to maintaining an existing one.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #41 from David Edelsohn --- SPE mostly is a separate architecture that happens to share many of the basic mnemonics with PowerPC. Maintaining the SPE port was a burden to the Power/PowerPC maintainers. As discussed in the other threads, despite years of promises, the SPE port was not maintained, not even regular testsuite results. The communication mostly consisted of bug reports raised a year after the patch or release. In regard to IBM employee response to PowerPC targets older than Power8, you said yourself that these are IBM employees. They are directed to work on specific projects and patches. Sometimes IBM developers can become too focused on the Power8 and later issue and include portability in their design, but IBM also is not a general support center for all PowerPC. IBM is a business. As with all commercially-supported Open Source projects and all forms of work in general, some developers have broader interest in the project and others approach it as a job.
[Bug objc/50909] Process "#pragma options align=reset" correctly on Mac OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50909 Eric Gallager changed: What|Removed |Added CC||iains at gcc dot gnu.org, ||mikestump at comcast dot net --- Comment #11 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #9) > (In reply to Alex from comment #8) > > As to someone implementing clang behavior: I was under the impression that > > the attached patch just needed to be applied? That is why I was inquiring as > > to why nobody had applied it after 3 years. > > Writing a patch is often the easy part. The hard part is getting the patch > approved and following up on reviewer's comments. See > https://gcc.gnu.org/contribute.html and https://gcc.gnu.org/wiki/GCC_Research > > The patch doesn't look correct to me anyway, but you will get a better > review from a Darwin maintainer, see the MAINTAINERS file in the gcc sources. Adding them on cc (Only Mike is currently listed as a Darwin maintainer, but IMO Iain ought to be listed as one, too)
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #40 from John Paul Adrian Glaubitz --- Is there documentation like this for gcc? > https://llvm.org/docs/WritingAnLLVMBackend.html Would be very useful for people wanting to help with the old backends.
[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81307 --- Comment #9 from Martin Liška --- Thanks Jakub, I can confirm I don't see any other UBSANs related to gstabs in the test-suite.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #39 from John Paul Adrian Glaubitz --- (In reply to Jakub Jelinek from comment #37) > Not sure about IBM, I as a GCC developer and RM have major problem with the > amount of dead code in the port, because anyone who makes changes to the > middle-end that need backend changes will waste time adjusting code that is > dead and can't be really tested (all the Altivec/VMX code, all the 64-bit > support in there, all the power6/7/8/9, all the floating point modes stuff, > etc.). It's not a waste of time if people are actually still using the code which is the case for both PowerPCSPE and m68k. I don't understand why some people think it's acceptable to kill open source stuff that is actively being used by others. > Furthermore the lack of -mno-lra removal in it. If somebody is > willing to change all backends rather than waiting on target maintainers to > fix stuff up, at least the work should not be wasted on dead code. Just > look e.g. how many times in the last year Richard Sandiford modified this > dead code in config/powerpcspe. That is pretty much all wasted effort > (others too). I think your problem lies in the fact that you are solely seeing this from the gcc maintainers perspective (which I cannot blame you for and which is not surprising). However, you have to keep in mind that - in the end - gcc is a product that people are using for productive work. So, there has to be a balance between the objective quality of the code and the usefulness of the project. If I understand Eric correctly, the PowerPCSPE backend has been split off from the other PPC code so as long as the code works and people are using it (and with someone even working on updating it), why the hurry to remove it?
[Bug rtl-optimization/85455] [8 Regression] ICE in verify_loop_structure, at cfgloop.c:1708 (error: basic block 3 should be marked irreducible)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85455 --- Comment #3 from Richard Biener --- Author: rguenth Date: Thu Apr 19 13:53:06 2018 New Revision: 259494 URL: https://gcc.gnu.org/viewcvs?rev=259494&root=gcc&view=rev Log: 2018-04-19 Richard Biener PR middle-end/85455 * cfg.c (clear_bb_flags): When loop state says we have marked irreducible regions also preserve BB_IRREDUCIBLE_LOOP. * gcc.dg/pr85455.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr85455.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfg.c trunk/gcc/testsuite/ChangeLog
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #38 from John Paul Adrian Glaubitz --- (In reply to Eric Botcazou from comment #35) > Do you IBM guys have a hidden agenda to bury the left-overs of Freescale? ;-) I thought Jakub works for RedHat? > The SPE port has already been moved out of the way so I don't really see the > point in further hammering it like that; there are plenty of obsolete ports > in the tree that would have to removed before this one if the above > criterion was followed to the letter. To be honest: I made this experience already in multiple projects. IBM employees have been quite unfriendly towards PPC targets which were not POWER8 or newer. The answer was usually "Anything lower than POWER8 is no longer supported." talking as if the project in question belongs to IBM. Quite frustrating.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #37 from Jakub Jelinek --- Not sure about IBM, I as a GCC developer and RM have major problem with the amount of dead code in the port, because anyone who makes changes to the middle-end that need backend changes will waste time adjusting code that is dead and can't be really tested (all the Altivec/VMX code, all the 64-bit support in there, all the power6/7/8/9, all the floating point modes stuff, etc.). Furthermore the lack of -mno-lra removal in it. If somebody is willing to change all backends rather than waiting on target maintainers to fix stuff up, at least the work should not be wasted on dead code. Just look e.g. how many times in the last year Richard Sandiford modified this dead code in config/powerpcspe. That is pretty much all wasted effort (others too).
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #36 from John Paul Adrian Glaubitz --- (In reply to Jakub Jelinek from comment #33) > Yes, but the port split was done in May last year, and nothing substantial > happened since then. Port maintainance is not about promises, but about > doing the work. If he does the work soon, the port can be de-obsoleted in > GCC9, otherwise it will be removed, which doesn't mean it can't be added at > some point later. Of course, the later it will be done, the harder it will > be. He is working on it and people are using it. It's not surprising that it takes longer than any work done by paid developers on the x86 or POWER targets. > > > m68k needs some serious work, too, in the not far future (if the cc0 > > > removal > > > finally goes through -- that has been over ten years now). > > > > Yes, I am aware of that. But there are enough people interested in such work > > so I think we will be able get around doing that at some point. > > Nobody did the work in the last 15+ years for m68k, it doesn't seem likely > that all of sudden it will happen. There have been numerous posts about > what to do to get rid of cc0, e.g. in 2005 and several other years. > See https://gcc.gnu.org/backends.html for details, a healthy port doesn't > have > c (cc0), p (not using define_peephole2), has a (uses LRA). We can't > maintain old reload, or cc0 support indefinitely. I have been doing some research yesterday myself and couldn't find a page which documents on how to write a port. I couldn't even find documentation on the cc0 stuff. > > > A port does not need maintenance only for that port, and its users, but > > > also > > > for GCC itself. All ports are a cost to _all_ GCC developers. If a port > > > is > > > not maintained it has to be removed. > > > > So, again my question is: What exactly is the with the powerpcspe target at > > the moment and why does upstream claim the port is broken when it apparently > > works for us in Debian? Am I missing something? > > Have you read all the threads mentioned in > https://gcc.gnu.org/ml/gcc/2018-04/msg00102.html > and all the above comments? All the details are in there. Could you please just mention issue in question that causes trouble? The messages directly linked only mention PR81084 but I haven't run into this issue myself. Again, could you please mention an urgent issue with the powerpcspe target that causes serious issues for other users or developers? Thanks!
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #35 from Eric Botcazou --- > A port does not need maintenance only for that port, and its users, but also > for GCC itself. All ports are a cost to _all_ GCC developers. If a port is > not maintained it has to be removed. Do you IBM guys have a hidden agenda to bury the left-overs of Freescale? ;-) The SPE port has already been moved out of the way so I don't really see the point in further hammering it like that; there are plenty of obsolete ports in the tree that would have to removed before this one if the above criterion was followed to the letter.
[Bug c++/85464] [7 Regression] Wignored-qualifiers is emitted by cc1plus without diagnostics when triggered by a cast operator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85464 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #5 from Jonathan Wakely --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00951.html I've created PR 85468 for the wrong location, so this one is just about the regression in gcc-7-branch.
[Bug c++/85468] New: Wrong location for -Wignored-qualifiers diagnostic on conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85468
Bug ID: 85468
Summary: Wrong location for -Wignored-qualifiers diagnostic on
conversion operator
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
struct Test {
operator int const() const; // { dg-error "type qualifiers ignored" }
};
ign.cc:2:25: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
operator int const() const; // { dg-error "type qualifiers ignored" }
^
The location should point to the first const.
This is the subject of PR 69733 but that fix didn't cover conversion operators.
[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84737 --- Comment #20 from Pat Haugen --- (In reply to Richard Biener from comment #18) > Fixed (hopefully). Yes, mgrid performance is back. Thanks.
[Bug rtl-optimization/85455] [8 Regression] ICE in verify_loop_structure, at cfgloop.c:1708 (error: basic block 3 should be marked irreducible)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85455 Richard Biener changed: What|Removed |Added Keywords||ice-checking --- Comment #2 from Richard Biener --- patch posted
[Bug tree-optimization/85467] [8 Regression] ICE: verify_gimple failed: non-trivial conversion at assignment with -O2 -fno-tree-ccp --param=sccvn-max-scc-size=10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85467 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 43991 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43991&action=edit gcc8-pr85467.patch fold-const.c this time. Untested patch.
