[Bug tree-optimization/80334] [5 Regression] Segfault when taking address of copy of unaligned struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80334 --- Comment #14 from Alexandre Oliva --- Done, bug 87054. The patch in comment 13 fails libstdc++-v3; the language-independent get_object_alignment can't deal with unresolved template expressions, so using the same logic you added to ivopts to adjust the type of the compiler-introduced pointer won't do in build_fold_addr_expr_loc.
[Bug tree-optimization/87054] New: misaligned asm output is turned into dereferenced pointer-to-aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87054
Bug ID: 87054
Summary: misaligned asm output is turned into dereferenced
pointer-to-aligned
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
Depends on: 80334
Target Milestone: ---
This bug came up while attempting to trigger the bug 80334, that was suspected
to be latent in earlier versions. I managed to trigger the latent problem with
a variant of the testcase below, but attempting to further minimize it, I found
a way to trigger it even in GCC 8 and trunk:
#ifndef T
# define T long
#endif
#ifndef R
# define R "r"
#endif
typedef T A; // #define T to long or __int128
struct B { char d; A c; } __attribute__((packed));
B b[50]; // many elements to avoid loop unrolling
int main () {
for (int i = 0; i < sizeof(b) / sizeof(*b); i++) {
asm ("" : "+" R (b[i].unpacked)); // #define R to "r" on ppc or "x" on
x86_64
}
}
The gimplifier introduces a pointer to the misaligned field for the asm output,
discarding the information about the misalignment, and that pointer is
dereferenced as if the object was aligned. There is a (broken) patch in that
bug that works around the problem, but that fails to build libstdc++-v3
(unbound template names).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80334#c12
FTR, the testcase that exercises the bug in older compilers, before the fix was
backported, has a "manual reload" of the asm operand, compared with the above:
auto r = b[i].unpacked; // aligned access to unaligned address
asm ("" : "+" R (r)); // #define R to "r" on ppc or "x" on x86_64
b[i].unpacked = r; // pretend the loop has externally-visible effects
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80334
[Bug 80334] [5 Regression] Segfault when taking address of copy of unaligned
struct
[Bug middle-end/87053] New: wrong code with c_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87053
Bug ID: 87053
Summary: wrong code with c_strlen
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
$ cat u.c
const union
{ struct {
char x[4];
char y[4];
};
struct {
char z[8];
};
} u = {{"1234", "567"}};
int test()
{
return __builtin_strlen(u.z);
}
$ gcc -S u.c
$
cat u.s
.file "u.c"
.text
.globl u
.section.rodata
.align 8
.type u, @object
.size u, 8
u:
.ascii "1234"
.string "567"
.text
.globl test
.type test, @function
test:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movl$4, %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size test, .-test
.ident "GCC: (GNU) 9.0.0 20180821 (experimental)"
.section.note.GNU-stack,"",@progbits
which Looks wrong.
expected: not folded, or evaluate to 7.
[Bug tree-optimization/87034] [9 Regression] missing -Wformat-overflow on a sprintf %s with a wide string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87034 Martin Sebor changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-22 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01321.html
[Bug middle-end/87052] STRING_CST printing incomplete in Gimple dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87052 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01324.html
[Bug fortran/86837] Optimization breaks an unformatted read with implicit loop on Mac OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-22 Ever confirmed|0 |1 --- Comment #3 from Jerry DeLisle --- Confirmed on current trunk.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #19 from qinzhao at gcc dot gnu.org --- which sparc machine was used to repeat the failure, and what's the configure and make options?
[Bug target/87040] ICE in extract_constrain_insn_cached, at recog.c:2218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87040 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Segher Boessenkool --- Dup of PR87026. *** This bug has been marked as a duplicate of bug 87026 ***
[Bug target/87026] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87026 Segher Boessenkool changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Segher Boessenkool --- *** Bug 87040 has been marked as a duplicate of this bug. ***
[Bug middle-end/87052] STRING_CST printing incomplete in Gimple dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87052 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-21 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/87052] New: STRING_CST printing incomplete in Gimple dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87052
Bug ID: 87052
Summary: STRING_CST printing incomplete in Gimple dumps
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
STRING_CST nodes with embedded nuls are formatted in Gimple dumps only up to
the first nul. Characters beyond the first nul are not printed. This makes
the dumps incomplete (and raises the question of whether the code is even
correct.) This has recently been exacerbated by transforming braced-list
initialized constant character arrays into STRING_CSTs (r263511).
$ cat f.c && gcc -O2 -S -Wall -fdump-tree-gimple=/dev/stdout f.c
void f (char *d)
{
const char a[3] = "\000ab";
__builtin_strcpy (d, a);
}
void g (char *d)
{
const char a[] = { 0, 'a', 'b', 'b' };
__builtin_strcpy (d, a);
}
f (char * d)
{
const char a[3];
try
{
a = "";
__builtin_strcpy (d, );
}
finally
{
a = {CLOBBER};
}
}
g (char * d)
{
const char a[4];
try
{
a = "";
__builtin_strcpy (d, );
}
finally
{
a = {CLOBBER};
}
}
[Bug c++/87051] is_trivially_move_constructible wrongly gives `false` for class with user-provided non-const copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87051 Ville Voutilainen changed: What|Removed |Added Status|NEW |ASSIGNED CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com --- Comment #1 from Ville Voutilainen --- I'll take a look.
[Bug sanitizer/82076] inconsistencies between sanitizer and -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82076 --- Comment #3 from Martin Sebor --- I think the problem in this case is that a) the sanitizers don't instrument calls to built-in functions like memcpy (the reason for the missing runtime error in the case of -DN=3), and b) -Wstringop-overflow doesn't handle MEM_REF (which is what memcpy with a small power-of-2 size is transformed into). Both should be solvable.
[Bug c++/87051] is_trivially_move_constructible wrongly gives `false` for class with user-provided non-const copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87051 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-21 CC||ville at gcc dot gnu.org Ever confirmed|0 |1
[Bug web/87050] Bump wwwdocs to html5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87050 Jonathan Wakely changed: What|Removed |Added CC||gerald at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- Makes sense to me. CCing Gerald.
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #4 from Steinar H. Gunderson --- Oh, it exists? Yes, if so, please count this as a request for enabling on -Wextra.
[Bug c++/87051] New: is_trivially_move_constructible wrongly gives `false` for class with user-provided non-const copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87051 Bug ID: 87051 Summary: is_trivially_move_constructible wrongly gives `false` for class with user-provided non-const copy constructor Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: arthur.j.odwyer at gmail dot com Target Milestone: --- cat > test.cc
[Bug rtl-optimization/87047] [7/8/9 Regression] performance regression because of if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047 --- Comment #2 from Andrew Pinski --- I suspect it is treating cost 0 as being free rather than unknown cost. And the x86 backend is returning 0 cost for the upper multiple.
[Bug rtl-optimization/87047] [7/8/9 Regression] performance regression because of if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-21 CC||amonakov at gcc dot gnu.org Component|middle-end |rtl-optimization Summary|gcc 7 & 8 - performance |[7/8/9 Regression] |regression because of |performance regression |if-conversion |because of if-conversion Ever confirmed|0 |1 --- Comment #1 from Alexander Monakov --- Indeed, on first glance something is suspicious in RTL if-conversion, the block is quite large and should not be transformed. Unfortunately the pass doesn't dump estimated costs :(
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #3 from joseph at codesourcery dot com --- This is Wjump-misses-init. Is this a request to make some other option such as -Wall or -Wextra enable that option (rather than just -Wc++-compat as at present)?
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #20 from Segher Boessenkool --- (In reply to Wilco from comment #19) > Well insn_cost() uses COSTS_N_INSNS (1) for instructions with unknown (zero) > costs. That's a reasonable default and gives more accurate cost comparisons, > eg. 0 + 4 vs 0 + 8 now becomes 4 + 4 vs 4 + 8. You're talking about the default insn_cost, which uses pattern_cost to do the work; pattern_cost returns COSTS_N_INSNS (1) if there is a single SET (or a single SET and a single SET of COMPARE), and set_src_cost of that SET says it is cost 0. It does not say cost 0 for a PARALLEL of two SETs, like you have here. A target-specific insn_cost can return a saner cost for all insns, including for those that are a "real" PARALLEL. (COSTS_N_INSNS (1) isn't minimal of course, it is 4 like you already point out; it is the default insn cost). It never is clear that 0+4 is better than 0+8, because the 0's usually are not the cost of the same insn. > With those changes I think there will be far fewer cases with unknown costs. I'm not sure what changes you propose. > There will be cases where target insn_cost needs to be improved to more > accurately model complex instructions, but that will result in even better > code. The arm port does not _have_ the insn_cost hook implemented; doing that will probably help, sure.
[Bug target/87040] ICE in extract_constrain_insn_cached, at recog.c:2218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87040 Segher Boessenkool changed: What|Removed |Added Target|ppc64le-linux-gnu |powerpc*-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-21 Host|x86_64-linux-gnu| Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- This is a dup of some other PR I already have a patch for.
[Bug web/87050] New: Bump wwwdocs to html5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87050 Bug ID: 87050 Summary: Bump wwwdocs to html5 Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- Currently the GCC website is "XHTML 1.0 Transitional". This specification has been superseded in favor of the latest HTML version, currently 5.2 (see https://www.w3.org/TR/xhtml1/ ). Reasons to update - Easier to hand-edit, e.g. in many cases no need for closing tags, and in general more forgiving parsing. - XHTML, and in particular XHTML delivered as text/html, is a technological dead end. People will only get less and less familiar with it. For a relatively simple set of pages like the GCC wwwdocs that doesn't use any particularly exotic features, HTML5 is more or less completely backwards compatible with XHTML 1.0 (for details, see https://www.w3.org/TR/html5-diff/ ). So apart from the headers, little work ought to be needed for the conversion itself.
[Bug tree-optimization/87008] [8/9 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #2 from Marc Glisse ---
Or just:
struct A { double a, b; };
struct B : A {};
double f(B x){
B y;
A*px=
A*py=
*py=*px;
return y.a;
}
MEM[(struct A *)] = MEM[(const struct A &)];
y_6 = MEM[(struct A *)];
y ={v} {CLOBBER};
return y_6;
where y_6 should be read directly from x. SRA doesn't dare touch it. SCCVN does
see that reading from y is equivalent to reading from x, but unless something
else is already reading from x, it keeps the read from y.
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 79342 ***
[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342 H.J. Lu changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #8 from H.J. Lu --- *** Bug 70578 has been marked as a duplicate of this bug. ***
[Bug c/87049] New: __clear_cache() prototype confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87049
Bug ID: 87049
Summary: __clear_cache() prototype confusion
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bunk at stusta dot de
Target Milestone: ---
$ cat test.cc
extern "C" void __clear_cache(char *beg, char *end);
$ g++-5 -c test.cc
test.cc:1:51: warning: new declaration 'void __clear_cache(char*, char*)'
ambiguates built-in declaration 'void __clear_cache(void*, void*)'
extern "C" void __clear_cache(char *beg, char *end);
^
$ g++-7 -c test.cc
test.cc:1:17: warning: new declaration 'void __clear_cache(char*, char*)'
ambiguates built-in declaration 'void __clear_cache(void*, void*)'
[-Wbuiltin-declaration-mismatch]
extern "C" void __clear_cache(char *beg, char *end);
^
$ g++-8 -c test.cc
test.cc:1:17: error: new declaration 'void __clear_cache(char*, char*)'
ambiguates built-in declaration 'void __clear_cache(void*, void*)'
[-fpermissive]
extern "C" void __clear_cache(char *beg, char *end);
^
$
The bug is not that g++ became more strict, the bug is that the built-in
declaration differs from the documented declaration.
Relevant part of the gcc sources:
gcc/builtins.def:DEF_EXT_LIB_BUILTIN(BUILT_IN_CLEAR_CACHE, "__clear_cache",
BT_FN_VOID_PTR_PTR, ATTR_NOTHROW_LEAF_LIST)
gcc/doc/extend.texi:@deftypefn {Built-in Function} void __builtin___clear_cache
(char *@var{begin}, char *@var{end})
libgcc/libgcc2.h:extern void __clear_cache (char *, char *);
Doesn't seem to be a new issue:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20130513/079828.html
[Bug libfortran/87048] [9 Regression] array_constructor_8.f90 failure on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87048 Thomas Koenig changed: What|Removed |Added Blocks||25829 Target Milestone|--- |9.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 [Bug 25829] [F03] Asynchronous IO support
[Bug libfortran/87048] New: [9 Regression] array_constructor_8.f90 failure on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87048 Bug ID: 87048 Summary: [9 Regression] array_constructor_8.f90 failure on armeb Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Since r263082, array_constructor_8.f90 fails on armeb. PR 25829 contains debugging info on that, see also https://gcc.gnu.org/ml/fortran/2018-08/msg00010.html and the following discussion.
[Bug tree-optimization/87008] [8/9 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #1 from Marc Glisse ---
struct A { double a, b; };
struct B : A {};
templatevoid cp(T,T const){a=b;}
double f(B x){
B y; cp(y,x);
B z; cp(z,x);
return y.a - z.a;
}
This is not quite equivalent because RTL manages to optimize this case, but
gimple, with -Ofast, still gets the ugly:
ISRA.1 = MEM[(const struct A &)];
SR.9_9 = MEM[(struct A *)];
ISRA.1 = MEM[(const struct A &)];
SR.8_10 = MEM[(struct A *)];
_3 = SR.9_9 - SR.8_10;
return _3;
Writing cp instead of cp makes it work, and the main difference starts in
SRA. I expect (didn't check) this is another victim of r255510 .
[Bug fortran/25829] [F03] Asynchronous IO support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 --- Comment #55 from Nicolas Koenig --- Author: koenigni Date: Tue Aug 21 18:48:59 2018 New Revision: 263750 URL: https://gcc.gnu.org/viewcvs?rev=263750=gcc=rev Log: 2018-08-21 Nicolas Koenig Thomas Koenig PR fortran/25829 * gfortran.texi: Add description of asynchronous I/O. * trans-decl.c (gfc_finish_var_decl): Treat asynchronous variables as volatile. * trans-io.c (gfc_build_io_library_fndecls): Rename st_wait to st_wait_async and change argument spec from ".X" to ".w". (gfc_trans_wait): Pass ID argument via reference. 2018-08-21 Nicolas Koenig Thomas Koenig PR fortran/25829 * gfortran.dg/f2003_inquire_1.f03: Add write statement. * gfortran.dg/f2003_io_1.f03: Add wait statement. 2018-08-21 Nicolas Koenig Thomas Koenig PR fortran/25829 * Makefile.am: Add async.c to gfor_io_src. Add async.h to gfor_io_headers. * Makefile.in: Regenerated. * gfortran.map: Add _gfortran_st_wait_async. * io/async.c: New file. * io/async.h: New file. * io/close.c: Include async.h. (st_close): Call async_wait for an asynchronous unit. * io/file_pos.c (st_backspace): Likewise. (st_endfile): Likewise. (st_rewind): Likewise. (st_flush): Likewise. * io/inquire.c: Add handling for asynchronous PENDING and ID arguments. * io/io.h (st_parameter_dt): Add async bit. (st_parameter_wait): Correct. (gfc_unit): Add au pointer. (st_wait_async): Add prototype. (transfer_array_inner): Likewise. (st_write_done_worker): Likewise. * io/open.c: Include async.h. (new_unit): Initialize asynchronous unit. * io/transfer.c (async_opt): New struct. (wrap_scalar_transfer): New function. (transfer_integer): Call wrap_scalar_transfer to do the work. (transfer_real): Likewise. (transfer_real_write): Likewise. (transfer_character): Likewise. (transfer_character_wide): Likewise. (transfer_complex): Likewise. (transfer_array_inner): New function. (transfer_array): Call transfer_array_inner. (transfer_derived): Call wrap_scalar_transfer. (data_transfer_init): Check for asynchronous I/O. Perform a wait operation on any pending asynchronous I/O if the data transfer is synchronous. Copy PDT and enqueue thread for data transfer. (st_read_done_worker): New function. (st_read_done): Enqueue transfer or call st_read_done_worker. (st_write_done_worker): New function. (st_write_done): Enqueue transfer or call st_read_done_worker. (st_wait): Document as no-op for compatibility reasons. (st_wait_async): New function. * io/unit.c (insert_unit): Use macros LOCK, UNLOCK and TRYLOCK; add NOTE where necessary. (get_gfc_unit): Likewise. (init_units): Likewise. (close_unit_1): Likewise. Call async_close if asynchronous. (close_unit): Use macros LOCK and UNLOCK. (finish_last_advance_record): Likewise. (newunit_alloc): Likewise. * io/unix.c (find_file): Likewise. (flush_all_units_1): Likewise. (flush_all_units): Likewise. * libgfortran.h (generate_error_common): Add prototype. * runtime/error.c: Include io.h and async.h. (generate_error_common): New function. 2018-08-21 Nicolas Koenig Thomas Koenig PR fortran/25829 * testsuite/libgomp.fortran/async_io_1.f90: New test. * testsuite/libgomp.fortran/async_io_2.f90: New test. * testsuite/libgomp.fortran/async_io_3.f90: New test. * testsuite/libgomp.fortran/async_io_4.f90: New test. * testsuite/libgomp.fortran/async_io_5.f90: New test. * testsuite/libgomp.fortran/async_io_6.f90: New test. * testsuite/libgomp.fortran/async_io_7.f90: New test. Added: trunk/libgfortran/io/async.c trunk/libgfortran/io/async.h trunk/libgomp/testsuite/libgomp.fortran/async_io_1.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_2.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_3.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_4.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_5.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_6.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/f2003_inquire_1.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_1.f03 trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in
[Bug c++/86499] lambda-expressions with capture-default are allowed at namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86499 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/86499] lambda-expressions with capture-default are allowed at namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86499 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Tue Aug 21 18:37:23 2018 New Revision: 263749 URL: https://gcc.gnu.org/viewcvs?rev=263749=gcc=rev Log: PR c++/86499 * parser.c (cp_parser_lambda_introducer): Give error if a non-local lambda has a capture-default. * g++.dg/cpp0x/lambda/lambda-non-local.C: New test. * g++.dg/cpp0x/lambda/lambda-this10.C: Adjust dg-error. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-non-local.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this10.C
[Bug middle-end/87047] New: gcc 7 & 8 - performance regression because of if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
Bug ID: 87047
Summary: gcc 7 & 8 - performance regression because of
if-conversion
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: already5chosen at yahoo dot com
Target Milestone: ---
Created attachment 44570
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44570=edit
demonstrate performance regression because of if-conversion
Very significant performance regression from gcc 6.x to 7.x and 8.x cause by
if-conversion of predictable branch.
Compilation flags: -O2 -Wall
Target: x86-64 (my test machine is IvyBridge)
It is possible that the problem is specific to x86-64 target. I tested (by
observing compiler output) aarch64 target and it looks o.k.
The problem occurs here:
if ((i & 15)==0) {
const uint64_t PROD_ONE = (uint64_t)(1) << 19;
uint64_t prod = umulh(invRange, range);
invRange = umulh(invRange, (PROD_ONE*2-1-prod)<<44)<<1;
}
The condition has low probability and is easily predicted by branch predictor,
while code within if has relatively high latency.
gcc, starting from gcc.7.x and up to the latest, is convinced that always
executing the inner part of the if is a bright idea. Measurements, on my
real-world code, do not agree and show 30% slowdown. I'm sure that on
artificial sequences I can demonstrate a slowdown of 100% and more.
What is special about this case is that compiler is VERY confident in its
stupid decision. It does not change its mind even when I replace
if ((i & 15)==0) {
by
if (__builtin_expect((i & 15)==0, 0)) {
I found only two ways of forcing sane code generation:
1. -fno-if-conversion
2.
if ((i & 15)==0) {
asm volatile("");
...
}
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|unknown |9.0 Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #11 from H.J. Lu --- Fixed for GCC 9 and on GCC 6/7/8 branches.
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 --- Comment #10 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Aug 21 16:38:17 2018 New Revision: 263745 URL: https://gcc.gnu.org/viewcvs?rev=263745=gcc=rev Log: x86: Always update EH return address in word_mode On x86, return address is always popped in word_mode. eh_return needs to put EH return address in word_mode on stack. gcc/ Backport from mainline PR target/87014 * config/i386/i386.md (eh_return): Always update EH return address in word_mode. gcc/testsuite/ Backport from mainline PR target/87014 * g++.dg/torture/pr87014.C: New file. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr87014.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/i386/i386.md branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 --- Comment #9 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Aug 21 16:27:22 2018 New Revision: 263744 URL: https://gcc.gnu.org/viewcvs?rev=263744=gcc=rev Log: x86: Always update EH return address in word_mode On x86, return address is always popped in word_mode. eh_return needs to put EH return address in word_mode on stack. gcc/ Backport from mainline PR target/87014 * config/i386/i386.md (eh_return): Always update EH return address in word_mode. gcc/testsuite/ Backport from mainline PR target/87014 * g++.dg/torture/pr87014.C: New file. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr87014.C Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/87044] stl_construct.h not interoperable with allocators with custom reference types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87044 --- Comment #3 from Jonathan Wakely --- See also https://cplusplus.github.io/LWG/lwg-closed.html#1318 which requested that custom references be put back, and was closed as Not A Defect.
[Bug libstdc++/87044] stl_construct.h not interoperable with allocators with custom reference types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87044 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- The address() member was removed from the allocator requirements for C++11, so it's wrong to expect it to be used. https://en.cppreference.com/w/cpp/named_req/Allocator#Requirements
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 --- Comment #8 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Aug 21 16:17:35 2018 New Revision: 263743 URL: https://gcc.gnu.org/viewcvs?rev=263743=gcc=rev Log: x86: Always update EH return address in word_mode On x86, return address is always popped in word_mode. eh_return needs to put EH return address in word_mode on stack. gcc/ Backport from mainline PR target/87014 * config/i386/i386.md (eh_return): Always update EH return address in word_mode. gcc/testsuite/ Backport from mainline PR target/87014 * g++.dg/torture/pr87014.C: New file. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr87014.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/i386/i386.md branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/87044] stl_construct.h not interoperable with allocators with custom reference types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87044 --- Comment #1 from Jonathan Wakely --- This is correct: custom reference types are not supported at all, and never will be. And that's not a bug. The container requirements in the standard require X::reference to be X::value_type&, and the allocator requirements do not have any reference/const_reference member types at all.
[Bug tree-optimization/87046] Incorrect vectorization of fma with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87046
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Component|target |tree-optimization
--- Comment #1 from Alexander Monakov ---
This appears recently fixed, gcc-8.1 still got this wrong but gcc-8.2 is ok.
Possibly went away with PR 85597 fix, but not sure about that.
On gcc-8.1 SLP incorrectly produced
vectp.1_29 = u_4(D);
vect__26.2_27 = MEM[(const double *)vectp.1_29];
_65 = MEM[(const double *)u_4(D) + 24B];
vectp.4_22 = v_7(D);
vect__28.5_17 = MEM[(const double *)vectp.4_22];
_67 = MEM[(const double *)v_7(D) + 24B];
vectp.7_64 = w_10(D);
vect__30.8_66 = MEM[(const double *)vectp.7_64];
_69 = MEM[(const double *)w_10(D) + 24B];
_68 = {_26, _39, _52, _65};
vect_cst__15 = _68;
vect__31.9_25 = vect__26.2_27 * vect__28.5_17 + vect_cst__15;
[Bug tree-optimization/87046] New: Incorrect vectorization of fma with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87046 Bug ID: 87046 Summary: Incorrect vectorization of fma with -O3 Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: yates at cscs dot ch Target Milestone: --- Created attachment 44569 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44569=edit Stripped preprocessed source of minimal test case. In some circumstances, vectorization of fma at -O3 on broadwell and haswell incorrectly uses the wrong data for the addition component. While the sample code was tested with gcc version 7.3.0 with -march=haswell, the same problem arises with gcc 6.4.0. Disabling tree-slp-vectorize restores correct behaviour. I've attached a stripped down preprocessed source that demonstrates the bug. gcc -v output: Using built-in specs. COLLECT_GCC=/opt/gcc/7.3.0/bin/../snos/bin/gcc COLLECT_LTO_WRAPPER=/opt/gcc/7.3.0/snos/libexec/gcc/x86_64-suse-linux/7.3.0/lto-wrapper Target: x86_64-suse-linux Configured with: ../cray-gcc-7.3.0-201801270210.d61239fc6000b/configure --prefix=/opt/gcc/7.3.0/snos --disable-nls --libdir=/opt/gcc/7.3.0/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/7.3.0/snos/include/g++ --with-slibdir=/opt/gcc/7.3.0/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --build=x86_64-suse-linux --with-ppl --with-cloog --disable-multilib Thread model: posix gcc version 7.3.0 20180125 (Cray Inc.) (GCC) Compilation command line and program output: $ gcc -O3 -march=haswell fma-reduced-bug.i $ ./a.out Aborted (core dumped)
[Bug c++/86981] Add Clang's -Wpessimizing-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86981 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Done for GCC 9.
[Bug fortran/87045] New: pointer to array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87045 Bug ID: 87045 Summary: pointer to array of character Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: valeryweber at hotmail dot com Target Milestone: --- hi all i m getting a weird error with the following code. many thanks v cat t2.f90 program test character(:), dimension(:), allocatable, target :: t character(:), pointer, dimension(:) :: p allocate( character(3) :: t(2) ) t(1) = "abc" t(2) = "123" write(*,*) t p => t write(*,*) p(1) write(*,*) p(2) end program test gfortran-8.1.0 t2.f90 -g -fcheck=all ./a.out abc123 At line 8 of file t2.f90 Fortran runtime error: Unequal character lengths (-3262553545697656832/3) in pointer assignment Error termination. Backtrace: #0 0x402548 in test at /home/vwe/work/axv/pkg/build/t2.f90:8 #1 0x402724 in main at /home/vwe/work/axv/pkg/build/t2.f90:11
[Bug c++/86981] Add Clang's -Wpessimizing-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86981 --- Comment #1 from Marek Polacek --- Author: mpolacek Date: Tue Aug 21 15:38:36 2018 New Revision: 263741 URL: https://gcc.gnu.org/viewcvs?rev=263741=gcc=rev Log: PR c++/86981, Implement -Wpessimizing-move. * c.opt (Wpessimizing-move): New option. * typeck.c (decl_in_std_namespace_p): New. (is_std_move_p): New. (maybe_warn_pessimizing_move): New. (can_do_nrvo_p): New, factored out of ... (check_return_expr): ... here. Warn about potentially harmful std::move in a return statement. * doc/invoke.texi: Document -Wpessimizing-move. * g++.dg/cpp0x/Wpessimizing-move1.C: New test. * g++.dg/cpp0x/Wpessimizing-move2.C: New test. * g++.dg/cpp0x/Wpessimizing-move3.C: New test. * g++.dg/cpp0x/Wpessimizing-move4.C: New test. * g++.dg/cpp1z/Wpessimizing-move1.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move1.C trunk/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move2.C trunk/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move3.C trunk/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move4.C trunk/gcc/testsuite/g++.dg/cpp1z/Wpessimizing-move1.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug c++/65043] Expected narrowing conversion during list initialization of bool from double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65043 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug c++/65043] Expected narrowing conversion during list initialization of bool from double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65043 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Tue Aug 21 15:25:17 2018 New Revision: 263739 URL: https://gcc.gnu.org/viewcvs?rev=263739=gcc=rev Log: PR c++/65043 * call.c (standard_conversion): Set check_narrowing. * typeck2.c (check_narrowing): Use CP_INTEGRAL_TYPE_P rather than comparing with INTEGER_TYPE. * g++.dg/concepts/pr67595.C: Add dg-warning. * g++.dg/cpp0x/Wnarrowing11.C: New test. * g++.dg/cpp0x/Wnarrowing12.C: New test. * g++.dg/cpp0x/rv-cast5.C: Add static_cast. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing11.C trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/concepts/pr67595.C trunk/gcc/testsuite/g++.dg/cpp0x/rv-cast5.C
[Bug libstdc++/87044] New: stl_construct.h not interoperable with allocators with custom reference types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87044
Bug ID: 87044
Summary: stl_construct.h not interoperable with allocators with
custom reference types
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: barmie.brace at outlook dot com
Target Milestone: ---
Created attachment 44568
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44568=edit
Custom allocator with custom reference object type.
STL containers don't seem to be interoperable with allocators with custom
reference types due to stl_construct.h's use of std::__addressof() instead of
the allocator's address() member.
Attached is a simple example using an allocator with a custom reference type.
[xiii@ea1c9ec7dba3 custom_allocator_test]$ make
g++ test.cpp -o test -std=gnu++14 -O3
In file included from /usr/include/c++/8.2.0/vector:62,
from test.cpp:1:
/usr/include/c++/8.2.0/bits/stl_construct.h: In instantiation of 'void
std::_Destroy(_ForwardIterator, _ForwardIterator, _Allocator&) [with
_ForwardIterator = custom_ptr; _Allocator = custom_allocator]':
/usr/include/c++/8.2.0/bits/stl_vector.h:567:15: required from
'std::vector<_Tp, _Alloc>::~vector() [with _Tp = int; _Alloc =
custom_allocator]'
test.cpp:12:43: required from here
/usr/include/c++/8.2.0/bits/stl_construct.h:198:46: error: cannot bind
non-const lvalue reference of type 'custom_ref&' to an rvalue of type
'custom_ptr::reference' {aka 'custom_ref'}
__traits::destroy(__alloc, std::__addressof(*__first));
^~~~
In file included from /usr/include/c++/8.2.0/bits/stl_pair.h:59,
from /usr/include/c++/8.2.0/bits/stl_algobase.h:64,
from /usr/include/c++/8.2.0/vector:60,
from test.cpp:1:
/usr/include/c++/8.2.0/bits/move.h:47:5: note: initializing argument 1 of
'constexpr _Tp* std::__addressof(_Tp&) [with _Tp = custom_ref]'
__addressof(_Tp& __r) _GLIBCXX_NOEXCEPT
^~~
make: *** [Makefile:2: test] Error 1
[Bug tree-optimization/86924] tree-slp-vectorize may create unaligned memory access, causing segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86924 --- Comment #3 from Mario Rohkrämer --- Created attachment 44567 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44567=edit Zipped temp output encoder.i by lupo... This is the "-save-temps" output which user lupo... attached in comment 12 to the Chromium bug report I linked above.
[Bug tree-optimization/86924] tree-slp-vectorize may create unaligned memory access, causing segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86924 --- Comment #2 from Mario Rohkrämer --- Unfortunately, I do not have much experience in running a compile manually. I only let the "media-autobuild suite" batch run. https://github.com/jb-alvarado/media-autobuild_suite/ I would not know for sure where to manipulate these batch/shell files to add the requested argument, or how to manually run the compilation for one specific file. It's all automated. But I will ask around and try to get advice.
[Bug fortran/86945] [8/9 Regression] BUG with optimisation of select case statement in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86945
--- Comment #8 from Richard Biener ---
C testcase:
void __attribute__((noinline,noipa))
foo(int id)
{
switch (id)
{
case (-__INT_MAX__ - 1)...-1:
__builtin_abort ();
default:;
}
}
int main()
{
foo(1);
return 0;
}
[Bug fortran/86945] [8/9 Regression] BUG with optimisation of select case statement in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86945 --- Comment #7 from Richard Biener --- With -fsanitize=undefined we get even at -O0 id= 1 : runtime error: signed integer overflow: 1 - -2147483647 cannot be represented in type 'integer(kind=4)' ierr1, OK =0 T : runtime error: signed integer overflow: 1 - -2147483648 cannot be represented in type 'integer(kind=4)' ierr2, OK =0 T so both foo1 and foo2 do not "work".
[Bug fortran/86945] [8/9 Regression] BUG with optimisation of select case statement in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86945 Richard Biener changed: What|Removed |Added Priority|P4 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- Confirmed. Likely caused by CFG cleanup convert_single_case_switch which generates a range test which is done in a signed type: : id.8_1 = CHAIN.11->id; _3 = id.8_1 - -2147483648; _4 = (unsigned int) _3; if (_4 <= 2147483647) when forwprop then combines this we fold (unsigned int) _3 <= 2147483647 to _3 >= 2147483647 which then is folded as id.8_1 - -2147483648 >= 2147483647 which is then folded to id.8_1 >= 2147483647 + -2147483648. But something goes wrong end we end up simplifying it as true.
[Bug fortran/87043] New: maybe-uninitialized warning for initialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87043
Bug ID: 87043
Summary: maybe-uninitialized warning for initialized variable
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: pvitt at posteo dot de
Target Milestone: ---
We have a MWE that provokes a "may be uninitialized" warning despite the value
being initialized in all cases. Additionally, this warning is only created with
-O[1,2,3,s,fast}, but not with -O{g}. The gcc is from Arch Linux.
$ gfortran -v -save-temps -O3 -Wmaybe-uninitialized uninitialized.f90
Driving: gfortran -v -save-temps -O3 -Wmaybe-uninitialized uninitialized.f90 -l
gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.1.1 20180531 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-Wmaybe-uninitialized'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/f951 uninitialized.f90 -quiet -dumpbase
uninitialized.f90 -mtune=generic -march=x86-64 -auxbase uninitialized -O3
-Wmaybe-uninitialized -version -fintrinsic-modules-path
/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/finclude -o uninitialized.s
GNU Fortran (GCC) version 8.1.1 20180531 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.1.1 20180531, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 8.1.1 20180531 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.1.1 20180531, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
uninitialized.f90:20:0:
max_err_len = maxval(len_trim(error_messages))
Warning: ‘error_messages.dim[0].ubound’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
[stripped assembler output...]
$ cat uninitialized.f90
module m
implicit none
integer, parameter :: error_buflen = 80
integer :: world_rank, world_size
contains
subroutine test()
character(len=error_buflen), allocatable :: error_messages(:)
integer :: allocstat, max_err_len
max_err_len = 0
if (world_rank == 0 ) then
allocate(error_messages(world_size), stat=allocstat)
else
allocate(error_messages(0))
end if
if (world_rank == 0) then
max_err_len = maxval(len_trim(error_messages))
end if
if (max_err_len > error_buflen-10) then
write(*,'(a)') 'Note...'
end if
end subroutine test
end module
program uninitialized
use m
implicit none
read(*,*) world_rank
world_size = 2
call test()
end program
[Bug c++/86943] [8/9 Regression] Wrong code when converting stateless generic lambda to function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|9.0 |8.3
[Bug tree-optimization/87042] New: UBSAN: poly-int.h:1095:5: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87042
Bug ID: 87042
Summary: UBSAN: poly-int.h:1095:5: runtime error: signed
integer overflow: 9223372036854775807 * 8 cannot be
represented in type 'long int'
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Blocks: 63426
Target Milestone: ---
Maybe a dup of PR85164, but:
$ cat strlen.i
const char a[] = {};
b() { '\0' == a[9223372036854775807]; }
$ UBSAN_OPTIONS=print_stacktrace=1 ./xgcc -B. strlen.i -O1
strlen.i:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | b() { '\0' == a[9223372036854775807]; }
| ^
../../gcc/poly-int.h:1095:5: runtime error: signed integer overflow:
9223372036854775807 * 8 cannot be represented in type 'long int'
#0 0xb98b74 in poly_int<1u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
operator*<1u, long, int>(poly_int_pod<1u, long> const&, int const&)
../../gcc/poly-int.h:1095
#1 0x23cc1c9 in fully_constant_vn_reference_p(vn_reference_s*)
../../gcc/tree-ssa-sccvn.c:1373
#2 0x23d61f7 in vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool) ../../gcc/tree-ssa-sccvn.c:2540
#3 0x23e1b38 in visit_reference_op_load ../../gcc/tree-ssa-sccvn.c:3798
#4 0x23e34a3 in visit_use ../../gcc/tree-ssa-sccvn.c:4163
#5 0x23e43e2 in process_scc ../../gcc/tree-ssa-sccvn.c:4346
#6 0x23e5812 in extract_and_process_scc_for_name
../../gcc/tree-ssa-sccvn.c:4467
#7 0x23e5bc4 in DFS ../../gcc/tree-ssa-sccvn.c:4517
#8 0x23ea154 in sccvn_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-sccvn.c:4956
#9 0x3ada486 in dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:353
#10 0x23ead4e in run_scc_vn(vn_lookup_kind) ../../gcc/tree-ssa-sccvn.c:5063
#11 0x23f2aa0 in execute ../../gcc/tree-ssa-sccvn.c:6044
#12 0x1a2a1fc in execute_one_pass(opt_pass*) ../../gcc/passes.c:2446
#13 0x1a2ab8d in execute_pass_list_1 ../../gcc/passes.c:2535
#14 0x1a2ac42 in execute_pass_list_1 ../../gcc/passes.c:2536
#15 0x1a2ace1 in execute_pass_list(function*, opt_pass*)
../../gcc/passes.c:2546
#16 0x1a251da in do_per_function_toporder(void (*)(function*, void*),
void*) ../../gcc/passes.c:1688
#17 0x1a2d2b4 in execute_ipa_pass_list(opt_pass*) ../../gcc/passes.c:2894
#18 0xdb3593 in ipa_passes ../../gcc/cgraphunit.c:2407
#19 0xdb434b in symbol_table::compile() ../../gcc/cgraphunit.c:2543
#20 0xdb522e in symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2788
#21 0x1e2d777 in compile_file ../../gcc/toplev.c:480
#22 0x1e349df in do_compile ../../gcc/toplev.c:2170
#23 0x1e3500d in toplev::main(int, char**) ../../gcc/toplev.c:2305
#24 0x3f49d8a in main ../../gcc/main.c:39
#25 0x75ca3fea in __libc_start_main ../csu/libc-start.c:308
#26 0x84a529 in _start
(/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x84a529)
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug tree-optimization/86936] strnlen() of a constant not folded due to laddress transformation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86936 --- Comment #3 from Richard Biener --- Note to GIMPLE [1][i_3(D)] is just address-computation and carries no semantics so you can't assume that i_3(D) isn't negative and thus ends up accessing "123". For the C testcase you of course can, but once we're in GIMPLE you cannot. If there's a load like _7 = a[1][i_3(D)]; you _can_ assume that i_3(D) fits in the respective array types domain.
[Bug c++/86908] static_cast()->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 --- Comment #9 from Jonathan Wakely --- (In reply to Kostya Frumkin from comment #8) > At the same time this design pattern (strategy) with placement-new is more > efficient than with common new. That's fine, but you can't use to access the AStrategy object you created at that position. You have several choices: - use an untyped buffer and create objects in there: alignas(AStrategy) unsigned char buf[sizeof(AStrategy)]; - use std::launder - use the pointer returned by the placement new-expression, which has the right type There are ways to do this safely in C++ today, but your original code is not one of those ways. You should fix your code. > So it has no rationale if the base methods > are used when using placement-new. At the same time other compilers > generates code where the derived method is callsed after placement-new. It's undefined behaviour, so anything can happen.
[Bug c++/86932] [8/9 Regression] Empty non-type template parameter pack not considered for SFINAE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86932 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3
[Bug c++/86926] [8/9 Regression] ICE for a recursive generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86926 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.3
[Bug tree-optimization/86924] tree-slp-vectorize may create unaligned memory access, causing segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86924 Richard Biener changed: What|Removed |Added Target||x86_64-w64-mingw32 Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-21 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- The question is where rcx comes from and why it isn't suitably aligned. This is very likely an issue in chromium, not gcc. The workaround patch shows the things to look at, namely the type declarations of *cpi and ordered_bwd and where they are allocated. Please attach preprocessed source for encoder.c as you use it when compiling for x86_64-w64-mingw32 (just add -save-temps to the compile that reproduces the failure).
[Bug c++/86922] Invoking templated PTMF on subclass gives false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86922 Richard Biener changed: What|Removed |Added Keywords||diagnostic, wrong-code --- Comment #1 from Richard Biener --- It warns about dereferencing (int (*) () * *) &((const struct B *) obj)->D.2305 which is built via #2 0x00b585af in cp_build_indirect_ref_1 ( ptr=, errorstring=RO_NULL, complain=3, do_fold=true) at /tmp/trunk/gcc/cp/typeck.c:3155 #3 0x00b58938 in cp_build_fold_indirect_ref ( pointer=) at /tmp/trunk/gcc/cp/typeck.c:3232 #4 0x00b59a5e in get_member_function_from_ptrfunc ( instance_ptrptr=0x7fffc868, function=, complain=3) at /tmp/trunk/gcc/cp/typeck.c:3565 #5 0x0097aabd in build_offset_ref_call_from_tree ( fn=, args=0x7fffc958, complain=3) at /tmp/trunk/gcc/cp/decl2.c:5095 #6 0x00ab9d26 in tsubst_copy_and_build (t=, args=, complain=3, in_decl=, function_p=false, integral_constant_expression_p=false) at /tmp/trunk/gcc/cp/pt.c:18485 the fnptr type has an alias-set that isn't compatible with that of struct B. Not sure where that int return type comes from ... Fishy. And possibly wrong-code afterwards because of that alias set.
[Bug tree-optimization/86919] strlen of a multidimensional array element with non-constant offset not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86919
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-21
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. But you'll have a hard time here since in
_6 = (sizetype) j_3(D);
_1 = + _6;
_2 = __builtin_strlen (_1);
the fact that you access a different dimension is lost. Consider
const char b[][3] = { "123", "2" };
where the "123" string overflows into the next dimension when you
ask for strlen (b).
[Bug c++/86908] static_cast()->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 --- Comment #8 from Kostya Frumkin --- > Either way you need to placement new the original type back again, otherwise > the wrong destructor gets called on scope exit, which adds more undefined > behaviour. There should not be undefined behavior because the size of both classes is same and destructors executes same code (in the case it is noop). So the memory to be freed up is same. The behavior must be defined by ISO committee because it is counterintuitive when the base methods are being called. (where to ask?) At the same time this design pattern (strategy) with placement-new is more efficient than with common new. So it has no rationale if the base methods are used when using placement-new. At the same time other compilers generates code where the derived method is callsed after placement-new. So I see two ways: - Ask the community to define behavior. or - Define behavior in gcc itself.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #19 from Marc Glisse --- This seems fixed in gcc-8, no?
[Bug c++/86917] [6/7/8/9 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |6.5
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #18 from joseph at codesourcery dot com --- On Tue, 21 Aug 2018, jvg1981 at aim dot com wrote: > intptr_t pVal = ((uintptr_t) p)/(sizeof *p); > intptr_t qVal = ((uintptr_t) q)/(sizeof *q); Note that this can be expanded like an exact division (right shift and multiply by reciprocal). See bug 67999 comment 24 and bug 81801 comment 4.
[Bug tree-optimization/86914] [8/9 Regression] -O2 generates wrong code with strlen() of pointers within one-element arrays of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.3
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 Joshua Green changed: What|Removed |Added CC||jvg1981 at aim dot com --- Comment #17 from Joshua Green --- "But if we don't know which pointer is greater, it gets more complicated: ..." I'm not sure that this is true. For types that are larger than 1 byte, it seems that one can do the subtraction after any division(s), hence only costing an additional division (or shift): T * p; T * q; . . . intptr_t pVal = ((uintptr_t) p)/(sizeof *p); intptr_t qVal = ((uintptr_t) q)/(sizeof *q); ptrdiff_t p_q = pVal - qVal; This should work in well-defined cases, for if p and q are pointers into the same array then (presumably) ((uintptr_t) p) and ((uintptr_t) q) must have the same remainder modulo sizeof(T). Of course, even an additional shift may be too expensive in some cases, so it's not entirely clear that this change should be made.
[Bug middle-end/86909] Missing common subexpression elimination for types other than int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86909 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-21 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Similar "bad" code for using 'unsigned int'. With 'int' the reassoc pass combines the repetitive checks to [local count: 840525100]: _8 = (unsigned int) _9; _15 = _8 <= 7; if (_15 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 532808861]: iftmp.1_6 = _3(D)->a; [local count: 1073741824]: # _1 = PHI return _1; with char or unsigned int it fails to do that which is because we are testing different vars: [local count: 840525100]: i_36 = (int) _9; if (i_36 == 0) goto ; [50.00%] else goto ; [50.00%] [local count: 420262550]: if (_9 == 0) goto ; [71.00%] else goto ; [29.00%] [local count: 532808861]: iftmp.1_6 = _3(D)->a; goto ; [100.00%] [local count: 303654184]: if (i_36 == 1) goto ; [67.33%] else goto ; [32.67%] [local count: 182536110]: if (_9 == 1) goto ; [43.66%] else goto ; [56.34%] same for char. We're somehow not seeing the equivalence _9 = MEM[(unsigned int *)in_3(D) + 4B]; i_36 = (int) _9; when we know either is of a specific value. Jump threading and/or CSE should do this job. Btw, the initial code is quite convoluted and needs lot of threading to get to the above "nice" state. EVRP figures out the equivalencies but is confused by the initial : _24 = MEM[(unsigned int *)in_5(D) + 4B]; if (_24 != 4294967295) goto ; [78.28%] else goto ; [21.72%] : iftmp.0_20 = (long long unsigned int) _24; : # iftmp.0_18 = PHI <18446744073709551615(2), iftmp.0_20(3)> i_7 = (int) iftmp.0_18; which has to be jump-threaded away first with later : if (_24 != 4294967295) goto ; [78.28%] else goto ; [21.72%] : if (_24 == 6) goto ; [55.78%] else goto ; [44.22%] : or alternatively the initial sequence needs to be phi-opted earlier. In the end it appears to be a pass-ordering issue.
[Bug c++/86908] static_cast()->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 --- Comment #7 from Jonathan Wakely --- (In reply to Richard Biener from comment #6) > (In reply to Jonathan Wakely from comment #1) > > No, your program has undefined behaviour. To make it valid you either need > > to use std::launder, or use the pointer that is returned by the placement > > new. > > > > The compiler is allowed to assume that the dynamic type of does > > not change (that's why you need to use std::launder). > > You need to use std::launder at every use of the object, right? Or just launder the pointer once and then use that: auto laundered = std::launder(); laundered->doIt(); // > I wonder > why static_cast() isn't a good enough "hint" here that > the type of strategy changed (from QOI perspective, std::launder is new). Casting from type X* to Y* where X and Y happen to be the same type can happen in generic code that was already written years ago, and doesn't play these sort of dirty tricks. It would be a shame to prevent useful optimisations because of a no-op cast. We don't need to make it easier to play nasty games with the type system. There are ways to do this sanely, without undefined behaviour, even without std::launder (just using the pointer returned by the placement new-expression should be good enough, instead of accessing through every time). > I guess a better testcase would be to declare strategy as AStrategy > and placement-new BaseStrategy over it or does the standard guaranteee > that AStrategy fits in the storage of BaseStrategy? For these types, with the Itanium ABI, it fits, and you could add a static_assert to verify it. Either way you need to placement new the original type back again, otherwise the wrong destructor gets called on scope exit, which adds more undefined behaviour.
[Bug c++/86997] error: call of overloaded ‘NoDestructor()’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86997
--- Comment #3 from Jonathan Wakely ---
Don't write weird code?
Either of these works fine and is obvious what it is supposed to do:
NoDestructor b;
NoDestructor b{};
The original is weird. Is it trying to construct an 'a' object and pass that to
the NoDestructor? Or just default construct the NoDestructor object?
[Bug c++/86997] error: call of overloaded ‘NoDestructor()’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86997 --- Comment #2 from Martin Liška --- (In reply to Jonathan Wakely from comment #1) > Looks like a dup of PR 59389 Any easy workaround for it?
[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86850 --- Comment #3 from rguenther at suse dot de --- On Tue, 21 Aug 2018, dcb314 at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86850 > > --- Comment #2 from David Binderman --- > Indeed it does look like vectorizer code. Here are 20 frames, > found by using the UBSAN_OPTIONS=print_stacktrace=1 option: OK, I suppose we're creating a SLP node for a PHI where there are zero operands and thus no children and SLP_TREE_CHILDREN (node).create (nops); will not create a vector but a splice of an empty vector will barf when splicing into it. Index: gcc/tree-vect-slp.c === --- gcc/tree-vect-slp.c (revision 263656) +++ gcc/tree-vect-slp.c (working copy) @@ -1489,7 +1489,9 @@ fail: node = vect_create_new_slp_node (stmts); SLP_TREE_TWO_OPERATORS (node) = two_operators; - SLP_TREE_CHILDREN (node).splice (children); + gcc_assert (children.length () == nops); + if (!children.is_empty ()) +SLP_TREE_CHILDREN (node).splice (children); return node; }
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #19 from Wilco --- (In reply to Segher Boessenkool from comment #16) > (In reply to Wilco from comment #14) > > Note there is also an issue with costs, if the cost is zero then it seems to > > behave like infinite cost. > > 0 means unknown cost. Any known cost is treated as at least as good as > unknown cost. > > > It would be better to properly cost an > > instruction sequence given there is a new interface for this now. > > Yup. > > > If the > > cost is still zero, it could get the default cost rather than being treated > > like infinite cost, resulting in non-optimal replacements. > > Treating unknown cost as minimal cost is still non-optimal. It might work > better for your case of course. But it means for example that combine will > modify parallels less often. Well insn_cost() uses COSTS_N_INSNS (1) for instructions with unknown (zero) costs. That's a reasonable default and gives more accurate cost comparisons, eg. 0 + 4 vs 0 + 8 now becomes 4 + 4 vs 4 + 8. With insn_cost() the ldm's get cost 8+8, so the comparison is 4 + 16 vs 8 + 8, and thus the substitution will happen (though it's not clear it's useful for the selected CPU). With those changes I think there will be far fewer cases with unknown costs. There will be cases where target insn_cost needs to be improved to more accurately model complex instructions, but that will result in even better code.
[Bug c++/86908] static_cast()->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- (In reply to Jonathan Wakely from comment #1) > No, your program has undefined behaviour. To make it valid you either need > to use std::launder, or use the pointer that is returned by the placement > new. > > The compiler is allowed to assume that the dynamic type of does > not change (that's why you need to use std::launder). You need to use std::launder at every use of the object, right? I wonder why static_cast() isn't a good enough "hint" here that the type of strategy changed (from QOI perspective, std::launder is new). I guess a better testcase would be to declare strategy as AStrategy and placement-new BaseStrategy over it or does the standard guaranteee that AStrategy fits in the storage of BaseStrategy?
[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86850 --- Comment #2 from David Binderman --- Indeed it does look like vectorizer code. Here are 20 frames, found by using the UBSAN_OPTIONS=print_stacktrace=1 option: ../../trunk/gcc/vec.h:1688:5: runtime error: member call on null pointer of type 'struct vec' #0 0x2be4a24 in vec<_slp_tree*, va_heap, vl_ptr>::splice(vec<_slp_tree*, va_ heap, vl_ptr> const&) ../../trunk/gcc/vec.h:1688 #1 0x2be4a24 in vect_build_slp_tree_2 ../../trunk/gcc/tree-vect-slp.c:1492 #2 0x2bd779e in vect_build_slp_tree ../../trunk/gcc/tree-vect-slp.c:1105 #3 0x2bdba6c in vect_build_slp_tree_2 ../../trunk/gcc/tree-vect-slp.c:1257 #4 0x2bd779e in vect_build_slp_tree ../../trunk/gcc/tree-vect-slp.c:1105 #5 0x2bdba6c in vect_build_slp_tree_2 ../../trunk/gcc/tree-vect-slp.c:1257 #6 0x2bd779e in vect_build_slp_tree ../../trunk/gcc/tree-vect-slp.c:1105 #7 0x2bf1e80 in vect_analyze_slp_instance ../../trunk/gcc/tree-vect-slp.c:19 56 #8 0x2bfa002 in vect_analyze_slp(vec_info*, unsigned int) ../../trunk/gcc/tr ee-vect-slp.c:2154 #9 0x2bfaf63 in vect_slp_analyze_bb_1 ../../trunk/gcc/tree-vect-slp.c:2839 #10 0x2bfaf63 in vect_slp_bb(basic_block_def*) ../../trunk/gcc/tree-vect-slp .c:2973 #11 0x2c0d5bc in execute ../../trunk/gcc/tree-vectorizer.c:1271 #12 0x1b4e1ac in execute_one_pass(opt_pass*) ../../trunk/gcc/passes.c:2446 #13 0x1b51cf7 in execute_pass_list_1 ../../trunk/gcc/passes.c:2535 #14 0x1b51d3e in execute_pass_list_1 ../../trunk/gcc/passes.c:2536 #15 0x1b51d3e in execute_pass_list_1 ../../trunk/gcc/passes.c:2536 #16 0x1b51e18 in execute_pass_list(function*, opt_pass*) ../../trunk/gcc/pas ses.c:2546 #17 0xc9d9da in cgraph_node::expand() ../../trunk/gcc/cgraphunit.c:2116 #18 0xca2db4 in expand_all_functions ../../trunk/gcc/cgraphunit.c:2254 #19 0xca2db4 in symbol_table::compile() ../../trunk/gcc/cgraphunit.c:2605 #20 0xcaca6a in symbol_table::finalize_compilation_unit() ../../trunk/gcc/cg raphunit.c:2698
[Bug fortran/86907] [9 Regression] bogus warning "No location in expression near"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |9.0 Summary|[9.0 regression] bogus |[9 Regression] bogus |warning "No location in |warning "No location in |expression near"|expression near"
[Bug c++/86905] [6/7/8/9 Regression] g++ ICE on valid code: verify_cgraph_node failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86905 Richard Biener changed: What|Removed |Added Keywords||ice-checking Known to work||4.9.4 Version|unknown |9.0 Target Milestone|--- |6.5 Summary|g++ ICE on valid code: |[6/7/8/9 Regression] g++ |verify_cgraph_node failed |ICE on valid code: ||verify_cgraph_node failed Known to fail||5.1.0
[Bug target/86902] [9 Regression] ICE: in as_a, at machmode.h:356 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86902 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/86900] [8/9 Regression] -gdwarf-5 -O2 -ffunction-sections = assembler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86900 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug middle-end/87041] GCC 8 regression: -Wformat "reading through null pointer" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87041 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-21 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started on trunk in r254930 to report the warning.
[Bug tree-optimization/86891] [9 Regression] wrong code with -O -frerun-cse-after-loop -fno-tree-dominator-opts -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug middle-end/87041] New: GCC 8 regression: -Wformat "reading through null pointer" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87041
Bug ID: 87041
Summary: GCC 8 regression: -Wformat "reading through null
pointer" on unreachable code
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: achurch+gcc at achurch dot org
Target Milestone: ---
In GCC 8, the following code compiled with -O1 -Wformat warns about passing
NULL to a %s format token even though the call can never be executed:
extern int printf(const char *, ...);
void foo(void) {
const char * const s = 0;
if (s) printf("%s\n", s);
}
foo.c: In function 'foo':
foo.c:4:5: warning: reading through null pointer (argument 2) [-Wformat=]
if (s) printf("%s\n", s);
^~
This breaks testing macros of the following style, which worked fine through
GCC 7.3.0:
#define CHECK_STREQUAL(value, expected) do { \
const char * const _value = value;\
const char * const _expected = expected; \
if (!_value && _expected) FAIL("Got NULL, expected [%s]", _expected); \
if (_value && !_expected) FAIL("Got [%s], expected NULL", _value);\
if (_value && _expected && strcmp(_value, _expected) != 0)\
FAIL("Got [%s], expected [%s]", _value, _expected); \
} while (0)
Here, passing NULL for the value of "expected" triggers the warning on the
final FAIL() invocation, even though that case will never be executed when
"expected" is NULL.
The warning disappears at -O0 or if the variable is not const (e.g., "const
char *s" instead of "const char * const s").
[Bug libstdc++/86860] Reject valid overloads of subclass ostream operator<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86860 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- Yep, let's close it.
[Bug target/86877] ICE in vectorizable_load, at tree-vect-stmts.c:8038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86877 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Blocks||53947 Target Milestone|9.0 |--- Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/86991] [8/9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-21 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |8.3 Summary|internal compiler error: in |[8/9 Regression] ICE in |vectorizable_reduction, at |vectorizable_reduction, at |tree-vect-loop.c:6919 |tree-vect-loop.c:6919 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r250382.
[Bug c++/86875] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86875 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.3
[Bug rtl-optimization/86990] [9 Regression] wrong code at -O2 on x86_64-linux-gnu in 64-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86990 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||8.2.0 Version|unknown |9.0 Keywords||wrong-code Last reconfirmed||2018-08-21 CC||ebotcazou at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|wrong code at -O2 on|[9 Regression] wrong code |x86_64-linux-gnu in 64-bit |at -O2 on x86_64-linux-gnu |mode|in 64-bit mode Target Milestone|--- |9.0 Known to fail||9.0 --- Comment #1 from Martin Liška --- Confirmed, started with r261089.
[Bug target/86869] ICE when taking address of array member of __memx struct pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86869 --- Comment #1 from Richard Biener --- #ifndef POINTERS_EXTEND_UNSIGNED gcc_assert (GET_MODE (x) == to_mode || GET_MODE (x) == VOIDmode); return x; #else /* defined(POINTERS_EXTEND_UNSIGNED) */ scalar_int_mode pointer_mode, address_mode, from_mode; rtx temp; So clearly avr has to define POINTERS_EXTEND_UNSIGNED in the correct way and/or the assert needs to be ajdusted for pointer/address_mode of as.
[Bug target/87040] New: ICE in extract_constrain_insn_cached, at recog.c:2218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87040
Bug ID: 87040
Summary: ICE in extract_constrain_insn_cached, at recog.c:2218
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu
Following ICEs:
$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20030605-1.c
-fif-conversion2 -Og
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20030605-1.c:
In function ‘set_bh_page’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20030605-1.c:12:1:
error: insn does not satisfy its constraints:
12 | }
| ^
(insn 25 0 0 (set (reg:DI 121)
(const_int 4095 [0xfff])) 441 {*movdi_internal64}
(nil))
during RTL pass: ce3
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20030605-1.c:12:1:
internal compiler error: in extract_constrain_insn_cached, at recog.c:2218
0xfa3b95 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:108
0xfa3bf9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:118
0xf47798 extract_constrain_insn_cached(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.c:2218
0x17b165d insn_default_length(rtx_insn*)
/home/marxin/Programming/gcc/gcc/config/rs6000/rs6000.md:6831
0xb90531 get_attr_length_1
/home/marxin/Programming/gcc/gcc/final.c:407
0xb90566 get_attr_length(rtx_insn*)
/home/marxin/Programming/gcc/gcc/final.c:425
0x14fb201 rs6000_insn_cost
/home/marxin/Programming/gcc/gcc/config/rs6000/rs6000.c:34085
0xfb2b71 insn_cost(rtx_insn*, bool)
/home/marxin/Programming/gcc/gcc/rtlanal.c:5435
0xb574bb canonicalize_comparison(machine_mode, rtx_code*, rtx_def**)
/home/marxin/Programming/gcc/gcc/expmed.c:6249
0xeab7af prepare_cmp_insn
/home/marxin/Programming/gcc/gcc/optabs.c:3816
0xeafb35 gen_cond_trap(rtx_code, rtx_def*, rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/optabs.c:5288
0x1a5960f find_cond_trap
/home/marxin/Programming/gcc/gcc/ifcvt.c:4657
0x1a58840 find_if_header
/home/marxin/Programming/gcc/gcc/ifcvt.c:4282
0x1a5b381 if_convert
/home/marxin/Programming/gcc/gcc/ifcvt.c:5405
0x1a5b801 execute
/home/marxin/Programming/gcc/gcc/ifcvt.c:5599
[Bug debug/87039] [8/9 Regression] DW_OP_fbreg used without a frame base on a C++ code w/ -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87039 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-21 CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||mark at gcc dot gnu.org Ever confirmed|0 |1
[Bug debug/87039] New: [8/9 Regression] DW_OP_fbreg used without a frame base on a C++ code w/ -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87039
Bug ID: 87039
Summary: [8/9 Regression] DW_OP_fbreg used without a frame base
on a C++ code w/ -fopenmp
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Starting from r257510, GCC emits debug info about which elfutils is not happy
about:
$ cat filter.ii
template void e(a, d, b);
template void g(double[][f]) {
for (int c; c;)
;
}
template
void i(int, int, int, int, int, int, int, int, double[], double[], double *[],
int) {
#pragma omp parallel
{
int j;
double k[1][h];
e(j, h, k);
g(k);
}
}
double *l;
int m;
double n[1], o[1];
void p() { i(0, 0, 1, 0, 0, 1, 0, 0, n, o, , m); }
$ g++ filter.ii -c -g -O2 -fopenmp &&
/home/marxin/Programming/elfutils/tests/varlocs -e filter.o
module 'filter.o'
[b] CU 'filter.ii'@0
[229] inlined function 'i'@20
[24e] parameter ''
[254] parameter ''
[25a] parameter ''
[260] parameter ''
[266] parameter ''
[26c] parameter ''
[272] parameter ''
[278] parameter ''
[27e] parameter ''
[20,30) {addr(0x38), stack_value}
[28e] parameter ''
[20,30) {addr(0x30), stack_value}
[29e] parameter ''
[20,30) {addr(0x48), stack_value}
[2ae] parameter ''
[20,2f) {addr(0x40)}
[18f] function '_Z1iIcLi1ELi0EEvPdS0_PS0_i._omp_fn.0'@0
frame_base: XXX zero address
[1a6] parameter ''
[0,b) {reg5}
[b,1a) {GNU_entry_value(1) {reg5}, stack_value}
[13d] inlined function 'g<1>'@15
[162] parameter ''
[15,1a) {/home/marxin/Programming/elfutils/tests/varlocs: DW_OP_fbreg
used without a frame base
The test-case is isolated from Inkscape program.
[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug libstdc++/86860] Reject valid overloads of subclass ostream operator<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86860 --- Comment #3 from Richard Biener --- So INVALID?
[Bug tree-optimization/86853] [7/8 Regression] sprintf optimization for wide strings doesn't account for conversion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86853 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||9.0 Target Milestone|--- |7.4 Summary|sprintf optimization for|[7/8 Regression] sprintf |wide strings doesn't|optimization for wide |account for conversion |strings doesn't account for |failure |conversion failure Known to fail|9.0 | --- Comment #3 from Richard Biener --- I assume trunk is fixed. This is a regression.
[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86850 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-21 CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Can you post a backtrace? Probably vectorizer code.
[Bug tree-optimization/86847] [9 Regression] Switch code size growth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86847 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
--- Comment #2 from Jonathan Wakely ---
And for the goto case Clang says:
87038.c:2:13: warning: variable 'foo' is used uninitialized whenever 'if'
condition is true [-Wsometimes-uninitialized]
if (x == 0) goto lbl;
^~
87038.c:5:31: note: uninitialized use occurs here
printf("foo is %d\n", foo);
^~~
87038.c:2:9: note: remove the 'if' if its condition is always false
if (x == 0) goto lbl;
^~~~
87038.c:3:9: note: variable 'foo' is declared here
int foo = 3;
^
1 warning generated.
