[Bug c++/87571] [8/9 Regression] ICE in friend_accessible_p, accessing protected member of template friend inside template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87571 Alexandre Oliva changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-28 CC||aoliva at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Alexandre Oliva --- The reason private works where protected doesn't is that private access checking uses is_friend, whereas protected access checking uses friend_accessible_p. The latter is supposed to grant access whenever is_friend would (that's the assert that fails), but while is_friend checks various possibilities of template specialization with is_specialization_of_friend, friend_accessible_p seems to only handle one layer of template friends. I'm afraid I don't quite see how to extend e.g. protected_accessible_p, used by friend_accessible_p, to deal with additional template layers.
[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843 --- Comment #13 from Christian Hoff --- Hello Jonathan, that is great news! Thank you very much for fixing this issue, I really appreciate this. Best regards, Christian
[Bug libstdc++/88199] [7/8 Regression] memory leak on unordered container move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88199 --- Comment #4 from François Dumont --- Author: fdumont Date: Wed Nov 28 06:27:28 2018 New Revision: 266543 URL: https://gcc.gnu.org/viewcvs?rev=266543=gcc=rev Log: 2018-11-28 François Dumont PR libstdc++/88199 * include/bits/hashtable.h (_Hashtable<>::_M_move_assign(_Hashtable&&, false_type)): Deallocate former buckets after assignment. * testsuite/23_containers/unordered_set/allocator/move_assign.cc (test03): New. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/hashtable.h branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_set/allocator/move_assign.cc
[Bug libstdc++/88199] [7/8 Regression] memory leak on unordered container move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88199 --- Comment #3 from François Dumont --- Author: fdumont Date: Wed Nov 28 06:19:38 2018 New Revision: 266542 URL: https://gcc.gnu.org/viewcvs?rev=266542=gcc=rev Log: 2018-11-28 François Dumont PR libstdc++/88199 * include/bits/hashtable.h (_Hashtable<>::_M_move_assign(_Hashtable&&, false_type)): Deallocate former buckets after assignment. * testsuite/23_containers/unordered_set/allocator/move_assign.cc (test03): New. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/hashtable.h branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/unordered_set/allocator/move_assign.cc
[Bug sanitizer/88234] New: UBsan and runtime error: signed integer overflow using unsigned vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234
Bug ID: 88234
Summary: UBsan and runtime error: signed integer overflow using
unsigned vector
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
I'm working on GCC135 from the compile farm. I'm experiencing a UBsan runtime
error for signed overflow when using unsigned vectors. The algorithms in the
real program depend on unsigned wrap; and not signed overflow.
gcc135:~$ cat test.cxx
#include
#include
#undef vector
#undef pixel
#undef bool
typedef unsigned char byte;
typedef __vector unsigned char uint8x16_p;
typedef __vector unsigned int uint32x4_p;
int main(int argc, char* argv[])
{
uint32x4_p a = { 1795745381, 0, 0, 0 };
uint32x4_p b = { 1359893119, 0, 0, 0 };
uint32x4_p c = vec_add(a, b);
byte x[16];
vec_vsx_st((uint8x16_p)c, 0, x);
for (size_t i=0; i<16; ++i)
printf("%02x ", x[i]);
printf("\n");
return 0;
}
The data "1795745381" and "1359893119" were taken from the first finding at
https://github.com/weidai11/cryptopp/issues/749.
And:
$ /opt/at12.0/bin/c++ -O1 -fsanitize=undefined -std=c++14 test.cxx -o test.exe
gcc135:~$ ./test.exe
test.cxx:15:25: runtime error: signed integer overflow: 1795745381 + 1359893119
cannot be represented in type 'int'
e4 38 17 bc 00 00 00 00 00 00 00 00 00 00 00 00
Finally:
gcc135:~$ /opt/at12.0/bin/c++ --version
c++ (GCC) 8.2.1 20180813 (Advance-Toolchain-at12.0) [revision 263510]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c/88172] attribute aligned of zero silently accepted but ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88172 Martin Sebor changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-28 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- The patch for pr88208 adds a warning for attribute aligned (0): https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02261.html
[Bug testsuite/88208] new test case c-c++-common/builtin-has-attribute-3.c in r266335 has multiple excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88208 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02261.html
[Bug c++/63392] poor error recovery with missing typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63392 --- Comment #5 from Eric Gallager --- (In reply to David Malcolm from comment #4) > I've added a fix-it hint (for gcc 9), but I'm not planning to improve the > error-recovery at this time. "at this time" meaning maybe later?
[Bug c++/77572] wrong value for extended ASCII characters in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77572 --- Comment #3 from Eric Gallager --- (In reply to Jonathan Wakely from comment #2) > I still get the same output as Martin using recent trunk, and any older > versions. Ah, I see what happens, I get the same nonsensical output as Martin when I compile for 64-bit, but when I compile for 32-bit, I get the normal-looking output I got before: $ g++ -m64 -c -S -Wall 77572.cc 77572.cc:1:19: error: invalid conversion from 'const char*' to 'int' [-fpermissive] constexpr int i = "\x0_\x01_\x7f_\x80_\xff"; ^ 77572.cc:1:19: error: '(int)((const char*)"\000_\001_\177_\3777600_\377")' is not a constant expression $ g++ -m32 -c -S -Wall 77572.cc 77572.cc:1:19: error: invalid conversion from 'const char*' to 'int' [-fpermissive] constexpr int i = "\x0_\x01_\x7f_\x80_\xff"; ^ 77572.cc:1:19: error: conversion from pointer type 'const char (*)[10]' to arithmetic type 'int' in a constant expression $
[Bug c++/72754] pointer to an unnamed struct with a sole flexible array member accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72754
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-11-28
Ever confirmed|0 |1
--- Comment #4 from Eric Gallager ---
(In reply to Eric Gallager from comment #1)
> gcc now produces at least 1 error in c++ mode:
>
> $ /usr/local/bin/gcc -c -S -Wall -Wextra -Wpedantic -xc 72754.cc
> 72754.cc:1:14: error: flexible array member in a struct with no named members
> struct { int a[]; } *p;
> ^
> 72754.cc:4:15: error: flexible array member in a struct with no named members
> struct { int a[]; } *q;
>^
> $ /usr/local/bin/g++ -c -S -Wall -Wextra -Wpedantic -xc++ 72754.cc
> 72754.cc:1:16: warning: ISO C++ forbids flexible array member ‘a’
> [-Wpedantic]
> struct { int a[]; } *p;
> ^
> 72754.cc:4:17: warning: ISO C++ forbids flexible array member ‘a’
> [-Wpedantic]
> struct { int a[]; } *q;
> ^
> 72754.cc:4:17: error: flexible array member ‘Sa’ in an
> otherwise empty ‘struct S’
> 72754.cc:1:22: warning: ‘p’ defined but not used [-Wunused-variable]
> struct { int a[]; } *p;
> ^
> $ /sw/opt/llvm-3.1/bin/clang++ -c -S -Wall -Wextra -pedantic -xc++ 72754.cc
> 72754.cc:1:14: warning: flexible array member 'a' in otherwise empty struct
> is a GNU extension [-pedantic,-Wgnu]
> struct { int a[]; } *p;
> ^
> 72754.cc:4:15: warning: flexible array member 'a' in otherwise empty struct
> is a GNU extension [-pedantic,-Wgnu]
> struct { int a[]; } *q;
> ^
> 72754.cc:1:22: warning: unused variable 'p' [-Wunused-variable]
> struct { int a[]; } *p;
> ^
> 3 warnings generated.
> $
>
Let me update the comparison output for clang to a newer version of it (6):
$ clang++ -c -S -Wall -Wextra -pedantic -xc++ 72754.cc
72754.cc:1:14: warning: flexible array member 'a' in otherwise empty struct is
a GNU extension [-Wgnu-empty-struct]
struct { int a[]; } *p;
^
72754.cc:1:14: warning: flexible array members are a C99 feature
[-Wc99-extensions]
72754.cc:4:15: warning: flexible array member 'a' in otherwise empty struct is
a GNU extension [-Wgnu-empty-struct]
struct { int a[]; } *q;
^
72754.cc:4:15: warning: flexible array members are a C99 feature
[-Wc99-extensions]
72754.cc:1:22: warning: unused variable 'p' [-Wunused-variable]
struct { int a[]; } *p;
^
5 warnings generated.
$
(In reply to Martin Sebor from comment #2)
> The second case has been diagnosed since r241143 (bug 71912) but the first
> one is still accepted.
Guess I should mark this as confirmed then.
[Bug c++/87742] [7/8/9 Regression] false warning: array subscript 3 is above array bounds of 'const std::type_info* const [3]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742 --- Comment #4 from Liu Hao --- In my real-world example, 0) the enclosing function is indeterminately recursive, but there is no infinite loop, and 1) `o` has type `size_t`, which is a compile time constant because it is the index of a type in a parameter pack; because the number of elements in the array is the `sizeof...` the parameter pack, in no case will it be out of bound. BTW the cast there is not to `unsigned char` but to an enum whose underlying type is `unsigned char`. Using a wider integer type for it might resolve the problem. Your information is invaluable.
[Bug rtl-optimization/88233] combine fails to merge insns leaving unneeded reg copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-28 Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed. We start with insn_cost 12 for 6: r121:TI=[r124:DI] REG_DEAD r124:DI insn_cost 4 for 9: r122:DF=r121:TI#0 insn_cost 4 for10: r123:DF=r121:TI#8 REG_DEAD r121:TI What we really want is a 6+9+10 combination. But combine does not currently try to do such a thing (both 9 and 10 link back via the same reg). It does try to do 6+9, but that needs to do a 2->2 combine, which it doesn't do because it started off with a move insn, it needs one in the end as well, and even if we didn't have such restrictions for 2->2, the insn_costs for the insns you end up with is bigger than that for what you started with (only when also combining it with insn 10 it becomes a lot lower). So, I'll see if I can easily make it try 6+9+10 here.
[Bug c++/88187] [9 Regression] ICE on (invalid) C++ code when compiled with -std=c++17: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88187 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/88187] [9 Regression] ICE on (invalid) C++ code when compiled with -std=c++17: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88187 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Nov 27 23:52:26 2018 New Revision: 266537 URL: https://gcc.gnu.org/viewcvs?rev=266537=gcc=rev Log: PR c++/88187 * decl.c (grokdeclarator): Don't diagnose deduction guide errors if !funcdecl_p. * g++.dg/other/pr88187.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/pr88187.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88229] ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88229 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-27 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed.
[Bug fortran/88228] ICE in check_null, at fortran/expr.c:2691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88228 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-invalid-code Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-27 CC||foreese at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175 --- Comment #13 from Jonny Grant --- (In reply to Jonathan Wakely from comment #11) > (In reply to Jonny Grant from comment #8) > > Do you agree this warning output should be changed to clarify? > > Yes, there's plenty of room to improve it. > > > I understand your reply about it being non-POD when a C++ STL string is > > added. Which adds the implicitly-defined copy constructor. Should it not say > > "implicitly-defined copy constructor for 'struct info'"? instead of "this > > function" ? > > That might be an improvement, but may not be easy to do. I doubt the code > generating that warning knows it's in an implicitly-defined member. > > > Think also better for GCC to show the typedef 'info_t' - would you agree? > > No, I don't think so. > > What's the point in that typedef anyway? In C++ it is allowed to omit the struct keyword where there is no ambiguity. I just always write it. The typedef keyword allows a programmer to assign an alternative name, and save the "struct" keyword in C. > > > (In reply to Jonny Grant from comment #10) > > I wonder if the "POD" location of the struct > > What does that mean? As I understand it, the POD location of the warning is shown when there are no implicit copy-constructor. That is cpp line 12. header.cpp: In function ‘void test(info)’: header.cpp:12:10: error: ‘copy’ is used uninitialized in this function [-Werror=uninitialized] temp = copy; ~^~ Where there is an implicit copy constructor, it shows the wrong file, and wrong function. header.h: In function ‘int main()’: header.h:8:16: error: ‘temp.info::registered’ is used uninitialized in this function [-Werror=uninitialized] typedef struct info ^~~~
[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jonathan Wakely --- Should be fixed on trunk now.
[Bug fortran/88227] ICE in gfc_convert_boz, at fortran/target-memory.c:788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88227 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-27 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > With -m32 down to at least gfortran-5 Confirmed from at least 4.8 up to trunk (9.0).
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #53 from postmas...@conky-be.bounceio.net --- Created attachment 45108 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45108=edit attachment-117920-1.eml
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #52 from postmas...@conky-be.bounceio.net --- Your email was bounced... - ... because something went wrong between you and your recipient. Ugh! What to do next? Well, your specific problem was a *5.1.2 * error. Which means you should: Check the "conky.be" part of "pav...@conky.be" for misspellings or missing letters. If you find an error, correct it in your contacts list or address book for next time. Or further: It is possible that the domain is temporarily inactive. If the spelling looks correct, contact your mail provider and if necessary, contact your recipient another way (e.g., phone or text message). Get more help on 5.1.2 errors here![1] Thanks, have a lovely day. Yours truly, betterbounces.net[2] Rate this email: Helpful[3] :) or... Not Helpful[4] :( Advertisement | Prefer no ads?[5] YOU MIGHT LIKE [6] [7] [8] Learn more about RevenueStripe...[9] - © 2017 betterbounces.net, All rights reserved. Privacy[10] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] 1. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfxj5awgG9sVb8_Cd5cK5ANeO.IEzkK.uYaZBMvRT7Y9_R0.pxZUOMLOeEvQ67WwEjWSpv.fIbGMVztPrlhIrjkrYPTtLx7n8uUUxLPT_9Ws0H1uuQjjdY8otZeSxUSvAfdDgY7ejOcGXKQwk1.7TCaevkuEFAewhiu3AoU3Z2mJ8MY851JGPURbWxWDghqtbyhCAuvLcI3WN3Ca.zo1NwqjQppKoAALG6sPBNYg7e8XMS9A.yJrfSOQmCw3wt58UXoeQOSB8XpF1ji.SOs_JzOTh_jxc_I0WeA- 2. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZp75YYBzCAsbFWEhqkj6hmXSy9lHQVt0YxMJz0eZcNxcaRow_S4zLdIAOhFZmoDnoEXQS2JLdx4XstRAboUmTZYMVtiJgtncOeMdpW8ZCHde1szSYKUSFUZRP9kD8EJ1aeP8fWtMveK1FxSqrkaXDN9ZiqFi2CwrA 3. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfyNQPwy8c.W4sID6tHoZkC_g_yuhxujPswL2TydbXkzrbXRAL6CW8oYv7hwHWJwSPVABg9QBSWeV9T1zP0Uwvnd51FciMElIKLuH5rn3PgpZp4B.7GYwuyfCFQLPGertDcDbqggI8KgIa5frSlJr.89MNYgzZnCxnu3AoU3Z2mJ8MY851JGPURbWxWDghqtbyhCAuvLcI3WN3Ca.zo1NwqjZSwwpJA2afzaD0ZoH8Bpv6EVYZ24p6WF5DxNGre2trVFs7Hk5loQdXDU5qAAcYOp0yrN48SXVUHXkPnaat9etrTOGBpQIUGH 4. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfyNQPwy8c.W4sID6tHoZkC_g_yuhxujPswL2TydbXkzrbXRAL6CW8oYv7hwHWJwSPVABg9QBSWeV9T1zP0Uwvnd51FciMElIKLuH5rn3PgpZp4B.7GYwuyfCFQLPGertDcDbqggI8KgIW0PZrmbqwh.fRzETjbz1Z_2K1P3VYjXnSw_zivbLYA8gsXkVv4pjsmdZK_tM9D5EurOblYuJB.1qZI8tAftCBEit1ddWRcTT1TLYGEi7Tj.yH7uKojMxfRsiQaxrWwS48wLgDT5YF2DyK2IrGBcooWA8gRybSOl5cJLod3FRuBN 5. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZg6_ypgY0WDlQMsIYMGmmjmzq.cd5wQ3gxmfQEmRwABeUylOv2VLqSp12HlZAMtQNAWBcOKn73T3HAsIIGydUm.kU0V3LihEyi5qTxkYYTmZ6DD2EVRJKaj7tmNnhcNldTU_rEvVb4SK7tPyEWu_mycRIj0RXlwoJbrkkBvvgBWH5qCG5cYRaLz.y7Gzl_trFl7dzTYw5w8u2naqeluvlPptvAUQ0QR3Mtei9C68cHzhAkfhytJvxrT.R7_4PXPDYNg3ycv.tZjIW9xvdDf7YwKuymxBbZcte7kMtoBDwfm2XDEYwd9uD9.l4AtKdaDE6WSEvL7EwZYTAinuY5JiyP0OT0CgMAe9K44KpeiBE4rWg2_qxn4jYjQq4b1TtdivcqWEZpTvwwms7lQpTIJx_WSBfoF23e8QU0jGXJDpf433JpLEWL_iZBP5QF24RC36fynEYA5jvw5Kn7dHKAdiI4Qk_1D5f8BNpdyC560RQkF51r0i2tp95k0dMw9RD4ed6GYKls.oEbv.HBr6C6TKfNiJKEU_FT4N.51FciMElIKLuH5rn3PgpZp4B.7GYwuyfCFQLPGertDej3w_ONQBpbA-- 6. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZKjzfoJuTwR0TS6q_0PFt_xTvenO_KUNEpUmBWVo0jroyTju34wY3k83Qy9KqqnrmbQxjAhjLLghxo_g7RBzHeaGy1BAuothz28tUpljMYjfydcYDss.ihRPyAPPU6qc49kQpB2yqLCdJfVPVPpUts1PEz0JpFpiyfNEnniQ88fcPjCsKk008Sz4vJppOoJnPMMPa4cdvfYVdv8U.SzNKsAk_1D5f8BNpdyC560RQkF51r0i2tp95k0dMw9RD4ed6GYKls.oEbv.HBr6C6TKfNiJKEU_FT4N.51FciMElIKLuH5rn3PgpZp4B.7GYwuyfCFQLPGertDej3w_ONQBpbA-- 7.
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #51 from postmas...@conky-be.bounceio.net --- Your email was bounced... - ... because something went wrong between you and your recipient. Oh no! What to do next? Well, your specific problem was a *5.1.2 * error. Which means you should: Check the "conky.be" part of "pav...@conky.be" for misspellings or missing letters. If you find an error, correct it in your contacts list or address book for next time. Or further: It is possible that the domain is temporarily inactive. If the spelling looks correct, contact your mail provider and if necessary, contact your recipient another way (e.g., phone or text message). Get more help on 5.1.2 errors here![1] Thanks, have a lovely day. Yours truly, betterbounces.net[2] Rate this email: Helpful[3] :) or... Not Helpful[4] :( Advertisement | Prefer no ads?[5] Learn more about RevenueStripe... [6] [7] - © 2017 betterbounces.net, All rights reserved. Privacy[8] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] 1. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfxj5awgG9sVb8_Cd5cK5ANeO.IEzkK.uYaZBMvRT7Y9_R0.pxZUOMLOeEvQ67WwEjWSpv.fIbGMVztPrlhIrjkrYPTtLx7n8uUUxLPT_9Ws0H1uuQjjdY8otZeSxUSvAfdDgY7ejOcGXKQwk1.7TCaevkuEFAewhiu3AoU3Z2mJ8MY851JGPURbWxWDghqtbyhCAuvLcI3WN3Ca.zo1NwqjQppKoAALG6u000Th8W6UhTVIf9pxofXym2Rh5ZgXtoz3zNAAmSz94VMZlodiXjtPh_jxc_I0WeA- 2. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZp75YYBzCAsbFWEhqkj6hmXSy9lHQVt0YxMJz0eZcNxcaRow_S4zLdIAOhFZmoDnoEXQS2JLdx4XstRAboUmTZYMVtiJgtncOxc5gIFtvspHf3UmTnnF45u5mKINjIGQTgajbM2Aw.ogBtZHVwNPZ19ZiqFi2CwrA 3. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfyNQPwy8c.W4sID6tHoZkC_g_yuhxujPswL2TydbXkzrbXRAL6CW8oYv7hwHWJwSPVABg9QBSWeVxkVOXwv5HCofzdrNyfgjWC8BoZYRkw26JL6gIo0KvqK4yaWDpEo.RwDbqggI8KgIa5frSlJr.89MNYgzZnCxnu3AoU3Z2mJ8MY851JGPURbWxWDghqtbyhCAuvLcI3WN3Ca.zo1NwqjZSwwpJA2afzaD0ZoH8Bpv6EVYZ24p6WFF6clqi3kP3lO9mNumckmdfh1jah5D5BlGg5EOcVWVhRvfFqz4odt8bTOGBpQIUGH 4. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfyNQPwy8c.W4sID6tHoZkC_g_yuhxujPswL2TydbXkzrbXRAL6CW8oYv7hwHWJwSPVABg9QBSWeVxkVOXwv5HCofzdrNyfgjWC8BoZYRkw26JL6gIo0KvqK4yaWDpEo.RwDbqggI8KgIW0PZrmbqwh.fRzETjbz1Z_2K1P3VYjXnSw_zivbLYA8gsXkVv4pjsmdZK_tM9D5EurOblYuJB.1qZI8tAftCBEit1ddWRcTT1TLYGEi7Tj.gn8gVxz9bUAWiTJAQhRPebGBFf1M8IcH.l._I_tEb3Y0N.EvWPKc0MJLod3FRuBN 5. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZg6_ypgY0WDlQMsIYMGmmjmzq.cd5wQ3gxmfQEmRwABfyd5wkEW426nttqOW5Ur.Hxmv0jqOfaK9v0.ELaZEJYeLQANwKCo5wi5qTxkYYTmZ6DD2EVRJKaj7tmNnhcNldTU_rEvVb4SK7tPyEWu_mycRIj0RXlwoJbrkkBvvgBWH5qCG5cYRaLz.y7Gzl_trFl7dzTYw5w8u2naqeluvlPptvAUQ0QR3Mtei9C68cHzhAkfhytJvxrT.R7_4PXPDYNg3ycv.tZjIW9xvdDf7YwKuymxBbZcte7kMtoBDwfm2XDEYwd9uD9.l4AtKdaDE6WSEvL7EwZYTAinuY5JiyP0OT0CgMAe9K44KpeiBE4rWg2_qxn4jYjSrZ.zg34r6KDdnCD_2bRjuSrPAr10H55865Cy.vUTsvTE96Oo05MGfVo8iTP_yjnwkYF1VHzwjsmqMbceeV6HCn7dHKAdiI4Qk_1D5f8BNpdyC560RQkF51r0i2tp95k0dMw9RD4ed6GYKls.oEbv.HBr6C6TKfNsBjhiWamoP9fzdrNyfgjWC8BoZYRkw26JL6gIo0KvqK4yaWDpEo.Ryj3w_ONQBpbA-- 6. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZzCFTlZ5zieJTlz6Kntx4wk.boz0f0v0vOzuVoMHqjxDZPGryGPm5DR80o108wYyBOmXlDHBZ1sY3PtFU6M1qwDL5GNtz7sgAFMSz0.vVrNAsxkpJYoCmieDNFbxEsaoHxBGL3a7F3rDHHgT1zGcKRJSW99fs8fCvHo223kNwGjhD4V.UeWvuoLkC5tXCniektXH5IlQ3z0DGxAo82dvf.egoYQy3mVjHoRVhnbinpYUXpyWqLeQ.eU72Y26ZySZ1_HWNqHkPkGUaDkQ5xVZWFG98WrPih23xtM4YGlAhQYc- 7.
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #50 from Jonathan Wakely --- Author: redi Date: Tue Nov 27 23:25:56 2018 New Revision: 266533 URL: https://gcc.gnu.org/viewcvs?rev=266533=gcc=rev Log: PR libstdc++/67843 set shared_ptr lock policy at build-time This resolves a longstanding issue where the lock policy for shared_ptr reference counting depends on compilation options when the header is included, so that different -march options can cause ABI changes. For example, objects compiled with -march=armv7 will use atomics to synchronize reference counts, and objects compiled with -march=armv5t will use a mutex. That means the shared_ptr control block will have a different layout in different objects, causing ODR violations and undefined behaviour. This was the root cause of PR libstdc++/42734 as well as PR libstdc++/67843. The solution is to decide on the lock policy at build time, when libstdc++ is configured. The configure script checks for the availability of the necessary atomic built-ins for the target and fixes that choice permanently. Different -march flags used to compile user code will not cause changes to the lock policy. This results in an ABI change for certain compilations, but only where there was already an ABI incompatibility between the libstdc++.so library and objects built with an incompatible -march option. In general, this means a more stable ABI that isn't silently altered when -march flags make addition atomic ops available. To force a target to use "atomic" or "mutex" the new configure option --with-libstdcxx-lock-policy can be used. In order to turn ODR violations into linker errors, the uses of shared_ptr in filesystem directory iterators have been replaced with __shared_ptr, and explicit instantiations are declared. This ensures that object files using those types cannot link to libstdc++ libs unless they use the same lock policy. PR libstdc++/67843 * acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY): Add new macro that defines _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Use GLIBCXX_ENABLE_LOCK_POLICY. * doc/xml/manual/configure.xml: Document new configure option. * include/bits/fs_dir.h (directory_iterator): Use __shared_ptr instead of shared_ptr. (recursive_directory_iterator): Likewise. (__shared_ptr<_Dir>): Add explicit instantiation declaration. (__shared_ptr): Likewise. * include/bits/shared_ptr_base.h (__allocate_shared, __make_shared): Add default template argument for _Lock_policy template parameter. * include/ext/concurrence.h (__default_lock_policy): Check macro _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY instead of checking if the current target supports the builtins for compare-and-swap. * src/filesystem/std-dir.cc (__shared_ptr<_Dir>): Add explicit instantiation definition. (__shared_ptr): Likewise. (directory_iterator, recursive_directory_iterator): Use __make_shared instead of make_shared. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/doc/xml/manual/configure.xml trunk/libstdc++-v3/include/bits/fs_dir.h trunk/libstdc++-v3/include/bits/shared_ptr_base.h trunk/libstdc++-v3/include/ext/concurrence.h trunk/libstdc++-v3/src/filesystem/std-dir.cc
[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843 --- Comment #11 from Jonathan Wakely --- Author: redi Date: Tue Nov 27 23:25:56 2018 New Revision: 266533 URL: https://gcc.gnu.org/viewcvs?rev=266533=gcc=rev Log: PR libstdc++/67843 set shared_ptr lock policy at build-time This resolves a longstanding issue where the lock policy for shared_ptr reference counting depends on compilation options when the header is included, so that different -march options can cause ABI changes. For example, objects compiled with -march=armv7 will use atomics to synchronize reference counts, and objects compiled with -march=armv5t will use a mutex. That means the shared_ptr control block will have a different layout in different objects, causing ODR violations and undefined behaviour. This was the root cause of PR libstdc++/42734 as well as PR libstdc++/67843. The solution is to decide on the lock policy at build time, when libstdc++ is configured. The configure script checks for the availability of the necessary atomic built-ins for the target and fixes that choice permanently. Different -march flags used to compile user code will not cause changes to the lock policy. This results in an ABI change for certain compilations, but only where there was already an ABI incompatibility between the libstdc++.so library and objects built with an incompatible -march option. In general, this means a more stable ABI that isn't silently altered when -march flags make addition atomic ops available. To force a target to use "atomic" or "mutex" the new configure option --with-libstdcxx-lock-policy can be used. In order to turn ODR violations into linker errors, the uses of shared_ptr in filesystem directory iterators have been replaced with __shared_ptr, and explicit instantiations are declared. This ensures that object files using those types cannot link to libstdc++ libs unless they use the same lock policy. PR libstdc++/67843 * acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY): Add new macro that defines _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Use GLIBCXX_ENABLE_LOCK_POLICY. * doc/xml/manual/configure.xml: Document new configure option. * include/bits/fs_dir.h (directory_iterator): Use __shared_ptr instead of shared_ptr. (recursive_directory_iterator): Likewise. (__shared_ptr<_Dir>): Add explicit instantiation declaration. (__shared_ptr): Likewise. * include/bits/shared_ptr_base.h (__allocate_shared, __make_shared): Add default template argument for _Lock_policy template parameter. * include/ext/concurrence.h (__default_lock_policy): Check macro _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY instead of checking if the current target supports the builtins for compare-and-swap. * src/filesystem/std-dir.cc (__shared_ptr<_Dir>): Add explicit instantiation definition. (__shared_ptr): Likewise. (directory_iterator, recursive_directory_iterator): Use __make_shared instead of make_shared. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/doc/xml/manual/configure.xml trunk/libstdc++-v3/include/bits/fs_dir.h trunk/libstdc++-v3/include/bits/shared_ptr_base.h trunk/libstdc++-v3/include/ext/concurrence.h trunk/libstdc++-v3/src/filesystem/std-dir.cc
[Bug testsuite/80580] GIMPLEFE ICE on invalid code (fuzz testing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80580 Mikhail Maltsev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Mikhail Maltsev --- Fixed
[Bug ipa/88231] aligned functions laid down inefficiently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88231 --- Comment #2 from Martin Sebor --- I see that with -Os GCC already optimizes space by reducing the alignment of functions from the default 16 on i86 to 1 (in the absence of attribute aligned), so this would seem to be just a missed opportunity.
[Bug rtl-optimization/88233] New: combine fails to merge insns leaving unneeded reg copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233
Bug ID: 88233
Summary: combine fails to merge insns leaving unneeded reg
copies
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
bergner@pike:~/gcc/BUGS/PR69493$ cat test.i
typedef struct { double a[2]; } A;
A
foo (const A *a)
{
return *a;
}
bergner@pike:~$ .../xgcc -B.../gcc -O2 -S test.i
bergner@pike:~$ cat test.s
ld 10,0(3)
ld 11,8(3)
mtvsrd 1,10
mtvsrd 2,11
blr
Entering combine, we have the following rtl:
...
insn 6 3 9 2 (set (reg:TI 121 [ D.2829 ])
(mem:TI (reg/v/f:DI 124 [ aD.2825 ]) [1 *a_2(D)+0 S16 A64]))
"test.i":5:10 1048 {*vsx_le_perm_load_ti}
(expr_list:REG_DEAD (reg/v/f:DI 124 [ aD.2825 ])
(nil)))
(insn 9 6 10 2 (set (reg:DF 122 [ ])
(subreg:DF (reg:TI 121 [ D.2829 ]) 0)) "test.i":5:10 515
{*movdf_hardfloat64}
(nil))
(insn 10 9 14 2 (set (reg:DF 123 [ +8 ])
(subreg:DF (reg:TI 121 [ D.2829 ]) 8)) "test.i":5:10 515
{*movdf_hardfloat64}
(expr_list:REG_DEAD (reg:TI 121 [ D.2829 ])
(nil)))
...
Combine should be able to merge insn 6 with both insn 9 and insn 10 to produce:
(insn ... (set (reg:DF 122)
(mem:DF (reg:DI 124))
(insn ... (set (reg:DF 123)
(mem:DF (plus:DI (reg:DI 124)
(const_int 8)))
By not merging them, we end up with two unneeded register copies we cannot
remove.
[Bug c++/88232] Please implement -Winfinite-recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88232 Marek Polacek changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-27 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- I'd like this too -- I've run into the same thing many times.
[Bug c++/88232] New: Please implement -Winfinite-recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88232
Bug ID: 88232
Summary: Please implement -Winfinite-recursion
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael at espindo dot la
Target Milestone: ---
This may sound like a silly warning, but it actually very useful in finding
missing member functions in CRTP. Given the testcase
template struct C {
void foo() { static_cast(this)->foo(); }
};
struct D : C {
// this is missing:
// void foo() {}
};
void f(D *d) { d->foo(); }
gcc is silent, but clang prints:
test.cpp:2:14: warning: all paths through this function will call itself
[-Winfinite-recursion]
void foo() { static_cast(this)->foo(); }
[Bug ipa/88231] aligned functions laid down inefficiently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88231 --- Comment #1 from Andrew Pinski --- This shouldn't be too hard to solve. Reording based on alignment should be easy to be taken into account.
[Bug middle-end/88231] New: aligned functions laid down inefficiently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88231
Bug ID: 88231
Summary: aligned functions laid down inefficiently
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
While testing attribute aligned on functions I noticed that GCC doesn't seem to
take advantage of function alignment to optimize space in the emitted assembly.
For instance, emitting the following functions in the order f8, f1, f2 would
reduce their size overall size from 10 bytes to 3.
$ cat t.c && gcc -Os -c -Wall t.c && objdump -d t.o
__attribute__ ((aligned (1))) void f1 (void) { }
__attribute__ ((aligned (8))) void f8 (void) { }
__attribute__ ((aligned (2))) void f2 (void) { }
t.o: file format elf64-x86-64
Disassembly of section .text:
:
0: c3 retq
1: 0f 1f 80 00 00 00 00nopl 0x0(%rax) ;; wasted space
0008 :
8: c3 retq
9: 90 nop ;; wasted space
000a :
a: c3 retq
[Bug other/87695] Fehler beim Kompilieren für das Board Arduino/Genuino Mega or Mega 2560.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695 Andrew Pinski changed: What|Removed |Added CC||al11 at lafcat dot com --- Comment #4 from Andrew Pinski --- *** Bug 88230 has been marked as a duplicate of this bug. ***
[Bug c++/86669] [7/8/9 regression] Complete object constructor clone omits length for a c++11 braced initialiser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669 --- Comment #6 from Iain Sandoe --- (In reply to Iain Sandoe from comment #5) > (In reply to Iain Sandoe from comment #4) > > (In reply to Jakub Jelinek from comment #3) > > > Created attachment 45105 [details] > > > gcc9-pr86669.patch > > > > I'll bootstrap/regtest the patch on x86_64-linux and i686-linux, can > > > somebody please do the 1) and 2)? Thanks. > > > > thanks for the patch, I will do 1 and 2 > > Works for me, tested on x86_64-darwin, and the test-case fails before the > patch and passes after it. NOTE: regtesting still in progress.
[Bug c++/86669] [7/8/9 regression] Complete object constructor clone omits length for a c++11 braced initialiser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669 --- Comment #5 from Iain Sandoe --- (In reply to Iain Sandoe from comment #4) > (In reply to Jakub Jelinek from comment #3) > > Created attachment 45105 [details] > > gcc9-pr86669.patch > > I'll bootstrap/regtest the patch on x86_64-linux and i686-linux, can > > somebody please do the 1) and 2)? Thanks. > > thanks for the patch, I will do 1 and 2 Works for me, tested on x86_64-darwin, and the test-case fails before the patch and passes after it. It applies cleanly to 7.x as well, I built 7.3.1 + the patch and built the original failing code with that; also passed.
[Bug libstdc++/88199] [7/8/9 Regression] memory leak on unordered container move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88199 --- Comment #2 from François Dumont --- Author: fdumont Date: Tue Nov 27 21:21:51 2018 New Revision: 266528 URL: https://gcc.gnu.org/viewcvs?rev=266528=gcc=rev Log: 2018-11-27 François Dumont PR libstdc++/88199 * include/bits/hashtable.h (_Hashtable<>::_M_assign_elements): New. (_Hashtable<>::operator=(const _Hashtable&)): Use latter. (_Hashtable<>::_M_move_assign(_Hashtable&&, false_type)): Likewise. * testsuite/23_containers/unordered_set/allocator/move_assign.cc (test03): New. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h trunk/libstdc++-v3/testsuite/23_containers/unordered_set/allocator/move_assign.cc
[Bug sanitizer/85663] [8/9 Regression] gcc-8.0.1 regression: sanitizer fails to build on mips-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85663 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-27 CC||law at redhat dot com Ever confirmed|0 |1
[Bug c++/88181] [7/8 Regression] ICE: verify_type failed (error: type variant differs by TYPE_PACKED)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88181 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Known to work||9.0 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[7/8/9 Regression] ICE: |[7/8 Regression] ICE: |verify_type failed (error: |verify_type failed (error: |type variant differs by |type variant differs by |TYPE_PACKED)|TYPE_PACKED) Known to fail|9.0 | --- Comment #9 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/88181] [7/8/9 Regression] ICE: verify_type failed (error: type variant differs by TYPE_PACKED)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88181 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Tue Nov 27 21:04:41 2018 New Revision: 266527 URL: https://gcc.gnu.org/viewcvs?rev=266527=gcc=rev Log: PR c++/88181 * class.c (fixup_attribute_variants): Also propagate TYPE_PACKED to variants. * g++.dg/debug/pr88181.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/pr88181.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/88184] [9 Regression] ICE on (invalid) C++ code when compiled with -std=c++2a: unexpected expression ‘f’ of kind template_id_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88184 --- Comment #4 from Marek Polacek --- -fchecking=2 is the answer.
[Bug c++/86669] [7/8/9 regression] Complete object constructor clone omits length for a c++11 braced initialiser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669 --- Comment #4 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #3) > Created attachment 45105 [details] > gcc9-pr86669.patch > > Indeed, it does. clone_body has code to unshare DECL_INITIAL, but it does > so only for FOR_EACH_LOCAL_DECL decls, the artificial temporary for > std::initializer_list in this case isn't tracked among those. > > The following patch fixes it at least when looking at the testcase using a > cross-compiler, but I have no way to 1) test it on darwin 2) check whether > the testcase in the patch actually fails at runtime without the patch and is > fixed with it. > I'll bootstrap/regtest the patch on x86_64-linux and i686-linux, can > somebody please do the 1) and 2)? Thanks. thanks for the patch, I will do 1 and 2
[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #10 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #9) > > OK, sounds like it might be an unrelated issue to the one I'm seeing. The > > following variant of that test crashes for me as well, even though there > > aren't > > any allocatable character strings in it. There's still no allocation code > > generated. > > I got a segfault with this test since at least 4.8.5 up to trunk (9.0). From F2018:11.1.3.3 "Within an ASSOCIATE, CHANGE TEAM, or SELECT TYPE construct, each associating entity has the same rank as its associated selector. The lower bound of each dimension is the result of the intrinsic function LBOUND (16.9.109) applied to the corresponding dimension of selector. The upper bound of each dimension is one less than the sum of the lower bound and the extent. The associating entity does not have the ALLOCATABLE or POINTER attributes; it has the TARGET attribute if and only if the selector is a variable and has either the TARGET or POINTER attribute." As I read that, or its equivalent in earlier standards, reallocation on assignment cannot occur for the likes of the testcase in comments #5 and #8. I guess that we have to think of a suitable runtime check to flag this up. How do the other brands behave? However, I think that the original testcase is valid and that the allocation on assignment should occur. I will take this but it joins an ever increasing number of bugs that I have on my TODO list. Paul
[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>>> --- Comment #1 from Iain Buclaw ---
>>> Is there another way to get a section in earlier versions of Solaris?
>>
>> What I initially did in LLVM's compiler-rt (which prompted the addition
>> of __start_SEC/__stop_SEC support to ld) was to add two startup files to
>> define the necessary labels and link the __start_SEC one early, the
>> __stop_SEC one late:
>>
>> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/
>>
>> See sancov_begin.S and sancov_end.S.
The attached patch implements this. There were a couple of unexpected
problems, though.
> To elaborate, here's my current plan:
>
> * Have some drtstuff.c like this
>
> #ifdef DRT_BEGIN
> void *__start_minfo[]
> __attribute__((used, section("minfo"), aligned(sizeof(void * = { };
> #endif
>
> #ifdef DRT_END
> void *__stop_minfo[]
> __attribute__((used, section("minfo"), aligned(sizeof(void * = { };
> #endif
>
> and compile it into separate drtbegin.o/drtend.o.
This worked fine. I'm wrapping it in __ELF__ to make certain there's
no attempt to compile it on targets without named section support.
> * Based on the outcome of DCFG_MINFO_BRACKETING, add them to
> libgphobos.spec like this:
>
> %rename startfile startfile_orig
> *startfile: %(startfile_orig) drtbegin.o%s
>
> %rename endfile endfile_orig
> *endfile: %(endfile_orig) drtend.o%s
This works, too. However, the substitution needs to be done using
AC_SUBST_FILE with the fragment above in a separate file. Initially, I
put it into a make variable, but the multiline variable confused the
hell out of make.
> * This will have to be done explicitly for libgdruntime.la and
> libgphobos.la since both are linked with -nophoboslib.
This is the part that didn't work the way I initially thought: I tried
to explicitly add drtbegin.o to *_la_LDFLAGS (so it comes at the very
beginning of the link line) and drtend.o to *_la_LDADD (so it comes at
the end). I couldn't get this to work, though: libtool insisted on
always moving those two files (either as .o or .lo files) to the very
end of the link line, completely breaking the intended bracketing.
Preceding the object files with -Wl or -Wc didn't change a thing.
So instead I went for a different approach: have gdc in concert with
libgphobos.spec do the work even when linking libgdruntime.la and
libgphobos.la. The problem was that I still needed the
drtbegin.o/drtend.o files to be added despite the use of -nophoboslib.
To achieve that, I added a new -dstartfiles option. I initially tried
-startfiles matching the existing -nostartfiles, but couldn't get that
option to be recognized by gdc. Of course I now need to add the
matching -B options so both libgphobos.spec and drtbegin.o/drtend.o are
found.
> Doing the equivalent of this manually allowed the libs to be linked on
> Solaris 10. However, this was before the section_elf_shared.d work, so
> the resulting libs had unresolved references.
I first tried this on Solaris 11.3 because S10 has quite a number of
additional problems. I needed only a single additional patch (to be
submitted separately) because unlike S11.4 the networking functions have
not yet been folded into libc, but live in separate libsocket and
libnsl.
With this patch, I could bootstrap sparc-sun-solaris2.11 and with as and
i386-pc-solaris2.11, each on S11.4 (where ld does section bracketing)
and S11.3 (where it doesn't).
A couple of additional comments/questions:
* I'm uncertain if we want -dstartfiles to be documented at all: it's
purely internal, I believe.
* I've switched the Makefile.am's from -Xcompiler to -Wc because the
latter is way less verbose and allows to apppend several
comma-separated args.
* The Minfo_Bracketing assert in sections_elf_shared.d fails now, of
course, but the file is usable even without linker-provided
bracketing. Should this go completely?
There still are a very large number of execution failures in the
libphobos and gdc.* testsuites, but this is already the case on S11.4
when the linker adds the minfo bracketing. At least we get the runtime
libs to link now.
[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675 --- Comment #3 from Scott Gayou --- My last comment was a bit confusing. I can reproduce 2/3 on a standard system, and the other 1/3 requires dropping ulimit -s down a bit. (to 4096).
[Bug fortran/88190] compile_options.allow_std does not allow to distinguish between GFC_STD_GNU and GFC_STD_LEGACY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88190 --- Comment #7 from Dominique d'Humieres --- > I have been giving this some thought. After reading our current documentation > for -std= why do we all of a sudden change a policy because the reporter of > 88052 does not like something? Why not just keep the current behavior and use > the allow_std for pr88052 and allow the extension with -std=gnu and default. > Then when user wants more rigorous compliance then use -std=f95, etc. as is > done now. Agreed! However I think it is not a good idea to keep gfc_option.allow_std the same for -std=gnu and std=legacy. This will allow to reject some legacy codes that should be fixed: dangerous extensions, easy to fix ones, ... My list in (weak) priority order is (1) AC-IMPLIED-DO (2) SAVE statement (3) PARAMETER without () (4) REAL array (5) Duplicate .* attribute (6) Label not in the same block (6) Hollerith ...
[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864 --- Comment #4 from Rainer Orth --- Created attachment 45106 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45106=edit Initial patch
[Bug target/88078] error: '__float128' was not declared in this scope on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88078 --- Comment #3 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #2) > For GCC 8.2 using -std=c++14 instead of -std=gnu++14 will disable the > __float128 specializations, avoiding the problem of long double and > __float128 being the same type. Thanks Jonathan.
[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675 Scott Gayou changed: What|Removed |Added CC||sgayou at redhat dot com --- Comment #2 from Scott Gayou --- As Michael said, this seems to be one of a large number of duplicates. At least CVE-2018-18484, CVE-2018-18701, and CVE-2018-18700 seems to be a duplicates. I can only reproduce one of them via setting a lower ulimit -s, and the crashes all appear to be in cp-demangle.c. The call flows are similar yet slightly different. My guess is that a recursion limit would fix all of these hence they are the same root issue. If upstream agrees, the duplicate CVE assignments can potentially be rejected. Let me know if anyone else has any evidence or arguments that these are different -- it is possible I made a mistake in the analysis.
[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed.
[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Tue Nov 27 19:23:39 2018 New Revision: 266524 URL: https://gcc.gnu.org/viewcvs?rev=266524=gcc=rev Log: PR middle-end/87157 * gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c (main1): Add noipa attribute. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c
[Bug c++/88103] [7/8/9 Regression] Wrong value category when conditional expression result is used as object expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88103
Jakub Jelinek changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Isn't that just because we've actually folded the true ? x : y expressions to x
before handling it?
If I tweak the testcase (below, so that it can't be folded), it started FAILing
with r200821.
struct A {
A(int);
A&& foo() && ;
int i;
};
void free(A&&);
void test_xvalue(A a, bool b, A c){
//No error
A&& ref = b? static_cast(a) : static_cast(c);
//No error
free(b? static_cast(a) : static_cast(c));
//Unexpected error: passing A as this discard qualifier
(b? static_cast(a) : static_cast(c)).foo();
//Unexpected error: error cannot bind rvalue reference
// of type int&& to lvalue of type int
int&& k=(b? static_cast(a) : static_cast(c)).i;
}
void test_prvalue(A a, bool b){
//No error
A&& ref = b? static_cast(a) : 1;
//No error
free(b? static_cast(a) : 1);
//No error
(b? static_cast(a) : 1).foo();
//No error
int&& k=(b? static_cast(a) : 1).i;
}
[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #17 from David Malcolm --- Fixed on trunk by r266516.
[Bug debug/86593] [8 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 Jakub Jelinek changed: What|Removed |Added CC||daniel.f.starke at freenet dot de --- Comment #14 from Jakub Jelinek --- *** Bug 87294 has been marked as a duplicate of this bug. ***
[Bug debug/87294] [8/9 Regression] dwarf-3 generation fails with ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87294 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 86593 ***
[Bug c++/87742] [7/8/9 Regression] false warning: array subscript 3 is above array bounds of 'const std::type_info* const [3]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
From my understanding, the warning is correct.
You have in the code essentially:
something b[3];
unsigned int o;
...
switch ((unsigned char) o)
{
case 2:
if (o == 2)
for (;;)
;
b[o];
}
Thus, the b[o] array access is executed only if the low 8 bits of o are 2, but
the high 24 bits of o are not 0, so whenever it is executed, it is always out
of bounds access.
The infinite loop above is the result of:
F::G::operator int*
recursing infinitely. So, in order to avoid the warning, you either want to
test all bits of o, rather than just the low 8 bits (i.e. avoid the cast to
bd), or do something with the conversion operator.
It of course could be just something introduced through creducing.
[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173 --- Comment #16 from Mike Gulick --- (In reply to Eric Gallager from comment #15) > So can this be closed as FIXED now? Yes, fixed by r266516.
[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173 --- Comment #15 from Eric Gallager --- (In reply to David Malcolm from comment #14) > Author: dmalcolm > Date: Tue Nov 27 16:04:31 2018 > New Revision: 266520 > > URL: https://gcc.gnu.org/viewcvs?rev=266520=gcc=rev > Log: > PR preprocessor/83173: Enhance -fdump-internal-locations output > > gcc/ChangeLog: > 2018-11-27 Mike Gulick > > PR preprocessor/83173 > * input.c (dump_location_info): Dump reason and included_from > fields from line_map_ordinary struct. Fix indentation when > location > 5 digits. > * diagnostic-show-locus.c (num_digits, num_digits): Move to > diagnostic.c to allow it to be utilized by input.c. > * diagnostic.c (num_digits, selftest::test_num_digits): Moved > here. > (selftest::diagnostic_c_tests): Run selftest::test_num_digits. > * diagnostic.h (num_digits): Add extern definition. > > libcpp/ChangeLog: > 2018-11-27 Mike Gulick > > PR preprocessor/83173 > * location-example.txt: Update example -fdump-internal-locations > output. > > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/diagnostic-show-locus.c > trunk/gcc/diagnostic.c > trunk/gcc/diagnostic.h > trunk/gcc/input.c > trunk/libcpp/ChangeLog > trunk/libcpp/location-example.txt So can this be closed as FIXED now?
[Bug c++/86669] [7/8/9 regression] Complete object constructor clone omits length for a c++11 braced initialiser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-27 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/86669] [7/8/9 regression] Complete object constructor clone omits length for a c++11 braced initialiser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669 --- Comment #3 from Jakub Jelinek --- Created attachment 45105 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45105=edit gcc9-pr86669.patch Indeed, it does. clone_body has code to unshare DECL_INITIAL, but it does so only for FOR_EACH_LOCAL_DECL decls, the artificial temporary for std::initializer_list in this case isn't tracked among those. The following patch fixes it at least when looking at the testcase using a cross-compiler, but I have no way to 1) test it on darwin 2) check whether the testcase in the patch actually fails at runtime without the patch and is fixed with it. I'll bootstrap/regtest the patch on x86_64-linux and i686-linux, can somebody please do the 1) and 2)? Thanks.
[Bug target/61976] aix64: Data corruption in struct passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61976
David Edelsohn changed:
What|Removed |Added
CC||segher at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
--- Comment #3 from David Edelsohn ---
GCC is passing aggregates containing a single member in the mode of the member
instead of following the ABI for aggregates.
USE_FP_FOR_ARG_P tests the MODE of the argument, which GCC presents as the
underlying MODE, e.g., the mode of the "byval" argument is SFmode, not SImode.
This ABI bug also is present for the PPC64 ELFv1 ABI, but is silently hidden
because PPC64 ELFv1 pads arguments downward like a numerical value while AIX
pads arguments upwards like a string.
The following patch seems to fix the oversight. I suspect that this only should
be fixed for AIX and not for Linux.
Index: rs6000.c
===
--- rs6000.c(revision 265577)
+++ rs6000.c(working copy)
@@ -11915,7 +11915,8 @@
if (elt_mode == TDmode && (cum->fregno % 2) == 1)
cum->fregno++;
- if (USE_FP_FOR_ARG_P (cum, elt_mode))
+ if (USE_FP_FOR_ARG_P (cum, elt_mode)
+ && (TREE_CODE (type) != RECORD_TYPE || DEFAULT_ABI != ABI_AIX))
{
rtx rvec[GP_ARG_NUM_REG + AGGR_ARG_NUM_REG + 1];
rtx r, off;
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #33 from janus at gcc dot gnu.org --- (In reply to janus from comment #30) > I have verified that the problem goes away when using the following as > version: > GNU assembler (GNU Binutils) 2.31.51.20181124 Same ǵoes for the 2.30 branch as of today. (I hope there will be a 2.30.1 release in the near future.) According to comment 22, binutils 2.29 also seems to work well.
[Bug fortran/88229] ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88229
--- Comment #1 from G. Steinmetz ---
This variant compiles and works :
$ cat z3.f90
program p
call s
contains
subroutine s
character(:), allocatable :: y
allocate (y, source=f('abcdefff'))
print *, len(y), y
end
function f(x) result(z)
character(*) :: x
character(:), allocatable :: z
allocate (z, source=x)
end
end
$ gfortran-9-20181125 z3.f90 -O2 -static-libgfortran
$ a.out
16 abcdefff
$
[Bug fortran/88229] New: ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88229
Bug ID: 88229
Summary: ICE tree check: expected integer_cst, have nop_expr in
get_len, at tree.h:5608
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
With valid code at -O[s123] :
$ cat z1.f90
program p
call s
contains
subroutine s
character(:), allocatable :: y
allocate (y, source=f('abcdefff'))
end
function f(x) result(z)
character(*) :: x
character(:), allocatable :: z
allocate (z, source=(x))
end
end
$ cat z2.f90
program p
call s
contains
subroutine s
character(:,kind=4), allocatable :: y
allocate (y, source=f(4_'abcd'))
end
function f(x) result(z)
character(*,kind=4) :: x
character(:,kind=4), allocatable :: z
allocate (z, source=(x))
end
end
$ gfortran-9-20181125 -c z1.f90 -O0
z1.f90:11:0:
11 | allocate (z, source=(x))
|
Error: size of variable 'source.0' is too large
$ gfortran-9-20181125 -c z1.f90 -O2
during GIMPLE pass: ccp
z1.f90:1:0:
1 | program p
|
internal compiler error: tree check: expected integer_cst, have nop_expr in
get_len, at tree.h:5608
0x5e466a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9745
0xec8c34 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3410
0xec8c34 wi::extended_tree<128>::get_len() const
../../gcc/tree.h:5608
0xec8c34 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc/wide-int.h:964
0xec8c34 wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:1013
0xec8c34 generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:788
0xec8c34 bool wi::eq_p >,
int>(generic_wide_int > const&, int const&)
../../gcc/wide-int.h:1832
0xec424a bool wi::ne_p >,
int>(generic_wide_int > const&, int const&)
../../gcc/wide-int.h:1870
0xec424a wi::binary_traits >, int,
wi::int_traits > >::precision_type,
wi::int_traits::precision_type>::predicate_result
operator!= >,
int>(generic_wide_int > const&, int const&)
../../gcc/wide-int.h:3269
0xec424a if_nonpoly::is_poly>::type
maybe_ne<1u, generic_wide_int >, int>(poly_int_pod<1u,
generic_wide_int > > const&, int const&)
../../gcc/poly-int.h:1282
0xec424a bool known_size_p
> > >(poly_int<1u, generic_wide_int > > const&)
../../gcc/poly-int.h:2487
0xec424a bool known_subrange_p > >, poly_int<1u,
generic_wide_int > >, int, poly_int<1u,
generic_wide_int > > >(poly_int<1u,
generic_wide_int > > const&, poly_int<1u,
generic_wide_int > > const&, int const&, poly_int<1u,
generic_wide_int > > const&)
../../gcc/poly-int.h:2595
0xec424a non_rewritable_mem_ref_base
../../gcc/tree-ssa.c:1450
0xec4b1d execute_update_addresses_taken()
../../gcc/tree-ssa.c:1697
0xba6078 execute_function_todo
../../gcc/passes.c:1952
0xba6fe2 execute_todo
../../gcc/passes.c:2031
$ gfortran-9-20181125 -c z2.f90 -O2
during GIMPLE pass: ccp
z2.f90:1:0:
1 | program p
|
internal compiler error: tree check: expected integer_cst, have mult_expr in
get_len, at tree.h:5608
0x5e466a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9745
#...
[Bug rtl-optimization/87902] [9 Regression] Shrink-wrapping multiple conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87902 --- Comment #8 from Segher Boessenkool --- (In reply to Ilya Leoshkevich from comment #7) > Apparently, for this specific case doing more of hard register copy > propagation is enough. I've just tried running pass_cprop_hardreg > before pass_thread_prologue_and_epilogue, and it helped. > > So, would running a mini-cprop_hardreg instead of just > copyprop_hardreg_forward_bb_without_debug_insn (entry_block) be > reasonable here? Something along the lines of: > > - Do something like pre_and_rev_post_order_compute_fn (), but do not go > further from bbs which contain insns satisfying > requires_stack_frame_p (), since shrink-wrapping cannot happen past > those anyway. I don't think that is true. Separate shrink-wrapping... > Same for bbs which have more than 1 predecessor, since > cprop_hardreg forgets everything it saw when it encounters those. Not > sure if a reasonable merge function can be defined for struct > value_data to improve this? > > Maybe also stop completely when a certain number of bbs is found. > > - Do something like pass_cprop_hardreg::execute (), but use only bbs > computed during the previous step. I think running the normal cprop_hardreg here is fine. Or is it so expensive? > Btw, would reverse postorder be > the "more intelligent queuing of blocks" mentioned in > pass_cprop_hardreg::execute ()? Maybe? It's not totally clear what is wanted here. > When you say that what IRA does is not effective, do you mean just the > need to track indirect hard register copies, or can it be improved even > further? I mean that split_live_ranges_for_shrink_wrap does not help much.
[Bug fortran/88228] New: ICE in check_null, at fortran/expr.c:2691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88228 Bug ID: 88228 Summary: ICE in check_null, at fortran/expr.c:2691 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With option -fdec since gfortran-7 : $ cat z1.f90 program p integer :: n = .not. 1 end $ cat z2.f90 program p integer :: j = .true. .or. 1 end $ gfortran-9-20181125 -c z1.f90 z1.f90:2:23: 2 |integer :: n = .not. 1 | 1 Error: Operand of .not. operator at (1) is INTEGER(4) $ gfortran-9-20181125 -c z1.f90 -fdec f951: internal compiler error: Segmentation fault 0xb2bcff crash_signal ../../gcc/toplev.c:326 0x61e8f6 check_null ../../gcc/fortran/expr.c:2691 0x61e8f6 gfc_check_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:2792 0x61ecb7 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:2955 0x621d90 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:3001 0x60f189 variable_decl ../../gcc/fortran/decl.c:2710 0x60f189 gfc_match_data_decl() ../../gcc/fortran/decl.c:5921 0x66dc23 match_word ../../gcc/fortran/parse.c:65 0x66dc23 decode_statement ../../gcc/fortran/parse.c:376 0x66f6aa next_free ../../gcc/fortran/parse.c:1234 0x66f6aa next_statement ../../gcc/fortran/parse.c:1466 0x671a14 parse_spec ../../gcc/fortran/parse.c:3674 0x673787 parse_progunit ../../gcc/fortran/parse.c:5671 0x674e09 gfc_parse_file() ../../gcc/fortran/parse.c:6211 0x6bdaff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/88227] New: ICE in gfc_convert_boz, at fortran/target-memory.c:788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88227 Bug ID: 88227 Summary: ICE in gfc_convert_boz, at fortran/target-memory.c:788 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With -m32 down to at least gfortran-5 : $ cat z1.f90 program p print *, dble(b'1010101001101') end $ cat z2.f90 program p print *, real(b'1010101001101') end $ gfortran-9-20181125 -m32 -fdefault-real-8 -c z2.f90 $ gfortran-9-20181125 -m64 -fdefault-real-8 -c z1.f90 $ $ gfortran-9-20181125 -m32 -fdefault-real-8 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb2bcff crash_signal ../../gcc/toplev.c:326 0x6b1ba9 mode_to_bytes(machine_mode) ../../gcc/machmode.h:520 0x6b1ba9 if_nonpoly::is_poly>::type GET_MODE_SIZE(scalar_int_mode const&) ../../gcc/machmode.h:617 0x6b1ba9 size_integer ../../gcc/fortran/target-memory.c:42 0x6b2ffc gfc_convert_boz(gfc_expr*, gfc_typespec*) ../../gcc/fortran/target-memory.c:788 0x69cb60 convert_boz ../../gcc/fortran/simplify.c:226 0x6a88a3 gfc_simplify_dble(gfc_expr*) ../../gcc/fortran/simplify.c: 0x62dedf do_simplify ../../gcc/fortran/intrinsic.c:4480 0x6385be gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:4875 0x68f961 resolve_unknown_f ../../gcc/fortran/resolve.c:2875 0x68f961 resolve_function ../../gcc/fortran/resolve.c:3213 0x68c1cd gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6832 0x68420b gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11262 0x693edf gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10302 0x684399 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11252 0x68702f resolve_codes ../../gcc/fortran/resolve.c:16704 0x6870fe gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16739 0x674e87 resolve_all_program_units ../../gcc/fortran/parse.c:6064 0x674e87 gfc_parse_file() ../../gcc/fortran/parse.c:6314 0x6bdaff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/80467] Function Without Arguments Fails to Generate Error When Declared Later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80467 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #8 from G. Steinmetz --- Update, renewing some insights from above. Also related to pr40678. $ cat z1.f90 program p contains subroutine testargs x = g !() end real function g() g = 3.0 end end $ cat z2.f90 program p ! reversed order contains real function g() g = 3.0 end subroutine testargs x = g !() end end $ gfortran-9-20181125 -c z2.f90 z2.f90:7:12: 7 | x = g !() |1 Error: Function 'g' requires an argument list at (1) $ gfortran-9-20181125-chk -c z1.f90 # with --enable-checking=yes z1.f90:3:0: 3 |subroutine testargs | Error: invalid types in conversion to floating point real(kind=4) real(kind=4) (*) (void) x = (real(kind=4)) g; z1.f90:3:0: internal compiler error: verify_gimple failed 0xcce85d verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.c:5082 0x9e2235 gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:13636 0x9e2524 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:13726 0xd3816f gimplify_all_functions ../../gcc/tree-nested.c:3410 0xd3815f gimplify_all_functions ../../gcc/tree-nested.c:3413 0xd41e9e lower_nested_functions(tree_node*) ../../gcc/tree-nested.c:3430 0x82c560 cgraph_node::analyze() ../../gcc/cgraphunit.c:673 0x82f9e9 analyze_functions ../../gcc/cgraphunit.c:1126 0x830ac2 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2835
[Bug tree-optimization/79351] [7/8/9 Regression] Invalid tree PRE optimization around compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79351
Alexander Monakov changed:
What|Removed |Added
Keywords||wrong-code
Status|WAITING |NEW
CC||amonakov at gcc dot gnu.org
Known to work||4.3.2
Summary|Invalid tree PRE|[7/8/9 Regression] Invalid
|optimization around |tree PRE optimization
|compound literal|around compound literal
Known to fail||4.7.2
--- Comment #4 from Alexander Monakov ---
Thanks, confirmed. Reduced testcase, aborts with -O -ftree-pre:
static struct state {
int k;
int dummy;
} states[256];
__attribute((noipa))
static void
ismatch(int n)
{
for (int j=0; j
[Bug c++/86205] [9 Regression] ICE on valid C++11 code: in type_dependent_expression_p, at cp/pt.c:25193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86205 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug ada/88200] [9 Regression] ada bootstrap failure on alpha-linux-gnu (aised STORAGE_ERROR : stack overflow or erroneous memory access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88200 --- Comment #2 from Matthias Klose --- reproduced with r266507. The native x86_64-linux-gnu compiler is configured with --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu note the --enable-default-pie. the cross compiler with --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libssp --disable-libsanitizer --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --disable-libphobos --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=alpha-linux-gnu --program-prefix=alpha-linux-gnu- --includedir=/usr/alpha-linux-gnu/include
[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-27 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/88211] missing warning on printf %ls and unterminated wide member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88211 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-27 Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- Confirmed as per the xfailed tests that show these missing warnings (comment #2).
[Bug middle-end/88226] missing warning on fprintf, fputs, and puts with an unterminated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88226 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-27 Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- Confirmed as per the xfailed tests that show these missing warnings (comment #2).
[Bug middle-end/88211] missing warning on printf %ls and unterminated wide member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88211 --- Comment #2 from Martin Sebor --- Author: msebor Date: Tue Nov 27 17:07:24 2018 New Revision: 266522 URL: https://gcc.gnu.org/viewcvs?rev=266522=gcc=rev Log: PR 87756 - missing unterminated argument warning using address of a constant character PR 88211 - missing warning on printf %ls and unterminated wide member array PR 88226 - missing warning on fprintf, fputs, and puts with an unterminated array gcc/ChangeLog: * gcc.dg/tree-ssa/builtin-fprintf-warn-1.c: Update/remove xfails. * gcc.dg/tree-ssa/builtin-printf-warn-1.c: Same. * gcc.dg/tree-ssa/user-printf-warn-1.c: Same. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-fprintf-warn-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-printf-warn-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/user-printf-warn-1.c
[Bug tree-optimization/87756] missing unterminated argument warning using address of a constant character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87756 --- Comment #7 from Martin Sebor --- Author: msebor Date: Tue Nov 27 17:07:24 2018 New Revision: 266522 URL: https://gcc.gnu.org/viewcvs?rev=266522=gcc=rev Log: PR 87756 - missing unterminated argument warning using address of a constant character PR 88211 - missing warning on printf %ls and unterminated wide member array PR 88226 - missing warning on fprintf, fputs, and puts with an unterminated array gcc/ChangeLog: * gcc.dg/tree-ssa/builtin-fprintf-warn-1.c: Update/remove xfails. * gcc.dg/tree-ssa/builtin-printf-warn-1.c: Same. * gcc.dg/tree-ssa/user-printf-warn-1.c: Same. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-fprintf-warn-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-printf-warn-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/user-printf-warn-1.c
[Bug middle-end/88226] missing warning on fprintf, fputs, and puts with an unterminated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88226 --- Comment #2 from Martin Sebor --- Author: msebor Date: Tue Nov 27 17:07:24 2018 New Revision: 266522 URL: https://gcc.gnu.org/viewcvs?rev=266522=gcc=rev Log: PR 87756 - missing unterminated argument warning using address of a constant character PR 88211 - missing warning on printf %ls and unterminated wide member array PR 88226 - missing warning on fprintf, fputs, and puts with an unterminated array gcc/ChangeLog: * gcc.dg/tree-ssa/builtin-fprintf-warn-1.c: Update/remove xfails. * gcc.dg/tree-ssa/builtin-printf-warn-1.c: Same. * gcc.dg/tree-ssa/user-printf-warn-1.c: Same. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-fprintf-warn-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-printf-warn-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/user-printf-warn-1.c
[Bug middle-end/88226] missing warning on fprintf, fputs, and puts with an unterminated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88226 Martin Sebor changed: What|Removed |Added Keywords||diagnostic See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=87756, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88211 --- Comment #1 from Martin Sebor --- See also pr87756 and pr88211.
[Bug middle-end/88226] New: missing warning on fprintf, fputs, and puts with an unterminated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88226
Bug ID: 88226
Summary: missing warning on fprintf, fputs, and puts with an
unterminated array
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: ---
Of the invalid uses of an unterminated character array below GCC diagnoses just
the first and none of the others.
$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
#include
const char c = 'a';
void g (FILE *f)
{
printf ("%s", );// warning (good)
fprintf (f, "%s", );// missing warning
fputs (, f);// same
puts ();// same
}
t.c: In function ‘g’:
t.c:7:12: warning: ‘%s’ directive argument is not a nul-terminated string
[-Wformat-overflow=]
7 | printf ("%s", );// warning (good)
| ~^~~~
t.c:3:12: note: referenced argument declared here
3 | const char c = 'a';
|^
;; Function g (g, funcdef_no=11, decl_uid=2409, cgraph_uid=12, symbol_order=12)
g (struct FILE * f)
{
[local count: 1073741824]:
printf ("%s", );
__builtin_fputs (, f_3(D));
fputs (, f_3(D));
puts (); [tail call]
return;
}
[Bug c++/86610] [8/9 Regression] non-const operator erroneously called in lambda in templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86610 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Nathan, another r255605 regression, can you please have a look?
[Bug sanitizer/85663] [8/9 Regression] gcc-8.0.1 regression: sanitizer fails to build on mips-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85663 Jakub Jelinek changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- CCing Hans-Peter, who has enabled libsanitizer on mips*. If this needs to be done, it should be ideally pushed upstream first and then cherry-picked.
[Bug fortran/88205] ICE in gfc_wide_strncasecmp, at fortran/scanner.c:249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88205 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-27 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > With a non-scalar-default-char-expr, down to at least gcc-5 : Confirmed from 4.8 up to trunk (9.0).
[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 --- Comment #9 from Dominique d'Humieres --- > OK, sounds like it might be an unrelated issue to the one I'm seeing. The > following variant of that test crashes for me as well, even though there > aren't > any allocatable character strings in it. There's still no allocation code > generated. I got a segfault with this test since at least 4.8.5 up to trunk (9.0).
[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173 --- Comment #14 from David Malcolm --- Author: dmalcolm Date: Tue Nov 27 16:04:31 2018 New Revision: 266520 URL: https://gcc.gnu.org/viewcvs?rev=266520=gcc=rev Log: PR preprocessor/83173: Enhance -fdump-internal-locations output gcc/ChangeLog: 2018-11-27 Mike Gulick PR preprocessor/83173 * input.c (dump_location_info): Dump reason and included_from fields from line_map_ordinary struct. Fix indentation when location > 5 digits. * diagnostic-show-locus.c (num_digits, num_digits): Move to diagnostic.c to allow it to be utilized by input.c. * diagnostic.c (num_digits, selftest::test_num_digits): Moved here. (selftest::diagnostic_c_tests): Run selftest::test_num_digits. * diagnostic.h (num_digits): Add extern definition. libcpp/ChangeLog: 2018-11-27 Mike Gulick PR preprocessor/83173 * location-example.txt: Update example -fdump-internal-locations output. Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-show-locus.c trunk/gcc/diagnostic.c trunk/gcc/diagnostic.h trunk/gcc/input.c trunk/libcpp/ChangeLog trunk/libcpp/location-example.txt
[Bug middle-end/86827] [8/9 Regression] -Warray-bounds produces negative indicies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86827 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from Martin Sebor --- I'm not working on this at the moment.
[Bug tree-optimization/79351] Invalid tree PRE optimization around compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79351 --- Comment #3 from Chris Wellons --- This bug is still present in GCC 8.2.0. I just tested my example again on x86-64, i686, and ARM64.
[Bug gcov-profile/88225] Slowness in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88225 --- Comment #2 from Martin Liška --- Patch candidate: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02203.html
[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 --- Comment #8 from Tomáš Trnka --- (In reply to Dominique d'Humieres from comment #7) > > Could you please kindly suggest what do I need to do to get this out of > > WAITING? ... > > AFAIK you can do it yourself. > > WAITING is not a punishment, it just mean that some feedback is needed, most > of the time from the reporter, but sometimes from the maintainers. In this > case it meant that at looked at the PR, but was unable to confirm it. OK, sorry for the noise then, I just found no way to change it myself. The only statuses offered in the drop-down for me were WAITING and RESOLVED. > Now I get a segfault at runtime for the test in comment 5, likely caused by > revision r257363 (pr84115). OK, sounds like it might be an unrelated issue to the one I'm seeing. The following variant of that test crashes for me as well, even though there aren't any allocatable character strings in it. There's still no allocation code generated. program p integer, allocatable :: z(:) call s(z) contains subroutine s(x) integer, allocatable :: x(:) associate (y => x) y = [1, 2, 3] end associate print *, allocated(x), size(x), x end end In case this turns out to be an unrelated issue, could you double-check if you get a call to malloc() with the original test in my first post?
[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173 --- Comment #13 from David Malcolm --- Author: dmalcolm Date: Tue Nov 27 15:53:51 2018 New Revision: 266518 URL: https://gcc.gnu.org/viewcvs?rev=266518=gcc=rev Log: PR preprocessor/83173: New test 2018-11-27 Mike Gulick PR preprocessor/83173 * gcc.dg/plugin/location-overflow-test-pr83173.c: New test. * gcc.dg/plugin/location-overflow-test-pr83173.h: Header for pr83173.c. * gcc.dg/plugin/location-overflow-test-pr83173-1.h: Header for pr83173.c. * gcc.dg/plugin/location-overflow-test-pr83173-2.h: Header for pr83173.c. * gcc.dg/plugin/location_overflow_plugin.c: Use PLUGIN_PRAGMAS instead of PLUGIN_START_UNIT. * gcc.dg/plugin/plugin.exp: Enable new test. Added: trunk/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-1.h trunk/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173-2.h trunk/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.c trunk/gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr83173.h Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c trunk/gcc/testsuite/gcc.dg/plugin/plugin.exp
[Bug rtl-optimization/87718] [9 Regression] FAIL: gcc.target/i386/avx512dq-concatv2si-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed, thanks.
[Bug c++/88184] [9 Regression] ICE on (invalid) C++ code when compiled with -std=c++2a: unexpected expression ‘f’ of kind template_id_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88184 --- Comment #3 from Marek Polacek --- FWIW, I'm still unable to reproduce. Tried (non-)bootstrap + (non-)checking builds but I get the output in Comment 2.
[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173 --- Comment #12 from David Malcolm --- Author: dmalcolm Date: Tue Nov 27 15:49:43 2018 New Revision: 266516 URL: https://gcc.gnu.org/viewcvs?rev=266516=gcc=rev Log: PR preprocessor/83173: Additional check before decrementing highest_location 2018-11-27 Mike Gulick PR preprocessor/83173 * files.c (_cpp_stack_include): Check if line_table->highest_location is past current line before decrementing. Modified: trunk/libcpp/ChangeLog trunk/libcpp/files.c
[Bug target/88188] ICE in print_operand, at config/rs6000/rs6000.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88188 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue Nov 27 15:40:57 2018 New Revision: 266515 URL: https://gcc.gnu.org/viewcvs?rev=266515=gcc=rev Log: PR target/88188 * config/rs6000/rs6000.c (print_operand) : Use output_operand_lossage instead of gcc_assert. : Likewise. : Likewise. : Use output_operand_lossage instead of gcc_unreachable. * gcc.target/powerpc/pr88188.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr88188.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-11.c
[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
--- Comment #9 from Jan Hubicka ---
> @@ -11,7 +11,7 @@ struct test {
>
> extern struct test s;
>
> -int main1 ()
> +__attribute__((noipa)) int main1 ()
> {
>int i;
>
> We want to test the vectorizer behavior, not depend on how many times the
> function has been inlined or versioned.
This looks like a good idea :)
[Bug tree-optimization/79351] Invalid tree PRE optimization around compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79351 Leonard König changed: What|Removed |Added CC||leonard.r.koenig@googlemail ||.com --- Comment #2 from Leonard König --- I could reproduce valid/broken cases from GCC-8 down to GCC-5, running on x86_64 ArchLinux.
[Bug gcov-profile/88225] Slowness in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88225 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-27 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine.
[Bug gcov-profile/88225] New: Slowness in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88225 Bug ID: 88225 Summary: Slowness in gcov Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- running gcov for tramp3d I see: $ perf report 83.09% gcov gcov [.] source_info::get_functions_at_location 8.68% gcov gcov [.] main 1.16% gcov libc-2.27.so [.] vfprintf 0.70% gcov [unknown] [k] 0xb5a001a6 I have a patch for that.
[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
So, I think we should go for:
--- gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c.jj
2017-03-21 11:10:40.276012822 +
+++ gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c 2018-11-27
15:29:00.685427859 +
@@ -11,7 +11,7 @@ struct test {
extern struct test s;
-int main1 ()
+__attribute__((noipa)) int main1 ()
{
int i;
We want to test the vectorizer behavior, not depend on how many times the
function has been inlined or versioned.
[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code Status|WAITING |NEW CC||pault at gcc dot gnu.org Known to fail||8.2.0 --- Comment #7 from Dominique d'Humieres --- > Could you please kindly suggest what do I need to do to get this out of > WAITING? ... AFAIK you can do it yourself. WAITING is not a punishment, it just mean that some feedback is needed, most of the time from the reporter, but sometimes from the maintainers. In this case it meant that at looked at the PR, but was unable to confirm it. Now I get a segfault at runtime for the test in comment 5, likely caused by revision r257363 (pr84115).
[Bug tree-optimization/87214] [9 Regression] SPEC CPU2017, CPU2006 520/620, 403 runfails after r263772 with march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Can you still reproduce this? There have been several vectorizer fixes since then?
[Bug c++/88122] [9 Regression] g++ ICE: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88122 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug middle-end/86827] [8/9 Regression] -Warray-bounds produces negative indicies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86827 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Martin, you've changed status to ASSIGNED, but not Assignee. Are you working on this, or is Alex working on it?
