[Bug debug/82144] [8 Regression] ICE in add_dwarf_attr with alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82144 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Sep 25 07:25:31 2017 New Revision: 253134 URL: https://gcc.gnu.org/viewcvs?rev=253134&root=gcc&view=rev Log: 2017-09-25 Richard Biener PR middle-end/82144 * dwarf2out.c (gen_enumeration_type_die): Do not add alignment attribute for incomplete types nor twice for complete ones. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug ipa/82278] [8 regression] gcc.dg/lto/chkp-ctor-merge fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82278
Martin Liška changed:
What|Removed |Added
CC||hubicka at ucw dot cz,
||rguenth at gcc dot gnu.org
--- Comment #3 from Martin Liška ---
So it's caused by r251333, where we try to redirect following callee:
Z5ctor2v.chkp/14 (ctor2.chkp) @0x13f4e170
Type: function definition analyzed
Visibility: artificial
References: glob/0 (read)glob/0 (write)
Referring:
Read from file: /tmp/ccsHDute.ltrans0.o
Function ctor2.chkp/14 is inline copy in
_GLOBAL__I_65535_0_chkp_ctor_merge_0.o/13
Availability: local
First run: 0
Function flags: local only_called_at_startup nonfreeing_fn executed_once
only_called_at_startup
Called by: _GLOBAL__I_65535_0_chkp_ctor_merge_0.o/13 (inlined) (1.00 per
call)
Calls:
Before the patch it was:
_Z5ctor2v.chkp/5 (ctor2.chkp) @0x13f4e450
Type: function definition analyzed
Visibility: prevailing_def_ironly asm_written artificial
References:
Referring: _Z5ctor2v/2 (chkp)
Availability: available
First run: 0
Function flags: only_called_at_startup nonfreeing_fn executed_once
only_called_at_startup
Called by: ctor2/2 (1.00 per call) _GLOBAL__I_65535_0_chkp_ctor_merge_0.o/13
(1.00 per call)
Calls:
Is instrumented version.
Anyway, it's probably for someone how is skilled in MPX. But as I'm reading the
change in r251333, it's very similar
to what I tried here:
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00926.html
and Honza had problem to select target_option_default_node as it's problematic
for LTO.
Anyway the test-case for PR71991 is currently rejected both w/ and w/o LTO:
$ cat /tmp/inline.c
static inline int __attribute__ ((__always_inline__)) fn1 () { return 0; }
static inline int __attribute__ ((target("inline-all-stringops"))) fn2 () {
return fn1 (); }
int main()
{
return fn2();
}
$ ./xgcc -B. /tmp/inline.c -O2 -flto
/tmp/inline.c: In function ‘fn2’:
/tmp/inline.c:1:55: error: inlining failed in call to always_inline ‘fn1’:
target specific option mismatch
static inline int __attribute__ ((__always_inline__)) fn1 () { return 0; }
^~~
/tmp/inline.c:2:84: note: called from here
static inline int __attribute__ ((target("inline-all-stringops"))) fn2 () {
return fn1 (); }
^~
$ ./xgcc -B. /tmp/inline.c -O2
/tmp/inline.c: In function ‘fn2’:
/tmp/inline.c:1:55: error: inlining failed in call to always_inline ‘fn1’:
target specific option mismatch
static inline int __attribute__ ((__always_inline__)) fn1 () { return 0; }
^~~
/tmp/inline.c:2:84: note: called from here
static inline int __attribute__ ((target("inline-all-stringops"))) fn2 () {
return fn1 (); }
[Bug debug/82144] [8 Regression] ICE in add_dwarf_attr with alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82144 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug bootstrap/82300] Bootstrapping gcc-8 does not work on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82300 Richard Biener changed: What|Removed |Added Target||x86_64-apple-darwin15.6.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Thus fixed.
[Bug other/82301] [8 regression] Updated test case g++.dg/ext/attr-ifunc-1.C (and others) in r253041 segfault on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82301 Richard Biener changed: What|Removed |Added Target|powerpc64-unknown-linux-gnu |powerpc64-unknown-linux-gnu ||, x86_64-*-* Target Milestone|--- |8.0 --- Comment #3 from Richard Biener --- Also seen on x86_64-linux.
[Bug lto/82302] LTO producing bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82302 Richard Biener changed: What|Removed |Added Keywords||lto, wrong-code Status|UNCONFIRMED |WAITING Last reconfirmed||2017-09-25 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Please do some more work to identify the issue given that most of the time the error is in the program.
[Bug lto/82302] LTO producing bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82302 --- Comment #2 from Martin Liška --- Looks I've got some issue with sharer: ./minecraft Warning: The created OpenGL context does not fully meet the settings that were requested Requested: version = 3.3 ; depth bits = 24 ; stencil bits = 8 ; AA level = 0 ; core = false ; debug = false ; sRGB = false Created: version = 3.3 ; depth bits = 24 ; stencil bits = 8 ; AA level = 0 ; core = true ; debug = false ; sRGB = false terminate called after throwing an instance of 'std::runtime_error' what(): Unable to load a shader: 0:22(48): error: syntax error, unexpected NEW_IDENTIFIER, expecting ')' or ',' Aborted (core dumped)
[Bug c++/82307] unscoped enum-base incorrect cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82307 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-25 Ever confirmed|0 |1 Known to fail||7.2.0 --- Comment #1 from Richard Biener --- clang accepts it.
[Bug c++/82308] [C++17] deduction of template arguments results in internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82308
--- Comment #1 from Richard Biener ---
I get with GCC 7.2
> /space/rguenther/install/gcc-7.2/bin/g++ -S t.C
t.C: In function ‘int main()’:
t.C:18:16: error: missing template arguments before ‘d’
Xd{a}; //cannot be deduced
^
and clang complains:
> clang++ -S t.C -std=c++14
t.C:18:11: error: use of class template 'X' requires template arguments
Xd{a}; //cannot be deduced
^
t.C:4:7: note: template is declared here
class X {
^
1 error generated.
[Bug fortran/82312] [7/8 Regression] Pointer assignment to component of class variable results wrong vptr for the variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82312 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.3
[Bug middle-end/82319] New: ICE in generic_simplify_148, at generic-match.c:6436 on arm-linux-gnueabi-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82319
Bug ID: 82319
Summary: ICE in generic_simplify_148, at generic-match.c:6436
on arm-linux-gnueabi-gcc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: arm-linux-gnueabi-gcc
Using cross-compiler, I see:
$ cat i.c
short nonfinite_x;
void nonfinite() {
nonfinite_x == __builtin_nanf("0");
}
$ arm-linux-gnueabi-gcc /tmp/i.c -fsignaling-nans
/tmp/i.c: In function ‘nonfinite’:
/tmp/i.c:3:3: internal compiler error: in generic_simplify_148, at
generic-match.c:6436
nonfinite_x == __builtin_nanf("0");
^~~
0xfb38d5 generic_simplify_148
/home/marxin/BIG/buildbot/slave/gcc-master-build-arm-weekend/build/builddir/gcc/generic-match.c:6436
0xff758c generic_simplify_EQ_EXPR
/home/marxin/BIG/buildbot/slave/gcc-master-build-arm-weekend/build/builddir/gcc/generic-match.c:33772
0xffe0fd generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/marxin/BIG/buildbot/slave/gcc-master-build-arm-weekend/build/builddir/gcc/generic-match.c:38305
0x850265 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
.././../gcc/fold-const.c:9144
0x85a9fa fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
.././../gcc/fold-const.c:12272
0x62e99b c_fully_fold_internal
.././../gcc/c/c-fold.c:303
0x6308e3 c_fully_fold(tree_node*, bool, bool*)
.././../gcc/c/c-fold.c:89
0x5c9a8f c_process_expr_stmt(unsigned int, tree_node*)
.././../gcc/c/c-typeck.c:10625
0x5c9e7d c_finish_expr_stmt(unsigned int, tree_node*)
.././../gcc/c/c-typeck.c:10670
0x61da2d c_parser_statement_after_labels
.././../gcc/c/c-parser.c:5586
0x61f9d4 c_parser_compound_statement_nostart
.././../gcc/c/c-parser.c:5098
0x620110 c_parser_compound_statement
.././../gcc/c/c-parser.c:4931
0x61bab4 c_parser_declaration_or_fndef
.././../gcc/c/c-parser.c:2291
0x623fe3 c_parser_external_declaration
.././../gcc/c/c-parser.c:1634
0x624a69 c_parser_translation_unit
.././../gcc/c/c-parser.c:1515
0x624a69 c_parse_file()
.././../gcc/c/c-parser.c:18388
0x684e96 c_common_parse_file()
.././../gcc/c-family/c-opts.c:1113
[Bug middle-end/82319] [8 Regression] ICE in generic_simplify_148, at generic-match.c:6436 on arm-linux-gnueabi-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82319 Andrew Pinski changed: What|Removed |Added CC||ygribov at gcc dot gnu.org Target Milestone|--- |8.0 Summary|ICE in |[8 Regression] ICE in |generic_simplify_148, at|generic_simplify_148, at |generic-match.c:6436 on |generic-match.c:6436 on |arm-linux-gnueabi-gcc |arm-linux-gnueabi-gcc --- Comment #1 from Andrew Pinski --- Most likely introduced by: commit 29587d84fb32032411a8006d8afd286e9b845442 Author: ygribov Date: Fri Aug 4 20:29:12 2017 + Remove useless floating point casts in comparisons. 2017-08-04 Yury Gribov PR tree-optimization/57371 gcc/ * match.pd: New pattern. gcc/testsuite/ * c-c++-common/pr57371-1.c: New test. * c-c++-common/pr57371-2.c: New test. * c-c++-common/pr57371-3.c: New test. * c-c++-common/pr57371-4.c: New test. * gcc.dg/pr57371-5.c: New test. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@250877 138bc75d-0d04-0410-961f-82ee72b054a4 -- CUT
[Bug middle-end/82319] [8 Regression] ICE in generic_simplify_148, at generic-match.c:6436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82319 Martin Liška changed: What|Removed |Added Last reconfirmed||2017-9-25 CC||rguenth at gcc dot gnu.org Summary|[8 Regression] ICE in |[8 Regression] ICE in |generic_simplify_148, at|generic_simplify_148, at |generic-match.c:6436 on |generic-match.c:6436 |arm-linux-gnueabi-gcc | --- Comment #2 from Martin Liška --- It's not ARM target specific. Can be seen on x86_64-linux-gnu since r252007, but will be probably related to Yuri's commit.
[Bug lto/82172] Destruction of basic_string in basic_stringbuf::overflow with _GLIBCXX_USE_CXX11_ABI=0, -flto, and C++17 mode results in invalid delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82172 --- Comment #15 from Martin Liška --- (In reply to Jonathan Wakely from comment #12) > N.B. this bug has been latent for years. The reason people are only seeing > it now is that usually the "extern template class std::basic_string" > explicit instantiation declarations prevent this symbol being emitted in > user's object files, so the definition in the library is used. > > When compiling with -std=c++17 that extern template is not declared, so the > compiler emits a definition of that symbol in every object that uses the old > std::string. LDPR_PREVAILING_DEF_IRONLY means that the symbol in our translation unit is prevailing definition with no reference. However it's not true as libstdc++ shared library is having it's own symbol. That's what causes the segfault. Shouldn't one have different versions of libstdc++.so in order to either have a single global symbol or definitions in user's object files?
[Bug middle-end/82319] [8 Regression] ICE in generic_simplify_148, at generic-match.c:6436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82319
--- Comment #3 from Richard Biener ---
Testing the following to match comments.
Index: gcc/match.pd
===
--- gcc/match.pd(revision 253134)
+++ gcc/match.pd(working copy)
@@ -2930,7 +2930,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
only one mantissa bit. */
bool signed_p = isign == SIGNED;
bool itype_fits_ftype_p
-= TYPE_PRECISION (itype) - signed_p <= significand_size (fmt);
+= (TYPE_PRECISION (itype) - signed_p) <= significand_size (fmt);
}
/* TODO: allow non-fitting itype and SNaNs when
-fno-trapping-math. */
@@ -2964,20 +2964,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
{ constant_boolean_node (cmp == LT_EXPR || cmp == LE_EXPR || cmp ==
NE_EXPR,
type); })
/* Remove cast if CST is an integer representable by ITYPE. */
- (if (cst_int_p)
-(cmp @0 { gcc_assert (!overflow_p);
- wide_int_to_tree (itype, icst_val); })
- )
+ (if (cst_int_p && ! overflow_p)
+(cmp @0 { wide_int_to_tree (itype, icst_val); }))
/* When CST is fractional, optimize
(FTYPE) N == CST -> 0
(FTYPE) N != CST -> 1. */
- (if (cmp == EQ_EXPR || cmp == NE_EXPR)
+ (if (! cst_int_p && (cmp == EQ_EXPR || cmp == NE_EXPR))
{ constant_boolean_node (cmp == NE_EXPR, type); })
- /* Otherwise replace with sensible integer constant. */
- (with
-{
- gcc_checking_assert (!overflow_p);
-}
+ /* Otherwise replace with sensible integer constant if it fits. */
+ (if (! overflow_p)
(icmp @0 { wide_int_to_tree (itype, icst_val); })
/* Fold A /[ex] B CMP C to A CMP B * C. */
[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 --- Comment #59 from Iain Sandoe --- Author: iains Date: Mon Sep 25 08:47:41 2017 New Revision: 253137 URL: https://gcc.gnu.org/viewcvs?rev=253137&root=gcc&view=rev Log: [Patch, Darwin] Fix PR80556 by linking the system unwinder ahead of libgcc_eh. PR target/80556 * config/i386/darwin.h (REAL_LIB_SPEC): New; put libSystem ahead of libgcc_eh for m64. * config/i386/darwin64.h: Likewise. /* WORKAROUND pr80556: For x86_64 Darwin10 and later, the unwinder is in libunwind (redirected from libSystem). This doesn't use the keymgr (see keymgr.c) and therefore the calls that libgcc makes to obtain the KEYMGR_GCC3_DW2_OBJ_LIST are not updated to include new images, and might not even be valid for a single image. Therefore, for 64b exes at least, we must use the libunwind implementation, even when static-libgcc is specified. We put libSystem first so that unwinder symbols are satisfied from there. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/darwin.h trunk/gcc/config/i386/darwin64.h
[Bug middle-end/82319] [8 Regression] ICE in generic_simplify_148, at generic-match.c:6436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82319 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Version|unknown |8.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 Iain Sandoe changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #60 from Iain Sandoe --- so fixed
[Bug sanitizer/82183] gcc.dg/sancov/cmp0.c fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82183
Tom de Vries changed:
What|Removed |Added
Target|aarch64 |aarch64,nvptx
CC||vries at gcc dot gnu.org
--- Comment #2 from Tom de Vries ---
(In reply to Steve Ellcey from comment #0)
> I am not sure if any other platforms are affected by this.
nvptx as well:
...
FAIL: gcc.dg/sancov/cmp0.c -O0 scan-tree-dump-times optimized
"__builtin___sanitizer_cov_trace_const_cmp" 7
FAIL: gcc.dg/sancov/cmp0.c -O0 scan-tree-dump-times optimized
"__builtin___sanitizer_cov_trace_switch \\(" 2
FAIL: gcc.dg/sancov/cmp0.c -O0 -g scan-tree-dump-times optimized
"__builtin___sanitizer_cov_trace_const_cmp" 7
FAIL: gcc.dg/sancov/cmp0.c -O0 -g scan-tree-dump-times optimized
"__builtin___sanitizer_cov_trace_switch \\(" 2
...
[Bug tree-optimization/82285] [6/7/8 Regression] Optimizing error when using enumeration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82285
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener ---
So the issue is
-t2.c:13:3: note: vect_is_simple_use: operand _1
-t2.c:13:3: note: def_stmt: _1 = i_14 <= 4;
-t2.c:13:3: note: type of def: internal
-t2.c:13:3: note: vect_is_simple_use: operand _1
-t2.c:13:3: note: def_stmt: _1 = i_14 <= 4;
-t2.c:13:3: note: type of def: internal
-t2.c:13:3: note: vect_recog_bool_pattern: detected:
-t2.c:13:3: note: bool pattern recognized: patt_12 = _1 ? 1 : 0;
which isn't detected if I make 'data' the enum type vs. unsigned int.
Fix:
Index: gcc/tree-vect-patterns.c
===
--- gcc/tree-vect-patterns.c(revision 253134)
+++ gcc/tree-vect-patterns.c(working copy)
@@ -3643,7 +3643,7 @@ vect_recog_bool_pattern (vec *
rhs_code = gimple_assign_rhs_code (last_stmt);
if (CONVERT_EXPR_CODE_P (rhs_code))
{
- if (TREE_CODE (TREE_TYPE (lhs)) != INTEGER_TYPE
+ if (! INTEGRAL_TYPE_P (TREE_TYPE (lhs))
|| TYPE_PRECISION (TREE_TYPE (lhs)) == 1)
return NULL;
vectype = get_vectype_for_scalar_type (TREE_TYPE (lhs));
[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631 --- Comment #18 from Tamar Christina --- Thanks for the quick fix Ian!
[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 --- Comment #61 from Eric Botcazou --- Nice work, thanks! But I'm sure the next Darwin crisis is already looming. ;-)
[Bug c++/82316] unexpected warning for using 'register' storage class in extern "C" declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82316 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- Failing to understand C++ is not a GCC bug though.
[Bug middle-end/82319] [8 Regression] ICE in generic_simplify_148, at generic-match.c:6436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82319 --- Comment #4 from Yury Gribov --- (In reply to Richard Biener from comment #3) > Testing the following to match comments. Thanks, so the assertion proved to be useful in the end. I'd rather change cst_int_p to be bool cst_int_p = real_identical (&icst, cst) && ! real_isnan (cst); and then maybe add a special case for nan case when expanding the pattern. I'll take a look in the evening and hopefully send a patch tomorrow if that's fine?
[Bug middle-end/82319] [8 Regression] ICE in generic_simplify_148, at generic-match.c:6436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82319 --- Comment #5 from rguenther at suse dot de --- On Mon, 25 Sep 2017, ygribov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82319 > > --- Comment #4 from Yury Gribov --- > (In reply to Richard Biener from comment #3) > > Testing the following to match comments. > > Thanks, so the assertion proved to be useful in the end. > > I'd rather change cst_int_p to be > bool cst_int_p = real_identical (&icst, cst) && ! real_isnan (cst); > and then maybe add a special case for nan case when expanding the pattern. > I'll take a look in the evening and hopefully send a patch tomorrow if that's > fine? Sure. But I think you miss a check whether the CST fits in the integer type so a testcase with int == 1e30 would still fail? It's hard to write one doing short == 10.
[Bug c++/82308] [C++17] deduction of template arguments results in internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82308 --- Comment #2 from sdalleig at mmci dot uni-saarland.de --- I think that the error-message you get is correct if you are using C++14. The new standard allows for template argument deduction based on constructors and guides. The problem occurred in C++17 mode (-std=c++17 or -std=c++1z) using 7.2. It happened to be the case that clang-5 has handled this code properly. On a different machine, gcc reported a parse-tree error instead of the ``internal compiler error''.
[Bug middle-end/82319] [8 Regression] ICE in generic_simplify_148, at generic-match.c:6436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82319
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
Shouldn't
/* Optimize cases when CST is outside of ITYPE's range. */
(if (real_compare (LT_EXPR, cst, &imin))
{ constant_boolean_node (cmp == GT_EXPR || cmp == GE_EXPR || cmp ==
NE_EXPR,
type); })
(if (real_compare (GT_EXPR, cst, &imax))
{ constant_boolean_node (cmp == LT_EXPR || cmp == LE_EXPR || cmp ==
NE_EXPR,
type); })
catch that? Though, for those I think you really don't need
itype_fits_ftype_p,
if cst is not a NaN (for NaN and !exception_p it is the cmp == NE_EXPR, then
true, otherwise false, at least IEEE semantics, not sure if we support any
other, but if yes, we should be able to query it from the real struct), then
the above if you actually round imin and imax to the corresponding real type
away from zero at least should work always.
[Bug target/80035] [nvptx] non-returning function call causes ptxas sigsegv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80035 --- Comment #7 from Tom de Vries --- Author: vries Date: Mon Sep 25 10:36:23 2017 New Revision: 253145 URL: https://gcc.gnu.org/viewcvs?rev=253145&root=gcc&view=rev Log: [nvptx] Add exit after call to noreturn function 2017-09-25 Tom de Vries PR target/80035 PR target/81069 * config/nvptx/nvptx.c (nvptx_output_call_insn): Add exit after call to noreturn function. Modified: trunk/gcc/ChangeLog trunk/gcc/config/nvptx/nvptx.c
[Bug target/81069] nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81069 --- Comment #11 from Tom de Vries --- Author: vries Date: Mon Sep 25 10:36:23 2017 New Revision: 253145 URL: https://gcc.gnu.org/viewcvs?rev=253145&root=gcc&view=rev Log: [nvptx] Add exit after call to noreturn function 2017-09-25 Tom de Vries PR target/80035 PR target/81069 * config/nvptx/nvptx.c (nvptx_output_call_insn): Add exit after call to noreturn function. Modified: trunk/gcc/ChangeLog trunk/gcc/config/nvptx/nvptx.c
[Bug target/79041] aarch64 backend emits R_AARCH64_ADR_PREL_PG_HI21 relocation despite -mpc-relative-literal-loads option being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79041 --- Comment #13 from Wilco --- (In reply to Andrew Pinski from comment #12) > This test also fails with -fpic. It doesn't run in the testsuite with -fpic, so is it a problem?
[Bug target/80035] [nvptx] non-returning function call causes ptxas sigsegv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80035 Tom de Vries changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Tom de Vries --- patch committed, marking resolved-fixed.
[Bug middle-end/82319] [8 Regression] ICE in generic_simplify_148, at generic-match.c:6436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82319 --- Comment #7 from Yury Gribov --- (In reply to Jakub Jelinek from comment #6) > Shouldn't > ... > catch that? Yes, these are the checks that constant fits into integer type. > Though, for those I think you really don't need itype_fits_ftype_p, > ... > then > the above if you actually round imin and imax to the corresponding real type > away from zero at least should work always. Problem is that then pattern would remove potential inexact/overflow IEEE exceptions. It may be ok under various cmdline flags that control floating point semantics (TODO in pattern mentions that) but I never got to implementing this.
[Bug tree-optimization/82285] [6/7/8 Regression] Optimizing error when using enumeration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82285 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Sep 25 11:40:23 2017 New Revision: 253146 URL: https://gcc.gnu.org/viewcvs?rev=253146&root=gcc&view=rev Log: 2017-09-25 Richard Biener PR tree-optimization/82285 * tree-vect-patterns.c (vect_recog_bool_pattern): Also handle enumeral types. * gcc.dg/torture/pr82285.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr82285.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug tree-optimization/82285] [6/7 Regression] Optimizing error when using enumeration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82285 Richard Biener changed: What|Removed |Added Known to work||8.0 Summary|[6/7/8 Regression] |[6/7 Regression] Optimizing |Optimizing error when using |error when using |enumeration |enumeration --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug ada/80590] [8 regression] non-bootstrap build failure of Ada runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80590 --- Comment #10 from Tom de Vries --- (In reply to Tom de Vries from comment #8) > (In reply to Tom de Vries from comment #7) > > Backtrace from gdb is more complete: > > Backtrace looks similar to PR 80556 comment 3. Problem in that PR also is > with g-exptty.adb. That PR is now fixed. I've re-enabled ada in my test setup, and will see if I can still reproduce this failure.
[Bug debug/82155] [7/8 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:21655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82155 --- Comment #5 from pmderodat at gcc dot gnu.org --- Author: pmderodat Date: Mon Sep 25 12:26:36 2017 New Revision: 253147 URL: https://gcc.gnu.org/viewcvs?rev=253147&root=gcc&view=rev Log: [PR82155] Fix crash in dwarf2out_abstract_function This patch is an attempt to fix the crash reported in PR82155. When generating a C++ class method for a class that is itself nested in a class method, dwarf2out_early_global_decl currently leaves the existing context DIE as it is if it already exists. However, it is possible that this call happens at a point where this context DIE is just a declaration that is itself not located in its own context. From there, if dwarf2out_early_global_decl is not called on any of the FUNCTION_DECL in the context chain, DIEs will be left badly scoped and some (such as the nested method) will be removed by the type pruning machinery. As a consequence, dwarf2out_abstract_function will will crash when called on the corresponding DECL because it asserts that the DECL has a DIE. This patch fixes this crash making dwarf2out_early_global_decl process context DIEs the same way we process abstract origins for FUNCTION_DECL: if the corresponding DIE exists but is only a declaration, call dwarf2out_decl anyway on it so that it is turned into a more complete DIE and so that it is relocated in the proper context. Bootstrapped and regtested on x86_64-linux. gcc/ PR debug/82155 * dwarf2out.c (dwarf2out_early_global_decl): Call dwarf2out_decl on the FUNCTION_DECL function context if it has a DIE that is a declaration. gcc/testsuite/ * g++.dg/pr82155.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/pr82155.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 --- Comment #3 from Vincent Lefèvre --- (In reply to Andrew Pinski from comment #1) > This is interesting because log2 should have already done a rounding to > double before returning. I suppose that if the C library has been built with GCC without -fexcess-precision=standard (explicitly or implied), then this rounding is not done. I've done my tests on a Debian/unstable machine (currently glibc 2.24).
[Bug tree-optimization/82321] New: [8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82321
Bug ID: 82321
Summary: [8 Regression] ICE in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:707
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-alpha20170924 snaphost (r253127) ICEs when compiling the following
snippet w/ -O2 -floop-nest-optimize:
int y8;
void
dm (int io)
{
if (y8 != 0)
{
int pu = 1;
while (io < 2)
{
int xo = (pu != 0) ? y8 : 0;
while (y8 != 0)
if (xo != 0)
{
gi:
xo = &io;
pu = 0;
}
}
}
if (io != 0)
{
y8 = 1;
while (y8 != 0)
if (io / !y8 != 0)
y8 = 0;
goto gi;
}
}
% gcc-8.0.0-alpha20170924 -O2 -floop-nest-optimize -w -c r9nismdn.c
during GIMPLE pass: graphite
r9nismdn.c: In function 'dm':
r9nismdn.c:4:1: internal compiler error: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:707
dm (int io)
^~
[Bug tree-optimization/82320] New: [8 Regression] Compile time hog w/ -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82320
Bug ID: 82320
Summary: [8 Regression] Compile time hog w/ -O
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-alpha20170917 snapshot (r252896) takes indefinite time when compiling
the following snippet w/ any optimization level except -O0:
void
ec (int n4, short int ea)
{
if (1)
{
if (ea != 0)
{
int *c1 = (int *)&ea;
nn:
for (;;)
++*c1;
}
}
else
{
int *lq = &n4;
int *md;
int da;
goto nn;
r1:
md = lq;
for (da = 0; da < 1; ++da)
{
ig:
++n4;
*md += n4;
}
}
for (ea = 0; ea < 1; ++ea)
goto r1;
goto ig;
}
% timeout 10 gcc-8.0.0-alpha20170924 -O1 -c yz3jwezs.c
zsh: exit 124 timeout 10 gcc-8.0.0-alpha20170924 -O1 -c yz3jwezs.c
perf top shows the following:
24.40% cc1 [.] visit_use
22.59% cc1 [.] operand_equal_p
9.84% cc1 [.] VN_INFO
9.53% cc1 [.] set_ssa_val_to
8.75% cc1 [.] DFS
7.36% cc1 [.] ssa_defined_default_def_p
4.13% cc1 [.] mark_use_processed
3.70% cc1 [.] ssa_undefined_value_p
2.22% cc1 [.] element_precision
1.80% cc1 [.] tree_strip_nop_conversions
1.71% cc1 [.] is_gimple_min_invariant
1.35% cc1 [.] _obstack_begin_worker
0.76% cc1 [.] _obstack_free
0.63% cc1 [.] mempool_obstack_chunk_free
0.58% cc1 [.] _obstack_begin
0.23% cc1 [.] mempool_obstack_chunk_alloc
0.22% cc1 [.] call_freefun
0.17% cc1 [.] call_chunkfun
[Bug target/82317] [8 Regression] "'__builtin_s390_vec_min' matching variant requires z14 or higher" for __vector(2) double when it should work on -march=z13 as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82317 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-25 Summary|error |[8 Regression] |"'__builtin_s390_vec_min' |"'__builtin_s390_vec_min' |matching variant requires |matching variant requires |z14 or higher" for |z14 or higher" for |__vector(2) double when it |__vector(2) double when it |should work on -march=z13 |should work on -march=z13 |as well |as well Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug target/82322] New: vec_ceil/vec_floor/vec_round intrincics do not work for gcc 8, need __builtin_s390_vfidb.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82322
Bug ID: 82322
Summary: vec_ceil/vec_floor/vec_round intrincics do not work
for gcc 8, need __builtin_s390_vfidb.
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
Build: s390x-ibm-linux-gnu
Created attachment 42233
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42233&action=edit
testcase demonstrating compiler error for vec_round, etc.
When trying to compile the attached source with gcc 8.0.0:
> g++ -mzvector -march=z14 /home/markos/Development/zvectortest.cpp -o
> /home/markos/Development/zvectortest
In file included from /home/markos/Development/zvectortest.cpp:1:0:
/home/markos/Development/zvectortest.cpp: In function 'Packet2d pround(const
Packet2d&)':
/home/markos/Development/zvectortest.cpp:6:45: error: '__builtin_s390_vfi' was
not declared in this scope
Packet2d pround(const Packet2d& a) { return vec_round(a); }
^
/home/markos/Development/zvectortest.cpp:6:45: note: suggested alternative:
'__builtin_s390_vfidb'
/home/markos/Development/zvectortest.cpp: In function 'Packet2d pceil(const
Packet2d&)':
/home/markos/Development/zvectortest.cpp:7:45: error: '__builtin_s390_vfi' was
not declared in this scope
Packet2d pceil(const Packet2d& a) { return vec_ceil(a); }
^~~~
/home/markos/Development/zvectortest.cpp:7:45: note: suggested alternative:
'__builtin_s390_vfidb'
/home/markos/Development/zvectortest.cpp: In function 'Packet2d pfloor(const
Packet2d&)':
/home/markos/Development/zvectortest.cpp:8:45: error: '__builtin_s390_vfi' was
not declared in this scope
Packet2d pfloor(const Packet2d& a) { return vec_floor(a); }
^
/home/markos/Development/zvectortest.cpp:8:45: note: suggested alternative:
'__builtin_s390_vfidb'
Same result with -march=z13. Works fine with g++-6.
However, it worked with both compilers if I add the code with #ifdef __GNUC__ <
8 and use helper defines using __builtin_s390_vfidb() intrinsic.
[Bug c++/61806] [C++11] Expression sfinae w/o access gives hard error in partial template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61806
gcc-bugs at marehr dot dialup.fu-berlin.de changed:
What|Removed |Added
CC||gcc-bugs at marehr dot
dialup.fu-b
||erlin.de
--- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I think I encountered a variant of this bug.
Using this new awesome -fconcept feature, you can do the following:
```
template
struct type_trait;
template <>
struct type_trait
{
static constexpr auto length = 0;
};
template <>
struct type_trait
{
private:
static constexpr auto length = 0;
};
template
concept bool has_length = requires(type_t a)
{
{ type_trait::length };
};
int main()
{
static_assert(!has_length); // expect: false, has no ::length
static_assert(has_length); // expect: true, has ::length
static_assert(!has_length); // expect: false, ::length is non-visible
// but, last one fails in a compiler error
return 0;
}
```
This example asks whether a type_trait is defined for a given type. And it
would be super useful to be able to express this.
I think gcc uses internally SFINAE to check this but unfortunately fails
because of this bug (probably).
[Bug tree-optimization/82320] [8 Regression] Compile time hog w/ -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82320 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-09-25 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 --- I will have a look - we don't converge VN the SCC formed by md_11, md_10 and md_9.
[Bug target/82322] [7/8 Regression] vec_ceil/vec_floor/vec_round intrincics do not work for gcc 8, need __builtin_s390_vfidb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82322 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-25 CC||dje at gcc dot gnu.org, ||krebbel at gcc dot gnu.org, ||vogt at linux dot vnet.ibm.com Summary|vec_ceil/vec_floor/vec_roun |[7/8 Regression] |d intrincics do not work|vec_ceil/vec_floor/vec_roun |for gcc 8, need |d intrincics do not work |__builtin_s390_vfidb. |for gcc 8, need ||__builtin_s390_vfidb Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug tree-optimization/82320] [8 Regression] Compile time hog w/ -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82320 --- Comment #2 from Richard Biener --- Starting iteration 37161 Value numbering md_11 stmt = md_11 = PHI Setting value number of md_11 to md_21(D) (changed) Value numbering md_10 stmt = md_10 = PHI Setting value number of md_10 to lq_24(D) (changed) Value numbering md_9 stmt = md_9 = PHI Setting value number of md_9 to md_21(D) (changed) Starting iteration 37162 Value numbering md_11 stmt = md_11 = PHI Setting value number of md_11 to lq_24(D) (changed) Value numbering md_10 stmt = md_10 = PHI Setting value number of md_10 to md_21(D) (changed) Value numbering md_9 stmt = md_9 = PHI Setting value number of md_9 to lq_24(D) (changed) Starting iteration 37163 Value numbering md_11 stmt = md_11 = PHI Setting value number of md_11 to md_21(D) (changed) Value numbering md_10 stmt = md_10 = PHI Setting value number of md_10 to lq_24(D) (changed) Value numbering md_9 stmt = md_9 = PHI Setting value number of md_9 to md_21(D) (changed) ... So we iterate between the different leaders for "undefined". I suppose not considering lq_24(D) -> md_21(D) a change in values would fix this. Index: gcc/tree-ssa-sccvn.c === --- gcc/tree-ssa-sccvn.c(revision 253149) +++ gcc/tree-ssa-sccvn.c(working copy) @@ -3355,6 +3355,12 @@ set_ssa_val_to (tree from, tree to) if (currval != to && !operand_equal_p (currval, to, 0) + /* Different undefined SSA names are not actually different. See + PR82320 for a testcase were we'd otherwise not terminate iteration. */ + && !(TREE_CODE (currval) == SSA_NAME + && TREE_CODE (to) == SSA_NAME + && ssa_undefined_value_p (currval, false) + && ssa_undefined_value_p (to, false)) /* ??? For addresses involving volatile objects or types operand_equal_p does not reliably detect ADDR_EXPRs as equal. We know we are only getting invariant gimple addresses here, so can use
[Bug tree-optimization/82321] [8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82321 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-09-25 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 --- Mine.
[Bug c/81854] weak alias of an incompatible symbol accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81854 --- Comment #13 from uros at gcc dot gnu.org --- Author: uros Date: Mon Sep 25 14:59:19 2017 New Revision: 253153 URL: https://gcc.gnu.org/viewcvs?rev=253153&root=gcc&view=rev Log: PR c/81854 * src/c++98/complex_io.cc (_GLIBCXX_LDBL_COMPAT): Declare alias target as a C++ function with no prototype. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++98/complex_io.cc
[Bug c/82296] Warn for code removal due to "code never accesses array out of bounds" assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82296 --- Comment #6 from Ingo --- > https://www.securecoding.cert.org/confluence/display/c/ARR30-C.+Do+not+form+or+use+out-of-bounds+pointers+or+array+subscripts Just out of curiosity: I am not able to find any of that in the ANSI/ISO C89 standard. That might be, because I am not familiar where to find that in the C89 standard (I am definitely not familiar with any of the formal C standard documents). I also noticed that if I compile the example with gcc -std=c89 -O2 -S gcc_check.c I also get assembler code which basically implements "return 1;". So does that mean gcc will always define "undefined behavior" according to the C-2011 standard, even if you use "-std=c89" ? What happens when the standard committee release a more recent version of the C standard ? Will the upcoming versions of GCC then use the updated definitions of "undefined behavior" from the upcoming C standards definition and thus produce non working code for any source code, which was not able to look into the future and guessing what the C standards committee might deem "undefined behavior" in the future ?
[Bug target/82175] [8 Regression] -march=native fails on armv7 big/little system armv7l-unknown-linux-gnueabihf with gcc 8.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82175 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-25 Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Richard Earnshaw --- Mine
[Bug fortran/38936] [F03] ASSOCIATE construct / improved SELECT TYPE (a=>expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936 Dominique d'Humieres changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #19 from Dominique d'Humieres --- > This commit did implement better handling for association to derived-types, > but some cases are still not handled (see the XFAIL of associate_9.f03). > I wanted to test with the code of PR 45369, but that also uses CLASS(*) so > I was not able to compile it still. The XFAIL has been removed at revision r252894. Is there anything left in this PR or could it be closed?
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-25 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.4 up to trunk (8.0). Note that the ICE is in is_illegal_recursion, at fortran/resolve.c from 4.4 up to 4.8.
[Bug fortran/82313] Rejects-valid for sum(minloc(...))) as array dimension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82313 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-25 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.4 up to trunk (8.0).
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-25 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- Confirmed from 5.4.0 up to trunk (8.0), 'ieee_arithmetic.mod' was not implemented before gcc-5.
[Bug c/82323] New: circular ifunc attribute on a function definition silently accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82323
Bug ID: 82323
Summary: circular ifunc attribute on a function definition
silently accepted
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: ---
While testing the implementation of the fix for bug 82301 (and bug 81854) I
noticed that the ifunc attribute is silently accepted on the definition of a
function, like below:
$ cat t.c && gcc -S -Wall -Wextra -Werror t.c
int __attribute__ ((ifunc ("foo")))
foo (void) { return 0; }
The attribute specification on this function is invalid because a) it specifies
the indirect function itself as its own resolver, and b) it specifies a
resolver that doesn't return the expected type (a pointer to the indirect
function).
It seems to me that the ifunc attribute should be rejected with an error on
definitions of functions.
[Bug c++/82230] [8 Regression] ICE: in tsubst, at cp/pt.c:13686 when binding lambda to variable inside a generic lambda inside a template member function inside a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82230 nik changed: What|Removed |Added CC||xerofoify at gmail dot com --- Comment #4 from nik --- I have new to the project but after looking at the code in semantics.c that was changed by that commit pointed out. It seems that a else above this if statement was removed: if (containing_function && DECL_TEMPLATE_INFO (context) && LAMBDA_FUNCTION_P (containing_function)) which in term means that: containing_function = NULL_TREE; is a NULL_TREE I assume that means it points to a nullptr or null pointer. Therefore we may be passing in a null tree to an incorrect branch due to the missing else. Seems it your trace, semantics.c is being called so it may be this. Anybody have any comments?
[Bug tree-optimization/82163] [8 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82163 --- Comment #3 from amker at gcc dot gnu.org --- Author: amker Date: Mon Sep 25 17:32:36 2017 New Revision: 253161 URL: https://gcc.gnu.org/viewcvs?rev=253161&root=gcc&view=rev Log: PR tree-optimization/82163 * tree-ssa-loop-manip.h (verify_loop_closed_ssa): New parameter. (checking_verify_loop_closed_ssa): New parameter. * tree-ssa-loop-manip.c (check_loop_closed_ssa_use): Delete. (check_loop_closed_ssa_stmt): Delete. (check_loop_closed_ssa_def, check_loop_closed_ssa_bb): New functions. (verify_loop_closed_ssa): Check loop closed ssa form for LOOP. (tree_transform_and_unroll_loop): Check loop closed ssa form only for changed loops. gcc/testsuite * gcc.dg/tree-ssa/pr82163.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr82163.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-manip.c trunk/gcc/tree-ssa-loop-manip.h
[Bug lto/82302] LTO producing bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82302 --- Comment #3 from krzysio.kurek at wp dot pl --- This happens only on GCC7 with -flto activated. clang-6, GCC6 and GCC5 with either flag enabled or disabled compile code that runs fine. I don't know why this error is occurring for you Martin.
[Bug libfortran/66756] libgfortran: ThreadSanitizer: lock-order-inversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66756 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Thomas Koenig --- I think the current behavior is correct, only that the thread sanitizer does not realize it. From the comment in unit.c: Therefore to avoid deadlocks, it is forbidden to acquire unit's private locks while holding UNIT_LOCK, except for freshly created units (where no other thread can get at their address yet) or when using just trylock rather than lock operation. ... and this appears to be exactly what is happening there. This makes debugging thread-related problems in libgfortran somewhat harder, so I'm not sure what is the best course. Should we try to "fix" this? It should be possible to do file opening under UNIT_LOCK, that should not be a serious performance bottleneck. OTOH, the current code seems OK, so it could be a case of "If it ain't broke, don't fix it". Opinions?
[Bug lto/82302] LTO producing bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82302 --- Comment #4 from Martin Liška --- Created attachment 42234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42234&action=edit Build log Hm, for me GCC 6 with -O0 also fails. Please take a look.
[Bug lto/82302] LTO producing bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82302 --- Comment #5 from krzysio.kurek at wp dot pl --- I can't reproduce your error.
[Bug fortran/82312] [7/8 Regression] Pointer assignment to component of class variable results wrong vptr for the variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82312 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 42235 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42235&action=edit Patch for the PR The attached bootstraps and regtests OK. I am busy on PR77296 right now. Will post this properly when done. Paul
[Bug lto/82302] LTO producing bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82302 --- Comment #6 from Martin Liška --- (In reply to krzysio.kurek from comment #5) > I can't reproduce your error. Is the error I see the same you see with GCC 7? That said a syntax error in a shader?
[Bug lto/82302] LTO producing bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82302 --- Comment #7 from krzysio.kurek at wp dot pl --- No, the error you're having is completely different from what I originally reported.
[Bug lto/82302] LTO producing bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82302 --- Comment #8 from krzysio.kurek at wp dot pl --- In a sense that there is no error, the program goes into infinite loop.
[Bug c/82323] circular ifunc attribute on a function definition silently accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82323 Eric Gallager changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-09-25 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- Confirmed that gcc silently accepts the example. I think it'd be okay to just issue a warning from -Wattributes or something though, instead of rejecting it completely.
[Bug tree-optimization/82224] Strict-aliasing not noticing valid aliasing of two unions with active members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82224 --- Comment #5 from Melissa --- This originated from a Stack Overflow post "supercat" made (I'm the "Myria" there). https://stackoverflow.com/questions/46205744/is-this-use-of-unions-strictly-conforming/
[Bug c++/82316] unexpected warning for using 'register' storage class in extern "C" declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82316
--- Comment #4 from Jordi Vilar ---
I'm sorry if I didn't explain it correctly.
I don't claim that a extern "C" declarations have to be interpreted as C in a
C++ translation unit. What I say is that most C libraries (libtiff, zlib, lcms,
etc.) provide a header that assumes that the C api can be reused for C++ just
by wrapping it with extern "C" {}. If a C library uses register in its api
declarations, then that legitimate C declarations no longer can be used in C++
code not even wrapped by extern "C". This is a breaking movement.
Supressing the warning in extern "C" declarations doesn't imply parsing it as
C, because it is actually a C++ translation, but would enable continuing using
the traditional C libraries.
For an example of C library that uses register in its api, you can take a look
on the little cms (lcms) that is included in most linux distributions. It just
has the classic #ifdef __cplusplus extern "C" { #endif and tons of register
function arguments.
Should C++17 applications REJECT all of those ligitimate C libraries?
[Bug testsuite/82324] New: Problem in new trunk test case gfortran.dg/promotion_4.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82324 Bug ID: 82324 Summary: Problem in new trunk test case gfortran.dg/promotion_4.f90 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- The new test case gfortran.dg/promotion_4.f90 doesn't seem to compile correctly. I saw this on powerpc64 both BE and LE. make -k check-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/promotion_4.f90 . . . Running /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/promotion_4.f90 -O0 (test for excess errors) FAIL: gfortran.dg/promotion_4.f90 -O1 (test for excess errors) FAIL: gfortran.dg/promotion_4.f90 -O2 (test for excess errors) FAIL: gfortran.dg/promotion_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/promotion_4.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/promotion_4.f90 -Os (test for excess errors) In the gfortran.log file from a full run: Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran1/../../gfortran -B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran1/../../ -B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/promotion_4.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never-O0 -fdefault-real-10 -B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libatomic/.libs -lm-o ./promotion_4.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran1/../../gfortran -B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran1/../../ -B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/promotion_4.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fdefault-real-10 -B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libatomic/.libs -lm -o ./promotion_4.exe f951: Fatal Error: REAL(KIND=10) is not available for '-fdefault-real-10' option compilation terminated. compiler exited with status 1 output is: f951: Fatal Error: REAL(KIND=10) is not available for '-fdefault-real-10' option compilation terminated. FAIL: gfortran.dg/promotion_4.f90 -O0 (test for excess errors) Excess errors: f951: Fatal Error: REAL(KIND=10) is not available for '-fdefault-real-10' option compilation terminated. UNRESOLVED: gfortran.dg/promotion_4.f90 -O0 compilation failed to produce executable
[Bug target/80266] ICE in store_pairsi condition with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80266 Qing Zhao changed: What|Removed |Added CC||qing.zhao at oracle dot com --- Comment #3 from Qing Zhao --- This is a very similar bug as PR80295. I have had a fix for 80295 already. hopefully that fix should fix this bug too. since I cannot build gnat on the available machines, I cannot confirm this on my side.
[Bug c++/82307] unscoped enum-base incorrect cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82307 --- Comment #2 from Maxim --- (In reply to Richard Biener from comment #1) > clang accepts it. Yes, I know. I would like to know if the g++ is deviating from the standard, that nothing is written about it, or will it be fixed?
[Bug target/79041] aarch64 backend emits R_AARCH64_ADR_PREL_PG_HI21 relocation despite -mpc-relative-literal-loads option being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79041
--- Comment #14 from Andrew Pinski ---
(In reply to Wilco from comment #13)
> It doesn't run in the testsuite with -fpic, so is it a problem?
I run the testsuite with RUNTESTFLAGS='--target_board=unix/\{,-fpic\}' and this
testcase fails in the -fpic is selected. Note this is done as we don't have
enough coverage for -fpic code in the normal testsuite run; running the
testsuite this way has allowed me to file PIC related bugs in the past.
[Bug c++/82325] New: worse code generated compared to clang when using a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82325
Bug ID: 82325
Summary: worse code generated compared to clang when using a
constexpr array
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dvd at gnx dot it
Target Milestone: ---
While testing some functions I'm writing for a deflate compressor I've noticed
that the following code is translated differently between gcc 7.2 and clang 5.0
#include
struct code_value
{
uint16_t base;
uint8_t bits;
};
constexpr std::array al = {{
{ 3, 0}, { 4, 0}, { 5, 0}, { 6, 0}, { 7, 0}, { 8, 0}, {
9, 0}, { 10, 0},
{ 11, 1}, { 13, 1}, { 15, 1}, { 17, 1},
{ 19, 2}, { 23, 2}, { 27, 2}, { 31, 2},
{ 35, 3}, { 43, 3}, { 51, 3}, { 59, 3},
{ 67, 4}, { 83, 4}, { 99, 4}, {115, 4},
{131, 5}, {163, 5}, {195, 5}, {227, 5},
{258, 0}
}};
code_value f(int v) {
size_t index = 0;
while (index < al.size()) {
auto mi = al[index].base;
auto mx = al[index].base + (1 << al[index].bits);
if (mi <= v && v < mx)
break;
index++;
}
return al[index];
}
On gcc (with -O3 and -funroll-loop) every iteration is (more or less):
.L4:
movzx ecx, BYTE PTR al[2+rax*4]
movzx r9d, WORD PTR al[0+rax*4]
mov r10d, esi
sal r10d, cl
add r10d, r9d
cmp r10d, edi
jle .L5
cmp r9d, edi
jle .L2
while on clang
.LBB0_4:
cmp edi, 13
jge .LBB0_6
mov eax, 8
mov eax, dword ptr [4*rax + al]
ret
It looks like the latter is able to infer at compilet time the values of
`al[index].base + (1 << al[index].bits);`
godbolt link:
https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAKxAEZSBnVAV2OUxAHIBSAJgGY8AO2QAbZlgDU3fgGEAhsWLyAnjOzcADAEEt2hgWLNkBSWiwB9AG7zxmPdwDsAIQeaAnM2EFaANgumAEbyDPb8rjpant4AHAGSgYQMMhG6jgAiKW7aaEIGmAAeAA7EkgboICCKympy5pjWtsyYpJK87uqSttL86dIuTqlRg5KS/K2aTumtI5IALBNTMy6jAKyLGcvOo74b0/3bko57W6MxJwej7heztJonbh0rtPSStEuXtONvHyO06z9Np9joDpo8/tc2r8VgJWrxodteCD4UCRvxXiiwZEPGiAfwEfNvvjUStVq9ifsRqtIRTSOCVr4QXMCTFvsySdt3JD2ZSXC8ATy6dins4vq9Vgi/N8JRzaO4ATLec5eEjWoqhbocS5eKtzpJJhkHIbDeFsnp6o07JIAGYQbySKwASgOjwYeAAXg1TMIsAUen1JqbhQB3BB4USYSR2oS%2BnqyLqiAB0bs9EEdzsG4I88mYREkAFs8P6E9xVs4fYVS%2BlE8FQllhVEc3n836ZH1bKXyzHK6tq7XI3xthBaHGZPGO2WKwUqzWko765qOh48Nao4XR70HdJeL4%2BL4t2OCwV5w2cR5AsRMPIANYL4bL7vT3iuZ93rWZYWXgisIQlyePqs7wyThHVIUQuFWThSCELhNCg1AuFkQdBzKFg2AHARaCgghYJA0DrxAfh%2BETIjSLI8jdnAzg5igmDODg0gEM4KCGBAe4cPokDSDgWAkDQfMinDTAyAoCB%2BMEiNiBAYBHF4UhrXDAhhNYiBAlw0hEiERQVC4LDSH4/NMCEAgAHkhFEHTONILB83kIRgAjdT8EvEw8CsTBWKswpMGQXMOE4PTvEwKiGMMPB81w0DRDwQJWMgUDUCKAg8FQPIuAAWnKNtkGQ59aHdSR0pM/hCutZghGIVBRFEdLRFQRKGBYtD2DoKKINo9SmIKGJfHS3w5kkYBkGQI5E14KNcEIEht3RVpZFQAShNKPh0UdbDIvwwjiPInbSMorgaOgzquBYtjSA4uDQJ4xAUAWiThPIShxKWlBRDs4BVk0e4FNEJTiBUtSrM07TdKggyjNM8zLIYmz3scqznJ85L3M8hjvN8pTQfIYzgvUsKIs4qKYritNGKSlK0s4TKCHQbLctFAqiv4JrWBa2g2s4SCjqsrqer6gaxHeyRVkTTRRYm/AiGWzC5rupaZt4Nbzo20gCKIkjdp2sCDo6nmTsYM6Lrw7XOF4XWGKY9bCdA9z/opkA5iAA%3D
[Bug ada/80590] [8 regression] non-bootstrap build failure of Ada runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80590 --- Comment #11 from Eric Botcazou --- > That PR is now fixed. I've re-enabled ada in my test setup, and will see if > I can still reproduce this failure. It's a different problem since it's on Linux and the other was Darwin-specific.
[Bug testsuite/82324] Problem in new trunk test case gfortran.dg/promotion_4.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82324
--- Comment #1 from kargl at gcc dot gnu.org ---
Does this fix the problem?
Index: promotion_3.f90
===
--- promotion_3.f90 (revision 253178)
+++ promotion_3.f90 (working copy)
@@ -1,5 +1,6 @@
! { dg-do run }
! { dg-options "-fdefault-real-16" }
+! { dg-require-effective-target fortran_large_real }
!
! PR 82143: add a -fdefault-real-16 flag
!
Index: promotion_4.f90
===
--- promotion_4.f90 (revision 253178)
+++ promotion_4.f90 (working copy)
@@ -1,5 +1,6 @@
! { dg-do run }
! { dg-options "-fdefault-real-10" }
+! { dg-require-effective-target fortran_large_real }
!
! PR 82143: add a -fdefault-real-16 flag
!
[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037 --- Comment #13 from Iain Sandoe --- Author: iains Date: Mon Sep 25 23:49:58 2017 New Revision: 253181 URL: https://gcc.gnu.org/viewcvs?rev=253181&root=gcc&view=rev Log: [Patch, Darwin] Fix 81037 by adjutng headers 2017-09-26 Iain Sandoe Ryan Mounce PR bootstrap/81037 Backport from mainline r235362 2016-04-22 Szabolcs Nagy * system.h (list, map, set, vector): Include conditionally. * auto-profile.c (INCLUDE_MAP, INCLUDE_SET): Define. * graphite-isl-ast-to-gimple.c (INCLUDE_MAP): Define. * ipa-icf.c (INCLUDE_LIST): Define. * ipa-icf-gimple.c (INCLUDE_LIST): Define. * config/sh/sh.c (INCLUDE_VECTOR): Define. * config/sh/sh_treg_combine.cc (INCLUDE_ALGORITHM): Define. (INCLUDE_LIST, INCLUDE_VECTOR): Define. * fortran/trans-common.c (INCLUDE_MAP): Define. Backport from mainline r235361 2016-04-22 Szabolcs Nagy * auto-profile.c: Remove include. * diagnostic.c: Remove include. * genmatch.c: Likewise. * pretty-print.c: Likewise. * toplev.c: Likewise * c/c-objc-common.c: Likewise. * cp/error.c: Likewise. * fortran/error.c: Likewise. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/auto-profile.c branches/gcc-5-branch/gcc/c/c-objc-common.c branches/gcc-5-branch/gcc/config/sh/sh.c branches/gcc-5-branch/gcc/config/sh/sh_treg_combine.cc branches/gcc-5-branch/gcc/cp/error.c branches/gcc-5-branch/gcc/diagnostic.c branches/gcc-5-branch/gcc/fortran/error.c branches/gcc-5-branch/gcc/fortran/trans-common.c branches/gcc-5-branch/gcc/genmatch.c branches/gcc-5-branch/gcc/graphite-isl-ast-to-gimple.c branches/gcc-5-branch/gcc/ipa-icf-gimple.c branches/gcc-5-branch/gcc/ipa-icf.c branches/gcc-5-branch/gcc/pretty-print.c branches/gcc-5-branch/gcc/system.h branches/gcc-5-branch/gcc/toplev.c
[Bug demangler/82195] Undemangleable lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82195 --- Comment #8 from Nathan Sidwell --- Author: nathan Date: Tue Sep 26 02:38:12 2017 New Revision: 253186 URL: https://gcc.gnu.org/viewcvs?rev=253186&root=gcc&view=rev Log: PR demangler/82195 * cp-demangle.c (d_encoding): Strip return type when name is a LOCAL_NAME. (d_local_name): Strip return type of enclosing TYPED_NAME. * testsuite/demangle-expected: Add and adjust tests. Modified: trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/testsuite/demangle-expected
