[Bug c/88525] gcc thinks that C11 program does not declare anything but it does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88525 --- Comment #2 from Anders Granlund --- Thanks for the explanation. That makes sense.
[Bug c/88526] gcc accepts ill-formed program with sizeof (int [*])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88526 --- Comment #2 from Anders Granlund --- Thanks for the clarification. I'll report this bug for clang instead.
[Bug debug/88534] internal compiler error: in tree_add_const_value_attribute, at dwarf2out.c:20246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88534 --- Comment #2 from krux --- The code is based on https://github.com/hanickadot/compile-time-regular-expressions/blob/master/include/ctll/fixed_string.hpp
[Bug c++/86176] Wnull-dereference warning disappears with a call to std::cout on the line after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86176 --- Comment #5 from Martin Sebor --- I think the question in comment #2 is whether it's possible to get the full benefit of the latter kind of warnings without relying on the optimizations being performed that they depend on. There is currently no way to do decouple the two: an inlining pass must run in order for the middle-end warnings that detect bugs across function boundaries to trigger. By "static analysis checkers" I meant all the warnings GCC emits today, mainly either from the front-end (with almost no dependency on optimizations) or from the middle-end (with the benefit of the optimizing passes). I wasn't suggesting to change GCC at this basic level (although suggestions along these lines have been made in the past, in hopes that it would avoid some of the false positives that GCC middle-end warnings are susceptible to).
[Bug debug/88534] internal compiler error: in tree_add_const_value_attribute, at dwarf2out.c:20246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88534 krux changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from krux --- https://godbolt.org/z/G-9Zqh
[Bug debug/88534] New: internal compiler error: in tree_add_const_value_attribute, at dwarf2out.c:20246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88534
Bug ID: 88534
Summary: internal compiler error: in
tree_add_const_value_attribute, at dwarf2out.c:20246
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: hoganmeier at gmail dot com
Target Milestone: ---
#include
#include
#include
template class basic_fixed_string
{
CharT content[N];
public:
using char_type = CharT;
template constexpr basic_fixed_string(const CharT
()[N], std::index_sequence) noexcept: content{input[I]...} { }
constexpr basic_fixed_string(const CharT ()[N]) noexcept:
basic_fixed_string(input, std::make_index_sequence()) { }
constexpr size_t size() const noexcept
{
// string literals are zero terminated
if (content[N-1] == '\0')
return N - 1;
else return N;
}
constexpr CharT operator[](size_t i) const noexcept
{
return content[i];
}
constexpr const CharT * begin() const noexcept
{
return content;
}
constexpr const CharT * end() const noexcept
{
return content + size();
}
};
template basic_fixed_string(const CharT (&)[N]) ->
basic_fixed_string;
template
struct F
{
};
auto foo()
{
F<"test"> f;
}
# g++ -O3 -std=c++2a -g -S
:46:1: internal compiler error: in tree_add_const_value_attribute, at
dwarf2out.c:20246
[Bug c++/86176] Wnull-dereference warning disappears with a call to std::cout on the line after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86176 Eric Gallager changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Jonathan Wakely from comment #3) > No, because GCC is not a static analyser. I thought one of Martin Sebor's talks at this year's Cauldron was about implementing static analysis checkers in the middle-end: https://gcc.gnu.org/wiki/cauldron2018#static-analysis
[Bug rtl-optimization/88253] Inlining of function incorrectly deletes volatile register access when using XOR in avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253 Senthil Kumar Selvaraj changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|segher at gcc dot gnu.org |saaadhu at gcc dot gnu.org --- Comment #8 from Senthil Kumar Selvaraj --- Fixed in trunk, and backported to gcc-8-branch and gcc-7-branch.
[Bug fortran/87945] [9 Regression] ICE in var_element, at fortran/decl.c:281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87945 --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to David Binderman from comment #6) > Not sure this is related, but I tried compiling ./gfortran.dg/pr87945_1.f90 > on an asan build of gcc trunk revision 267200 and got this: > I think it's irrelevant to my patch. Fixing the ICE simply allows one to get to where the sanitizers get upset. When find_inquiry_ref() is used to a inquiry reference, it nullifies a pointer. If it is called twice on the same expression, then this might be why there is a use after free.
[Bug c/88532] variable has initializer but incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Joseph S. Myers --- Already under discussion. *** This bug has been marked as a duplicate of bug 88477 ***
[Bug c/88477] Variable with type completed in initializer not allowed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477 Joseph S. Myers changed: What|Removed |Added CC||sasho648 at gmail dot com --- Comment #5 from Joseph S. Myers --- *** Bug 88532 has been marked as a duplicate of this bug. ***
[Bug c/88526] gcc accepts ill-formed program with sizeof (int [*])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88526 --- Comment #1 from joseph at codesourcery dot com --- Types with [*] are definitely complete types; the standard explicitly says "such arrays are nonetheless complete types". The "'[*]' not in a declaration" warning is a warning, not an error with -pedantic-errors, because the final wording adopted for DR#341 didn't actually disallow such cases (lexically inside a parameter declaration but not directly part of the syntax for a parameter's declarator). But even without that construct, you can still apply sizeof to [*] (see test gcc.dg/vla-5.c for example - cases such as "int foo5(int a, int b[*][*], int c[static sizeof(*b)]);") - it's definitely allowed to do so.
[Bug fortran/87945] [9 Regression] ICE in var_element, at fortran/decl.c:281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87945 --- Comment #7 from Dominique d'Humieres --- > Not sure this is related, but I tried compiling ./gfortran.dg/pr87945_1.f90 > on an asan build of gcc trunk revision 267200 and got this: I think it is a duplicate of pr87881.
[Bug c/88525] gcc thinks that C11 program does not declare anything but it does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88525 --- Comment #1 from joseph at codesourcery dot com --- I'd say the enum member a is declared by a contained struct-declaration, not by the declaration itself. The case of reading the text to allow for a declarator inside a struct-declaration was addressed in response to C90 DR#115 by adding (in C99) the "(other than the parameters of a function or the members of a structure or union)" now present after "declarator". I expect it simply wasn't noticed at the time that much the same issue would apply to tags, and enum members, declared inside of a structure or union. I think the intent stated in that DR response applies here as well: "In the case of an aggregate, the intent was to require a tag or declarator for the aggregate itself.".
[Bug libstdc++/71044] Optimize std::filesystem implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71044 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Mon Dec 17 22:43:31 2018 New Revision: 267222 URL: https://gcc.gnu.org/viewcvs?rev=267222=gcc=rev Log: PR libstdc++/71044 fix off-by-one errors introduced recently The recent changes to append/concat directly from strings (without constructing paths) introduced regressions where one of the components could be omitted from the iteration sequence in the result. PR libstdc++/71044 * src/filesystem/std-path.cc (path::_M_append): Fix off-by-one error that caused a component to be lost from the iteration sequence. (path::_M_concat): Likewise. * testsuite/27_io/filesystem/path/append/source.cc: Test appending long strings. * testsuite/27_io/filesystem/path/concat/strings.cc: Test concatenating long strings. * testsuite/27_io/filesystem/path/construct/string_view.cc: Test construction from long string. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/filesystem/std-path.cc trunk/libstdc++-v3/testsuite/27_io/filesystem/path/append/source.cc trunk/libstdc++-v3/testsuite/27_io/filesystem/path/concat/strings.cc trunk/libstdc++-v3/testsuite/27_io/filesystem/path/construct/string_view.cc
[Bug fortran/87945] [9 Regression] ICE in var_element, at fortran/decl.c:281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87945 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #6 from David Binderman --- Not sure this is related, but I tried compiling ./gfortran.dg/pr87945_1.f90 on an asan build of gcc trunk revision 267200 and got this: ./gfortran.dg/pr87945_1.f90 = ==30485==ERROR: AddressSanitizer: heap-use-after-free on address 0x61703ed8 at pc 0x01323891 bp 0x7fff1aa0dbd0 sp 0x7fff1aa0dbc8 READ of size 8 at 0x61703ed8 thread T0 #0 0x1323890 in simplify_ref_chain ../../trunk/gcc/fortran/expr.c:1943 #1 0x132226c in gfc_simplify_expr(gfc_expr*, int) ../../trunk/gcc/fortran/expr.c:2164 #2 0x144b2a9 in gfc_match_varspec(gfc_expr*, int, bool, bool) ../../trunk/gcc/fortran/primary.c:2287 #3 0x144d207 in match_variable ../../trunk/gcc/fortran/primary.c:3971 $ ~/gcc/results/bin/gfortran -v Using built-in specs. COLLECT_GCC=/home/dcb/gcc/results/bin/gfortran COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.267200.asan/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.267200.asan --with-build-config=bootstrap-asan --disable-multilib --disable-werror --enable-checking=release --enable-languages=c,c++,fortran Thread model: posix gcc version 9.0.0 20181217 (experimental) (GCC) $
[Bug fortran/88533] [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533 --- Comment #4 from Harald Anlauf --- Without CONTIGUOUS, I see -O3 brings gcc-9 to the level of gcc-7 or gcc-8: baseline + -O3 -funroll-loops -fcheck=bounds : 7: 1.57 8: 1.40 9: 1.57 baseline + -O3 -funroll-loops -fcheck=bounds -fno-tree-ch : 7: 1.76 8: 1.55 9: 1.54 So there's something between -O2 and -O3 that helps sometimes.
[Bug c++/88410] [8 Regression] internal compiler error: output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88410 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] internal |[8 Regression] internal |compiler error: |compiler error: |output_operand: invalid |output_operand: invalid |expression as operand |expression as operand --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/87870] ppc64le generates poor code when loading constants into TImode vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87870 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #2 from Peter Bergner --- Fixed.
[Bug target/87870] ppc64le generates poor code when loading constants into TImode vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87870 --- Comment #1 from Peter Bergner --- Author: bergner Date: Mon Dec 17 22:07:11 2018 New Revision: 267221 URL: https://gcc.gnu.org/viewcvs?rev=267221=gcc=rev Log: gcc/ PR target/87870 * config/rs6000/vsx.md (nW): New mode iterator. (vsx_mov_64bit): Use it. Remove redundant GPR 0/-1 alternative. Update length attribute for (, ) alternative. (vsx_mov_32bit): Likewise. gcc/testsuite/ PR target/87870 * gcc.target/powerpc/pr87870.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr87870.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/vsx.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/88533] [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533 --- Comment #3 from Harald Anlauf --- (In reply to Thomas Koenig from comment #2) > Strange. > > I ran the code (with the data) a few times on my Ryzen 7 home > system. > > Here are some timings (run 10 times): [snipped] > Is it possible that the data size of the problem is just at > the edge of cache size, so that (depending on what else happens > on the system) it is possible to either get a lot of cache misses > or not? The matrix has ~ 250k real elements (~ 1MB), and the meta-data is roughly the same size, so everything should easily fit into L3, but probably not into L2. (My machine reports 6 MB (L3?) cache). I do not see significant variations in runtime on my system (but I did usually average over 3 runs and made sure this machine had no load), and certainly not those that you found. I perused the vectorization report from Intel (it does heavy inlining and seems to see the actual arguments) and found that the code can be further optimized by declaring the array dummy arguments to subroutine csc_times_vector as CONTIGUOUS, by adding after line 11: CONTIGUOUS :: a, ia, ja, x, y This strongly reduces the runtime, e.g.: baseline + -funroll-loops + CONTIGUOUS : 7: 0.74 8: 0.77 9: 0.73 (Now *that* is really good! The same level as PGI on my machine.) baseline + -funroll-loops -fcheck=bounds + CONTIGUOUS : 7: 1.50 8: 1.36 9: 1.63 (Note the drop in runtime for gcc-8) baseline + -funroll-loops -fno-tree-ch -fcheck=bounds + CONTIGUOUS : 7: 1.52 8: 1.51 9: 1.52
[Bug c++/88410] [8/9 Regression] internal compiler error: output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88410 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Dec 17 21:54:37 2018 New Revision: 267220 URL: https://gcc.gnu.org/viewcvs?rev=267220=gcc=rev Log: PR c++/88410 * cp-gimplify.c (cp_fold) : For offsetof-like folding, call maybe_constant_value on val to see if it is INTEGER_CST. * g++.dg/cpp0x/pr88410.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr88410.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/52321] poor diagnostic of invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #13 from Jonathan Wakely --- Fixed for gcc 9.
[Bug c++/52321] poor diagnostic of invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 --- Comment #14 from Jonathan Wakely --- Author: redi Date: Mon Dec 17 21:49:58 2018 New Revision: 267219 URL: https://gcc.gnu.org/viewcvs?rev=267219=gcc=rev Log: PR c++/52321 print note for static_cast to/from incomplete type PR c++/52321 * typeck.c (build_static_cast): Print a note when the destination type or the operand is a pointer/reference to incomplete class type. Added: trunk/gcc/testsuite/g++.dg/expr/static_cast8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c
[Bug fortran/88533] [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Strange. I ran the code (with the data) a few times on my Ryzen 7 home system. Here are some timings (run 10 times): $ gfortran -O3 -ftree-vectorize -g csc_test.f90 $ for a in 1 2 3 4 5 6 7 8 9 10; do ./a.out; done CPU time [s]: 1.20 CPU time [s]: 2.52 CPU time [s]: 2.53 CPU time [s]: 2.53 CPU time [s]: 2.53 CPU time [s]: 2.53 CPU time [s]: 2.53 CPU time [s]: 1.18 CPU time [s]: 2.49 CPU time [s]: 2.53 $ gfortran -O3 -ftree-vectorize -fcheck=bounds -g csc_test.f90 $ for a in 1 2 3 4 5 6 7 8 9 10; do ./a.out; done CPU time [s]: 1.28 CPU time [s]: 2.62 CPU time [s]: 2.62 CPU time [s]: 2.60 CPU time [s]: 2.59 CPU time [s]: 2.60 CPU time [s]: 2.60 CPU time [s]: 2.63 CPU time [s]: 2.65 CPU time [s]: 2.57 What strikes me is that I hardly see any slowdown from bounds checking, and that some runs (only a few) are far faster than others. Is it possible that the data size of the problem is just at the edge of cache size, so that (depending on what else happens on the system) it is possible to either get a lot of cache misses or not? (I made sure to always seed the random number generator with the same values).
[Bug c++/88528] [7 Regression] ICE with templated operator bool() in gcc 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528 --- Comment #4 from Pavel Roskin --- The trivial backport of PR c++/85032 fixes both my testcase and the original issue with my code. Please include the fix in gcc 7.5.
[Bug fortran/88533] [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533 --- Comment #1 from Harald Anlauf --- Created attachment 45250 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45250=edit Sparse matrix meta-data
[Bug fortran/88533] New: [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533 Bug ID: 88533 Summary: [9 Regression] Higher performance penalty of array-bounds checking for sparse-matrix vector multiply Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gmx dot de Target Milestone: --- Created attachment 45249 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45249=edit Fortran code I am seeing an increased performance penalty due to array-bounds checking, in particular for sparse-matrix (CSC) vector multiplication. The attached, semi-reduced test case, which only needs the provided meta-data but otherwise uses random elements, should be sufficient for demonstration. I have tested on an i5-8250U and tuned the "outer loop" so that the testcase runs in 1-2 seconds on that machine. For that purpose, I have used some feedback provided to my initial posting on gcc-help, see https://gcc.gnu.org/ml/gcc-help/2018-12/msg00041.html Tested compilers: gcc-7.3.1 20180323 [gcc-7-branch revision 258812] gcc-8.2.1 20181202 gcc-9.0.0 20181214 baseline options: -O2 -ftree-vectorize -g -march=skylake -mfpmath=sse 7: 1.12 8: 1.12 9: 1.12 baseline + -funroll-loops : 7: 1.00 8: 1.00 9: 0.99 baseline + -funroll-loops -fcheck=bounds : 7: 1.56 8: 1.56 9: 1.93 baseline + -funroll-loops -fcheck=bounds -fno-tree-ch : 7: 1.78 8: 1.80 9: 1.83 baseline + -funroll-loops -fno-tree-ch : 7: 1.05 8: 1.09 9: 1.09 Preliminary conclusions: - -funroll-loops is helpful here - -fcheck=bounds is quite expensive with current 9.0 - -fno-tree-ch brings the different versions in line, it benefits 9, but is worse for 7 and 8 - there a no options above that bring 9 to the level of 7 and 8 as long as bounds-checking is desired.
[Bug target/88522] Error: operand size mismatch for `vpgatherqq'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-17 Ever confirmed|0 |1 --- Comment #4 from H.J. Lu --- (In reply to Jakub Jelinek from comment #3) > Yes, it does. So, shall we emit just PTR always, or have a configure check > to detect this and use PTR if assembler with this support isn't detect, > otherwise whatever it requires newly (is that whatever is normally used for > an element of the vector)? I think we should just emit PTR without assembler check.
[Bug c++/88528] [7 Regression] ICE with templated operator bool() in gcc 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528 --- Comment #3 from Pavel Roskin --- I ran "git bisect" between gcc 7.1.0 (affected) and gcc 8.1.0 (unaffected). Following commit fixed the issue: https://github.com/gcc-mirror/gcc/commit/e0ccd4807edc919735b4d86590b5a9def529f91c 2018-04-11 Marek Polacek PR c++/85032 * constexpr.c (potential_constant_expression_1): Consider conversions from classes to literal types potentially constant. The original issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85032 It's a short fix that also adds a similar testcase. The fix can be applied to gcc-7-branch. Let's see if it fixes my testcase and also my "real world" issue.
[Bug c/88532] variable has initializer but incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532 --- Comment #2 from sasho648 at gmail dot com --- Related points from the standard: 6.7.9 p3 states: The type of the entity to be initialized shall be an array of unknown size or a complete object type that is not a variable length array type. However 6.2.5 p22 says that a structure or union type of unknown content is an incomplete type. It is completed, for all declarations of that type, by declaring the same structure or union tag with its defining content later in the same scope. @Andrew Pinski I don't think the sizeof operator introduces a new identifiers scope.
[Bug c++/88521] gcc 9.0 from r266355 miscompile x265 for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #7 from mateuszb at poczta dot onet.pl ---
W dniu 17.12.2018 o 13:52, umesh.kalappa0 at gmail dot com pisze:
> mateuszb,
> Please can you provide us the sample file to investigate more on this .
I'm not assembly expert, but this looks to me as a bug:
$ cat t.c
float fun1(void)
{
return 4.14f;
}
Mateusz@Mateusz-i7 /c/temp
$ gcc -c -O2 -o t354.o t.c
Mateusz@Mateusz-i7 /c/temp
$ objdump -d t354.o
t354.o: file format pe-x86-64
Disassembly of section .text:
:
0: f3 0f 10 05 00 00 00movss 0x0(%rip),%xmm0# 8
7: 00
8: c3 retq
9: 90 nop
a: 90 nop
b: 90 nop
c: 90 nop
d: 90 nop
e: 90 nop
f: 90 nop
Mateusz@Mateusz-i7 /c/temp
$ m64- 355
Mateusz@Mateusz-i7 /c/temp
$ gcc -c -O2 -o t355.o t.c
Mateusz@Mateusz-i7 /c/temp
$ objdump -d t355.o
t355.o: file format pe-x86-64
Disassembly of section .text:
:
0: 8b 05 00 00 00 00 mov0x0(%rip),%eax# 6
6: c3 retq
7: 90 nop
8: 90 nop
9: 90 nop
a: 90 nop
b: 90 nop
c: 90 nop
d: 90 nop
e: 90 nop
f: 90 nop
This patch is really intended to change abi for float return (without struct)?
[Bug c/88532] variable has initializer but incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532 --- Comment #1 from Andrew Pinski --- IIRC types defined in sizeof are not exposed to the current scope.
[Bug c/88532] New: variable has initializer but incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532
Bug ID: 88532
Summary: variable has initializer but incomplete type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sasho648 at gmail dot com
Target Milestone: ---
Consider the following snippet:
main()
{
struct t a = (sizeof(struct t { }), a);
}
It currently fails with variable 'a' has initializer but incomplete type. The
above code works fine with clang.
[Bug rtl-optimization/49884] get_last_value in combine ignores register mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49884 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Segher Boessenkool --- Okay, closing then. Thanks.
[Bug rtl-optimization/49884] get_last_value in combine ignores register mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49884 pmatos at gcc dot gnu.org changed: What|Removed |Added CC||pmatos at gcc dot gnu.org --- Comment #3 from pmatos at gcc dot gnu.org --- I am not working anymore on this company and have no access to the original code. I think we can safely close this bug.
[Bug target/88522] Error: operand size mismatch for `vpgatherqq'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522 --- Comment #3 from Jakub Jelinek --- Yes, it does. So, shall we emit just PTR always, or have a configure check to detect this and use PTR if assembler with this support isn't detect, otherwise whatever it requires newly (is that whatever is normally used for an element of the vector)?
[Bug target/88522] Error: operand size mismatch for `vpgatherqq'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522
--- Comment #2 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #1)
> binutils 2.29 doesn't accept the syntax that 2.32 accepts and vice versa.
> Why has it changed incompatibly?
> Shouldn't new binutils accept both forms?
binutils 2.29 is wrong. Since Intel syntax is rarely used, it was decided
not to accept wrong syntax in binutils 2.32. Does
vpgatherdd xmm0{k1}, PTR [eax+xmm1*1]
vpgatherdd ymm0{k1}, PTR [eax+ymm1*1]
vpgatherdd zmm1{k1}, PTR [eax+zmm0*1]
vpgatherdq xmm0{k1}, PTR [eax+xmm1*1]
vpgatherdq ymm0{k1}, PTR [eax+xmm1*1]
vpgatherdq zmm1{k1}, PTR [eax+ymm0*1]
vpgatherqd xmm0{k1}, PTR [eax+xmm1*1]
vpgatherqd xmm0{k1}, PTR [eax+ymm1*1]
vpgatherqd ymm1{k1}, PTR [eax+zmm0*1]
vpgatherqd ymm2{k1}, PTR [edx+zmm1*1]
vpgatherqq xmm0{k1}, PTR [eax+xmm1*1]
vpgatherqq ymm0{k1}, PTR [eax+ymm1*1]
vpgatherqq zmm2{k1}, PTR [edx+zmm1*1]
work with binutils 2.29?
[Bug target/88522] Error: operand size mismatch for `vpgatherqq'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- binutils 2.29 doesn't accept the syntax that 2.32 accepts and vice versa. Why has it changed incompatibly? Shouldn't new binutils accept both forms?
[Bug target/88514] [9 Regression] FAIL: gcc.target/i386/avx512vl-pr79299-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88514 --- Comment #5 from Jakub Jelinek --- Created attachment 45248 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45248=edit gcc9-pr88513.patch Full untested patch.
[Bug demangler/88480] libiberty's use of VLAs causing stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88480 Tamar Christina changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Tamar Christina --- Sorry, I read the function wrong, it's still an issue, in both cases the demangler uses the stack to allocate, just one it uses a VLA and the other alloca. So there needs to be a third option to do heap allocation or a smarter way to do the demangling that doesn't require these huge lists.
[Bug c++/81239] std::__cxx11::string& visible in gcc warning output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239 --- Comment #7 from Jonathan Wakely --- (In reply to Jonny Grant from comment #5) > (In reply to Jonathan Wakely from comment #4) > > I fixed the std::__cxx11::string case on trunk, the output is now: > > Great! > > I wonder how this looks now with -std=c++14or -std=c++17 Identical. > (not sure why I still saw __cxx11 with both of these with my g++ 8.2.0 Because that namespace has absolutely nothing to do with any -std flag. https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
[Bug c++/81239] std::__cxx11::string& visible in gcc warning output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239 --- Comment #6 from Jonny Grant --- > I imagine you may have found out that this goes away if the "const" is > removed. So it becomes > void test_params(string & mystr1, string & out_str) To add, by this I mean the std:: namespace is visible, providing the parameter is not const
[Bug c++/81239] std::__cxx11::string& visible in gcc warning output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239 --- Comment #5 from Jonny Grant --- (In reply to Jonathan Wakely from comment #4) > I fixed the std::__cxx11::string case on trunk, the output is now: Great! I wonder how this looks now with -std=c++14or -std=c++17 (not sure why I still saw __cxx11 with both of these with my g++ 8.2.0 [..] > The error: line shows the namespace for one parameter and not the other: > > 81239.cc: In function 'int main()': > 81239.cc:16:15: error: too few arguments to function 'void test_params(const > cfoo&, a::b::cfoo&)' >16 | test_params(); > | ^ > 81239.cc:10:6: note: declared here >10 | void test_params(const cfoo&, cfoo&) > | ^~~ I imagine you may have found out that this goes away if the "const" is removed. So it becomes void test_params(string & mystr1, string & out_str)
[Bug c++/88521] gcc 9.0 from r266355 miscompile x265 for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521 --- Comment #6 from mateuszb at poczta dot onet.pl --- W dniu 17.12.2018 o 10:20, rguenth at gcc dot gnu.org pisze: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521 > > --- Comment #2 from Richard Biener --- > Since the patch changes the ABI can it be you have library dependences with > the > old ABI around? I have 2 GCC binaries compiled from sources -- r266354 and r266355. If I compile x265 by old GCC (266354), next delete x265.exe, replace compiler by new GCC (266355) and execute 'make' -- it will be x265.exe that is compiled by old GCC and linked by new GCC (x265o-n.exe). x265n-o.exe is x265 compiled by new GCC and linked by old GCC, x265o.exe -- x265 compiled and linked by old GCC, x265n.exe -- x265 compiled and linked by new GCC. Encoding results (--crf 20 --no-asm): x265o.exe -- encoded 600 frames in 104.10s (5.76 fps), 4187.99 kb/s, Avg QP:25.15 x265n.exe -- encoded 600 frames in 94.14s (6.37 fps), 4670.69 kb/s, Avg QP:43.14 x265o-n.exe -- encoded 600 frames in 58.90s (10.19 fps), 112.00 kb/s, Avg QP:51.00 x265n-o.exe -- encoded 600 frames in 241.80s (2.48 fps), 238059.27 kb/s, Avg QP:0.00 It is quite possible that the problem is in mingw-w64 code that uses ASM or inline ASM and assume old GCC behavior. The movie produced by x265n-o.exe is not lossless but the quality is really OK (almost impossible with wrong compiler). I will try to dig deeper...
[Bug c++/88501] Improve suggested alternative to be closer to typo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88501 --- Comment #6 from Jonathan Wakely --- Or just don't offer suggestions for identifiers that might be cut short by invalid bytes after them.
[Bug target/88469] [7/8/9 regression] AAPCS - Struct with 64-bit bitfield may be passed in wrong registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469 --- Comment #5 from Richard Earnshaw --- Tentative patch posted here. https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01231.html
[Bug demangler/88480] libiberty's use of VLAs causing stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88480 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Tamar Christina --- The VLAs are guarded by CP_DYNAMIC_ARRAYS, so that should just be specified. Though I wonder why it's not.. But in any case, not a libiberty issue after all.
[Bug tree-optimization/88531] Index data types when targeting AVX-512 vectorization with gather/scatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531 --- Comment #3 from Florian Schornbaum --- Thank you for your very quick replies! I'm aware of 88464 (I think this is the recent work you are referring to?), but this had no effect on the index data type issue I was describing. Even if the gathers/scatters do widening themselves, my code example is not vectorized when using int16_t. Probably because no gather/scatter is created by GCC in the first place? As for uint32_t with -m64 (= unsgined int on x86-64, and sadly the problem that we are facing): I'm aware that manually transforming the index array from uint32_t to int64_t is a solution, but one that comes at a cost for us. Looking at clang, they use "vpmovzxdq" when loading the data. Which is the only difference to the int64_t/uint64_t version, which uses a different load. Are there any plans for GCC to make these "unfitting" index data types work with AVX-512 gathers/scatters?
[Bug target/88502] Inline built-in asinh, acosh, atanh for -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88502 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Mon Dec 17 15:46:20 2018 New Revision: 267204 URL: https://gcc.gnu.org/viewcvs?rev=267204=gcc=rev Log: PR target/88502 * internal-fn.def (ACOSH): New. (ASINH): Ditto. (ATANH): Ditto. * optabs.def (acosh_optab): New. (asinh_optab): Ditto. (atanh_optab): Ditto. * config/i386/i386-protos.h (ix86_emit_i387_asinh): New prototype. (ix86_emit_i387_acosh): Ditto. (ix86_emit_i387_atanh): Ditto. * config/i386/i386.c (ix86_emit_i387_asinh): New function. (ix86_emit_i387_acosh): Ditto. (ix86_emit_i387_atanh): Ditto. * config/i386/i386.md (asinhxf2): New expander. (asinh2): Ditto. (acoshxf2): Ditto. (acosh2): Ditto. (atanhxf2): Ditto. (atanh2): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/internal-fn.def trunk/gcc/optabs.def
[Bug c++/88501] Improve suggested alternative to be closer to typo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88501
--- Comment #5 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #4)
[..]
> > "st!ing"
>
> ! is a single byte in UTF-8
Fair enough. Just my idea below.
How about converting those two utf8 bytes, to a marker one byte, to help the
suggestion at least? (although it still needs to get past the identifier
parser stopping at "st"
if(utf8_found)
{
convert_utf8_to_to_char(inbuf, outbuf);
suggest_alternative(outbuf);
}
else
{
suggest_alternative(inbuf);
}
in this case, inbuf would contain "st£ing" and be 7bytes+NUL and outbuf would
contain "str!ing" 6 bytes+NUL, that way, when it was compared, it would
correctly propose an identifier that was also 6 characters long
[Bug c++/52321] poor diagnostic of invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 --- Comment #12 from Jonathan Wakely --- (In reply to Ivan Godard from comment #4) > Define an enum of reasons with "success" first, flop the sense of the test > so that false means coercion was OK (grep to find all calls and put a "!" in > front of each), and return the reason enum instead of bool. The code that is > reason-aware saves the enum and builds a good message; the legacy code that > is not reason-aware treats the enum as a bool and works as before except for > the inverted sense of the test. Maybe half an hour of work. A much simpler "good enough" solution is to just leave build_static_cast_1 alone. In the caller, if the cast fails and one or both types is a pointer/reference to incomplete class, issue a note. It doesn't matter if the reason it failed is the incomplete type, because I don't try to say that, I just say it's incomplete.
[Bug c++/52321] poor diagnostic of invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 Jonathan Wakely changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #11 from Jonathan Wakely --- Patch tested and posted to https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01228.html
[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394 --- Comment #11 from Eric Gallager --- (In reply to Marc Glisse from comment #10) > IMO -Wmaybe-uninitialized should not be enabled by -Wall, whatever the > optimization level (even at -O3), it has too many false positives that are > all but impossible to work around (thus violating the definition of -Wall), > -Wextra is good enough for it. We could keep -Wuninitialized though (it > requires changing the dependency between these 2 warnings). I think I remember at least 1 other bug where we came to this conclusion; I forget its number right now though...
[Bug c++/88507] utf8 not displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507 --- Comment #5 from Jonny Grant --- Created attachment 45247 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45247=edit C example of this UTF8 not displaying
[Bug target/54589] struct offset add should be folded into address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
--- Comment #14 from Jaydeep Chauhan ---
(In reply to Jaydeep Chauhan from comment #10)
I have tried solve this case using define_split or define_insn_and_split
but i am facing is some issue as per below:
1.It is not possible to combine below four instruction
addq$1, %rax
salq$4, %rax
addqp1(%rip), %rax
movl(%rax), %eax
into the this
shlq$4, %rcx
movl16(%rax,%rcx), %eax
using define_split or define_insn_and_split
To add offset "16" and "p1" it is creating problem because "p1" is symbol ref.
2.Also to optimize
addqp1(%rip), %rax
movl(%rax), %eax
into a single instruction it should need to be seperate define_split or
define_insn_and_split.
So it should need to be seperate
3.I have also tried this case with peephole but i am facing same problem with
this also
(define_peephole2
[(parallel [(set (match_operand:DI 0 "register_operand")
(plus:DI (match_dup 0)
(match_operand:DI 1 "const_int_operand")))
(clobber (reg:CC FLAGS_REG))])
(parallel [(set (match_dup 0)
(ashift:DI (match_dup 0)
(match_operand 2 "const_int_operand")))
(clobber (reg:CC FLAGS_REG))])
(parallel [(set (match_dup 0)
(plus:DI (match_operand:DI 4 "nonimmediate_operand")
(mem:DI (match_operand:SDWIM 5 ""
(clobber (reg:CC FLAGS_REG))])]
""
[(parallel [(set (match_dup 0)
(ashift:DI (match_dup 0)(match_dup 2)))
(clobber (reg:CC FLAGS_REG))])
(parallel [(set (match_dup 0)
(plus:DI (match_dup 4)
(mem:DI (match_dup 5
(clobber (reg:CC FLAGS_REG))])]
{
int scale = 8 << INTVAL (operands[1]);
operands[4] = gen_rtx_PLUS (DImode,operands[4], GEN_INT (scale));
})
Please share your comment/suggestion on this.
[Bug c++/88507] utf8 not displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507 --- Comment #4 from Jonny Grant --- Clang has an appropriate message and displays the UTF8 okay. GCC just needs to catch up with clang on this one... #1 with x86-64 clang (trunk) :8:7: error: non-ASCII characters are not allowed outside of literals and identifiers st£ing buf; ^ :8:5: error: unknown type name 'st' st£ing buf; ^ :8:12: error: expected ';' at end of declaration st£ing buf; ^ ; :10:5: error: use of undeclared identifier 'buf' buf = "£" ^ 4 errors generated. Compiler returned: 1
[Bug c++/88507] utf8 not displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507 --- Comment #3 from Jonny Grant --- ICC displays the UTF8 ok: #1 with x86-64 icc 19.0.1 (8): error: unrecognized token st£ing buf; ^ (8): error: identifier "st" is undefined st£ing buf; ^ (8): error: expected a ";" st£ing buf; ^ (10): error: identifier "buf" is undefined buf = "£" ^ (11): error: expected a ";" } ^ compilation aborted for (code 2) Compiler returned: 2
[Bug c++/88507] utf8 not displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507 --- Comment #2 from Jonny Grant --- (In reply to Jonathan Wakely from comment #1) > (In reply to Jonny Grant from comment #0) > > Hello > > > > This is an typo in the word "string", just reporting as perhaps it could > > show £ correctly, as it does on line 10 error. > > But then you couldn't have two separate caret locations pointing to the two > invalid bytes, because it would only occupy a single column. You also assume > the terminal is capable of showing UTF-8 characters. Ok. I would suggest worth displaying the "st£ing" and say ‘st£ing’ was not a valid identifier (Latin letter, underscore, or non-digit character) as per C/C++ specs? Example expected output: $ g++ -Wall -o string string.cpp string.cpp: In function ‘int main()’: string.cpp:8:5: error: ‘st£ing’ is not a valid identifier as contains non-latin characters st£ing buf; ^~ string.cpp:8:5: note: suggested alternative: ‘string’ st£ing buf; ^~ string string.cpp:10:5: error: ‘buf’ was not declared in this scope buf = "£" ^~~
[Bug target/88497] Improve Accumulation in Auto-Vectorized Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497 --- Comment #6 from Bill Schmidt --- Reassociation width should be 4 for this case per the target hook. Kelvin, you can experiment with rs6000_reassociation_width to see if larger values give you what you expect.
[Bug c++/52321] poor diagnostic of invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
--- Comment #10 from Jonathan Wakely ---
Untested patch:
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -7348,8 +7348,19 @@ build_static_cast (tree type, tree oexpr, tsubst_flags_t
complain)
}
if (complain & tf_error)
-error ("invalid static_cast from type %qT to type %qT",
- TREE_TYPE (expr), type);
+{
+ error ("invalid static_cast from type %qT to type %qT",
+TREE_TYPE (expr), type);
+ if ((TYPE_PTR_P (type) || TYPE_REF_P (type))
+ || !COMPLETE_TYPE_P (TREE_TYPE (type)))
+ inform (DECL_SOURCE_LOCATION (TYPE_MAIN_DECL (TREE_TYPE (type))),
+ "class type %qT is incomplete", TREE_TYPE (type));
+ tree expr_type = TREE_TYPE (expr);
+ if ((TYPE_PTR_P (expr_type) || TYPE_REF_P (expr_type))
+ || !COMPLETE_TYPE_P (TREE_TYPE (expr_type)))
+ inform (DECL_SOURCE_LOCATION (TYPE_MAIN_DECL (TREE_TYPE (expr_type))),
+ "class type %qT is incomplete", TREE_TYPE (expr_type));
+}
return error_mark_node;
}
For the original example this produces:
53231.cc: In function 'int main()':
53231.cc:5:31: error: invalid static_cast from type 'foo*' to type 'bar*'
5 | bar* b = static_cast(f);
| ^
53231.cc:1:7: note: class type 'foo' is incomplete
1 | class foo;
| ^~~
And for the example from Bug 88503:
88503.cc: In function 'Derived* foo(Parent*)':
88503.cc:6:39: error: invalid static_cast from type 'Parent*' to type
'Derived*'
6 | return static_cast(p);
| ^
88503.cc:2:7: note: class type 'Derived' is incomplete
2 | class Derived;
| ^~~
88503.cc:1:7: note: class type 'Parent' is incomplete
1 | class Parent;
| ^~
[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Known to work|5.4.1, 7.0 |9.0 Resolution|--- |FIXED Target Milestone|6.5 |9.0 --- Comment #15 from H.J. Lu --- Fixed for GCC 9.
[Bug c++/52321] poor diagnostic of invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 --- Comment #9 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #8) > Clang outputs an extra line saying the type is incomplete (which should > probably be a "note:" but nevermind): Ha, it is a note, but on my terminal the "note:" part is shown as black text on a black background. It only showed up when I pasted it in here!
[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342 --- Comment #14 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Dec 17 13:49:16 2018 New Revision: 267202 URL: https://gcc.gnu.org/viewcvs?rev=267202=gcc=rev Log: DWARF: Don't expand hash table when no insertion is needed dwarf2out_finish performs: 1. save_macinfo_strings 2. hash table traverse of index_string 3. output_macinfo -> output_macinfo_op 4. output_indirect_strings -> hash table traverse of output_index_string find_slot_with_hash has if (insert == INSERT && m_size * 3 <= m_n_elements * 4) expand (); which may expand hash table even if no insertion is neeed and change hash table traverse order. When output_macinfo_op is called, all index strings have been added to hash table by save_macinfo_strings and we shouldn't expand index string hash table. Otherwise find_slot_with_hash will expand hash table when hash table has the right size and hash table traverse of output_index_string will have a different traverse order from index_string. PR debug/79342 * dwarf2out.c (find_AT_string_in_table): Add insert argument defaulting to INSERT and replace INSERT. (find_AT_string): Likewise. (output_macinfo_op): Pass NO_INSERT to find_AT_string. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug c++/52321] poor diagnostic of invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-17 Ever confirmed|0 |1 --- Comment #8 from Jonathan Wakely --- Clang outputs an extra line saying the type is incomplete (which should probably be a "note:" but nevermind): 53231.cc:5:17: error: static_cast from 'foo *' to 'bar *', which are not related by inheritance, is not allowed bar* b = static_cast(f); ^~~~ 53231.cc:1:7: note: 'foo' is incomplete class foo; ^ 1 error generated. When both types are incomplete it says that too: 88503.cc:6:16: error: static_cast from 'Parent *' to 'Derived *', which are not related by inheritance, is not allowed return static_cast(p); ^~~~ 88503.cc:2:7: note: 'Derived' is incomplete class Derived; ^ 88503.cc:1:7: note: 'Parent' is incomplete class Parent; ^ 1 error generated.
[Bug c++/88503] 'invalid static_cast' error message could be more helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88503 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- I've encoutnered this problem myself and would love to see it improved. We have an existing bug with some discussion. *** This bug has been marked as a duplicate of bug 52321 ***
[Bug c++/52321] poor diagnostic of invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 Jonathan Wakely changed: What|Removed |Added CC||petschy at gmail dot com --- Comment #7 from Jonathan Wakely --- *** Bug 88503 has been marked as a duplicate of this bug. ***
[Bug c++/88512] Too much STL in error output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512
--- Comment #7 from Jonathan Wakely ---
I don't think this has anything to do with the std::lib anyway (and certainly
not "the STL" which the example doesn't use at all). Most of the differences
between GCC and Clang can be shown by an example like this with no std::lib
types:
template
struct basic_string {
using iterator = C*;
using const_iterator = const C*;
using size_type = unsigned long;
iterator end();
size_type find(C) const;
void erase(size_type, size_type);
void erase(const_iterator);
void erase(const_iterator, const_iterator);
};
using string = basic_string;
int main()
{
string str;
auto s = str.find(' ');
str.erase(s, str.end());
}
I see two concrete differences.
Firstly, GCC says:
s.cc:19:27: error: no matching function for call to 'erase(long unsigned int&,
basic_string::iterator)'
vs Clang's
s.cc:19:9: error: no matching member function for call to 'erase'
Arguably, Clang's is better. We're showing a member function signature for a
member that doesn't exist, which isn't very helpful. THe original is even
worse, showing the made up member as a qualified name:
s.cc:6:27: error: no matching function for call to
'std::basic_string::erase(std::size_t&,
std::basic_string::iterator)'
(I don't know why that shows std::__cxx11::basic_string::erase(...) and my
reduced example only shows erase(...), but showing it as a member is worse
IMHO).
The fact that the arguments have type size_t& and string::iterator doesn't
imply there's a member function with parameters of those type. Those arguments
could match:
erase(size_t, const_iterator)
erase(int, const_iterator);
or any other number of functions callable with size_t lvalue and iterator
rvalue.
So displaying some made up member function as a means of showing the argument
types is not great. On the other hand, sometimes that first error is all you
need to look at, because it might be obvious from 'erase(size_t&, iterator)'
that you mixed up the arguments. In that case you can ignore the errors showing
the overload resolution results. Clang's brief 'erase' doesn't help with that,
you have to read the later errors.
Secondly, for each overload candidate Clang shows a single note that says why
overload resolution failed (and the declaration of the candidate with a caret
location):
s.cc:9:8: note: candidate function not viable: no known conversion from
'basic_string::iterator' (aka 'char *') to 'basic_string::size_type' (aka
'unsigned long') for 2nd argument; dereference the argument with *
void erase(size_type, size_type);
^
GCC shows a note describing the candidate (with a caret location for the
declaration of that candidate), and a second note saying why overload
resolution failed, and the failure reason as an error (and a second caret
location showing the location of that error):
s.cc:9:8: note: candidate: 'void
basic_string::erase(basic_string::size_type, basic_string::size_type)
[with C = char; basic_string::size_type = long unsigned int]'
9 | void erase(size_type, size_type);
|^
s.cc:9:8: note: conversion of argument 2 would be ill-formed:
s.cc:19:25: error: invalid conversion from 'basic_string::iterator' {aka
'char*'} to 'basic_string::size_type' {aka 'long unsigned int'}
[-fpermissive]
19 | str.erase(s, str.end());
| ~~~^~
| |
| basic_string::iterator {aka char*}
So Clang has a note and a caret location, but GCC has two notes, an error, and
two caret locations. But it's not clear to me that any of GCC's output can be
removed without losing useful information. Clang shows less output, but that
also includes less information.
The only change I'd make that seems definitely an improvement would be to drop
the class name qualification from the made up function signature here:
stl_string.cpp:7:27: error: no matching function for call to
‘std::__cxx11::basic_string::erase(std::size_t&,
std::__cxx11::basic_string::iterator)’
Additionally, we should use the standard typedefs and display
std::__cxx11::basic_string<_CharT, _Traits, _Alloc> as std::string (I think
there's an existing bug for that, though I can't find it).
[Bug c++/81239] std::__cxx11::string& visible in gcc warning output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-06-28 00:00:00 |2018-12-17
--- Comment #4 from Jonathan Wakely ---
I fixed the std::__cxx11::string case on trunk, the output is now:
81239.cc: In function 'int main()':
81239.cc:15:17: error: too few arguments to function 'void test_params(const
string&, std::string&)'
15 | test_params();
| ^
81239.cc:7:6: note: declared here
7 | void test_params(const string & mystr1, string & out_str)
| ^~~
However the problem still exists in general:
namespace a {
inline namespace b {
template class foo { };
using cfoo = foo;
}
}
using namespace a;
void test_params(const cfoo&, cfoo&)
{
}
int main (void)
{
test_params();
}
The error: line shows the namespace for one parameter and not the other:
81239.cc: In function 'int main()':
81239.cc:16:15: error: too few arguments to function 'void test_params(const
cfoo&, a::b::cfoo&)'
16 | test_params();
| ^
81239.cc:10:6: note: declared here
10 | void test_params(const cfoo&, cfoo&)
| ^~~
[Bug target/88514] [9 Regression] FAIL: gcc.target/i386/avx512vl-pr79299-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88514 Jakub Jelinek changed: What|Removed |Added Attachment #45245|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek --- Created attachment 45246 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45246=edit gcc9-pr88514-wip.patch Updated WIP patch.
[Bug c++/88520] improve warning when `struct` is required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88520 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-17 Ever confirmed|0 |1
[Bug rtl-optimization/88253] Inlining of function incorrectly deletes volatile register access when using XOR in avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253 --- Comment #7 from Senthil Kumar Selvaraj --- Author: saaadhu Date: Mon Dec 17 13:26:50 2018 New Revision: 267201 URL: https://gcc.gnu.org/viewcvs?rev=267201=gcc=rev Log: 2018-12-17 Senthil Kumar Selvaraj Backport from trunk 2018-12-17 Senthil Kumar Selvaraj PR rtl-optimization/88253 * combine.c (combine_simplify_rtx): Test for side-effects before substituting by zero. 2018-12-17 Senthil Kumar Selvaraj Backport from trunk 2018-12-17 Senthil Kumar Selvaraj PR rtl-optimization/88253 * gcc.target/avr/pr88253.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/avr/pr88253.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/combine.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/88521] gcc 9.0 from r266355 miscompile x265 for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521 --- Comment #5 from mateuszb at poczta dot onet.pl --- W dniu 17.12.2018 o 13:52, umesh.kalappa0 at gmail dot com pisze: > mateuszb, > Please can you provide us the sample file to investigate more on this . OK, after work I will investigate more and post back the results.
[Bug c++/88512] Too much STL in error output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512 --- Comment #6 from Jonathan Wakely --- (In reply to Jonny Grant from comment #3) > Hi Marc > > I agree to useful to have the option to keep on for regular code. > Perhaps a way just to turn off all expansive output for STL's std namespace? But what about cases where you call a std::lib function template that accepts any arguments, which forwards them to some other std::lib function that gives an error because the args are invalid. If you remove all the context that's in the std::lib then you remove the relevant context. > The easiest would be to remove cxx11 namespace from the messages > "std::__cxx11::basic_string" etc, so at least that doesn't shwo. > > > Updated output I had executed from STL with clear candidate suggestions: > > $ g++ -Wall -o stl_string stl_string.cpp > stl_string.cpp: In function ‘int main()’: > stl_string.cpp:7:27: error: no matching function for call to > ‘std::string::erase(std::size_t&, std::string::iterator)’ > str.erase(s, str.end()); > ^ > candidates are: > std::string& std::string::erase(size_type index = 0, size_type count = > npos) > std::string::iterator std::string::erase(const_iterator first, > const_iterator last) > std::string::iterator std::string::erase(const_iterator position) You've removed all the information that says *why* it didn't match (e.g. no conversion from size_t to const_iterator). That's useful. You don't improve the compiler's diagnostics by optimising for a single example where the verbose info happens to be unnecessary. That info is useful in other cases.
[Bug c++/88521] gcc 9.0 from r266355 miscompile x265 for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521 --- Comment #4 from Umesh Kalappa --- mateuszb, Please can you provide us the sample file to investigate more on this .
[Bug c++/88521] gcc 9.0 from r266355 miscompile x265 for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521 Umesh Kalappa changed: What|Removed |Added CC||umesh.kalappa0 at gmail dot com --- Comment #3 from Umesh Kalappa --- mateuszb, Please can you provide us the sample file to investigate more on this .
[Bug c++/88507] utf8 not displayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507 --- Comment #1 from Jonathan Wakely --- (In reply to Jonny Grant from comment #0) > Hello > > This is an typo in the word "string", just reporting as perhaps it could > show £ correctly, as it does on line 10 error. But then you couldn't have two separate caret locations pointing to the two invalid bytes, because it would only occupy a single column. You also assume the terminal is capable of showing UTF-8 characters. > Perhaps could also show the > stray bytes in hex as well? ie "0xF3C2" I don't see why that would that be an improvement.
[Bug c++/59002] [meta-bug] Access checking in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 Bug 59002 depends on bug 78986, which changed state. Bug 78986 Summary: [7/8/9 Regression] template inner classes are not affected by access specifiers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78986 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/78986] [7/8/9 Regression] template inner classes are not affected by access specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78986 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- Fixed by the patch for PR 86823 *** This bug has been marked as a duplicate of bug 86823 ***
[Bug c++/86823] [7/8 Regression] private member template struct/class is publicly accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86823 Jonathan Wakely changed: What|Removed |Added CC||michele.caini at gmail dot com --- Comment #8 from Jonathan Wakely --- *** Bug 78986 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/88531] Index data types when targeting AVX-512 vectorization with gather/scatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #2 from Jakub Jelinek ---
I think I haven't changed anything on this. AVX2 and AVX512{F,VL} gathers and
scatters only do signed widening themselves. Thus, if the index is uint32_t
and -m64, the only hope would be to perform vectorization conversion of it to
uint64_t/int64_t vector first and then use gathers or scatters with V*DImode
indexes.
[Bug target/88530] [8/9 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||assemble-failure CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/88531] Index data types when targeting AVX-512 vectorization with gather/scatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-17 CC||jakub at gcc dot gnu.org Component|c++ |tree-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- There were recent updates to scatter/gather support for AVX512 and GCC 9. I'm not sure that generic widening is done though.
[Bug c++/88531] New: Index data types when targeting AVX-512 vectorization with gather/scatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531
Bug ID: 88531
Summary: Index data types when targeting AVX-512 vectorization
with gather/scatter
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: florian.schornbaum at siemens dot com
Target Milestone: ---
Hi,
I realized that GCC fails to vectorize simple loops if there are indirect loads
(or stores) and the index used for the indirect access doesn't match a very
small subset of possible integer data types. I'm targeting AVX-512. This is the
MWE (only an indirect load, but a direct store):
==
#include
using loop_t = uint32_t;
using idx_t = uint32_t;
void loop(double * const __restrict__ dst,
double const * const __restrict__ src,
idx_t const * const __restrict__ idx,
loop_t const begin,
loop_t const end)
{
for (loop_t i = begin; i < end; ++i)
{
dst[i] = 42.0 * src[idx[i]];
}
}
==
See: https://godbolt.org/z/Ps-sOv
This only vectorizes if idx_t is int32_t, int64_t, or uint64_t.
My suspicion is this goes back to the gather/scatter instructions of AVX-512
that come in two flavors: with 32 and 64 bit signed integers for the indices.
Unsigned 64 bit probably works (on a 64 bit architecture) because it looks like
it's just treated as a signed 64 bit value, which probably is due to (from the
documentation):
"... The scaled index may require more bits to represent than the address bits
used by the processor (e.g., in 32-bit mode, if the scale is greater than one).
In this case, the most significant bits beyond the number of address bits are
ignored. ..."
Unfortunately, for int16_t, uint16_t, and uint32_t, this does not vectorize.
Although the 32 bit version of gather/scatter could be used -- with proper zero
padding -- for int16_t and uint16_t. Likewise, the 64 bit version could be used
with indices of type uint32_t.
Although the code example only uses idx[i] for loading, it appears to be the
exact same issue when using idx[i] for storing (meaning: when scatter would be
required).
Are there any plans to get this working?
Or did I maybe miss something and this should already work?
Many thanks in advance
Florian
[Bug c++/88504] Inconsistent error message notes when using forward-declared type as value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88504 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-17 Ever confirmed|0 |1
[Bug rtl-optimization/88253] Inlining of function incorrectly deletes volatile register access when using XOR in avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253 --- Comment #6 from Senthil Kumar Selvaraj --- Author: saaadhu Date: Mon Dec 17 12:07:26 2018 New Revision: 267199 URL: https://gcc.gnu.org/viewcvs?rev=267199=gcc=rev Log: 2018-12-17 Senthil Kumar Selvaraj Backport from trunk 2018-12-17 Senthil Kumar Selvaraj PR rtl-optimization/88253 * combine.c (combine_simplify_rtx): Test for side-effects before substituting by zero. 2018-12-17 Senthil Kumar Selvaraj Backport from trunk 2018-12-17 Senthil Kumar Selvaraj PR rtl-optimization/88253 * gcc.target/avr/pr88253.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/avr/pr88253.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/combine.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/88501] Improve suggested alternative to be closer to typo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88501 --- Comment #4 from Jonathan Wakely --- (In reply to Jonny Grant from comment #3) > I wonder, for typos if a simple byte compare would be enough? Vary each char > by 1 letter, or length. This starts to get complicated I know.. The matching code is already significantly smarter than that. The problem is that "string" is not in the set of candidates being matched against, so a simple byte compare isn't going to help find it any better than the current code. > "st!ing" ! is a single byte in UTF-8
[Bug target/88530] [8/9 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-17 Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/88530] New: [8/9 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530 Bug ID: 88530 Summary: [8/9 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to. Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tnfchris at gcc dot gnu.org Target Milestone: --- Target: aarch64*-*-* With GCC 8 we retro-actively split some command-line options and took care to not pass them along to assemblers if the user didn't specify them. Unfortunately -mtune=nativeand -mcpu=native will enable all feature bits supported. We then pass these on to the assembler even though we don't need to since the old option which is a grouping of the new options can be used instead. This breaks the compiler's support for older assemblers when `native` is used, requiring a relatively new binutils even for older compilers.
[Bug rtl-optimization/88253] Inlining of function incorrectly deletes volatile register access when using XOR in avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253 --- Comment #5 from Senthil Kumar Selvaraj --- Author: saaadhu Date: Mon Dec 17 10:50:54 2018 New Revision: 267198 URL: https://gcc.gnu.org/viewcvs?rev=267198=gcc=rev Log: Fix PR 88253 gcc/ChangeLog: PR rtl-optimization/88253 * combine.c (combine_simplify_rtx): Test for side-effects before substituting by zero. gcc/testsuite/ChangeLog: PR rtl-optimization/88253 * gcc.target/avr/pr88253.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/pr88253.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug c/81665] Please introduce flags attribute for enums which will mimic one from C#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81665
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #5 from Harald van Dijk ---
> It should work in similar way as a [Flags] attribute in C#.
Bitwise operations are allowed on enum types in C# and produce values of that
type regardless of attributes. The [Flags] attribute's effect is pretty much
limited to changing how converting enum values to strings behaves. This is not
at all what you're asking __attribute__((flags)) to do. I suggest editing the
title to not recommend mimicking C#'s attribute.
One thing that I would like to ask to consider is the debugging experience.
Please make sure that no function body is ever emitted (which implies that just
like with standard built-in operators, it's not possible to take the operator's
address). For a custom overloaded operator, it will be, and it's even possible
to break on it or step through it when debugging, but this probably isn't
useful here. Please also make sure that enough information is available to the
debugger so treat the type the same way as the compiler: in gdb, given the code
enum E { a = 1, b = 2, c = 4 };
p b|c will produce $n = 6, whereas p (E)(b|c) will produce $n = (b | c). If the
flags attribute is added, p b|c should probably also produce $n = (b | c). This
is something you cannot and perhaps should not get with custom overloaded
operators (you can write p operator|(b,c) instead), but should be safe and
reasonable here.
[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 #14 from Jonny Grant --- Wondering, if there is an implicitly created copy-constructor, can the warning clarify that? Perhaps there is some attribute or flag set so later code can know it was implicitly created? eg output could be: $ g++ -O2 -Werror=uninitialized -o header header.cpp header.cpp: In function ‘void test(info_t)’: header.cpp:10:10: error: ‘copy.info::registered’ is used uninitialized in implicitly created copy-constructor function for struct info::info() [-Werror=uninitialized] temp = copy; ~^~ cc1plus: some warnings being treated as errors
[Bug tree-optimization/88464] AVX-512 vectorization of masked scatter failing with "not suitable for scatter store"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88464 --- Comment #16 from Moritz Kreutzer --- I can confirm the fix from my side. Thanks again!
[Bug c++/88528] [7 Regression] ICE with templated operator bool() in gcc 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||6.5.0, 8.1.0 Keywords||ice-on-valid-code Last reconfirmed||2018-12-17 Ever confirmed|0 |1 Summary|ICE with templated operator |[7 Regression] ICE with |bool() in gcc 7 |templated operator bool() ||in gcc 7 Target Milestone|--- |7.5 Known to fail||7.1.0, 7.4.0 --- Comment #2 from Richard Biener --- Confirmed.
[Bug c++/88521] gcc 9.0 from r266355 miscompile x265 for mingw-w64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521 --- Comment #2 from Richard Biener --- Since the patch changes the ABI can it be you have library dependences with the old ABI around?
[Bug tree-optimization/88519] [9 Regression] internal compiler error: in expand_widen_pattern_expr, at optabs.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88519 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Component|rtl-optimization|tree-optimization Target Milestone|--- |9.0 Summary|internal compiler error: in |[9 Regression] internal |expand_widen_pattern_expr, |compiler error: in |at optabs.c:278 |expand_widen_pattern_expr, ||at optabs.c:278
[Bug middle-end/88518] Function call defeats -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88518 Richard Biener changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Richard Biener --- Not so easy.
[Bug c++/88517] Virtual-base class class constructor with for-loop with initializer list referencing local variable not executed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88517
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-12-17
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Confirmed. What happens is that
const int * __for_begin;
<::begin ((struct
initializer_list *) __for_range)) >;
const int * __for_end;
<::end ((struct initializer_list
*) __for_range)) >;
while (1)
{
if (__for_begin == __for_end) goto ;
this is true initially
int i = (int) *__for_begin;
<::operator<< ((struct basic_ostream *)
std::basic_ostream::operator<< (, i), endl) >;
<>;
}
but somehow not when cut that directly into main().
[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394 --- Comment #10 from Marc Glisse --- IMO -Wmaybe-uninitialized should not be enabled by -Wall, whatever the optimization level (even at -O3), it has too many false positives that are all but impossible to work around (thus violating the definition of -Wall), -Wextra is good enough for it. We could keep -Wuninitialized though (it requires changing the dependency between these 2 warnings). It is possible that even -Wextra should require at least -O1 (considering -Og as -O0.5) to enable it...
[Bug c++/88529] New: G++ clears the return register on x86_64 when returning an empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88529
Bug ID: 88529
Summary: G++ clears the return register on x86_64 when
returning an empty class
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rohan at rohanlean dot de
Target Milestone: ---
Target: x86_64
The following code causes G++ to emit an "xorl %eax, %eax" on x86_64. I believe
the Itanium ABI does not require it, so this is a missed optimisation.
class A{};
A f() { return {}; }
