[Bug fortran/85364] -fopenmp should not put array in program on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85364 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- -fopenmp just implies -frecursive and has to, because the OpenMP semantics requires it. Does fortran guarantee that MAIN__ can't be invoked more than once? If so, perhaps MAIN__ could be special-cased for -frecursive, you'd need to update the docs too. There would be no way to force automatic variables in MAIN__ though if the user wants it for some reason (you can't mark MAIN__ RECURSIVE). On the other side, the user can easily do it now by adding SAVE attribute to the vars he doesn't want to be automatic.
[Bug target/85296] [nvptx] pr85244-1.c execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85296 --- Comment #2 from Tom de Vries --- Author: vries Date: Thu Apr 12 07:17:29 2018 New Revision: 259337 URL: https://gcc.gnu.org/viewcvs?rev=259337&root=gcc&view=rev Log: [nvptx] Fix handling of extern var with flexible array member 2018-04-12 Tom de Vries PR target/85296 * config/nvptx/nvptx.c (flexible_array_member_type_p): New function. (nvptx_assemble_decl_begin): Add undefined param. Declare undefined array with flexible array member as array without given dimension. (nvptx_assemble_undefined_decl): Set nvptx_assemble_decl_begin call argument for undefined param to true. Modified: trunk/gcc/ChangeLog trunk/gcc/config/nvptx/nvptx.c
[Bug c/85362] unnecessary checks with -fsanitize=object-size and non-int indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85362 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is intentional. For sanitization we don't want to heavily rely on value range propagation, because value range propagation is relying on no undefined behavior occuring in the program and the sanitizer's purpose is exactly catch undefined behavior in the program. We don't have 2 sets of value ranges where one would be extra conservative and another another one what we have right now where we could use the extra conservative for sanitization. And by using the normal value range we would just not detect many undefined behaviors.
[Bug rtl-optimization/85354] [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354 Richard Biener changed: What|Removed |Added Target|powerpc64*-*-* |powerpc64*-*-*, x86_64-*-* Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-12 Target Milestone|--- |8.0 Ever confirmed|0 |1
[Bug sanitizer/83356] [7 Regression] excessive stack usage compiling with -O2 -fsanitize=bounds -fsanitize=object-size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356 Jakub Jelinek changed: What|Removed |Added CC||breiten at lexmark dot com --- Comment #14 from Jakub Jelinek --- *** Bug 85362 has been marked as a duplicate of this bug. ***
[Bug c/85362] unnecessary checks with -fsanitize=object-size and non-int indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85362 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356#c9 for more details. *** This bug has been marked as a duplicate of bug 83356 ***
[Bug c/85361] Variable length array allowed in c89/90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85361 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Richard Biener --- It's been a GCC extension so you need -pedantic or -pedantic-errors.
[Bug target/85296] [nvptx] pr85244-1.c execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85296 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tom de Vries --- Patch committed, test-case not required. Marking resolved-fixed.
[Bug gcov-profile/85367] New: [GCOV] A call to the _subborrow_u64 builtin-function is wrongly marked as executed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85367
Bug ID: 85367
Summary: [GCOV] A call to the _subborrow_u64 builtin-function
is wrongly marked as executed twice
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)
$ cat small.c
#include
int main ()
{
unsigned char c;
unsigned long long x, y;
c = 0;
x = 1LL;
y = 0LL;
/* X = 0x0001, Y = 0x, C = 0. */
c = _subborrow_u64 (c, y, x, &x);
return 0;
}
$ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 6
Creating 'small.c.gcov'
File '/usr/lib/gcc/x86_64-linux-gnu/8/include/adxintrin.h'
Lines executed:100.00% of 1
Creating 'adxintrin.h.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:
1:3:int main ()
-:4:{
-:5: unsigned char c;
-:6: unsigned long long x, y;
-:7:
1:8: c = 0;
1:9: x = 1LL;
1: 10: y = 0LL;
-: 11:
-: 12: /* X = 0x0001, Y = 0x, C = 0. */
2: 13: c = _subborrow_u64 (c, y, x, &x);
-: 14:
1: 15: return 0;
-: 16:}
Line #13 is wrongly marked as executed twice.
Replacing _subborrow_u64 to _subborrow_u32, same problem.
I am not sure whether the problem is due to the value stored in the address &x
will be changed in _subborrow_u64.
[Bug target/85296] [nvptx] pr85244-1.c execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85296 Tom de Vries changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/85368] New: [8 regression] phi-opt-11 test fails on IBM Z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85368
Bug ID: 85368
Summary: [8 regression] phi-opt-11 test fails on IBM Z
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
No IF statements remain although LOGICAL_OP_NON_SHORT_CIRCUIT is not
defined on S/390 and hence defaults to true when using
-mbranch-cost=2.
The testcase appears to expect 2 IFs to remain for function
h. However, these get removed in phiopt1.
This code turns the TRUTH_ANDIF_EXPR condition into a TRUTH_AND_EXPR:
fold-const.c:8178
if (LOGICAL_OP_NON_SHORT_CIRCUIT
&& !flag_sanitize_coverage
&& (code == TRUTH_AND_EXPR
|| code == TRUTH_ANDIF_EXPR
|| code == TRUTH_OR_EXPR
|| code == TRUTH_ORIF_EXPR))
{
enum tree_code ncode, icode;
ncode = (code == TRUTH_ANDIF_EXPR || code == TRUTH_AND_EXPR)
? TRUTH_AND_EXPR : TRUTH_OR_EXPR;
icode = ncode == TRUTH_AND_EXPR ? TRUTH_ANDIF_EXPR : TRUTH_ORIF_EXPR;
...
/* Transform (A AND-IF B) into (A AND B), or (A OR-IF B)
into (A OR B).
For sequence point consistancy, we need to check for trapping,
and side-effects. */
else if (code == icode && simple_operand_p_2 (arg0)
&& simple_operand_p_2 (arg1))
return fold_build2_loc (loc, ncode, type, arg0, arg1);
ANDIFs would be split into two separate IFs but since it had been replaced with
and AND instead the truth value gets computed by the gimplifier:
004t.gimple
h (int a, int b, int c, int d)
{
int D.2246;
_1 = a == d;
_2 = b > c;
_3 = _1 & _2;
if (_3 != 0) goto ; else goto ;
:
D.2246 = d;
// predicted unlikely by early return (on trees) predictor.
return D.2246;
:
D.2246 = a;
return D.2246;
}
which eventually gets optimized in phiop1 to:
Removing basic block 3
;; basic block 3, loop depth 0
;; pred: 2
;; succ: 4
COND_EXPR in block 2 and PHI in block 4 converted to straightline code.
Merging blocks 2 and 4
fix_loop_structure: fixing up loops for function
h (int a, int b, int c, int d)
{
_Bool _1;
_Bool _2;
_Bool _3;
[local count: 1073741825]:
_1 = a_5(D) == d_6(D);
_2 = b_7(D) > c_8(D);
_3 = _1 & _2;
return a_5(D);
}
No IFs.
[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81184 --- Comment #10 from Andreas Krebbel --- I've verified that the problem is fixed on Power. So I've opened a separate BZ for this #85368
[Bug tree-optimization/85368] [8 regression] phi-opt-11 test fails on IBM Z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85368 --- Comment #1 from Andreas Krebbel --- For e.g. Power this has been fixed as part of PR81184
[Bug tree-optimization/85366] Failure to use both div and mod results of one IDIV in a prime-factor loop while(n%i==0) { n/=i; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85366 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-12 Component|target |tree-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. I think the most natural thing would be to apply additional jump threading here (aka rotate the inner loop).
[Bug tree-optimization/85360] FAIL: gfortran.dg/deallocate_stat.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85360 --- Comment #1 from Richard Biener --- Can't reproduce with a cross from x86_64-linux on r259337. Any special configury required?
[Bug testsuite/85368] [8 regression] phi-opt-11 test fails on IBM Z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85368 Richard Biener changed: What|Removed |Added Component|tree-optimization |testsuite Target Milestone|--- |8.0 --- Comment #2 from Richard Biener --- Testsuite issue.
[Bug middle-end/85369] New: no -Wstringop-overflow for a strcpy / stpcpy call with a nonstring pointer when providing movstr pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85369 Bug ID: 85369 Summary: no -Wstringop-overflow for a strcpy / stpcpy call with a nonstring pointer when providing movstr pattern Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org Target Milestone: --- c-c++-common/attr-nonstring-3.c fails on IBM Z. A warning only appears when the strcpy/stpcpy are expanded as normal calls. If the back-end provides the movstr expander no warning will appear (if the expander can be used). Just issuing a warning in the builtin expansion logic might end up emitting two warnings: see PR85359
[Bug gcov-profile/85370] New: [GCOV] Wrong coverage with the target_clones attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85370
Bug ID: 85370
Summary: [GCOV] Wrong coverage with the target_clones attribute
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)
$ cat small.c
__attribute__((target_clones("arch=slm","default")))
int foo1 (int a, int b) {
return a + b;
}
int foo2 (int a, int b) {
return a + b;
}
int main() {
foo1(1, 1);
foo2(1, 1);
return 1;
}
$ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:88.89% of 9
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:__attribute__((target_clones("arch=slm","default")))
#:2:int foo1 (int a, int b) {
1:3: return a + b;
-:4:}
-:5:
1:6:int foo2 (int a, int b) {
1:7: return a + b;
-:8:}
-:9:
1: 10:int main() {
1: 11: foo1(1, 1);
1: 12: foo2(1, 1);
1: 13: return 1;
1: 14:}
Line #2 is wrongly marked as not executed with "#".
Function foo2 is with no attribute, the coverage of function foo2 is correct.
[Bug c/85361] Variable length array allowed in c89/90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85361 Will Hawkins changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME |--- --- Comment #2 from Will Hawkins --- (In reply to Richard Biener from comment #1) > It's been a GCC extension so you need -pedantic or -pedantic-errors. Got it! Thank you for your response! But, shouldn't that behavior be isolated to the gnu90 standard rather than the c90 c89 iso9899:1990 standards?
[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315 --- Comment #8 from rguenther at suse dot de --- On Wed, 11 Apr 2018, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315 > > --- Comment #7 from Martin Sebor --- > I asked Peter about that yesterday. The access to *p in your example is still > meant to be undefined even under the proposed provenance rules. Here's his Even with -fno-provenance? > response: http://www.open-std.org/jtc1/sc22/wg14/15051 It's not yet entirely > clear to me how to derive this answer from the proposed wording but if it > can't > be it's presumably just a bug that will be fixed. > > I think the intent of the "happens to immediately follow the first array > object in the address space" was to allow implementations to return true for > the (&a + i == &b) kind of equalities and the text just came out wrong (as a > requirement rather than a permission). The text was added in C99 but I > haven't > yet been able to find the paper that added it. OK, even GCC might end up computing true if we don't optimize but translate to a cmp instruction and var layout happens to be. Like for -O0 and int *p = &a + i; int *q = &b; if (p == q) ... but at -O1 we'd always compute it as false. > The implications of the "immediately follows the first array" sentence for > equality having to return true would be at odds with the "single provenance" > and so the result of the equality is only specified with -fno-provenance > (otherwise it's unspecified). > > Regarding your suggestion for the equality being undefined, since it's > well-defined in C and explicitly unspecified in C++, changing it to undefined > in C would introduce an incompatibility with C++. That would go against > WG14's I think for the compiler "unspecified" works as well - we can still unconditionally optimize it to return false, correct? > goal (part of C2X charter) to align more closely with C++. To make it pass in > WG14, C++ would most likely have to agree to change first. But I'll bring it > up during the meeting. > > The rationale for the-f[no-]provenance option is discussed in N2119. It > sounds > like the authors think it disabling the provenance rules might make for more > intuitive behavior and help avoid bugs. I'll also bring it at the meeting. The issue I see is that implementing -fno-provenance is impossible (well, we might be able to alias it to -O0 and disable all folding). But I don't have time to read up its full specification/rationale right now.
[Bug lto/85371] New: [8 Regression] Compiling code with -g -flto gives an ICE on darwin after revision r259317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85371 Bug ID: 85371 Summary: [8 Regression] Compiling code with -g -flto gives an ICE on darwin after revision r259317 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin17 Target: x86_64-apple-darwin17 Build: x86_64-apple-darwin17 Compiling code with -g -flto gives an ICE on darwin: (lldb) run -g -flto /opt/gcc/work/gcc/testsuite/gfortran.dg/allocatable_function_3.f90 Process 8193 launched: '/opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/8.0.1/f951' (x86_64) transform_to_spectral_from scram MAIN__ main Analyzing compilation unit Process 8193 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x0001010209c3 f951`darwin_asm_output_dwarf_offset(file=0x7fffb5933030, size=4, lab="*Lskeleton_debug_line0", offset=0, base=0x) at darwin.c:2900 2897 bool is_for_lto; 2898 const char *lto_add = ""; 2899 -> 2900 gcc_checking_assert (base->common.flags & SECTION_NAMED); 2901 is_for_lto = strncmp (base->named.name, "__GNU_DWARF_LTO,", 16) == 0; 2902 gcc_checking_assert (is_for_lto 2903|| strncmp (base->named.name, "__DWARF,", 8) == 0); Target 0: (f951) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x0001010209c3 f951`darwin_asm_output_dwarf_offset(file=0x7fffb5933030, size=4, lab="*Lskeleton_debug_line0", offset=0, base=0x) at darwin.c:2900 frame #1: 0x0001007671a1 f951`dw2_asm_output_offset(size=, label=, base=, comment="%s") at dwarf2asm.c:198 frame #2: 0x0001007996b8 f951`::output_die(die=0x000143ed8000) at dwarf2out.c:10780 frame #3: 0x00010079a420 f951`::output_comp_unit(die=, output_if_empty=, dwo_id=) at dwarf2out.c:11037 frame #4: 0x0001007c41f1 f951`::dwarf2out_early_finish(filename="/opt/gcc/work/gcc/testsuite/gfortran.dg/allocatable_function_3.f90") at dwarf2out.c:31900 frame #5: 0x0001006eb09a f951`symbol_table::finalize_compilation_unit(this=0x000143d25100) at cgraphunit.c:2713 frame #6: 0x000100c3a3fa f951`::compile_file() at toplev.c:480 frame #7: 0x0001012a665b f951`toplev::main(int, char**) at toplev.c:2132 frame #8: 0x0001012a819e f951`main(argc=4, argv=0x7ffeefbff200) at main.c:39 frame #9: 0x7fff7d651015 libdyld.dylib`start + 1 Reverting revision r259317 returns to normal.
[Bug gcov-profile/85372] New: [GCOV] Wrong coverage with setjmp and longjmp function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85372
Bug ID: 85372
Summary: [GCOV] Wrong coverage with setjmp and longjmp function
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)
$ cat small.c
void *buf[5];
void fjmp (void) {
__builtin_longjmp (buf, 1);
}
int main(void)
{
int last = 0;
if (__builtin_setjmp (buf) == 0) {
__builtin_printf("True branch\n");
while (1) {
last = 1;
fjmp ();
}
} else {
__builtin_printf("False branch\n");
}
return 0;
}
$ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
True branch
False branch
File 'small.c'
Lines executed:90.00% of 10
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:void *buf[5];
-:2:
1:3:void fjmp (void) {
1:4: __builtin_longjmp (buf, 1);
-:5:}
-:6:
1:7:int main(void)
-:8:{
1:9: int last = 0;
-: 10:
2: 11: if (__builtin_setjmp (buf) == 0) {
1: 12:__builtin_printf("True branch\n");
-: 13:while (1) {
#: 14: last = 1;
1: 15: fjmp ();
-: 16:}
-: 17: } else {
1: 18:__builtin_printf("False branch\n");
-: 19: }
-: 20:
1: 21: return 0;
-: 22:}
Line #14 is wrongly marked as not executed with "#".
In the first setjmp always return 0, then execute the true branch. Thus, Line
#14 should be executed.
[Bug lto/85371] [8 Regression] Compiling code with -g -flto gives an ICE on darwin after revision r259317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85371 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-12 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/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
W.H. Ding changed:
What|Removed |Added
CC||dingcurie at icloud dot com
--- Comment #47 from W.H. Ding ---
Hi, everyone
I wonder if this issue has to do with the bug-like problem I encountered when
accessing an unaligned stand-alone global variable (rather than a member of a
packed struct). A test case is as follows:
char g_c = 'x';
int g_d __attribute__((aligned(1))) = 13;
int main(void)
{
g_c = 'z';
//
g_d = 33;// Crash on, in my case, ARM Cortex-M0
//
return 0;
}
Due to the presence of g_c, g_d is at an odd address, as the map file
indicates:
.data.g_c 0x20200x1 ./src/test.o
0x2020g_c
.data.g_d 0x20210x4 ./src/test.o
0x2021g_d
The generated assembly, however, accesses g_d as if it were properly aligned:
8:../src/test.c //
9:../src/test.c g_d = 33;
52.loc 1 9 0
53 000a 044B ldr r3, .L2+4
54 000c 2122 movsr2, #33
55 000e 1A60 str r2, [r3]
10:../src/test.c //
BTW: I'm using GNU ARM Embedded Toolchain 7-2017-q4-major and on Windows 7.
Any ideas?
[Bug lto/85371] [8 Regression] Compiling code with -g -flto gives an ICE on darwin after revision r259317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85371 --- Comment #2 from Richard Biener --- Created attachment 43916 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43916&action=edit patch I am testing The attached solved the crash I reproduced with a cross.
[Bug rtl-optimization/85342] [8 Regression] ICE: SIGSEGV in copyprop_hardreg_forward_1 (regcprop.c:995) with -O2 -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85342 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Apr 12 08:39:50 2018 New Revision: 259338 URL: https://gcc.gnu.org/viewcvs?rev=259338&root=gcc&view=rev Log: PR rtl-optimization/85342 * regcprop.c (copyprop_hardreg_forward_1): Remove replaced array, use a bool scalar var inside of the loop instead. Don't try to update recog_data.operand after failed apply_change_group. * gcc.target/i386/pr85342.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr85342.c Modified: trunk/gcc/ChangeLog trunk/gcc/regcprop.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/85342] [8 Regression] ICE: SIGSEGV in copyprop_hardreg_forward_1 (regcprop.c:995) with -O2 -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85342 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug fortran/85352] Incorrect error diagnosed for dummy argument used in specification expression to subprogram with ENTRY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85352 --- Comment #3 from mecej4 --- I found a server that had an older version of GCC, on which the test code compiled without error messages from the compiler: gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC)
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #48 from rguenther at suse dot de ---
On Thu, 12 Apr 2018, dingcurie at icloud dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> W.H. Ding changed:
>
>What|Removed |Added
>
> CC||dingcurie at icloud dot com
>
> --- Comment #47 from W.H. Ding ---
> Hi, everyone
>
> I wonder if this issue has to do with the bug-like problem I encountered when
> accessing an unaligned stand-alone global variable (rather than a member of a
> packed struct). A test case is as follows:
>
> char g_c = 'x';
> int g_d __attribute__((aligned(1))) = 13;
>
> int main(void)
> {
> g_c = 'z';
> //
> g_d = 33;// Crash on, in my case, ARM Cortex-M0
> //
> return 0;
> }
>
> Due to the presence of g_c, g_d is at an odd address, as the map file
> indicates:
>
> .data.g_c 0x20200x1 ./src/test.o
> 0x2020g_c
> .data.g_d 0x20210x4 ./src/test.o
> 0x2021g_d
>
> The generated assembly, however, accesses g_d as if it were properly aligned:
>
>8:../src/test.c //
>9:../src/test.c g_d = 33;
> 52.loc 1 9 0
> 53 000a 044B ldr r3, .L2+4
> 54 000c 2122 movsr2, #33
> 55 000e 1A60 str r2, [r3]
> 10:../src/test.c //
>
> BTW: I'm using GNU ARM Embedded Toolchain 7-2017-q4-major and on Windows 7.
>
> Any ideas?
It looks like RTL expansion is broken here (also on x86_64):
;; g_d = 33;
(insn 6 5 0 (set (mem/c:SI (symbol_ref:DI ("g_d") [flags 0x2] ) [1 g_d+0 S4 A32])
(const_int 33 [0x21])) "t.c":7 -1
(nil))
notice how the MEM has 32bit alignment. This is probably because
while g_d has a DECL_ALIGN of 8 it has a type with TYPE_ALIGN of 32.
IIRC there's related bugs for the FEs that taking the address of
g_d results in a 32bit aligned int * pointer and thus
*&g_d has different alignment than g_d.
A workaround is to place such variables in a struct I guess.
The "bug" is in set_mem_attributes_minus_bitpos (when you ignore
the FE bug of mismatch of decl and type alignment):
/* We can set the alignment from the type if we are making an object or if
this is an INDIRECT_REF. */
if (objectp || TREE_CODE (t) == INDIRECT_REF)
attrs.align = MAX (attrs.align, TYPE_ALIGN (type));
a workaround would be to do the following as in the !TYPE_P path
we already use the type to derive alignment when allowed.
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 259337)
+++ gcc/emit-rtl.c (working copy)
@@ -1985,9 +1985,8 @@ set_mem_attributes_minus_bitpos (rtx ref
able to simply always use TYPE_ALIGN? */
}
- /* We can set the alignment from the type if we are making an object or
if
- this is an INDIRECT_REF. */
- if (objectp || TREE_CODE (t) == INDIRECT_REF)
+ /* We can set the alignment from the type if we are making an object.
*/
+ if (objectp && TYPE_P (t))
attrs.align = MAX (attrs.align, TYPE_ALIGN (type));
/* If the size is known, we can set that. */
[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 --- Comment #23 from Eric Botcazou --- > Huh, no. Never seen that. Well, well, well... ;-) Index: lto-wrapper.c === --- lto-wrapper.c (revision 259205) +++ lto-wrapper.c (working copy) @@ -983,7 +983,7 @@ debug_objcopy (const char *infile) infile = fname; inoff = (off_t) loffset; } - int infd = open (infile, O_RDONLY); + int infd = open (infile, O_RDONLY | O_BINARY); if (infd == -1) return NULL; simple_object_read *inobj = simple_object_start_read (infd, inoff,
[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 --- Comment #24 from rguenther at suse dot de --- On Thu, 12 Apr 2018, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 > > --- Comment #23 from Eric Botcazou --- > > Huh, no. Never seen that. > > Well, well, well... ;-) He! Thanks - counts as obvious. > Index: lto-wrapper.c > === > --- lto-wrapper.c (revision 259205) > +++ lto-wrapper.c (working copy) > @@ -983,7 +983,7 @@ debug_objcopy (const char *infile) >infile = fname; >inoff = (off_t) loffset; > } > - int infd = open (infile, O_RDONLY); > + int infd = open (infile, O_RDONLY | O_BINARY); >if (infd == -1) > return NULL; >simple_object_read *inobj = simple_object_start_read (infd, inoff,
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #77 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #62 from Richard Biener --- > Waiting for Solaris engineer input... (or a machine to be able to debug this > directly - is there one on the CF?). We're finally getting to the bottom of this: * The original analysis of the objects rewritten by lto-wrapper and passed to ld -r (which cause the relocation error) pointed out that they were in violation of the ELF gABI access rules for COMDAT sections: https://docs.oracle.com/cd/E53394_01/html/E54813/chapter7-26.html#scrolltoc (the first bullet point). * However, while checking the input objects passed to lto-wrapper, I determined they have the same problem, but don't trigger the error. * It turned out that this happened because Solaris ld has heuristics to implicitly relax that check for gcc objects, as can be done explicitly with -z relax=comdat/-z relaxreloc. It checks for a .comment section containing the string "GCC: (GNU)". However, unlike the input objects, that section isn't copied by simple_object_copy_lto_debug_sections. Since trying to fix the initial issue is out of scope for GCC 8, there are two possible fixes: * Just copy the .comment section as well. Turns out to be trivial, and the attached patch does just that. * Pass -z relaxreloc to the ld -r invocation in lto-wrapper. This is uglier and needs more code.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #78 from Rainer Orth --- Created attachment 43917 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43917&action=edit Proposed patch for gcc.dg/debug/pr41893-1.c failure
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #79 from rguenther at suse dot de --- On Thu, 12 Apr 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 > > --- Comment #77 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- > > --- Comment #62 from Richard Biener --- > > Waiting for Solaris engineer input... (or a machine to be able to debug > > this > > directly - is there one on the CF?). > > We're finally getting to the bottom of this: > > * The original analysis of the objects rewritten by lto-wrapper and > passed to ld -r (which cause the relocation error) pointed out that > they were in violation of the ELF gABI access rules for COMDAT > sections: > > https://docs.oracle.com/cd/E53394_01/html/E54813/chapter7-26.html#scrolltoc > > (the first bullet point). > > * However, while checking the input objects passed to lto-wrapper, I > determined they have the same problem, but don't trigger the error. > > * It turned out that this happened because Solaris ld has heuristics to > implicitly relax that check for gcc objects, as can be done explicitly > with -z relax=comdat/-z relaxreloc. It checks for a .comment section > containing the string "GCC: (GNU)". However, unlike the input > objects, that section isn't copied by simple_object_copy_lto_debug_sections. > > Since trying to fix the initial issue is out of scope for GCC 8, there > are two possible fixes: > > * Just copy the .comment section as well. Turns out to be trivial, and > the attached patch does just that. Sounds good - I suppose identical .comment sections are merged in the final link.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #80 from Richard Biener --- (In reply to Rainer Orth from comment #78) > Created attachment 43917 [details] > Proposed patch for gcc.dg/debug/pr41893-1.c failure OK. Can you add a comment as to why we do that? Thanks.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #82 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #80 from Richard Biener --- > (In reply to Rainer Orth from comment #78) >> Created attachment 43917 [details] >> Proposed patch for gcc.dg/debug/pr41893-1.c failure > > OK. Can you add a comment as to why we do that? Thanks. Sure. Will repost with ChangeLog to gcc-patches. Thanks. Rainer
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #81 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #79 from rguenther at suse dot de --- > On Thu, 12 Apr 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote: [...] >> Since trying to fix the initial issue is out of scope for GCC 8, there >> are two possible fixes: >> >> * Just copy the .comment section as well. Turns out to be trivial, and >> the attached patch does just that. > > Sounds good - I suppose identical .comment sections are merged in the > final link. Indeed. E.g. in cc1 the .comment section is just GCC: (GNU) 8.0.1 20180411 (experimental) [trunk revision 259325] as: Studio 12.6 Compiler Common 12.6 SunOS_i386 st_017 03/03/2018 GCC: (GNU) 4.9.0 GCC: (GNU) 7.1.0 ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.3143 so the space cost is acceptable.
[Bug fortran/85352] [6/7/8 Regression] Incorrect error diagnosed for dummy argument used in specification expression to subprogram with ENTRY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85352 Dominique d'Humieres changed: What|Removed |Added Keywords||rejects-valid Known to work||4.5.4 Summary|Incorrect error diagnosed |[6/7/8 Regression] |for dummy argument used in |Incorrect error diagnosed |specification expression to |for dummy argument used in |subprogram with ENTRY |specification expression to ||subprogram with ENTRY Known to fail||4.6.4, 4.7.3, 4.8.5, 4.9.3, ||5.5.0, 6.4.0, 7.3.0, 8.0.1 --- Comment #4 from Dominique d'Humieres --- > I found a server that had an older version of GCC, on which the test code > compiled without error messages from the compiler: It compiles also with 4.5.4, but not with 4.6.4. The change occurred between revisions r162456 (2010-07-23, compiles) and r1635293 (2010-08-24, error), r162486 (pr45030)?
[Bug target/71991] Inconsistency for __attribute__ ((__always_inline__)) among LTO and non-LTO compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71991 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- (In reply to Jan Hubicka from comment #5) > Created attachment 43798 [details] > proposed fix > > > this patch simply while-lists some transitions of target flags for always > inline functions. It is ugly but I can't think of anything else which would > look safe. > Martin, you mentioned there was packages broken by this. Perhaps we can try > rebuild with this patch to see if all of the real world issues are solved? > If not, i guess we will need to decide case-by-case what is safe and what > not :( I think that patch is quite reasonable, with a couple of small nits LGTM s/alwyas/always/ put = on the next line in bool always_inline = and perhaps add int safe_mask = always_inline ? always_inline_safe_mask : 0; and use unconditionally (caller_opts->x_target_flags & ~safe_mask) != (callee_opts->x_target_flags & ~safe_mask) maybe use unsigned HOST_WIDE_INT instead of int for the masks, so when the masks grow beyond 32 bits we don't suddenly misbehave (or add gcc_chec king_assert that sizeof (callee_opts->x_target_flags) == sizeof (always_inline_safe_mask) The xen case should just be fixed in xen IMHO.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #49 from Sven ---
(In reply to W.H. Ding from comment #47)
> Hi, everyone
>
> I wonder if this issue has to do with the bug-like problem I encountered
> when accessing an unaligned stand-alone global variable (rather than a
> member of a packed struct). A test case is as follows:
>
> char g_c = 'x';
> int g_d __attribute__((aligned(1))) = 13;
>
> int main(void)
> {
> g_c = 'z';
> //
> g_d = 33;// Crash on, in my case, ARM Cortex-M0
> //
> return 0;
> }
This doesn't work. The aligned attribute is for providing additional alignment
hints. The GCC documentation clearly states, that aligned can increase the
alignment. So g_d is still 4 byte aligned, and correctly so.
Also, you cannot use the packed attribute (which reduces the alignment to 1)
for simple types. You can only use it for structs.
Try a packed struct that contains a single int. That will work.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #50 from Sven --- (In reply to Sven from comment #49) > This doesn't work. The aligned attribute is for providing additional > alignment hints. The GCC documentation clearly states, that aligned can > increase the alignment. So g_d is still 4 byte aligned, and correctly so. Submitted too soon. Should have been "The GCC documentation clearly states that the aligned attribute can only increase the alignment"
[Bug gcov-profile/85367] [GCOV] A call to the _subborrow_u64 builtin-function is wrongly marked as executed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85367 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-12 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug gcov-profile/85372] [GCOV] Wrong coverage with setjmp and longjmp function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85372 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-12 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug gcov-profile/85370] [GCOV] Wrong coverage with the target_clones attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85370 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-12 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #9 from Jakub Jelinek ---
So (completely untested):
--- gcc/asan.c.jj 2018-01-09 21:53:38.821577722 +0100
+++ gcc/asan.c 2018-04-12 12:30:43.360840432 +0200
@@ -554,14 +554,14 @@ get_last_alloca_addr ()
return last_alloca_addr;
}
-/* Insert __asan_allocas_unpoison (top, bottom) call after
+/* Insert __asan_allocas_unpoison (top, bottom) call before
__builtin_stack_restore (new_sp) call.
The pseudocode of this routine should look like this:
- __builtin_stack_restore (new_sp);
top = last_alloca_addr;
bot = new_sp;
__asan_allocas_unpoison (top, bot);
last_alloca_addr = new_sp;
+ __builtin_stack_restore (new_sp);
In general, we can't use new_sp as bot parameter because on some
architectures SP has non zero offset from dynamic stack area. Moreover, on
some architectures this offset (STACK_DYNAMIC_OFFSET) becomes known for
each
@@ -584,9 +584,9 @@ handle_builtin_stack_restore (gcall *cal
tree restored_stack = gimple_call_arg (call, 0);
tree fn = builtin_decl_implicit (BUILT_IN_ASAN_ALLOCAS_UNPOISON);
gimple *g = gimple_build_call (fn, 2, last_alloca, restored_stack);
- gsi_insert_after (iter, g, GSI_NEW_STMT);
+ gsi_insert_before (iter, g, GSI_SAME_STMT);
g = gimple_build_assign (last_alloca, restored_stack);
- gsi_insert_after (iter, g, GSI_NEW_STMT);
+ gsi_insert_before (iter, g, GSI_SAME_STMT);
}
/* Deploy and poison redzones around __builtin_alloca call. To do this, we
? If the __builtin_stack_restore is at the end of function or isn't even
present at all (if __builtin_alloca is used), then it is already doing the
right thing. Small testcase:
void baz (char *, int);
void
foo (int n)
{
baz (__builtin_alloca (n), n);
}
void
bar (int n)
{
{
char a[n];
baz (a, n);
}
{
char b[n + 2];
baz (b, n + 2);
}
}
The patch only changes the order of __asan_allocas_unpoison and stack restore
after the first call to baz from bar above, the rest is unchanged.
[Bug c++/85363] Throwing exception from member constructor (brace initializer vs initializer list)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85363
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-04-12
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Please provide *complete* testcases, not ones missing headers.
Confirmed with this:
int init (int f) {
throw f;
}
struct X {
X (int f) : n {init (f)} {}
int n;
};
struct P {
X x {20};
};
int main ()
{
try {
P p {};
}
catch (int n) {
return 0;
}
return 1;
}
It only fails in C++11 mode, not C++14 or later.
[Bug demangler/85373] New: Ice in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85373 Bug ID: 85373 Summary: Ice in demangler Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: fiesh at zefix dot tv Target Milestone: --- The following leads to cxxfilt running with 100% CPU indefinitely: /tmp/binutils-gdb/binutils (master✗) % echo '_ZN9QtPrivate18QFunctorSlotObjectIZN9MainOwner20setupCommandLineModeEvEUlT_E_Li1ENS_4ListIJN5boost6fusion3mapIJNS6_4pairIN3row12ManufacturerESt10shared_ptrIKSt6vectorISA_SaISA_ENS8_INS9_8MaterialESB_IKSC_ISI_SaISI_ENS8_INS9_12UserMaterialESB_IKSC_ISO_SaISO_ENS8_INS9_13UpperDieGroupESB_IKSC_ISU_SaISU_ENS8_INS9_13LowerDieGroupESB_IKSC_IS10_SaIS10_ENS8_INS9_16AirBendDeductionESB_IKSC_IS16_SaIS16_ENS8_INS9_8UpperDieESB_IKSC_IS1C_SaIS1C_ENS8_INS9_8LowerDieESB_IKSC_IS1I_SaIS1I_ENS8_INS9_12UpperDieUnitESB_IKSC_IS1O_SaIS1O_ENS8_INS9_12LowerDieUnitESB_IKSC_IS1U_SaIS1U_ENS8_INS9_16LaserCuttingTypeESB_IKSC_IS20_SaIS20_ENS8_INS9_22LaserCuttingTechnologyESB_IKSC_IS26_SaIS26_ENS8_INS9_8WorkStepESB_IKSC_IS2C_SaIS2C_ENS8_INS9_14CalcPriceBlockESB_IKSC_IS2I_SaIS2I_ENS8_INS9_19CalcSheetMetalPriceESB_IKSC_IS2O_SaIS2O_ENS8_INS9_26CalcLaserCuttingTechnologyESB_IKSC_IS2U_SaIS2U_ENS8_INS9_16CalcAirBendTimesESB_IKSC_IS30_SaIS30_ENS8_INS9_19CalcWorkStepPricingESB_IKSC_IS36_SaIS36_ENS8_INS9_19UserDefinedWorkStepESB_IKSC_IS3C_SaIS3C_ENS8_INS9_14CalcSurchargesESB_IKSC_IS3I_SaIS3I_ENS8_INS9_15UserContactDataESB_IKSC_IS3O_SaIS3O_ENS8_INS9_15TermsOfDeliveryESB_IKSC_IS3U_SaIS3U_ENS8_INS9_14TermsOfPaymentESB_IKSC_IS40_SaIS40_ENS8_INS9_8CustomerESB_IKSC_IS46_SaIS46_ENS8_INS9_21CustomerContactPersonESB_IKSC_IS4C_SaIS4C_ENS8_INS9_15CustomerAddressESB_IKSC_IS4I_SaIS4I_ENS8_INS9_12SupplierTypeESB_IKSC_IS4O_SaIS4O_ENS8_INS9_8SupplierESB_IKSC_IS4U_SaIS4U_ENS8_INS9_21SupplierContactPersonESB_IKSC_IS50_SaIS50_ENS8_INS9_15SupplierAddressESB_IKSC_IS56_SaIS56_ENS8_INS9_20CalcLaserCuttingTypeESB_IKSC_IS5C_SaIS5C_ENS8_INS9_22CalcCustomerPriceBlockESB_IKSC_IS5I_SaIS5I_ENS8_INS9_29CommonConstraintsSheetCuttingESB_IKSC_IS5O_SaIS5O_ENS8_INS9_31SpecificConstraintsSheetCuttingESB_IKSC_IS5U_SaIS5U_EEEvE4implEiPNS_15QSlotObjectBaseEP7QObjectPPvPb' | ./cxxfilt (I originally reported this bug erroneously here: https://sourceware.org/bugzilla/show_bug.cgi?id=23045)
[Bug c++/85363] Throwing exception from member constructor (brace initializer vs initializer list)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85363
--- Comment #2 from Jonathan Wakely ---
In C++11 mode the compiler emits a constructor for P:
;; Function constexpr P::P() (null)
;; enabled by -tree-original
{
>
20 ) >;
}
And the initialization of p{} in main is different:
;; Function int main() (null)
;; enabled by -tree-original
{
<<< Unknown tree: try_block
{
struct P p;
struct P p;
<>> >>>) >;
}
<<< Unknown tree: handler
try
{
<;
return = 0;
}
finally
{
__cxa_end_catch ();
} >>> >>>;
return = 1;
}
return = 0;
Whereas in C++14 mode p.x gets constructed directly:
;; Function int main() (null)
;; enabled by -tree-original
{
<<< Unknown tree: try_block
{
struct P p;
struct P p;
<>>
20 >;
}
<<< Unknown tree: handler
try
{
<;
return = 0;
}
finally
{
__cxa_end_catch ();
} >>> >>>;
return = 1;
}
return = 0;
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #10 from Jakub Jelinek --- Unfortunately that doesn't work, because the second argument to __asan_allocas_unpoison is incorrect then.
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #11 from chefmax at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #10) > Unfortunately that doesn't work, because the second argument to > __asan_allocas_unpoison is incorrect then. Unfortunately we can't use new_sp as a second parameter for __asan_allocas_unpoison, because e.g. for PowerPC it doesn't point to a new (restored) dynamic stack area (http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#DYNAM-STACK). That's why current implementation inserts __asan_allocas_unpoison after __builtin_stack_restore and uses virtual_dynamic_stack_rtx as a second argument. We can probably use a 'new_sp + STACK_DYNAMIC_OFFSET' for a second argument for __asan_allocas_unpoison inside expand_asan_emit_allocas_unpoison, but AFAIU STACK_DYNAMIC_OFFSET becomes valid only in pass_instantiate_virtual_regs (so we can't rely on it during pass_expand).
[Bug c++/85374] New: Confusing diagnostic for function with missing brace that looks like a function-try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85374
Bug ID: 85374
Summary: Confusing diagnostic for function with missing brace
that looks like a function-try-block
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
I had a function that originally looked like:
int func(int some, int params, int blah) {
and I removed the parameters, unintentionally also removing the opening brace
at the end of the line, to give:
int func()
// Oops, opening brace missing
try {
throw 1;
}
catch (...) {
return 0;
}
return 1;
}
a.cc:9:5: error: expected unqualified-id before 'return'
return 1;
^~
a.cc:10:1: error: expected declaration before '}' token
}
^
Clang does a bit better by saying "extraneous closing brace":
a.cc:9:5: error: expected unqualified-id
return 1;
^
a.cc:10:1: error: extraneous closing brace ('}')
}
^
2 errors generated.
I couldn't figure out what was wrong with the code from GCC's error, and only
saw the problem after trying to compile it with Clang.
[Bug c++/85374] Confusing diagnostic for function with missing brace that looks like a function-try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85374 --- Comment #1 from Jonathan Wakely --- If we see a return statement outside a function block it should be a clue that there's some incorrect brace nesting going on.
[Bug tree-optimization/85375] New: possible missed optimisation / regression from 6.3 with while (__builtin_ffs(x) && x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85375
Bug ID: 85375
Summary: possible missed optimisation / regression from 6.3
with while (__builtin_ffs(x) && x)
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at oracle dot com
Target Milestone: ---
Input:
extern int a;
int f(int x)
{
while (__builtin_ffs(x) && x)
x -= a;
return x;
}
gcc 6.3.0 with -O3 compiled this as:
f(int):
movl %edi, %eax
movl a(%rip), %esi
movl $-1, %ecx
jmp .L3
.L11:
testl %eax, %eax
je .L2
subl %esi, %eax
.L3:
bsfl %eax, %edx
cmove %ecx, %edx
cmpl $-1, %edx
jne .L11
.L2:
rep ret
whereas current trunk (also with -O3) compiles it as:
f(int):
movl $-1, %ecx
bsfl %edi, %eax
cmove %ecx, %eax
cmpl %ecx, %eax
je .L5
testl %edi, %edi
je .L6
movl a(%rip), %esi
movl %edi, %eax
jmp .L3
.L4:
testl %eax, %eax
je .L1
.L3:
subl %esi, %eax
bsfl %eax, %edx
cmove %ecx, %edx
cmpl $-1, %edx
jne .L4
ret
.L6:
xorl %eax, %eax
.L1:
ret
.L5:
movl %edi, %eax
ret
There are fewer instructions overall for the case where x is 0 on entry, but
trunk still has longer code overall even if we change the while-condition to
__builtin_expect(!!__builtin_ffs(x) && x, 1) which ideally should pessimise
this case.
For the same input, clang trunk with -O3 gives:
f(int): # @f(int)
test edi, edi
je .LBB0_3
mov eax, dword ptr [rip + a]
neg edi
.LBB0_2: # =>This Inner Loop Header: Depth=1
add edi, eax
jne .LBB0_2
.LBB0_3:
xor eax, eax
ret
This seems to rely simply on the fact that (__builtin_ffs(x) == 0) and (x == 0)
are equivalent.
If you simplify the while-condition to simply __builtin_ffs(x), then the
difference is smaller but still there:
6.3.0:
f(int):
movl %edi, %eax
movl a(%rip), %esi
movl $-1, %ecx
jmp .L3
.L5:
subl %esi, %eax
.L3:
bsfl %eax, %edx
cmove %ecx, %edx
cmpl $-1, %edx
jne .L5
rep ret
trunk:
f(int):
movl $-1, %ecx
bsfl %edi, %eax
cmove %ecx, %eax
cmpl %ecx, %eax
je .L4
movl a(%rip), %esi
movl %edi, %eax
.L3:
subl %esi, %eax
bsfl %eax, %edx
cmove %ecx, %edx
cmpl $-1, %edx
jne .L3
ret
.L4:
movl %edi, %eax
ret
[Bug target/85328] [8 Regression] accessing ymm16 with non-avx512 instruction form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85328 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Thu Apr 12 11:17:23 2018 New Revision: 259344 URL: https://gcc.gnu.org/viewcvs?rev=259344&root=gcc&view=rev Log: PR target/85328 * config/i386/sse.md (avx512dq_vextract64x2_1 split, avx512f_vextract32x4_1 split, vec_extract_lo_ split, vec_extract_lo_v32hi, vec_extract_lo_v64qi): For non-AVX512VL if input is xmm16+ reg and output is a reg, avoid creating invalid lowpart subreg, but instead split into a 512-bit move. Don't split if not AVX512VL, input is xmm16+ reg and output is a mem. (vec_extract_lo_, vec_extract_lo_v32hi, vec_extract_lo_v64qi): Don't require split if not AVX512VL, input is xmm16+ reg and output is a mem. * gcc.target/i386/pr85328.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr85328.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/85376] New: [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376
Bug ID: 85376
Summary: [8 Regression] wrong code with -Og -fno-dce -fgcse
-fno-tree-ccp -fno-tree-copy-prop
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 43918
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43918&action=edit
reduced testcase
Output:
$ x86_64-pc-linux-gnu-gcc -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
testcase.c -Wno-psabi
$ ./a.out
Aborted
At the assembly level:
...
# testcase.c:16: q[7] >>= __builtin_add_overflow (0xfff0, __builtin_ffs
(n), &s[5]);
mov eax, 0 # tmp201,
bsf edx, eax# _28, tmp201
mov ecx, -16# tmp204,
add eax, ecx# tmp203, tmp204
mov DWORD PTR [rsp+404], ecx# s, tmp204
# testcase.c:17: t = __builtin_ffs (g[7]);
bsf eax, DWORD PTR g[rip+28]# _38, g
lea ecx, [rcx+15] # tmp206,
cmove eax, ecx# tmp206,, _38
add eax, 1 # _38,
# testcase.c:18: e *= __builtin_sub_overflow (o, t, &f);
mov ecx, 0 # _41,
sub dl, al # tmp208, _38
jb .L7 #,
...
"sub dl, al" is using edx set in "bsf edx, eax", which is not related (and even
undefined because eax == 0).
Use of ecx is correct, even though it does not look so on the first sight ("lea
ecx, [rcx+15]" just sets ecx=-1 with affecting the flags)
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-259340-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-259340-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
gcc version 8.0.1 20180412 (experimental) (GCC)
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #12 from Dmitry Vyukov --- When/if you have a patch I can test it on kernel. But seems this is a problem for user-space too. We just need a large alloca + signal handlers, or dirty manual SP manipulations (like we have in tsan to implement "cold call" calling convention).
[Bug gcov-profile/85377] New: [GCOV] Wrong coverage with label and if(cond) break in while(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85377
Bug ID: 85377
Summary: [GCOV] Wrong coverage with label and if(cond) break in
while(1)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc pv
gcc: error: pv: No such file or directory
gcc: fatal error: no input files
compilation terminated.
root@localhost:~/ccv# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)
$ cat small.c
int g = 0;
int main ()
{
while (1)
{
int i = 2;
L1:
if (g < 1)
break;
}
while (1)
{
int i = 2;
L2:
// if (g < 1)
break;
}
return 0;
}
$ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:90.00% of 10
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int g = 0;
-:2:
1:3:int main ()
-:4:{
-:5: while (1)
#:6: {
1:7:int i = 2;
1:8:L1:
1:9:if (g < 1)
1: 10: break;
-: 11: }
-: 12:
-: 13: while (1)
-: 14: {
1: 15:int i = 2;
1: 16:L2:
-: 17:// if (g < 1)
1: 18: break;
-: 19: }
1: 20: return 0;
-: 21:}
Line #6 is wrongly marked as not executed with "#".
For the second while statement, coverage of Line #14 is correct.
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #13 from Jakub Jelinek --- Created attachment 43919 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43919&action=edit gcc8-pr85230.patch So, if you want to add STACK_DYNAMIC_OFFSET to new_sp for the second argument, then we could do either what this patch does (i.e. pass new_sp + (virtual_stack_dynamic_rtx - stack_pointer_rtx) as second argument) and rely on cse/forwprop/combine to optimize it into new_sp (if STACK_DYNAMIC_OFFSET is 0) or to just addition of some constant, or introduce a new virtual pseudo register that vregs pass would map directly to dynamic_offset.
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #14 from chefmax at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #13) > or introduce a new virtual pseudo register that vregs pass would map directly > to dynamic_offset. Yeah, that's what I though about (LLVM does pretty the same thing). But (new_sp + virtual_stack_dynamic_rtx - stack_pointer_rtx) seems like an appropriate solution too. I'll cover the testing for both approaches.
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/85375] possible missed optimisation / regression from 6.3 with while (__builtin_ffs(x) && x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85375 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-12 Blocks||85316 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- .optimized shows [local count: 114863532]: _8 = __builtin_ffs (x_4(D)); if (_8 != 0) goto ; [94.50%] else goto ; [5.50%] [local count: 108546038]: if (x_4(D) != 0) goto ; [94.50%] else goto ; [5.50%] missed jump-threading. [local count: 958878293]: # x_10 = PHI x_6 = x_10 - a.0_1; _2 = __builtin_ffs (x_6); if (_2 != 0) goto ; [94.50%] else goto ; [5.50%] [local count: 906139986]: if (x_6 != 0) goto ; [94.50%] else goto ; [5.50%] likewise. VRP needs to derive a range for x_6 from _2 != 0. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #15 from Jakub Jelinek ---
(In reply to chefmax from comment #14)
> (In reply to Jakub Jelinek from comment #13)
> > or introduce a new virtual pseudo register that vregs pass would map
> > directly to dynamic_offset.
>
> Yeah, that's what I though about (LLVM does pretty the same thing). But
> (new_sp + virtual_stack_dynamic_rtx - stack_pointer_rtx) seems like an
> appropriate solution too. I'll cover the testing for both approaches.
The above patch passed
make -j16 -k check-gcc check-g++ RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
asan.exp=alloca*'
on x86_64-linux and powerpc64-linux and without the -m32, part also on
powerpc64le-linux.
[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246 --- Comment #2 from Tom de Vries --- (In reply to Tom de Vries from comment #1) > I went through a couple of cycles of minimizing the failure, seeing > something suspicious, modifying by hand or writing a tentative patch, but > every time I went back to the original non-minimized example I got the > failure again. > > Anyway, things that may be causing this fail: > > 1. > > The og7 fix for PR85204 introduces a unified jump (bra.uni) for a jump > conditional consisting of a test for vector id == 0 && worker id == 0. The > fact that we're going a different direction in worker id 0 for vector id 0 > and vector id 1 means the branch diverges, and is _not_ unified. It seems > prudent to fix this by reverting the og7 fix and backporting the trunk fix. Fixed here: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00525.html
[Bug lto/85371] [8 Regression] Compiling code with -g -flto gives an ICE on darwin after revision r259317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85371 --- Comment #3 from Richard Biener --- Author: rguenth Date: Thu Apr 12 12:27:14 2018 New Revision: 259345 URL: https://gcc.gnu.org/viewcvs?rev=259345&root=gcc&view=rev Log: 2018-04-12 Richard Biener PR lto/85371 * dwarf2out.c (init_sections_and_labels): Use debug_line_section[_label] for the early LTO debug to properly generate references to it during DIE emission. Do not re-use that for the skeleton for split-dwarf. (dwarf2out_early_finish): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug target/85328] [8 Regression] accessing ymm16 with non-avx512 instruction form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85328 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug target/85378] New: -fsplit-stack is incompatible with -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85378 Bug ID: 85378 Summary: -fsplit-stack is incompatible with -fcf-protection -mcet Product: gcc Version: 8.0.1 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: --- -fsplit-stack requires gold linker, which doesn't support GNU property required by Intel CET: https://sourceware.org/bugzilla/show_bug.cgi?id=22914 https://sourceware.org/bugzilla/show_bug.cgi?id=22915 It should be an error to use -fsplit-stack with -fcf-protection -mcet. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 [Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs
[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246 --- Comment #3 from Tom de Vries --- (In reply to Tom de Vries from comment #1) > I went through a couple of cycles of minimizing the failure, seeing > something suspicious, modifying by hand or writing a tentative patch, but > every time I went back to the original non-minimized example I got the > failure again. > > Anyway, things that may be causing this fail: > 2. > > The bar.sync instruction may not be sufficiently understood. > > In the documentation for bar.sync it says: > ... > bar.sync and bar.red also guarantee memory ordering among threads identical > to > membar.cta . Thus, threads within a CTA that wish to communicate via memory > can > store to memory, execute a bar.sync or bar.red instruction, and then safely > read > values stored by other threads prior to the barrier. > ... > > The question is what happens when you specify a thread count. Does the > memory ordering still apply to the whole CTA, or only to the threads > participating in the barrier? > > So if we store something in vector id 0, worker id 0, and load it in worker > id 1, we may have to use a bar.sync 0 instead to synchronize (or keep the > same barrier but add a membar.cta). I misanalyzed why the test was failing, it was not a barrier problem. There are two situations in which there is state propagation: 1. when transitioning from single to partition mode, for either worker or vector (so, when entering a partitioned loop) 2. when propagating branch conditions. [ We implement worker-single and vector-single by branch around, but do not branch around branches, so the branch condition is calculated in either W0V0 or WAV0 code, and then used in WAVA code. To go from worker single to worker partitioned (W0V0 -> WAV0), we use a generic broadcast buffer. To go from vector single to vector partitioned (WAV0 -> WAVA), we use a worker-specific broadcast buffer. To propagate the branch condition, we use the worker-specific broadcast buffer, but that only works for WAV0 -> WAVA. For the W0V0 -> WAVA propagation, we need to use the generic broadcast buffer.
[Bug lto/85371] [8 Regression] Compiling code with -g -flto gives an ICE on darwin after revision r259317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85371 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Should be fixed now.
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-12 Known to work||7.3.1 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246 --- Comment #4 from Tom de Vries --- Created attachment 43920 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43920&action=edit 0001-nvptx-Simplifly-logic-in-nvptx_single.patch NFC patch to make fix easier
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 --- Comment #2 from Jakub Jelinek --- Started with r257852.
[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246 --- Comment #5 from Tom de Vries --- Created attachment 43921 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43921&action=edit 0002-nvptx-Fix-propagation-of-branch-cond-in-vw-neutered-code.patch Tentative fix.
[Bug tree-optimization/85360] FAIL: gfortran.dg/deallocate_stat.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85360 --- Comment #2 from dave.anglin at bell dot net --- On 2018-04-12 3:43 AM, rguenth at gcc dot gnu.org wrote: > Any special > configury required? No.
[Bug target/85378] -fsplit-stack is incompatible with -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85378 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- -fsplit-stack doesn't require gold linker, only if you want to build parts with -fsplit-stack and other parts without it and rely on the linker to fix it up, you need gold. So, emitting an error is just incorrect.
[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 85378, which changed state. Bug 85378 Summary: -fsplit-stack is incompatible with -fcf-protection -mcet https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85378 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376
--- Comment #3 from Richard Biener ---
-fdisable-rtl-cprop2 -fdisable-rtl-cprop1 fixes it, likewise
-fdisable-rtl-cse_local:
> diff -u t.c.245r.cprop2 t.c.247r.cse_local
...
- 41: r194:SI=0x20
- REG_DEAD r91:HI
42: r108:QI=0
- 43: {flags:CC=cmp(r194:SI#0,r104:SI#0);r195:QI=r194:SI#0-r104:SI#0;}
+ 43: {flags:CC=cmp(r93:SI#0,r104:SI#0);r195:QI=r93:SI#0-r104:SI#0;}
huh.
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 --- Comment #4 from Richard Biener --- Thus looks like a cselib issue to me.
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #16 from Dmitry Vyukov --- Here is disasm of the function with the patch: https://gist.githubusercontent.com/dvyukov/e9dca961ceb436049cf5881b3307b104/raw/05ed3daff60d00eb71ca7a85be707d6d5eca3c47/gistfile1.txt And the epilogue: 8305fe5f: 48 8d 75 d8 lea-0x28(%rbp),%rsi 8305fe63: 48 89 e7mov%rsp,%rdi 8305fe66: e8 35 a9 ac fe callq 81b2a7a0 <__asan_allocas_unpoison> 8305fe6b: 44 89 f0mov%r14d,%eax 8305fe6e: 48 8b 4d d0 mov-0x30(%rbp),%rcx 8305fe72: 65 48 33 0c 25 28 00xor%gs:0x28,%rcx 8305fe79: 00 00 8305fe7b: 0f 85 5f 01 00 00 jne8305ffe0 8305fe81: 48 8d 65 d8 lea-0x28(%rbp),%rsp 8305fe85: 5b pop%rbx 8305fe86: 41 5c pop%r12 8305fe88: 41 5d pop%r13 8305fe8a: 41 5e pop%r14 8305fe8c: 41 5f pop%r15 8305fe8e: 5d pop%rbp 8305fe8f: c3 retq Kernel boots. So far I don't see these alloca-related false positives. If I see something suspicious I will post here, but otherwise consider that everything is good. Thanks!
[Bug libgcc/85379] New: Missing ENDBR in __stack_split_initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85379 Bug ID: 85379 Summary: Missing ENDBR in __stack_split_initialize Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Blocks: 81652 Target Milestone: --- Target: x86_64-*-*, i?86-*-* 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 diff --git a/libgcc/config/i386/morestack.S b/libgcc/config/i386/morestack.S index eca441a2867..99e65eaaff4 100644 --- a/libgcc/config/i386/morestack.S +++ b/libgcc/config/i386/morestack.S @@ -730,6 +730,7 @@ __morestack_large_model: #endif __stack_split_initialize: + _CET_ENDBR #ifndef __x86_64__ fixes it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 [Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs
[Bug middle-end/84955] [7/8 Regression] Incorrect OpenACC tile expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84955 --- Comment #5 from cesar at gcc dot gnu.org --- Author: cesar Date: Thu Apr 12 13:15:45 2018 New Revision: 259346 URL: https://gcc.gnu.org/viewcvs?rev=259346&root=gcc&view=rev Log: PR middle-end/84955 gcc/ * lto-streamer-out.c (output_function): Fix CFG loop state before streaming out. * omp-expand.c (expand_oacc_for): Handle calls to internal functions like regular functions. libgomp/ * testsuite/libgomp.oacc-c-c++-common/pr84955.c: New test. * testsuite/libgomp.oacc-fortran/pr84955.f90: New test. Added: trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr84955.c trunk/libgomp/testsuite/libgomp.oacc-fortran/pr84955.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/omp-expand.c trunk/gcc/testsuite/ChangeLog
[Bug gcov-profile/85377] [GCOV] Wrong coverage with label and if(cond) break in while(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85377 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-12 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug c++/85258] [7/8 Regression] ICE with invalid range-based for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85258 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 --- Comment #5 from Jakub Jelinek --- There is nothing weird about what cprop1 does, __builtin_ffs (0) is known to be 0, with so many disabled optimizations we just don't optimize it away nor simplify earlier. So the mov eax, 0 # tmp201, bsf edx, eax# _28, tmp201 mov ecx, -16# tmp204, add eax, ecx# tmp203, tmp204 part is just fine, we replaced the edx in the addition with eax which is known to hold the same value, and because DCE is disabled nothing removes the dead bsf.
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
The bug seems to be introduced during cse_local, before that we have:
(insn 28 26 31 2 (parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 188)
(const_int 0 [0])))
(set (reg:SI 93 [ _13 ])
(ctz:SI (reg:SI 188)))
]) "pr85376.c":12 735 {*bsfsi_1}
(expr_list:REG_DEAD (reg:SI 188)
(expr_list:REG_UNUSED (reg:SI 93 [ _13 ])
(expr_list:REG_UNUSED (reg:CCZ 17 flags)
(nil)
...
(insn 55 54 56 2 (set (reg:SI 194 [ o ])
(const_int 32 [0x20])) "pr85376.c":14 86 {*movsi_internal}
(expr_list:REG_DEAD (reg/v:HI 91 [ o ])
(nil)))
(insn 56 55 57 2 (set (reg:QI 108 [ _26+1 ])
(const_int 0 [0])) "pr85376.c":14 88 {*movqi_internal}
(nil))
(insn 57 56 58 2 (parallel [
(set (reg:CC 17 flags)
(compare:CC (subreg:QI (reg:SI 194 [ o ]) 0)
(subreg:QI (reg:SI 104 [ _23 ]) 0)))
(set (reg:QI 195)
(minus:QI (subreg:QI (reg:SI 194 [ o ]) 0)
(subreg:QI (reg:SI 104 [ _23 ]) 0)))
]) "pr85376.c":14 294 {*subqi_3}
(expr_list:REG_DEAD (reg:SI 194 [ o ])
(expr_list:REG_DEAD (reg:SI 104 [ _23 ])
(nil
But cse_local changes that to:
(insn 56 54 57 2 (set (reg:QI 108 [ _26+1 ])
(const_int 0 [0])) "pr85376.c":14 88 {*movqi_internal}
(nil))
(insn 57 56 58 2 (parallel [
(set (reg:CC 17 flags)
(compare:CC (subreg:QI (reg:SI 93 [ _13 ]) 0)
(subreg:QI (reg:SI 104 [ _23 ]) 0)))
(set (reg:QI 195)
(minus:QI (subreg:QI (reg:SI 93 [ _13 ]) 0)
(subreg:QI (reg:SI 104 [ _23 ]) 0)))
]) "pr85376.c":14 294 {*subqi_3}
(expr_list:REG_DEAD (reg:SI 194 [ o ])
(expr_list:REG_DEAD (reg:SI 104 [ _23 ])
(nil
but pseudo 93 certainly isn't known to contain (const_int 32). I don't think
cse pass uses cselib though.
[Bug ada/85380] New: gnatbind fails with small executable & restricted runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85380 Bug ID: 85380 Summary: gnatbind fails with small executable & restricted runtime Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Host: x86_64-apple-darwin15 Target: arm-eabi Build: x86_64-apple-darwin15 After following the change suggested in PR ada/66205 comment 14, System.Suppress_Standard_Library set to False, I attempted to build a small program and got the error b__generate_hard_fault.adb:62:44: "Parameters" not declared in "System" gprbind: compilation of binder generated file failed This line is Default_Secondary_Stack_Size : System.Parameters.Size_Type; pragma Import (C, Default_Secondary_Stack_Size, "__gnat_default_ss_size"); and in successful builds of other programs System.Parameters is withed (in the spec; why not in the body?). On investigating, I find that none of the units in the closure required the secondary stack (the P lines didn’t contain 'SS'); this means that Opt.Sec_Stack_Used is False. The 'with System.Parameters;' line is generated at bindgen.adb:2286 if Opt.Sec_Stack_Used is True. If Suppress_Standard_Library_On_Target is False, the 'Default_Secondary_Stack_Size' line is generated unconditionally at bindgen.adb:748. Proposed solution: make generation of the 'with System.Parameters;' line conditional on (Opt.Sec_Stack_Used or not Suppress_Standard_Library_On_Target). Proposed alternative solution: make generation of the 'Default_Secondary_Stack_Size' and related lines at bindgen.adb:748 conditional on Opt.Sec_Stack_Used. I think this would need a lot more thought to make sure it was OK in all circumstances.
[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81184 --- Comment #11 from seurer at gcc dot gnu.org --- I dug through my logs and the last failures I saw for phi-opt-11.c and pr21643.c on powerpc64 were in mid January immediately before Eric's patch.
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #17 from chefmax at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #15)
> (In reply to chefmax from comment #14)
> > (In reply to Jakub Jelinek from comment #13)
> > > or introduce a new virtual pseudo register that vregs pass would map
> > > directly to dynamic_offset.
> >
> > Yeah, that's what I though about (LLVM does pretty the same thing). But
> > (new_sp + virtual_stack_dynamic_rtx - stack_pointer_rtx) seems like an
> > appropriate solution too. I'll cover the testing for both approaches.
>
> The above patch passed
> make -j16 -k check-gcc check-g++
> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp=alloca*'
> on x86_64-linux and powerpc64-linux and without the -m32, part also on
> powerpc64le-linux.
Nice! Jakub, would you post the patch in ML?
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #18 from Jakub Jelinek --- I will, once I bootstrap/regtest it fully on a couple of targets.
[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246 Tom de Vries changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tom de Vries --- Patch committed, marking resolved-fixed
[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 --- Comment #25 from Eric Botcazou --- Author: ebotcazou Date: Thu Apr 12 14:18:17 2018 New Revision: 259347 URL: https://gcc.gnu.org/viewcvs?rev=259347&root=gcc&view=rev Log: PR target/85238 * lto-wrapper.c (debug_objcopy): Open the files in binary mode. * dwarf2out.c (dwarf2out_early_finish): Do not generate assembly in LTO mode for PE-COFF targets. * config/i386/i386-protos.h (i386_pe_asm_lto_start): Declare. (i386_pe_asm_lto_end): Likewise. * config/i386/cygming.h (TARGET_ASM_LTO_START): Define. (TARGET_ASM_LTO_END): Likewise. * config/i386/winnt.c (saved_debug_info_level): New static variable. (i386_pe_asm_lto_start): New function. (i386_pe_asm_lto_end): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygming.h trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/winnt.c trunk/gcc/dwarf2out.c trunk/gcc/lto-wrapper.c
[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|ktietz at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #26 from Eric Botcazou --- This should work now.
[Bug fortran/83064] DO CONCURRENT and auto-parallelization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #28 from Christophe Lyon --- (In reply to Thomas Koenig from comment #27) > > 2018-04-09 Thomas Koenig > > PR fortran/83064 > * gfortran.dg/do_concurrent_5.f90: New test. Hi, I think the testcase is probably missing a require-effective-target, because I see it failing on aarch64/arm with this error message: gfortran: error: libgomp.spec: No such file or directory
[Bug target/85381] New: [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85381
Bug ID: 85381
Summary: [og7, nvptx, openacc] parallel-loop-1.c fails with
default vector length 128
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
When running parallel-loop-1.c with this patch, it hangs:
...
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c
b/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c
index 4bc71415688..5e7adcb4340 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c
@@ -1,4 +1,5 @@
/* { dg-do run } */
+/* { dg-additional-options "-fopenacc-dim=::128" } */
#include
...
[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84733
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot com
--- Comment #7 from Paolo Carlini ---
For the remaining error-recovery issue, loosening a bit the assertion would be
enough - see below - I don't know if we want to dig deeper... Opinions?
Index: name-lookup.c
===
--- name-lookup.c (revision 259340)
+++ name-lookup.c (working copy)
@@ -2052,7 +2052,7 @@ pop_local_binding (tree id, tree decl)
binding->value = NULL_TREE;
else
{
- gcc_assert (binding->type == decl);
+ gcc_assert (!binding->type || binding->type == decl);
binding->type = NULL_TREE;
}
[Bug rtl-optimization/85354] [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354 --- Comment #4 from Alexander Monakov --- Author: amonakov Date: Thu Apr 12 15:40:44 2018 New Revision: 259348 URL: https://gcc.gnu.org/viewcvs?rev=259348&root=gcc&view=rev Log: sel-sched: move cleanup_cfg before calculate_dominance_info (PR 85354) PR rtl-optimization/85354 * sel-sched-ir.c (sel_init_pipelining): Move cfg_cleanup call... * sel-sched.c (sel_global_init): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/sel-sched.c
[Bug rtl-optimization/85354] [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354 Alexander Monakov changed: What|Removed |Added Status|NEW |RESOLVED Blocks||84659 Resolution|--- |FIXED --- Comment #5 from Alexander Monakov --- Fixed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659 [Bug 84659] [6/7 Regression] ICE: Segmentation fault (stack overflow in bb_note) w/ selective scheduling
[Bug rtl-optimization/84659] [6/7 Regression] ICE: Segmentation fault (stack overflow in bb_note) w/ selective scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659 Bug 84659 depends on bug 85354, which changed state. Bug 85354 Summary: [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/85357] gfortran versions 7.2.0/8.0.1 reject F03 procedure overriding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85357 c...@mnet-mail.de changed: What|Removed |Added Summary|Regression: gfortran|gfortran versions |versions 7.2.0/8.0.1 reject |7.2.0/8.0.1 reject F03 |F03 procedure overriding|procedure overriding --- Comment #1 from c...@mnet-mail.de --- Can't actually vouch for gfortran 7.1 being able to compile this, as I no longer have access to that gfortran version, so I changed the title (might still be a regression, though). Also, when replacing the line: use base by use base, only: base_type the code compiles with both gfortran 7.2.0 and 8.0.1.
[Bug target/85347] New testcase vec-ldl-1.c FAILs on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85347 --- Comment #2 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Thu Apr 12 16:16:08 2018 New Revision: 259350 URL: https://gcc.gnu.org/viewcvs?rev=259350&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2018-04-12 Kelvin Nilsen PR target/85347 * gcc.target/powerpc/vec-ldl-1.c: Change dejagnu directives to specify -mvsx on gcc command line. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/vec-ldl-1.c
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 43922 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43922&action=edit gcc8-pr85376.patch The problem is that cse.c (fold_rtx) uses simplify_unary_operation and that contains stuff like: else if (! CLZ_DEFINED_VALUE_AT_ZERO (imode, int_value)) int_value = GET_MODE_PRECISION (imode); That is fine in some optimization passes, where we just want some value for the expression, but not in cse, where we want to record that some register has this constant value and then optimize other uses of the same constant, canonicalizing to that register. Of course, when the value is not defined for zero, the register contains some random value, not the constant we've computed. So, either we can do what the patch does, or punt instead of returning GET_MODE_PRECISION in simplify-rtx.c.
