[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #2 from Richard Biener --- You also might want to test the patch from PR87132. --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Richard Biener --- > If you disable bootstrap does it work? The backtrace makes it look like > memory > corruption. Maybe you can also throw valgrind on it? A --disable-bootstrap build (c, c++ only) does work on i386-pc-solaris2.11, but I didn't run make check. While there is a Solaris/x86 valgrind port, I haven't used it yet (and it seems I'll have to use the git version on Solaris 11.4). For a start, I ran the failing compilation with libumem (a debugging malloc) preloaded and UMEM_DEBUG=default: this way, the compilation succeeded without errors. Afterwards, I managed to bootstrap with just LD_PRELOAD=libumem.so on both i386-pc-solaris2.11 and sparc-sun-solaris2.11. That completed successfully, but 200+ 32-bit Go tests now FAIL, together with two 64-bit libstdc++ max_align_t tests. Since there are already similar Go failures with the libc malloc, I'm pretty sure this is just uncovering a preexisting libgo bug. I'll try what I can find with valgrind next.
[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 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to cfd from comment #5) > It would be rather surprising if the Fortran standard viewed this as being > invalid code (the procedure in question is bound to a dervied type, > hence should > be overridable). Note that the error has nothing to do with type binding or overriding at all. It concerns the name clash of the two subroutines. This reduced version (without any derived types) shows the same error (and ICE): module base implicit none contains subroutine summation(i,j) integer(4), intent(in) :: i integer(4), intent(out) :: j j = i + 1 end subroutine end module base module extended use base implicit none contains subroutine summation(i,j) integer(4), intent(in) :: i integer(4), intent(out) :: j j = i + 2 end subroutine end module extended You have plenty of options to get around the error: a) Don't use-import the first 'summation' routine in the second module (as shown comment 1). b) Make the 'summation' routines private and only make them available via the type binding. c) Use two different names, e.g. type, abstract :: base_type contains procedure :: summation => summation_base end type base_type type, extends(base_type) :: extended_type contains procedure :: summation => summation__ext end type extended_type
[Bug c++/87148] New: backward compatibility issue to take char [] as incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87148
Bug ID: 87148
Summary: backward compatibility issue to take char [] as
incomplete type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: will.xzm at gmail dot com
Target Milestone: ---
struct Tst{
char t[];
};
new Tst();
It will fail when compiled by gcc (7.3 or 8.2)
error: value-initialization of incomplete type [1mchar []
I have to correct to "char t[0]";
but with gcc 4.8.2 , it works fine.
Is it by design ??
Is there alternative way to make last version to compile successfully without
modify code ??
[Bug c++/49224] [C++0x] Scoped enumeration instantiated even if not required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49224 Eric Gallager changed: What|Removed |Added CC||jason at redhat dot com, ||nathan at acm dot org --- Comment #3 from Eric Gallager --- cc-ing c++ FE maintainers
[Bug middle-end/86540] [9 Regression] pr77445-2.c and ssa-dom-thread-7.c regressions since May 20, 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86540 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law --- It's on my TODO list :-)
[Bug tree-optimization/84561] -Wstringop-truncation with -O2 depends on strncpy's size type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84561 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01934.html
[Bug target/86856] Format warnings building all-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856 --- Comment #12 from jon_y <10walls at gmail dot com> --- I've just tested the trunk version as a Linux native build, I don't see the warnings. I will proceed to do a mingw cross compiler soon with the trunk version.
[Bug target/87139] 6.4 x86_64 incorrect code generation with -O3 around _addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87139 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE Target Milestone|--- |6.5 --- Comment #6 from H.J. Lu --- Fixed on GCC 6 branch and above. *** This bug has been marked as a duplicate of bug 81300 ***
[Bug target/81300] -fpeephole2 breaks __builtin_ia32_sbb_u64, _subborrow_u64 on AMD64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81300 H.J. Lu changed: What|Removed |Added CC||cbcode at gmail dot com --- Comment #7 from H.J. Lu --- *** Bug 87139 has been marked as a duplicate of this bug. ***
[Bug middle-end/87053] wrong code with c_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87053 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- Fixed by Bernd's patch on the trunk.
[Bug middle-end/87053] wrong code with c_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87053 --- Comment #1 from Jeffrey A. Law --- Author: law Date: Wed Aug 29 22:16:09 2018 New Revision: 263968 URL: https://gcc.gnu.org/viewcvs?rev=263968&root=gcc&view=rev Log: gcc: 2018-08-22 Bernd Edlinger PR middle-end/87053 * builtins.c (c_strlen): Improve range checks. testsuite: 2018-08-22 Bernd Edlinger PR middle-end/87053 * gcc.c-torture/execute/pr87053.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr87053.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/84561] -Wstringop-truncation with -O2 depends on strncpy's size type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84561 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Known to fail||8.2.0, 9.0 --- Comment #3 from Martin Sebor --- Testing a patch.
[Bug middle-end/86714] tree-ssa-forwprop.c confused by too long initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86714 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #9 from Jeffrey A. Law --- Should be fixed on trunk now.
[Bug middle-end/86711] [9 Regression] wrong folding of memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86711 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law --- Should be fixed on trunk now.
[Bug sanitizer/87095] [8/9 Regression] UndefinedBehaviorSanitizer vptr false positive with virtual inheritance only with -fno-sanitize-recover
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87095 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Aug 29 21:43:18 2018 New Revision: 263967 URL: https://gcc.gnu.org/viewcvs?rev=263967&root=gcc&view=rev Log: PR c++/87095 * decl.c (begin_destructor_body): If current_class_type has virtual bases and the primary base is nearly empty virtual base, voidify clearing of vptr and make it conditional on in-charge argument. * g++.dg/ubsan/vptr-13.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/vptr-13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/87147] New: GCC miscompiles at -O3 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87147
Bug ID: 87147
Summary: GCC miscompiles at -O3 on valid code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
It miscompiles after r263959. Bisect points to r263875.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180829 (experimental) [trunk revision 263965] (GCC)
$ gcc-trunk abc.c ; ./a.out
$ gcc-trunk -O3 abc.c ; timeout -s 9 10 ./a.out
Killed
$ cat abc.c
short a;
long b;
int c, d, g;
char e, h;
long f[] = {0};
int main() {
int i = 1;
for (; a <= 3; a++) {
c = 0;
for (; c <= 2; c++) {
b = 0;
for (; b <= 3; b++) {
h = i && f[d];
e = g && i;
i = 0;
}
}
}
}
[Bug tree-optimization/87117] [9 Regression] ICE in eliminate_dom_walker::eliminate_cleanup(bool) at gcc/gcc/tree-ssa-sccvn.c:5431 since r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87117 --- Comment #16 from David Binderman --- (In reply to rguent...@suse.de from comment #15) > On Wed, 29 Aug 2018, dcb314 at hotmail dot com wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87117 > > > > --- Comment #14 from David Binderman --- > > Using a non-gcc compiler, for example clang, at the start > > seems to break the ubsan bootstrap. > > > > Would it be worth me sending in another bug report or just posting > > it here ? > > Please in another bug, not here. Done. #87146.
[Bug bootstrap/87146] New: ubsan bootstrap with non-gcc compiler fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87146 Bug ID: 87146 Summary: ubsan bootstrap with non-gcc compiler fails Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- This bootstrap configure line works fine: ../trunk/configure --prefix=/home/dcb/gcc/results.263945.ubsan \ --with-build-config=bootstrap-ubsan \ --disable-multilib \ --disable-werror \ --enable-checking=release \ --enable-languages=c,c++,fortran This doesn't CC="/home/dcb/llvm/clang601/bin/clang -Wall" \ CXX="/home/dcb/llvm/clang601/bin/clang++ -Wall" \ ../trunk/configure --prefix=/home/dcb/gcc/results.263945.ubsan \ --with-build-config=bootstrap-ubsan \ --disable-multilib \ --disable-werror \ --enable-checking=release \ --enable-languages=c,c++,fortran failing at the bootstrap compare Comparing stages 2 and 3 Bootstrap comparison failure! fixincludes/fixfixes.o differs gcc/ira-conflicts.o differs gcc/gcc.o differs gcc revision is 263945. Should I wait for upcoming clang 7.0 or is there something special about a non-gcc compiler bootstrap ?
[Bug c++/87145] New: Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145
Bug ID: 87145
Summary: Implicit conversion to scoped enum fails: "error:
taking address of temporary/rvalue"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: programmer at posteo dot de
Target Milestone: ---
The following code can be compiled with GCC 6.3, but GCC 7.1 and later abort
the compilation with an error message.
=
#include
#include
enum class Enum : std::size_t {};
struct Pod {
std::size_t val;
constexpr operator Enum() const {
return static_cast(val);
}
};
template
constexpr void foo() {
using Foo = std::integral_constant;
}
int main() {
foo<2>();
}
=
Error message from current trunk:
=
: In instantiation of 'constexpr void foo() [with long unsigned int N =
2]':
:21:10: required from here
:17:50: error: taking address of rvalue [-fpermissive]
17 | using Foo = std::integral_constant;
| ^
:17:50: error: no matching function for call to 'Pod::operator
Enum(Pod*)'
:10:13: note: candidate: 'constexpr Pod::operator Enum() const'
10 | constexpr operator Enum() const {
| ^~~~
:10:13: note: candidate expects 0 arguments, 1 provided
Compiler returned: 1
=
Live demo: https://godbolt.org/z/vfvGiS
PS: Which version should I choose if multiple versions are affected: stable,
trunk or [the first version with that regression]?
[Bug fortran/29550] Optimize -fexternal-blas calls for conjg()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550 Thomas Koenig changed: What|Removed |Added Attachment #44600|0 |1 is obsolete|| --- Comment #13 from Thomas Koenig --- Created attachment 44627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44627&action=edit Patch which shows the principle This shows a way in which this could be done. Bounds checking and reallocation on assignment are still missing, but should be doable (like the inline matmul stuff already does).
[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 --- Comment #5 from c...@mnet-mail.de --- It would be rather surprising if the Fortran standard viewed this as being invalid code (the procedure in question is bound to a dervied type, hence should be overridable). Better to consult the standard to be sure (don't have a copy at hand, unfortunately). On 08/29/2018 09:47 PM, janus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85357 > > janus at gcc dot gnu.org changed: > > What|Removed |Added > > CC||janus at gcc dot gnu.org > > --- Comment #4 from janus at gcc dot gnu.org --- > I would argue that the code is actually invalid. A current trunk build shows: > > 23 |use base > | 2 > > 34 |subroutine summation(self,i,j) > | 1 > Error: Procedure ‘summation’ at (1) is already defined at (2) > > That's also what I get with all earlier versions I tried, and I think the > error > is correct. > > The only bug I can see is the ICE that occurs with trunk (after the original > error message and a couple of follow-up errors): > > f951: internal compiler error: Segmentation fault > 0xc5ac8f crash_signal > /home/jweil/github/gcc/trunk/gcc/toplev.c:325 > 0x6a75b4 free_sym_tree > /home/jweil/github/gcc/trunk/gcc/fortran/symbol.c:3892 > 0x6a75bc free_sym_tree > /home/jweil/github/gcc/trunk/gcc/fortran/symbol.c:3892 > 0x6a75bc free_sym_tree > /home/jweil/github/gcc/trunk/gcc/fortran/symbol.c:3892 > 0x6a75bc free_sym_tree > /home/jweil/github/gcc/trunk/gcc/fortran/symbol.c:3892 > 0x6a75bc free_sym_tree > /home/jweil/github/gcc/trunk/gcc/fortran/symbol.c:3892 > > Looks like an infinite recursion in 'free_sym_tree'. >
[Bug target/86106] powerpc: Suboptimal logical operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86106 Segher Boessenkool changed: What|Removed |Added Target|powerpc |powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-29 Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed. GCC has constant ints (not a variable) already before expand, and already in GCC 4.8 (I didn't check older).
[Bug tree-optimization/87144] New: missing -Wformat for mismatched argument type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87144
Bug ID: 87144
Summary: missing -Wformat for mismatched argument type
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC fails to diagnose the argument mismatch below. -Wformat runs too early to
detect it but the snprintf pass could do it.
$ cat f.c && gcc -O2 -S -Wall f.c
int f (_Bool str, int x, const char *s)
{
const char *f = str ? "%s" : "%i";
// Note the typo in the ternary operator below: it should be
// str ? s : x);
// instead.
return __builtin_snprintf (0, 0, f, s ? str : x);
}
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 85265, which changed state. Bug 85265 Summary: [concepts] ICE with missing identifier https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85265 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/85265] [concepts] ICE with missing identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85265 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #3 from Paolo Carlini --- Fixed.
[Bug c++/85265] [concepts] ICE with missing identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85265 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Aug 29 20:29:55 2018 New Revision: 263966 URL: https://gcc.gnu.org/viewcvs?rev=263966&root=gcc&view=rev Log: /cp 2018-08-29 Paolo Carlini PR c++/85265 * parser.c (cp_parser_introduction_list): If cp_parser_identifier returns error_mark_node early exit the loop. (cp_parser_template_introduction): Improve error-recovery, remove error call about empty introduction-list. /testsuite 2018-08-29 Paolo Carlini PR c++/85265 * g++.dg/concepts/pr85265.C: New. Added: trunk/gcc/testsuite/g++.dg/concepts/pr85265.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug target/86856] Format warnings building all-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856 Martin Sebor changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #11 from Martin Sebor --- (In reply to nightstrike from comment #9) The %G warnings are due to r263239: the expected argument type has changed in GCC 9 from gcall* to gimple*. There's no way to avoid those warnings when using an older compiler. They should not appear if you use GCC 9 to build it.
[Bug c++/84898] Fix-it hints for '.' vs '->'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84898 David Malcolm changed: What|Removed |Added Keywords||patch --- Comment #4 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01909.html which implements the fix-it hints for C++, but doesn't change the wording.
[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 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #4 from janus at gcc dot gnu.org --- I would argue that the code is actually invalid. A current trunk build shows: 23 |use base | 2 34 |subroutine summation(self,i,j) | 1 Error: Procedure ‘summation’ at (1) is already defined at (2) That's also what I get with all earlier versions I tried, and I think the error is correct. The only bug I can see is the ICE that occurs with trunk (after the original error message and a couple of follow-up errors): f951: internal compiler error: Segmentation fault 0xc5ac8f crash_signal /home/jweil/github/gcc/trunk/gcc/toplev.c:325 0x6a75b4 free_sym_tree /home/jweil/github/gcc/trunk/gcc/fortran/symbol.c:3892 0x6a75bc free_sym_tree /home/jweil/github/gcc/trunk/gcc/fortran/symbol.c:3892 0x6a75bc free_sym_tree /home/jweil/github/gcc/trunk/gcc/fortran/symbol.c:3892 0x6a75bc free_sym_tree /home/jweil/github/gcc/trunk/gcc/fortran/symbol.c:3892 0x6a75bc free_sym_tree /home/jweil/github/gcc/trunk/gcc/fortran/symbol.c:3892 Looks like an infinite recursion in 'free_sym_tree'.
[Bug preprocessor/87088] Attached program doesn't finish compiling and linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87088 --- Comment #14 from Jonathan Wakely --- There is no GCC bug here.
[Bug tree-optimization/87074] [8/9 Regression] Unroll and jam bug: O3 result differ from O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87074
--- Comment #4 from Jakub Jelinek ---
outer->header is:
bb_4 (preds = {bb_3 bb_11 }, succs = {bb_5 })
{
[local count: 118111601]:
# f.10_31 = PHI
# .MEM_34 = PHI <.MEM_18(D)(3), .MEM_21(11)>
# g_lsm.15_33 = PHI
_75 = (unsigned int) g_lsm.15_33;
}
the bb into which the inner loop exits is:
bb_6 (preds = {bb_5 }, succs = {bb_11 bb_7 })
{
[local count: 118111601]:
# _11 = PHI <_8(5)>
_9 = (int) _11;
_12 = f.10_31 + 1;
if (_12 <= 10)
goto ; [89.00%]
else
goto ; [11.00%]
}
and outer->latch is:
bb_11 (preds = {bb_6 }, succs = {bb_4 })
{
[local count: 105119325]:
goto ; [100.00%]
}
>From what I can see, gimple-loop-jam.c verifies using bb_prevents_fusion_p
these 3 bbs, but nothing checks the outer loop's IVs.
The problem is that a value computed by the inner loop (_8) is then used inside
of the outer loop and fed into the next inner loop too.
So, shall we punt if there are any phis in single_exit (loop)->dest (other than
virtual) (assuming here that we are in loop closed SSA form) and thus there are
any SSA_NAME uses from the inner loop to next outer loop's iteration?
Or are there perhaps any exceptions that can be handled, like if a value
computed by the inner loop is not used only after the outer loop exits?
[Bug c++/87137] [8/9 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 --- Comment #10 from Nathan Sidwell --- gcc-8 patch posted https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01900.html
[Bug preprocessor/87088] Attached program doesn't finish compiling and linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87088 --- Comment #13 from miltonkbenjamin --- (In reply to Jonathan Wakely from comment #12) > (In reply to miltonkbenjamin from comment #11) > > > C:\parser>g++ -include iostream.h -Xpreprocessor "FlexLexer.h" > > > lex1.yy.cc > > You're STILL passing a filename as the argument to -Xpreprocessor. > > What part of my comments do you not understand? Hi Jonathan, I tried what you suggested, and it failed as per comment 10 here. If you can send me an email address, I can send you the files (and for a fee?) see if you can get it working. I installed win_flex, win_bison and g++ on dozens of Win 7 PCS and it worked each and every time. I currently have a Win 10 PC and it failed on 3 Win 10 PC's I have access to. Thanks for your support, Milt Benjamin
[Bug target/87133] ICE in aggregate_value_p with -frounding-math on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87133 --- Comment #7 from Segher Boessenkool --- lang_hooks.types.type_for_mode can return NULL, but emit_library_call_value cannot handle that. Why it fails on a cross and not natively, I don't know... target bug is my guess.
[Bug middle-end/86714] tree-ssa-forwprop.c confused by too long initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86714 --- Comment #8 from Jeffrey A. Law --- Author: law Date: Wed Aug 29 17:17:08 2018 New Revision: 263963 URL: https://gcc.gnu.org/viewcvs?rev=263963&root=gcc&view=rev Log: PR tree-optimization/86714 PR tree-optimization/86711 * builtins.c (c_strlen): Add arguments to call to string_constant. * expr.c (string_constant): Add argument. Detect missing nul terminator and outermost declaration it's missing in. * expr.h (string_constant): Add argument. * fold-const.c (read_from_constant_string): Add arguments to call to string_constant. (c_getstr): Likewise. * tree-ssa-forwprop.c (simplify_builtin_call): Likewise. to string_constant. * tree-ssa-strlen.c (get_stridx): Likewise. PR tree-optimization/86714 PR tree-optimization/86711 * gcc.c-torture/execute/memchr-1.c: New test. * gcc.c-torture/execute/pr86714.c: New test. * gcc.c-torture/execute/widechar-3.c: New test. * gcc.dg/strlenopt-58.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/memchr-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr86714.c trunk/gcc/testsuite/gcc.c-torture/execute/widechar-3.c trunk/gcc/testsuite/gcc.dg/strlenopt-58.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/expr.c trunk/gcc/expr.h trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c trunk/gcc/tree-ssa-strlen.c
[Bug middle-end/86711] [9 Regression] wrong folding of memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86711 --- Comment #5 from Jeffrey A. Law --- Author: law Date: Wed Aug 29 17:17:08 2018 New Revision: 263963 URL: https://gcc.gnu.org/viewcvs?rev=263963&root=gcc&view=rev Log: PR tree-optimization/86714 PR tree-optimization/86711 * builtins.c (c_strlen): Add arguments to call to string_constant. * expr.c (string_constant): Add argument. Detect missing nul terminator and outermost declaration it's missing in. * expr.h (string_constant): Add argument. * fold-const.c (read_from_constant_string): Add arguments to call to string_constant. (c_getstr): Likewise. * tree-ssa-forwprop.c (simplify_builtin_call): Likewise. to string_constant. * tree-ssa-strlen.c (get_stridx): Likewise. PR tree-optimization/86714 PR tree-optimization/86711 * gcc.c-torture/execute/memchr-1.c: New test. * gcc.c-torture/execute/pr86714.c: New test. * gcc.c-torture/execute/widechar-3.c: New test. * gcc.dg/strlenopt-58.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/memchr-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr86714.c trunk/gcc/testsuite/gcc.c-torture/execute/widechar-3.c trunk/gcc/testsuite/gcc.dg/strlenopt-58.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/expr.c trunk/gcc/expr.h trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c trunk/gcc/tree-ssa-strlen.c
[Bug fortran/87143] Uninitialized warnings when using automatic array allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87143 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-29 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 7.3 up to trunk (9.0). I am sure there are several duplicates.
[Bug middle-end/86995] [9 regression] c-c++-common/torture/builtin-arith-overflow-17.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86995 --- Comment #6 from Vlad Lazar --- Here's the patch: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01889.html
[Bug middle-end/87138] [8/9 Regression] wrong code with TI multiplication with -O -march=k8 -fno-tree-fre -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87138 --- Comment #2 from Jakub Jelinek --- Created attachment 44626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44626&action=edit gcc9-pr87138.patch That revision just uncovered a latent bug in expand_mult_const. If val_so_far is above HOST_WIDE_INT_MAX and nmode is wider than 64-bits, it adds an incorrect REG_EQUAL note, says the partial result is equal to const_int 0x8000, which is a negative value of (__int128) (- LONG_MAX - 1), but it should actually use const_wide_int 0x08000 instead (or const_double if const_wide_int isn't supported).
[Bug target/87139] 6.4 x86_64 incorrect code generation with -O3 around _addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87139 --- Comment #5 from cbcode at gmail dot com --- (In reply to H.J. Lu from comment #4) > (In reply to cbcode from comment #2) > > Created attachment 44621 [details] > > test reproducing the problem > > How to show the problem? Save the attachment as test.cpp, compile, run and look at the output: g++ -std=c++11 -O3 -o test test.cpp && ./test 10 function bigmul() multiplies two arbitrary-precision integers, and main() generates a few random examples and format them as a python3-script, consisting of lines of the form: if a * b != expected: print a, b, expected, a * b To run the tests, do: g++ -std=c++11 -O3 -o test test.cpp && ./test 10 | python3 If the gcc version is not 6, or if the optimization level is below -O3, all checks will pass and there is no output. With the default g++ in amd64-debian-stable at the time of this writing (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) I get the following output: $ g++ -std=c++11 -O3 -o test test.cpp && ./test 10 | python3 0xbeeb8da1658eec67910a2dec89025cc1 * 0x71c18690ee42c90bf893a2eefb32555e = 0x54d64d7566d4996250f93066b9e161138d4d6f3a582b5c4f9f3bd72d705c23de ? 0x54d64d7566d4996250f93066b9e161128d4d6f3a582b5c4f9f3bd72d705c23de 0xc34d0bff9015028071bb54d8d101b5b9 * 0x85e7bb0f12278575e099ec6cd7363ca5 = 0x6627d0766096e0e087e772aabc35719b32092fcf64d348f16eb53cc1d0b77c3d ? 0x6627d0766096e0e087e772aabc35719a32092fcf64d348f16eb53cc1d0b77c3d 0xcb435c8e74616796491718de357e3da8 * 0x9afcd44d14cf8bfe6775dc7701564f61 = 0x7b0f448dcaac0546958108e31e6bff5afc779f31bc686ccf2bbb7e72984c34a8 ? 0x7b0f448dcaac0546958108e31e6bff59fc779f31bc686ccf2bbb7e72984c34a8 0x87b341d690d7a28a7476cf8a4baa5dc0 * 0x2ac2ce17a5794a3b6f9b6dae6f4c57a8 = 0x16aaabe3e0298b6b287985777faad3121c5e6216bd208bf75d540032a2a9c600 ? 0x16aaabe3e0298b6b287985777faad3111c5e6216bd208bf75d540032a2a9c600 0xd0bad0da572baaf1a534a6a6b7fd0b63 * 0xe263183773ef6508ae84379630af89ee = 0xb895b85e3fa2b67d1b3b3243d7509b6b0ca8fe779ebdc9d4475c5094d105910a ? 0xb895b85e3fa2b67d1b3b3243d7509b6a0ca8fe779ebdc9d4475c5094d105910a 0x70616f2f48dce01c65ace2685a072c6d * 0x879e2e2256feff0c40d6824e2ef3fc17 = 0x3b88d20523b761dd4aec1ed139f28c4baa0e1564fccd5926707eb1ffe7d749cb ? 0x3b88d20523b761dd4aec1ed139f28c4aaa0e1564fccd5926707eb1ffe7d749cb 0xbf8c59bb003553c18b2e02445e4be0f5 * 0xab27a171be5b133cd16aa4b296eb9d18 = 0x8010671df4712da0478a910d2b8b019bd201c56c8ce38b81bf08880e6efa57f8 ? 0x8010671df4712da0478a910d2b8b019ad201c56c8ce38b81bf08880e6efa57f8 7 out of 10 tests fail, there is bit flipped somewhere in the middle. g++ -std=c++11 -O2 -o test test.cpp && ./test 10 | python3 passes all tests, as does g++ -O3 with a gcc version other than 6.x. The problem seems to require the presence of loops (and presumably their unrolling), and the add_overflow and add_carry need to appear next to each other without anything in between. I was not able to narrow it down further.
[Bug fortran/87143] New: Uninitialized warnings when using automatic array allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87143 Bug ID: 87143 Summary: Uninitialized warnings when using automatic array allocation Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: andrew at fluidgravity dot co.uk Target Milestone: --- I get the following warnings when compiling the code below: > gfortran -Wall -std=f2008 code.f90 code.f90:5:0: i = [0, 1, 2] Warning: ‘i.offset’ is used uninitialized in this function [-Wuninitialized] code.f90:5:0: Warning: ‘i.dim[0].lbound’ is used uninitialized in this function [-Wuninitialized] code.f90:5:0: Warning: ‘i.dim[0].ubound’ is used uninitialized in this function [-Wuninitialized] code.f90:5:0: i = [0, 1, 2] Warning: ‘i.dim[0].lbound’ may be used uninitialized in this function [-Wmaybe-uninitialized] code.f90:5:0: Warning: ‘i.dim[0].ubound’ may be used uninitialized in this function [-Wmaybe-uninitialized] code.f90:5:0: Warning: ‘i.dim[0].ubound’ may be used uninitialized in this function [-Wmaybe-uninitialized] code.f90:5:0: Warning: ‘i.dim[0].lbound’ may be used uninitialized in this function [-Wmaybe-uninitialized] > cat code.f90 PROGRAM p IMPLICIT NONE INTEGER, ALLOCATABLE :: i(:) i = [0, 1, 2] PRINT*,SIZE(i) PRINT*,i END PROGRAM p
[Bug c++/30812] enhancement: exception specification in __PRETTY_FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30812 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #4 from Nathan Sidwell --- A function's noexceptness is part of the type in c++11, so it might make sense to include that.
[Bug middle-end/87138] [8/9 Regression] wrong code with TI multiplication with -O -march=k8 -fno-tree-fre -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87138 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Component|rtl-optimization|middle-end
[Bug fortran/87142] New: Aliasing issue with overloaded assignment and allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142
Bug ID: 87142
Summary: Aliasing issue with overloaded assignment and
allocatable components
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mscfd at gmx dot net
Target Milestone: ---
The following code does not work, as the left hand side in "str = str%cs(1:10)"
is deallocated, before the right hand side, where str also appears, is
evaluated. With gfortran-7.3.0, the output looks right, but I see invalid
memory accesses in valgrind. In other circumstances, depending on the length of
the string and with 8.1.0, I have also seen wrong results, but then depending
on the optimisation level. As far as I know, this is a violation of the
standard, which requires that the right hand side is evaluated before the left
hand side is modified (i.e. in this case deallocated).
module mod
implicit none
private
type, public :: string
character(len=:), allocatable :: cs
contains
procedure, public :: assign
generic, public :: assignment(=) => assign
end type string
contains
elemental subroutine assign(self, cs)
class(string), intent(inout) :: self
character(len=*), intent(in) :: cs
! this is not working if cs and self%cs are aliasing
self%cs = cs
end subroutine assign
end module mod
program assign_alias
use mod
implicit none
type(string) :: str
str%cs = repeat('0123456789', 100)
str = str%cs(1:10)
end program assign_alias
[Bug c++/87137] [8/9 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 --- Comment #9 from Liu Hao --- (In reply to Nathan Sidwell from comment #6) > Created attachment 44623 [details] > patch > > This patch appears to fix the problem It'd be good to (a) confirms it also > passes on MS's compiler With this patch applied, GCC 8.2.1 accepts the testcase, as well as Microsoft CL 19.15.26726 .
[Bug bootstrap/87141] New: configure:14586: error: Could not determine word size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87141 Bug ID: 87141 Summary: configure:14586: error: Could not determine word size. Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mfe at live dot de Target Milestone: --- Created attachment 44625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44625&action=edit config he exact version of GCC: gcc-8.2.0 the system type: NetgearReadyNAS Duo (http://wiki.dietpc.org/index.php/DIET-PC_on_SPARC_ReadyNAS) the options given when GCC was configured/built: ../gcc-8.2.0/configure --prefix=/opt/gcc-8.2/ --enable-languages=c,c++,go --with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local --with-isl=/usr/local/ --disable-doc --host=sparc-linux --build=sparc-linux --disable-libstdcxx-pch --disable-linux-futex --disable-libsanitizer --disable-libcilkrts --disable-libitm --disable-libitm CC=/opt/gcc-7.3/bin/gcc CXX=/opt/gcc-7.3/bin/g++ && /usr/local/bin/make ## - ## ## Platform. ## ## - ## hostname = nas-02-90-38 uname -m = padre uname -r = 2.6.17.14ReadyNAS uname -s = Linux uname -v = #1 Wed Jun 20 20:08:20 PDT 2012 the complete command line that triggers the bug (stage3); /usr/local/bin/make the compiler output (error messages, warnings, etc.); [...] checking if /media/gcc-8.2.0-compiled/./gcc/xgcc -B/media/gcc-8.2.0-compiled/./gcc/ -B/opt/gcc-8.2/sparc-linux/bin/ -B/opt/gcc-8.2/sparc-linux/lib/ -isystem /opt/gcc-8.2/sparc-linux/include -isystem /opt/gcc-8.2/sparc-linux/sys-includesupports -c -o file.o... (cached) yes checking whether the /media/gcc-8.2.0-compiled/./gcc/xgcc -B/media/gcc-8.2.0-compiled/./gcc/ -B/opt/gcc-8.2/sparc-linux/bin/ -B/opt/gcc-8.2/sparc-linux/lib/ -isystem /opt/gcc-8.2/sparc-linux/include -isystem /opt/gcc-8.2/sparc-linux/sys-includelinker (/media/gcc-8.2.0-compiled/./gcc/collect-ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for thread model used by GCC... posix checking for ANSI C header files... (cached) yes checking whether string.h and strings.h may both be included... yes looking for a compliant stdint.h in stdint.h, checking for uintmax_t... yes checking for uintptr_t... yes checking for int_least32_t... yes checking for int_fast32_t... yes checking for uint64_t... yes checking what to include in gstdint.h... stdint.h (already complete) checking fenv.h usability... yes checking fenv.h presence... yes checking for fenv.h... yes checking for 1 byte integer... yes checking for 2 byte integer... yes checking for 4 byte integer... yes checking for 8 byte integer... yes checking for 16 byte integer... no checking for __atomic_load/store for size 1... yes checking for __atomic_load/store for size 2... yes checking for __atomic_load/store for size 4... yes checking for __atomic_load/store for size 8... yes checking for __atomic_load/store for size 16... no checking for __atomic_test_and_set for size 1... yes checking for __atomic_test_and_set for size 2... yes checking for __atomic_test_and_set for size 4... yes checking for __atomic_test_and_set for size 8... yes checking for __atomic_test_and_set for size 16... no checking for __atomic_exchange for size 1... yes checking for __atomic_exchange for size 2... yes checking for __atomic_exchange for size 4... yes checking for __atomic_exchange for size 8... no checking for __atomic_exchange for size 16... no checking for __atomic_compare_exchange for size 1... yes checking for __atomic_compare_exchange for size 2... yes checking for __atomic_compare_exchange for size 4... yes checking for __atomic_compare_exchange for size 8... no checking for __atomic_compare_exchange for size 16... no checking for __atomic_fetch_add for size 1... yes checking for __atomic_fetch_add for size 2... yes checking for __atomic_fetch_add for size 4... yes checking for __atomic_fetch_add for size 8... no checking for __atomic_fetch_add for size 16... no checking for __atomic_fetch_op for size 1... yes checking for __atomic_fetch_op for size 2... yes checking for __atomic_fetch_op for size 4... yes checking for __atomic_fetch_op for size 8... no checking for __atomic_fetch_op for size 16... no checking whether byte ordering is bigendian... yes checking for the word size... configure: error: Could not determine word size. make[1]: *** [Makefile:22655: configure-target-libatomic] Error 1 make[1]: Leaving directory '/c/m
[Bug target/87139] 6.4 x86_64 incorrect code generation with -O3 around _addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87139 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-29 Ever confirmed|0 |1 --- Comment #4 from H.J. Lu --- (In reply to cbcode from comment #2) > Created attachment 44621 [details] > test reproducing the problem How to show the problem?
[Bug c++/87137] [8/9 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 --- Comment #8 from Jonathan Wakely --- It compiles successfully with MSVC https://godbolt.org/z/Cw-yiW
[Bug tree-optimization/87132] [9 Regression] Gcc miscompiles at -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87132 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug c++/87137] [8/9 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 --- Comment #7 from Nathan Sidwell --- Created attachment 44624 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44624&action=edit this is the testcase
[Bug c++/87137] [8/9 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 --- Comment #6 from Nathan Sidwell --- Created attachment 44623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44623&action=edit patch This patch appears to fix the problem It'd be good to (a) confirms it also passes on MS's compiler
[Bug rtl-optimization/87138] [8/9 Regression] wrong code with TI multiplication with -O -march=k8 -fno-tree-fre -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87138 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-29 CC||jakub at redhat dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It was caused by r250397.
[Bug libgomp/87140] New: Segmentation fault in priority_list_upgrade_task function when execution tasks with priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87140 Bug ID: 87140 Summary: Segmentation fault in priority_list_upgrade_task function when execution tasks with priority Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: silvestri at diag dot uniroma1.it CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 44622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44622&action=edit Program to test BUG FIX Hello, in GOMP_taskwait function within task.c at line 1352, the following code leads to SIGSEV when executing tasks with priority: struct gomp_task *next_task = priority_queue_next_task (PQ_CHILDREN, &task->children_queue, PQ_TEAM, &team->task_queue, &child_q); This is possible because priority_queue_next_task function may return a non-child task instead of a child task every time both team queue and children queue return GOMP_TASK_WAITING tasks, and the non-child task has greater priority value. Since it's impossible to rearrange a non-child task order in children queue, the segmentation fault occurs in priority_list_upgrade_task funtion. The libgomp implementation uses TIED tasks by default and the aforementioned behaviour leads also to violate TSC2. The proposed fix is the following: struct gomp_task *next_task = priority_queue_next_task (PQ_CHILDREN, &task->children_queue, PQ_IGNORED, NULL, &child_q); In the attachment a program to test libgomp before and after the proposed fix.
[Bug tree-optimization/87132] [9 Regression] Gcc miscompiles at -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87132 --- Comment #3 from Richard Biener --- Author: rguenth Date: Wed Aug 29 14:13:20 2018 New Revision: 263959 URL: https://gcc.gnu.org/viewcvs?rev=263959&root=gcc&view=rev Log: 2018-08-29 Richard Biener PR tree-optimization/87132 * tree-ssa-alias.c (get_continuation_for_phi): Do not translate when skipping defs reachable over backedges. * gcc.dg/torture/pr87132.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr87132.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug c++/87137] [8/9 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137
--- Comment #5 from Nathan Sidwell ---
what should the layout of the following be?
struct Foo {
unsigned one : 24;
static int var;
unsigned two : 4;
};
is this size 8 or 4?
[Bug c++/85110] Missing underlines for some bad arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85110
--- Comment #7 from David Malcolm ---
Author: dmalcolm
Date: Wed Aug 29 13:52:22 2018
New Revision: 263957
URL: https://gcc.gnu.org/viewcvs?rev=263957&root=gcc&view=rev
Log:
C++: underline param in print_conversion_rejection (more PR c++/85110)
Consider this bogus code (from g++.dg/diagnostic/param-type-mismatch-2.C):
struct s4 { static int member_1 (int one, const char **two, float three); };
int test_4 (int first, const char *second, float third)
{
return s4::member_1 (first, second, third);
}
Before this patch, g++ emits:
demo.cc: In function 'int test_4(int, const char*, float)':
demo.cc:5:44: error: no matching function for call to 's4::member_1(int&, const
char*&, float&)'
5 | return s4::member_1 (first, second, third);
|^
demo.cc:1:24: note: candidate: 'static int s4::member_1(int, const char**,
float)'
1 | struct s4 { static int member_1 (int one, const char **two, float three);
};
|^~~~
demo.cc:1:24: note: no known conversion for argument 2 from 'const char*' to
'const char**'
With this patch, it highlights the pertinent parameter in the
"no known conversion" note:
demo.cc: In function 'int test_4(int, const char*, float)':
demo.cc:5:44: error: no matching function for call to 's4::member_1(int&, const
char*&, float&)'
5 | return s4::member_1 (first, second, third);
|^
demo.cc:1:24: note: candidate: 'static int s4::member_1(int, const char**,
float)'
1 | struct s4 { static int member_1 (int one, const char **two, float three);
};
|^~~~
demo.cc:1:56: note: no known conversion for argument 2 from 'const char*' to
'const char**'
1 | struct s4 { static int member_1 (int one, const char **two, float three);
};
| ~^~~
gcc/cp/ChangeLog:
PR c++/85110
* call.c (print_conversion_rejection): Add "fn" param and use it
for "no known conversion" messages to underline the pertinent
param.
(print_z_candidate): Supply "fn" to the new param above.
gcc/testsuite/ChangeLog:
PR c++/85110
* g++.dg/diagnostic/param-type-mismatch-2.C: Update expected
output to reflect underlining of pertinent parameter in decl
for "no known conversion" messages.
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/diagnostic/param-type-mismatch-2.C
[Bug target/87133] ICE in aggregate_value_p with -frounding-math on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87133 --- Comment #6 from Martin Liška --- Backtrace from GDB with function arguments visible: #0 0x015140fd in aggregate_value_p (exp=0x0, fntype=0x0) at /home/marxin/Programming/gcc/gcc/function.c:2046 #1 0x00f3d2e0 in emit_library_call_value_1 (retval=1, orgfun=0x75834210, value=0x0, fn_type=LCT_CONST, outmode=E_KFmode, nargs=1, args=0x7fffc0d0) at /home/marxin/Programming/gcc/gcc/calls.c:4745 #2 0x0136c557 in emit_library_call_value (fun=0x75834210, value=0x0, fn_type=LCT_CONST, outmode=E_KFmode, arg1=0x75912ea0, arg1_mode=E_SFmode) at /home/marxin/Programming/gcc/gcc/rtl.h:4185 #3 0x013b3a7a in convert_mode_scalar (to=0x75917558, from=0x75912ea0, unsignedp=0) at /home/marxin/Programming/gcc/gcc/expr.c:329 #4 0x013b2da4 in convert_move (to=0x75917558, from=0x75912ea0, unsignedp=0) at /home/marxin/Programming/gcc/gcc/expr.c:271 #5 0x013ba345 in convert_modes (mode=E_KFmode, oldmode=E_SFmode, x=0x75912ea0, unsignedp=0) at /home/marxin/Programming/gcc/gcc/expr.c:712 #6 0x013b86db in convert_to_mode (mode=E_KFmode, x=0x75912ea0, unsignedp=0) at /home/marxin/Programming/gcc/gcc/expr.c:637 #7 0x01c27738 in expand_fix (to=0x75912f30, from=0x75912ea0, unsignedp=1) at /home/marxin/Programming/gcc/gcc/optabs.c:4930 #8 0x01405268 in expand_expr_real_2 (ops=0x7fffd1e0, target=0x75912f30, tmode=E_DImode, modifier=EXPAND_NORMAL) at /home/marxin/Programming/gcc/gcc/expr.c:8961 #9 0x00f8e553 in expand_gimple_stmt_1 (stmt=) at /home/marxin/Programming/gcc/gcc/cfgexpand.c:3673 #10 0x00f8ea9a in expand_gimple_stmt (stmt=) at /home/marxin/Programming/gcc/gcc/cfgexpand.c:3734 #11 0x00fa3f59 in expand_gimple_basic_block (bb=, disable_tail_calls=false) at /home/marxin/Programming/gcc/gcc/cfgexpand.c:5770 #12 0x00fa88db in (anonymous namespace)::pass_expand::execute (this=0x6e6f770, fun=0x75903000) at /home/marxin/Programming/gcc/gcc/cfgexpand.c:6373 #13 0x01d1578d in execute_one_pass (pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2446 #14 0x01d1611e in execute_pass_list_1 (pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2535 #15 0x01d16272 in execute_pass_list (fn=0x75903000, pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2546 #16 0x010a13e3 in cgraph_node::expand (this=) at /home/marxin/Programming/gcc/gcc/cgraphunit.c:2121 #17 0x010a3a16 in output_in_order () at /home/marxin/Programming/gcc/gcc/cgraphunit.c:2365 #18 0x010a5434 in symbol_table::compile (this=0x7580d000) at /home/marxin/Programming/gcc/gcc/cgraphunit.c:2609 #19 0x010a5ea7 in symbol_table::finalize_compilation_unit (this=0x7580d000) at /home/marxin/Programming/gcc/gcc/cgraphunit.c:2788 #20 0x020dd5b6 in compile_file () at /home/marxin/Programming/gcc/gcc/toplev.c:480 #21 0x020e4821 in do_compile () at /home/marxin/Programming/gcc/gcc/toplev.c:2170 #22 0x020e4e50 in toplev::main (this=0x7fffd98e, argc=12, argv=0x7fffda88) at /home/marxin/Programming/gcc/gcc/toplev.c:2305 #23 0x03aec681 in main (argc=12, argv=0x7fffda88) at /home/marxin/Programming/gcc/gcc/main.c:39
[Bug target/87133] ICE in aggregate_value_p with -frounding-math on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87133
--- Comment #5 from Martin Liška ---
In calls.c I see:
│4742 if (outmode != VOIDmode)
│4743{
│4744 tfom = lang_hooks.types.type_for_mode (outmode, 0);
>│4745 if (aggregate_value_p (tfom, 0))
(gdb) p tfom
$2 =
(gdb) p outmode
$3 = E_KFmode
Would it help?
[Bug target/87133] ICE in aggregate_value_p with -frounding-math on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87133 --- Comment #4 from Martin Liška --- ubsan build helps: $ UBSAN_OPTIONS=print_stacktrace=1 ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/real_do_1.f90 -frounding-math /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/real_do_1.f90:13:5: 13 | do x = 1.0, 2.05, 0.1 | 1 Warning: Deleted feature: Loop variable at (1) must be integer /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/real_do_1.f90:13:8: 13 | do x = 1.0, 2.05, 0.1 |1 Warning: Deleted feature: Start expression in DO loop at (1) must be integer /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/real_do_1.f90:13:13: 13 | do x = 1.0, 2.05, 0.1 | 1 Warning: Deleted feature: End expression in DO loop at (1) must be integer /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/real_do_1.f90:13:19: 13 | do x = 1.0, 2.05, 0.1 | 1 Warning: Deleted feature: Step expression in DO loop at (1) must be integer /home/marxin/Programming/gcc/gcc/function.c:2046:22: runtime error: member access within null pointer of type 'const union tree_node' #0 0x15140fc in aggregate_value_p(tree_node const*, tree_node const*) /home/marxin/Programming/gcc/gcc/function.c:2046 #1 0xf3d2df in emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type, machine_mode, int, std::pair*) /home/marxin/Programming/gcc/gcc/calls.c:4745 #2 0x136c556 in emit_library_call_value(rtx_def*, rtx_def*, libcall_type, machine_mode, rtx_def*, machine_mode) /home/marxin/Programming/gcc/gcc/rtl.h:4185 #3 0x13b3a79 in convert_mode_scalar /home/marxin/Programming/gcc/gcc/expr.c:329 #4 0x13b2da3 in convert_move(rtx_def*, rtx_def*, int) /home/marxin/Programming/gcc/gcc/expr.c:271 #5 0x13ba344 in convert_modes(machine_mode, machine_mode, rtx_def*, int) /home/marxin/Programming/gcc/gcc/expr.c:712 #6 0x13b86da in convert_to_mode(machine_mode, rtx_def*, int) /home/marxin/Programming/gcc/gcc/expr.c:637 #7 0x1c27737 in expand_fix(rtx_def*, rtx_def*, int) /home/marxin/Programming/gcc/gcc/optabs.c:4930 #8 0x1405267 in expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /home/marxin/Programming/gcc/gcc/expr.c:8961 #9 0xf8e552 in expand_gimple_stmt_1 /home/marxin/Programming/gcc/gcc/cfgexpand.c:3673 #10 0xf8ea99 in expand_gimple_stmt /home/marxin/Programming/gcc/gcc/cfgexpand.c:3734 #11 0xfa3f58 in expand_gimple_basic_block /home/marxin/Programming/gcc/gcc/cfgexpand.c:5770 #12 0xfa88da in execute /home/marxin/Programming/gcc/gcc/cfgexpand.c:6373 #13 0x1d1578c in execute_one_pass(opt_pass*) /home/marxin/Programming/gcc/gcc/passes.c:2446 #14 0x1d1611d in execute_pass_list_1 /home/marxin/Programming/gcc/gcc/passes.c:2535 #15 0x1d16271 in execute_pass_list(function*, opt_pass*) /home/marxin/Programming/gcc/gcc/passes.c:2546 #16 0x10a13e2 in cgraph_node::expand() /home/marxin/Programming/gcc/gcc/cgraphunit.c:2121 #17 0x10a3a15 in output_in_order /home/marxin/Programming/gcc/gcc/cgraphunit.c:2365 #18 0x10a5433 in symbol_table::compile() /home/marxin/Programming/gcc/gcc/cgraphunit.c:2609 #19 0x10a5ea6 in symbol_table::finalize_compilation_unit() /home/marxin/Programming/gcc/gcc/cgraphunit.c:2788 #20 0x20dd5b5 in compile_file /home/marxin/Programming/gcc/gcc/toplev.c:480 #21 0x20e4820 in do_compile /home/marxin/Programming/gcc/gcc/toplev.c:2170 #22 0x20e4e4f in toplev::main(int, char**) /home/marxin/Programming/gcc/gcc/toplev.c:2305 #23 0x3aec680 in main /home/marxin/Programming/gcc/gcc/main.c:39 #24 0x75ea1fea in __libc_start_main ../csu/libc-start.c:308 #25 0x812bc9 in _start (/dev/shm/objdir2/gcc/f951+0x812bc9) during RTL pass: expand /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/real_do_1.f90:13:0: 13 | do x = 1.0, 2.05, 0.1 | internal compiler error: Segmentation fault 0x20dc92f crash_signal /home/marxin/Programming/gcc/gcc/toplev.c:325 0x75eb710f ??? /usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x15140fd aggregate_value_p(tree_node const*, tree_node const*) /home/marxin/Programming/gcc/gcc/function.c:2046 0xf3d2df emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type, machine_mode, int, std::pair*) /home/marxin/Programming/gcc/gcc/calls.c:4745 0x136c556 emit_library_call_value(rtx_def*, rtx_def*, libcall_type, machine_mode, rtx_def*, machine_mode) /home/marxin/Programming/gcc/gcc/rtl.h:4185 0x13b3a79 convert_mode_scalar /home/marxin/Programming/gcc/gcc/expr.c:329 0x13b2da3 convert_move(rtx_def*, rtx_def*, int) /home/marxin/Programming/gcc/gcc/expr.c:271 0x13ba344 convert_modes(machine_mode, machine_mode, rtx_def*, int) /home/marxin/Programming/gcc/gcc/expr.c:712 0x13b86da convert_to_mode(machine_mode, rtx_def*, int) /home/marxin/Programming/gcc/gcc/expr.c:637 0x1c27737 expand_fix(rtx_
[Bug target/87133] ICE in aggregate_value_p with -frounding-math on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87133 --- Comment #3 from Segher Boessenkool --- ... Nope, works fine with trunk as well. You must be doing something you're not telling us?
[Bug target/87139] 6.4 x86_64 incorrect code generation with -O3 around _addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87139 --- Comment #3 from cbcode at gmail dot com --- -fno-strict-aliasing makes no difference.
[Bug target/87139] 6.4 x86_64 incorrect code generation with -O3 around _addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87139 cbcode at gmail dot com changed: What|Removed |Added CC||cbcode at gmail dot com --- Comment #2 from cbcode at gmail dot com --- Created attachment 44621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44621&action=edit test reproducing the problem
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 --- Comment #9 from Sandro Mani --- Thanks --- Comment #10 from Sandro Mani --- Thanks
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 --- Comment #9 from Sandro Mani --- Thanks --- Comment #10 from Sandro Mani --- Thanks
[Bug other/86726] Undocumented option -f{,no}-tree-scev-cprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86726 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amonakov at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Alexander Monakov --- Fixed, thanks.
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 H.J. Lu changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-29 Ever confirmed|0 |1 --- Comment #8 from H.J. Lu --- A patch was posted at https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00559.html
[Bug c++/87137] [8/9 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug other/86726] Undocumented option -f{,no}-tree-scev-cprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86726 --- Comment #1 from Alexander Monakov --- Author: amonakov Date: Wed Aug 29 12:39:12 2018 New Revision: 263955 URL: https://gcc.gnu.org/viewcvs?rev=263955&root=gcc&view=rev Log: doc: document -ftree-scev-cprop PR other/86726 * invoke.texi (Optimization Options): List -ftree-scev-cprop. (-O): Ditto. (-ftree-scev-cprop): Document. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug c++/57170] Diagnostic for a negative case when switching over unsigned comes from -Wsign-conversion instead of -Wpedantic or -Wnarrowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57170 --- Comment #6 from Jonathan Wakely --- It should be an error, not a warning. For other narrowing conversions involving constants we do actually use -Wnarrowing (but still defaulting to an error) so I guess my last comment was wrong. Or it could just be an unconditional error. Or a permerror, so -fpermissive would allow it. The code that handles this is in gcc/c-family/c-common.c so isn't C++-specific. I'm not sure if that code has enough context to know if the conversion happens in a constant expression where narrowing conversions are disallowed. #0 unsafe_conversion_p (loc=, loc@entry=267203, type=type@entry=0x7013c690, expr=expr@entry=0x701401f8, result=result@entry=0x70140048, produce_warns=produce_warns@entry=true) at /home/jwakely/src/gcc/gcc/gcc/c-family/c-common.c:1261 #1 0x008cdb27 in conversion_warning (loc=267203, type=type@entry=0x7013c690, expr=expr@entry=0x701401f8, result=result@entry=0x70140048) at /home/jwakely/src/gcc/gcc/gcc/c-family/c-warn.c:1127 #2 0x008d11d1 in warnings_for_convert_and_check (loc=, loc@entry=267203, type=type@entry=0x7013c690, expr=expr@entry=0x701401f8, result=result@entry=0x70140048) at /home/jwakely/src/gcc/gcc/gcc/c-family/c-warn.c:1278 #3 0x0085df41 in convert_and_check (loc=loc@entry=267203, type=type@entry=0x7013c690, expr=0x701401f8) at /home/jwakely/src/gcc/gcc/gcc/c-family/c-common.c:1548 #4 0x00886a55 in c_add_case_label (loc=loc@entry=267203, cases=0x24ad5e0, cond=cond@entry=0x77ff6cf0, orig_type=orig_type@entry=0x7013c690, low_value=, low_value@entry=0x701401f8, high_value=, high_value@entry=0x0, outside_range_p=0x24abff0) at /home/jwakely/src/gcc/gcc/gcc/c-family/c-common.c:4780 #5 0x0066b1fa in finish_case_label (loc=267203, low_value=, low_value@entry=0x701401f8, high_value=) at /home/jwakely/src/gcc/gcc/gcc/cp/decl.c:3669 #6 0x007309e9 in cp_parser_label_for_labeled_statement (parser=parser@entry=0x77ff6ab0, attributes=attributes@entry=0x0) at /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11072
[Bug c++/87122] [8/9 Regression] ICE in tsubst_decomp_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87122 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Aug 29 12:32:13 2018 New Revision: 263954 URL: https://gcc.gnu.org/viewcvs?rev=263954&root=gcc&view=rev Log: PR c++/87122 * pt.c (tsubst_expr) : If processing_template_decl and decl is structured binding decl, call cp_finish_decomp. * g++.dg/cpp1z/decomp47.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/decomp47.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/pt.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/87122] [8/9 Regression] ICE in tsubst_decomp_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87122 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Aug 29 12:27:55 2018 New Revision: 263953 URL: https://gcc.gnu.org/viewcvs?rev=263953&root=gcc&view=rev Log: PR c++/87122 * pt.c (tsubst_expr) : If processing_template_decl and decl is structured binding decl, call cp_finish_decomp. * g++.dg/cpp1z/decomp47.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/decomp47.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/87117] [9 Regression] ICE in eliminate_dom_walker::eliminate_cleanup(bool) at gcc/gcc/tree-ssa-sccvn.c:5431 since r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87117 --- Comment #15 from rguenther at suse dot de --- On Wed, 29 Aug 2018, dcb314 at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87117 > > --- Comment #14 from David Binderman --- > (In reply to Richard Biener from comment #10) > > Didn't check ubsan bootstrap. > > I did. It seems to work at the -O2 level. > > -O3 level hasn't worked for months, but that's an old problem. > ints and longs not wide enough types. > > Using a non-gcc compiler, for example clang, at the start > seems to break the ubsan bootstrap. > > Would it be worth me sending in another bug report or just posting > it here ? Please in another bug, not here.
[Bug tree-optimization/87117] [9 Regression] ICE in eliminate_dom_walker::eliminate_cleanup(bool) at gcc/gcc/tree-ssa-sccvn.c:5431 since r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87117 --- Comment #14 from David Binderman --- (In reply to Richard Biener from comment #10) > Didn't check ubsan bootstrap. I did. It seems to work at the -O2 level. -O3 level hasn't worked for months, but that's an old problem. ints and longs not wide enough types. Using a non-gcc compiler, for example clang, at the start seems to break the ubsan bootstrap. Would it be worth me sending in another bug report or just posting it here ?
[Bug c++/87137] [8/9 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 Richard Biener changed: What|Removed |Added Keywords||ABI, wrong-code Target Milestone|--- |8.3
[Bug c++/45113] absent or confusing diagnostics of invalid template argument list in implicit template class instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45113 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2017-08-17 00:00:00 |2018-8-29 --- Comment #3 from Jonathan Wakely --- The first example was fixed for GCC 4.8.0 The second started saying "template argument 1 is invalid" in GCC 4.8.0 and stopped also saying "invalid type in declaration" for GCC 5.1.0 The caret locations for "template argument 1" are poor though, they point to the end of the template argument list. For the second and third ones Clang gives a nicer diagnostic: 45113.cc:2:15: error: type-id cannot have a name typedef U A; ^ 45113.cc:2:21: error: type-id cannot have a name typedef U A; ^ 2 errors generated. That's accurate and helpful. We could even add a fix-it to remove those names.
[Bug middle-end/86995] [9 regression] c-c++-common/torture/builtin-arith-overflow-17.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86995 --- Comment #5 from Jakub Jelinek --- Like: --- gcc/expmed.c.jj 2018-08-26 22:42:22.526779583 +0200 +++ gcc/expmed.c2018-08-29 14:04:32.669509929 +0200 @@ -6239,7 +6239,9 @@ canonicalize_comparison (machine_mode mo wrapping around in the case of unsigned values. If any occur cancel the optimization. */ wi::overflow_type overflow = wi::OVF_NONE; - wide_int imm_modif = wi::add (imm_val, to_add, sgn, &overflow); + wide_int imm_modif += (to_add > 0 ? wi::add (imm_val, 1, sgn, &overflow) + : wi::sub (imm_val, 1, sgn, &overflow)); if (overflow) return; If so, please submit it as soon as possible, leaving such important wrong-code bug for so long is highly undesirable.
[Bug rtl-optimization/87138] [8/9 Regression] wrong code with TI multiplication with -O -march=k8 -fno-tree-fre -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87138 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.3
[Bug target/87139] 6.4 x86_64 incorrect code generation with -O3 around _addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87139 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Component|c |target --- Comment #1 from Richard Biener --- Can you attach the testcases? cut&pasting has whitespace issues. It may be an aliasing issue so try -fno-strict-aliasing.
[Bug c++/87137] [8/9 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-29 Known to work||7.3.0 Summary|[8 Regression] Non-virtual |[8/9 Regression] |member function increases |Non-virtual member function |struct size |increases struct size Ever confirmed|0 |1 Known to fail||9.0 --- Comment #4 from Jonathan Wakely --- That's r250413 Confirmed
[Bug middle-end/86995] [9 regression] c-c++-common/torture/builtin-arith-overflow-17.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86995 --- Comment #4 from Vlad Lazar --- That's right. It's not the right fix. The actual cause is the use of wi::add in r263591, which does not set the flag in case of underflow. The correct way is to use wi::add for addition and wi::sub for substraction. I'm testing a patch which does that.
[Bug c/87139] New: 6.4 x86_64 incorrect code generation with -O3 around _addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87139
Bug ID: 87139
Summary: 6.4 x86_64 incorrect code generation with -O3 around
_addcarry_u64
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cbcode at gmail dot com
Target Milestone: ---
x86_64 gcc-6 (tested with 6.4.0 and 6.3.0 under linux and 6.4.0 under
windows/mingw) generates incorrect code when optimizing with -O3 in certain
situations around _addcarry_u64. gcc-6 with -O2 is fine. gcc-5, gcc-7 and gcc-8
with -O3 are all fine. It is difficult to pinpoint the exact problem but the
following should narrow it down enough to be helpful.
#include
#include
#include
#include
#include
using std::size_t;
using std::uint64_t;
static_assert(sizeof(size_t) == sizeof(uint64_t), "");
//big-integer multiplication, limb-size is size_t is uint64_t
template
std::array big_mul(std::array const& aa,
std::array const& bb) noexcept {
static constexpr size_t const Nc = Na + Nb;
std::array cc = {{0,}};
for (size_t na = 0; na != Na; ++na) {
for (size_t nb = 0; nb != Nb; ++nb) {
alignas(__uint128_t) size_t lohi[2];
reinterpret_cast<__uint128_t&>(lohi) = __uint128_t(aa[na]) *
__uint128_t(bb[nb]); //Note: placement-new instead of reinterpret_cast makes no
difference
size_t n = na + nb;
unsigned char c = __builtin_add_overflow(cc[n], lohi[0], &cc[n]);
#if 1 //Note: x86_64-gcc-6 -O3 generates bad code; gcc-6 -O2 is fine; gcc-5 and
gcc-7 and above are fine
c = _addcarry_u64(c, cc[n + 1], lohi[1], &reinterpret_cast(cc[n + 1]));
for (n += 2; n <= Nc - 1; ++n) c = __builtin_add_overflow(cc[n], c,
&cc[n]);
#elif 1 //Note: added 'c &&' in for-loop condition: problem goes away
c = _addcarry_u64(c, cc[n + 1], lohi[1], &reinterpret_cast(cc[n + 1]));
for (n += 2; c && n <= Nc - 1; ++n) c =
__builtin_add_overflow(cc[n], c, &cc[n]);
#else //Note: inserted '++n' between add_overflow and add_carry: problem goes
away
++n;
c = _addcarry_u64(c, cc[n], lohi[1], &reinterpret_cast(cc[n]));
for (++n; c && n <= Nc - 1; ++n) c = __builtin_add_overflow(cc[n],
c, &cc[n]);
#endif
}
}
return cc;
}
//simple random-number-generator,
https://github.com/svaarala/duktape/blob/master/misc/splitmix64.c
static uint64_t rnd_state = 1;
static inline uint64_t rnd() {
uint64_t z = rnd_state += 0x9e3779b97f4a7c15;
z = (z ^ (z >> 30)) * 0xbf58476d1ce4e5b9;
z = (z ^ (z >> 27)) * 0x94d049bb133111eb;
return z ^ (z >> 31);
}
//main() writes python3-script; pipe into python3; no output means no error
//g++-6 -std=c++11 -O3 -o test test.cpp && ./test 100 | python3 #bad
//g++-6 -std=c++11 -O2 -o test test.cpp && ./test 100 | python3 #Ok
//g++-5 -std=c++11 -O3 -o test test.cpp && ./test 100 | python3 #Ok
//g++-7 -std=c++11 -O3 -o test test.cpp && ./test 100 | python3 #Ok
//g++-8 -std=c++11 -O3 -o test test.cpp && ./test 100 | python3 #Ok
int main(int argc, char const** argv) { assert(argc == 2);
size_t const M = size_t(std::strtoull(argv[1], nullptr, 0));
static constexpr size_t const Na = 2, Nb = 2; //Note: any combination of
Na>=2, Nb>=2 causes the problem
std::array aa;
std::array bb;
std::array cc;
for (size_t m = 0; m != M; ++m) {
for (size_t& a: aa) a = rnd();
for (size_t& b: bb) b = rnd();
cc = big_mul(aa, bb);
std::printf( "a=0x");for (size_t n = Na;n--;)
std::printf("%016zx", aa[n]);
std::printf("; b=0x");for (size_t n = Nb;n--;)
std::printf("%016zx", bb[n]);
std::printf("; c=0x");for (size_t n = Na+Nb; n--;)
std::printf("%016zx", cc[n]);
std::printf("\nif a*b!=c: print(hex(a),'*',
hex(b),'\\n=',hex(a*b),'\\n?',hex(c))\n");
}
return 0;
}
[Bug c++/87137] [8 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 --- Comment #3 from Sandro Mani --- See https://github.com/gcc-mirror/gcc/commit/ab87ee8f509c0b600102195704105d4d98ec59d9
[Bug c++/87137] [8 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #2 from Nathan Sidwell --- What changelog does that has refer to? (I don;t use the git repo)
[Bug middle-end/86995] [9 regression] c-c++-common/torture/builtin-arith-overflow-17.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86995 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- How could a cost adjustment be a right fix to a wrong-code bug? That seems just to make it latent.
[Bug middle-end/86540] [9 Regression] pr77445-2.c and ssa-dom-thread-7.c regressions since May 20, 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86540 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |law at gcc dot gnu.org --- Comment #2 from Martin Liška --- Ok, so after I installed quite some switch related patches these still remain: 1) pr77445-2.c: grep 'not considered' pr77* pr77445-2.c.175t.thread3:FSM jump-thread path not considered: the number of basic blocks on the path exceeds PARAM_MAX_FSM_THREAD_LENGTH. pr77445-2.c.175t.thread3:FSM jump-thread path not considered: the number of basic blocks on the path exceeds PARAM_MAX_FSM_THREAD_LENGTH. pr77445-2.c.175t.thread3:FSM jump-thread path not considered: the number of basic blocks on the path exceeds PARAM_MAX_FSM_THREAD_LENGTH. pr77445-2.c.178t.thread4:FSM jump-thread path not considered: the number of basic blocks on the path exceeds PARAM_MAX_FSM_THREAD_LENGTH. pr77445-2.c.178t.thread4:FSM jump-thread path not considered: the number of basic blocks on the path exceeds PARAM_MAX_FSM_THREAD_LENGTH. pr77445-2.c.178t.thread4:FSM jump-thread path not considered: the number of basic blocks on the path exceeds PARAM_MAX_FSM_THREAD_LENGTH. 2) ssa-dom-thread-7.c FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump-not vrp2 "Jumps threaded" Jeff can you please investigate that and eventually adjust test-case if possible?
[Bug rtl-optimization/87138] New: [8/9 Regression] wrong code with TI multiplication with -O -march=k8 -fno-tree-fre -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87138 Bug ID: 87138 Summary: [8/9 Regression] wrong code with TI multiplication with -O -march=k8 -fno-tree-fre -mavx512bw Product: gcc Version: 9.0 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 44620 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44620&action=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O -march=k8 -fno-tree-fre -mavx512bw testcase.c $ sde64 -- ./a.out Aborted The difference between broken a good assembler is: movabs rax, 9223372036854775805# tmp167, - mov rdx, -2 #, + mov rdx, 1 #, mov QWORD PTR [rsp], rax# %sfpD.2961, tmp167 mov QWORD PTR [rsp+8], rdx # %sfpD.2961, For some reason, 3 * 0x7FFF is computed as 0xfffe7ffd instead of 0x17ffd. The wrong value first appears in the .cse1 dump. $ 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-263946-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/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 --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-263946-checking-yes-rtl-df-extra-amd64 Thread model: posix gcc version 9.0.0 20180829 (experimental) (GCC)
[Bug bootstrap/87130] [9 Regression] LTO bootstrap failed with profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87130 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug debug/86593] [8/9 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 --- Comment #7 from Sandro Mani --- Any chance of getting the fix committed?
[Bug c++/87137] [8 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 Sandro Mani changed: What|Removed |Added Target||i686-w64-mingw32, ||x86_64-w64-mingw32 CC||nathan at acm dot org --- Comment #1 from Sandro Mani --- CC nat...@acm.org as author of ab87ee8f509c0b600102195704105d4d98ec59d9
[Bug c++/87137] New: [8 Regression] Non-virtual member function increases struct size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137
Bug ID: 87137
Summary: [8 Regression] Non-virtual member function increases
struct size
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manisandro at gmail dot com
Target Milestone: ---
With gcc-8.0.0 onwards, specifically commit
ab87ee8f509c0b600102195704105d4d98ec59d9, the following test case fails to
compile using either i686-w64-mingw32-g++ or x86_64-w64-mingw32-g++ (but
compiles normally using the native x86_64-linux-g++):
--- test.cpp ---
template
void check_size() {
static_assert(ExpectedSize == RealSize, "Size is off!");
}
struct Foo {
unsigned u1 : 5;
unsigned u2 : 5;
unsigned u3 : 3;
unsigned u4 : 3;
unsigned u5 : 4;
unsigned u6 : 2;
unsigned u7 : 3;
unsigned u8 : 2;
unsigned u9 : 1;
unsigned u10 : 3;
// 31 bits
unsigned u11 : 2;
unsigned u12 : 2;
unsigned u13 : 2;
unsigned u14 : 6;
unsigned u15 : 7;
unsigned u16 : 1;
unsigned u17 : 1;
unsigned u18 : 1;
unsigned u19 : 1;
unsigned u20 : 1;
bool bar() const { return false; }
private:
unsigned u21 : 1;
unsigned u22 : 1;
unsigned u23 : 1;
unsigned u24 : 1;
// 59 bits
};
int main(int argc, char* argv[]) {
check_size();
return 0;
}
-
$ x86_64-w64-mingw32-g++ test.cpp -o test.exe
test.cpp: In instantiation of 'void check_size() [with ToCheck = Foo; unsigned
int ExpectedSize = 8; unsigned int RealSize = 12]':
test.cpp:41:24: required from here
test.cpp:3:30: error: static assertion failed: Size is off!
static_assert(ExpectedSize == RealSize, "Size is off!");
Notice the presence of the bar member function. Without the member function,
sizeof(Foo) = 8 as expected, but with the member function, sizeof(Foo) = 12.
[Bug bootstrap/87130] [9 Regression] LTO bootstrap failed with profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87130 --- Comment #3 from Martin Liška --- Author: marxin Date: Wed Aug 29 10:48:50 2018 New Revision: 263950 URL: https://gcc.gnu.org/viewcvs?rev=263950&root=gcc&view=rev Log: Fix thinko in lto.c (PR bootstrap/87130). 2018-08-29 Martin Liska PR bootstrap/87130 * lto.c (read_cgraph_and_symbols): Fix thinko, revert to behavior before r263887. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c
[Bug target/87133] ICE in aggregate_value_p with -frounding-math on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87133 --- Comment #2 from Segher Boessenkool --- Actually, doesn't fail on powerpc64le-linux either. Well let me try some brand spanking new tree...
[Bug c++/87136] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87136 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-29 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Please create pre-processed source file (with -E option) and attach it.
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413 Jonathan Wakely changed: What|Removed |Added Resolution|INVALID |FIXED Target Milestone|--- |9.0 --- Comment #29 from Jonathan Wakely --- I've modified the test to also work with Debian's D_FMT string.
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413 --- Comment #28 from Jonathan Wakely --- Author: redi Date: Wed Aug 29 10:05:55 2018 New Revision: 263948 URL: https://gcc.gnu.org/viewcvs?rev=263948&root=gcc&view=rev Log: PR libstdc++/31413 fix test failure on Debian systems Debian uses a different D_FMT string for the zh_TW.UTF-8 locale, which caused this test to fail. Try to detect the Debian format and adjust the input being tested. PR libstdc++/31413 * testsuite/22_locale/time_get/get_date/wchar_t/4.cc: Check D_FMT string for alternative format. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/22_locale/time_get/get_date/wchar_t/4.cc
[Bug target/87133] ICE in aggregate_value_p with -frounding-math on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87133 --- Comment #1 from Segher Boessenkool --- Does not fail on powerpc64-linux, even with -mlittle -mabi=elfv2 .
[Bug c++/87136] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87136 --- Comment #1 from Darko Veberic --- Created attachment 44619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44619&action=edit the actual cc source file
[Bug c++/87136] New: internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87136 Bug ID: 87136 Summary: internal compiler error: in emit_move_insn, at expr.c:3722 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: darko.veberic at ijs dot si Target Milestone: --- Created attachment 44618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44618&action=edit command-line options to g++ (as invoked from a cmake makefile) most probably our code is sub par, but the compiler should issue an error instead of giving up. i am attaching all the relevant files: the command-line of the g++ invocation, the cc file itself, and the compiler-produced intermediates. the same bug is present also in the 7.* versions, i switched my ubuntu alternatives to gcc/g++ 8 for this reason, but it didn't help.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #2 from Richard Biener --- You also might want to test the patch from PR87132.
[Bug tree-optimization/87132] [9 Regression] Gcc miscompiles at -O2 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87132
--- Comment #2 from Richard Biener ---
Simplified:
extern void abort (void);
int c, d;
int main()
{
int e[] = {4, 4, 4, 4, 4, 4, 4, 4, 4};
d = 8;
for (; d; d--)
for (int a = 0; a <= 8; a++)
{
c = e[1];
e[d] = 0;
}
if (c != 0)
abort ();
return 0;
}
this one is going to be interesting to fix. The issue is that we either
stop iterating too early or we over-eagerly use values from the previous
iteration when walk_non_aliased_vuses skips over e[d] = 0 when looking
for aliasing defs to e[1]. d still has the previous iteration value of 8
because we didn't yet re-visit the load of it when walking defs across
the backedge.
So this is
static void *
vn_reference_lookup_3 (ao_ref *ref, tree vuse, void *vr_,
bool *disambiguate_only)
{
...
/* First try to disambiguate after value-replacing in the definitions LHS.
*/
if (is_gimple_assign (def_stmt))
{
...
lhs_ops = valueize_refs_1 (lhs_ops, &valueized_anything, true);
as well as the load from e[1] in the first iteration not needing to
visit e[d] because of the not yet executable backedge and thus the
virtual PHI degenerating to the entry value.
A fix could be somehow tracking memory state changes and iterating once more
or avoiding last-iteration values in valueization (or valueization completely
when performing the walk over backedges). The latter latter is easiest,
testing that for fallout.
Index: gcc/tree-ssa-alias.c
===
--- gcc/tree-ssa-alias.c(revision 263944)
+++ gcc/tree-ssa-alias.c(working copy)
@@ -2722,7 +2722,14 @@ next:;
if (arg1 == arg0)
;
else if (! maybe_skip_until (phi, arg0, ref, arg1, cnt, visited,
- abort_on_visited, translate, data))
+ abort_on_visited,
+ /* Do not translate when walking over
+ backedges. */
+ dominated_by_p
+(CDI_DOMINATORS,
+ gimple_bb (SSA_NAME_DEF_STMT (arg1)),
+ phi_bb)
+ ? NULL : translate, data))
return NULL_TREE;
}
