[Bug c++/87322] [8/9 Regression] GCC fails to parse captured lambda of 2nd inner lambda if the captured lambda has "," (having 2 arguments)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87322 --- Comment #5 from Alexandre Oliva --- Created attachment 45614 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45614=edit Candidate patch Besides the cp_unevaluated_operand issue that Jakub mentioned, that causes parm lists to be incompletely tsubsted, we needed to arrange for the tsubsted lambda expr and type to be reused: the expr appears both in a decltype type in the capture variable and in its initializer.
[Bug fortran/84006] [7/8/9 Regression] ICE in storage_size() with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 --- Comment #5 from Thomas Koenig --- However, this also fails: program p type t integer i end type integer rslt class(t), allocatable :: t_alloc(:) allocate (t_alloc(10), source=t(1)) rslt = storage_size(t_alloc) end program p $ cat a.f90 program p type t integer i end type integer rslt class(t), allocatable :: t_alloc(:) allocate (t_alloc(10), source=t(1)) rslt = storage_size(t_alloc) end program p $ gfortran a.f90 a.f90:8:0: 8 | rslt = storage_size(t_alloc) | interner Compiler-Fehler: Speicherzugriffsfehler 0xe24dbf crash_signal ../../trunk/gcc/toplev.c:326 0x9582fe gfc_conv_intrinsic_storage_size ../../trunk/gcc/fortran/trans-intrinsic.c:7683 0x960de1 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../trunk/gcc/fortran/trans-intrinsic.c:10013 0x939b6a gfc_conv_expr(gfc_se*, gfc_expr*) ../../trunk/gcc/fortran/trans-expr.c:8315 0x9437c2 gfc_trans_assignment_1 ../../trunk/gcc/fortran/trans-expr.c:10524 0x8ffcf2 trans_code ../../trunk/gcc/fortran/trans.c:1822 0x92c2fb gfc_generate_function_code(gfc_namespace*) ../../trunk/gcc/fortran/trans-decl.c:6530 0x8b3eae translate_all_program_units ../../trunk/gcc/fortran/parse.c:6134 0x8b3eae gfc_parse_file() ../../trunk/gcc/fortran/parse.c:6337 0x8fd06f gfc_be_parse_file ../../trunk/gcc/fortran/f95-lang.c:204 Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein; inclusive vorverarbeitetem Quellcode, wenn es dienlich ist. Please include the complete backtrace with any bug report.
[Bug c++/87322] [8/9 Regression] GCC fails to parse captured lambda of 2nd inner lambda if the captured lambda has "," (having 2 arguments)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87322 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED CC||aoliva at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #4 from Alexandre Oliva --- Mine
[Bug lto/89207] Symbols missing in map file with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89207 --- Comment #5 from Liviu Ionescu --- Do you suggest to report this to the binutils tracker?
[Bug c++/71302] -Wzero-as-null-pointer-constant: misleading caret location for pointer in function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #1) > I don't think this can be fixed without having locations for constants (or > at least for the arguments of function calls, thus fixing PR43486.) Even though bug 43486 isn't quite fixed yet, David Malcolm still made some major progress on it for GCC 9.
[Bug go/89019] LTO and gccgo cause ICE during free_lang_data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89019 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Wed Feb 6 04:48:35 2019 New Revision: 268572 URL: https://gcc.gnu.org/viewcvs?rev=268572=gcc=rev Log: gcc/go: PR go/89019 * go-gcc.cc (Gcc_backend::placeholder_struct_type): Mark placeholder structs as requiring structural equality. (Gcc_backend::set_placeholder_pointer_type): Propagate the canonical type from the desired pointer type to the placeholder pointer type. gcc/testsuite/: * lib/go-torture.exp: Test compiling with -flto. Modified: trunk/gcc/go/ChangeLog trunk/gcc/go/go-gcc.cc trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/go-torture.exp
[Bug c++/89218] [8/9 Regression] g++ miscompiles functions returning non-void without return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89218 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- C++ says it is undefined even if you dont use the return value. This is different from C. GCC assumes that the path leading to the return without a value will not happen so it uses __builtin_unreachable call there.
[Bug c++/89218] New: [8/9 Regression] g++ miscompiles functions returning non-void without return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89218 Bug ID: 89218 Summary: [8/9 Regression] g++ miscompiles functions returning non-void without return statements Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldv at sourceware dot org Target Milestone: --- $ gcc -xc++ -S -O - <: In function 'int foo()': :1:19: warning: no return statement in function returning non-void [-Wreturn-type] Results to main: .LFB1: .cfi_startproc .cfi_endproc Executing this results to segfault. Miscompilation happens with -Og and higher optimization levels. gcc -xc is fine.
[Bug c++/89217] ICE tree check: expected constructor, have error_mark in split_nonconstant_init_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89217 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-06 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Started with r268321.
[Bug c++/89217] ICE tree check: expected constructor, have error_mark in split_nonconstant_init_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89217 --- Comment #1 from Maxime Coste --- Forgot to mention that this is a regression since gcc 8.2.1 which compiles this code fine. It fails on gcc trunk r268563.
[Bug fortran/56850] Diagnostic of REAL*8 is odd: Accepted with -std=f95, -pedantic prints warning only with -std=gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56850 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- The reason it is called twice is because of the way the matchers work. Attempts are made to match a particular feature or pattern. In each situation if an error is found it is buffered in a list so that if a following matching attempt is successful, the previous error condition can be dropped. My guess is when -Werror is used, the first pass through the matchers returns a solid error and even though the second is also an error one is treated as the first one and acted on to emit the message. The case of the Syntax error is because the matcher returned to the top of the hunt with no good match so, must be 'Syntax' vs the other path giving the warning. I also have been hitting the debugger on this. ne of the paths is via gfc_match_data_decl and the other through gfc_match_prefix. I have gotten as far as confirming, I think, that the code: const bool warning = (wstd != 0) && !inhibit_warnings; const bool error = (estd != 0); is correct. I am still digging on this so stand by for next round depending on how much time I can find.
[Bug c++/89217] New: ICE tree check: expected constructor, have error_mark in split_nonconstant_init_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89217
Bug ID: 89217
Summary: ICE tree check: expected constructor, have error_mark
in split_nonconstant_init_1
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mawww at kakoune dot org
Target Milestone: ---
Created attachment 45613
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45613=edit
Source file that triggers the bug.
Compiling the following source (attached as well):
struct R {};
struct C
{
R* begin() const { return }
R* end() const { return }
R& r;
};
struct S
{
void f1() { f2(); }
template
void f2()
{
for (auto i : C{r}) {}
}
R& r;
};
Leads to an internal compiler error:
test.cc: In instantiation of ‘void S::f2() [with bool = true]’:
test.cc:13:26: required from here
test.cc:18:9: error: cannot convert ‘((S*)this)->S::r’ from type ‘R’ to type
‘R*’
18 | for (auto i : C{r}) {}
| ^~~
test.cc:18:9: internal compiler error: tree check: expected constructor, have
error_mark in split_nonconstant_init_1, at cp/typeck2.c:635
0x7bb804 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../.././gcc/tree.c:9813
0x671510 tree_check(tree_node*, char const*, int, char const*, tree_code)
../.././gcc/tree.h:3176
0x671510 split_nonconstant_init_1
../.././gcc/cp/typeck2.c:635
0xa5fced split_nonconstant_init(tree_node*, tree_node*)
../.././gcc/cp/typeck2.c:760
0x896f15 set_up_extended_ref_temp
../.././gcc/cp/call.c:11297
0x896f15 extend_ref_init_temps_1
../.././gcc/cp/call.c:11434
0xa628a7 store_init_value(tree_node*, tree_node*, vec**, int)
../.././gcc/cp/typeck2.c:833
0x8f07c2 check_initializer
../.././gcc/cp/decl.c:6508
0x91079c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../.././gcc/cp/decl.c:7184
0x9804b1 cp_convert_range_for(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int, bool, unsigned short)
../.././gcc/cp/parser.c:12361
0x9cf457 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17116
0x9cc449 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17212
0x9cbdce tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:16896
0x9cbdce instantiate_decl(tree_node*, bool, bool)
../.././gcc/cp/pt.c:24584
0xa01f3b instantiate_pending_templates(int)
../.././gcc/cp/pt.c:24700
0x9200f0 c_parse_final_cleanups()
../.././gcc/cp/decl2.c:4792
[Bug c/88584] [7/8/9 Regression] GCC thinks that the type is complete despite shadowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584 Joseph S. Myers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|7.5 |9.0 --- Comment #10 from Joseph S. Myers --- Fixed for GCC 9. Since the fix results in code (albeit invalid code) being rejected that has been accepted for a very long time, it seems safest not to backport this regression fix to previous release branches.
[Bug c/13801] [3.4/4.0 Regression] Decls should regain old type at end of scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13801 --- Comment #6 from Joseph S. Myers --- Author: jsm28 Date: Wed Feb 6 01:51:29 2019 New Revision: 268571 URL: https://gcc.gnu.org/viewcvs?rev=268571=gcc=rev Log: Fix type of extern array declared in inner scope with outer initialization shadowed (PR c/88584). As reported in bug 88584, if you have a file-scope array with external linkage, initialized at file scope, and that array is shadowed at block scope, and is declared again with external linkage and an incomplete type in an inner scope, it is wrongly given a complete type in that inner scope when the correct C semantics give it an incomplete type (only the visible declarations contribute to the type in a given scope). In general, issues with the types of external linkage declarations being different in different scopes were addressed by my fixes for bug 13801, for GCC 4.0. In this case, however, the code in pushdecl dealing with giving declarations the right type in each scope works fine, and the type is subsequently modified by complete_array_type called from finish_decl: finish_decl is trying to complete an array type based on an initializer, but that's only correct for the original initialization at file scope, not for such a declaration in an inner scope (it's harmless but unnecessary in the case where the original declaration is still visible in the inner scope). Thus, this patch changes finish_decl to stop this logic applying for such an external declaration in an inner scope. (An erroneous attempt to include an initializer for an extern variable in an inner scope is diagnosed elsewhere.) This is a regression from GCC 3.4, which properly rejected the code in question (quite likely by accident). Bootstrapped with no regressions on x86_64-pc-linux-gnu. gcc/c: PR c/88584 * c-decl.c (finish_decl): Do not complete array types for arrays with external linkage not at file scope. gcc/testsuite: PR c/88584 * gcc.dg/redecl-18.c: New test. Added: trunk/gcc/testsuite/gcc.dg/redecl-18.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog
[Bug c/88584] [7/8/9 Regression] GCC thinks that the type is complete despite shadowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584 --- Comment #9 from Joseph S. Myers --- Author: jsm28 Date: Wed Feb 6 01:51:29 2019 New Revision: 268571 URL: https://gcc.gnu.org/viewcvs?rev=268571=gcc=rev Log: Fix type of extern array declared in inner scope with outer initialization shadowed (PR c/88584). As reported in bug 88584, if you have a file-scope array with external linkage, initialized at file scope, and that array is shadowed at block scope, and is declared again with external linkage and an incomplete type in an inner scope, it is wrongly given a complete type in that inner scope when the correct C semantics give it an incomplete type (only the visible declarations contribute to the type in a given scope). In general, issues with the types of external linkage declarations being different in different scopes were addressed by my fixes for bug 13801, for GCC 4.0. In this case, however, the code in pushdecl dealing with giving declarations the right type in each scope works fine, and the type is subsequently modified by complete_array_type called from finish_decl: finish_decl is trying to complete an array type based on an initializer, but that's only correct for the original initialization at file scope, not for such a declaration in an inner scope (it's harmless but unnecessary in the case where the original declaration is still visible in the inner scope). Thus, this patch changes finish_decl to stop this logic applying for such an external declaration in an inner scope. (An erroneous attempt to include an initializer for an extern variable in an inner scope is diagnosed elsewhere.) This is a regression from GCC 3.4, which properly rejected the code in question (quite likely by accident). Bootstrapped with no regressions on x86_64-pc-linux-gnu. gcc/c: PR c/88584 * c-decl.c (finish_decl): Do not complete array types for arrays with external linkage not at file scope. gcc/testsuite: PR c/88584 * gcc.dg/redecl-18.c: New test. Added: trunk/gcc/testsuite/gcc.dg/redecl-18.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog
[Bug c/89216] Can't make tools for cross compile from linux to windows (MinGW)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89216 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-06 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to RM Beer from comment #0) > I'm trying make a own tools of MinGW. > The line for Configure: > > ./configure --prefix=/opt/MV3/MinGW64 --libexecdir=/opt/MV3/MinGW64/lib > --target=x86_64-w64-mingw32 > --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared > --enable-static --enable-threads=posix --enable-fully-dynamic-string > --enable-libstdcxx-time=yes --with-system-zlib --enable-cloog-backend=isl > --enable-lto --disable-dw2-exceptions --enable-libgomp --disable-multilib > --enable-checking=release > > It's during 'make': > > Checking multilib configuration for libgcc... > Configuring in x86_64-w64-mingw32/libgcc > configure: loading cache ./config.cache > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-w64-mingw32 > checking for --enable-version-specific-runtime-libs... no > checking for a BSD-compatible install... /usr/bin/install -c > checking for gawk... gawk > checking for x86_64-w64-mingw32-ar... x86_64-w64-mingw32-ar > checking for x86_64-w64-mingw32-lipo... x86_64-w64-mingw32-lipo > checking for x86_64-w64-mingw32-nm... > /opt/MV3/SrcMinGW/gcc-8.2.0/host-x86_64-pc-linux-gnu/gcc/nm > checking for x86_64-w64-mingw32-ranlib... x86_64-w64-mingw32-ranlib > checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip > checking whether ln -s works... yes > checking for x86_64-w64-mingw32-gcc... > /opt/MV3/SrcMinGW/gcc-8.2.0/host-x86_64-pc-linux-gnu/gcc/xgcc > -B/opt/MV3/SrcMinGW/gcc-8.2.0/host-x86_64-pc-linux-gnu/gcc/ > -L/opt/MV3/MinGW64/x86_64-w64-mingw32/lib -L/opt/MV3/MinGW64/mingw/lib > -isystem /opt/MV3/MinGW64/x86_64-w64-mingw32/include -isystem > /opt/MV3/MinGW64/mingw/include -B/opt/MV3/MinGW64/x86_64-w64-mingw32/bin/ > -B/opt/MV3/MinGW64/x86_64-w64-mingw32/lib/ -isystem > /opt/MV3/MinGW64/x86_64-w64-mingw32/include -isystem > /opt/MV3/MinGW64/x86_64-w64-mingw32/sys-include > checking for suffix of object files... configure: error: in > `/opt/MV3/SrcMinGW/gcc-8.2.0/x86_64-w64-mingw32/libgcc': It failed in this directory ^^^ so you need to look at the config.log in that directory, not the config.log that you pasted here. Look in that log file for the "cannot compute suffix" error, and it will tell you what's wrong.
[Bug c/89216] New: Can't make tools for cross compile from linux to windows (MinGW)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89216 Bug ID: 89216 Summary: Can't make tools for cross compile from linux to windows (MinGW) Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rmbeer2 at gmail dot com Target Milestone: --- I'm trying make a own tools of MinGW. The line for Configure: ./configure --prefix=/opt/MV3/MinGW64 --libexecdir=/opt/MV3/MinGW64/lib --target=x86_64-w64-mingw32 --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-threads=posix --enable-fully-dynamic-string --enable-libstdcxx-time=yes --with-system-zlib --enable-cloog-backend=isl --enable-lto --disable-dw2-exceptions --enable-libgomp --disable-multilib --enable-checking=release It's during 'make': Checking multilib configuration for libgcc... Configuring in x86_64-w64-mingw32/libgcc configure: loading cache ./config.cache checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-w64-mingw32 checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk checking for x86_64-w64-mingw32-ar... x86_64-w64-mingw32-ar checking for x86_64-w64-mingw32-lipo... x86_64-w64-mingw32-lipo checking for x86_64-w64-mingw32-nm... /opt/MV3/SrcMinGW/gcc-8.2.0/host-x86_64-pc-linux-gnu/gcc/nm checking for x86_64-w64-mingw32-ranlib... x86_64-w64-mingw32-ranlib checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip checking whether ln -s works... yes checking for x86_64-w64-mingw32-gcc... /opt/MV3/SrcMinGW/gcc-8.2.0/host-x86_64-pc-linux-gnu/gcc/xgcc -B/opt/MV3/SrcMinGW/gcc-8.2.0/host-x86_64-pc-linux-gnu/gcc/ -L/opt/MV3/MinGW64/x86_64-w64-mingw32/lib -L/opt/MV3/MinGW64/mingw/lib -isystem /opt/MV3/MinGW64/x86_64-w64-mingw32/include -isystem /opt/MV3/MinGW64/mingw/include -B/opt/MV3/MinGW64/x86_64-w64-mingw32/bin/ -B/opt/MV3/MinGW64/x86_64-w64-mingw32/lib/ -isystem /opt/MV3/MinGW64/x86_64-w64-mingw32/include -isystem /opt/MV3/MinGW64/x86_64-w64-mingw32/sys-include checking for suffix of object files... configure: error: in `/opt/MV3/SrcMinGW/gcc-8.2.0/x86_64-w64-mingw32/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [Makefile:12669: configure-target-libgcc] Error 1 make[1]: se sale del directorio '/opt/MV3/SrcMinGW/gcc-8.2.0' make: *** [Makefile:905: all] Error 2 It's the log of config.log: configure:2300: checking build system type configure:2314: result: x86_64-pc-linux-gnu configure:2361: checking host system type configure:2374: result: x86_64-pc-linux-gnu configure:2394: checking target system type configure:2407: result: x86_64-w64-mingw32 configure:2461: checking for a BSD-compatible install configure:2529: result: /usr/bin/install -c configure:2540: checking whether ln works configure:2562: result: yes configure:2566: checking whether ln -s works configure:2570: result: yes configure:2577: checking for a sed that does not truncate output configure:2641: result: /usr/bin/sed configure:2650: checking for gawk configure:2666: found /usr/bin/gawk configure:2677: result: gawk configure:3170: checking for libatomic support configure:3180: result: yes configure:3208: checking for libitm support configure:3214: result: no configure:3227: checking for libsanitizer support configure:3233: result: no configure:3246: checking for libvtv support configure:3256: result: yes configure:3266: checking for libmpx support configure:3272: result: no configure:3285: checking for libhsail-rt support configure:3291: result: no configure:4004: checking for gcc configure:4020: found /usr/bin/gcc configure:4031: result: gcc configure:4260: checking for C compiler version configure:4269: gcc --version >&5 gcc (GCC) 8.2.1 20181127 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. configure:4280: $? = 0 configure:4269: gcc -v >&5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #2 from Jonathan Wakely --- That changed with P0548R1 (which is not a DR).
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-06 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- We implement the C++14 rules still, where common_type::type is just decay::type.
[Bug libstdc++/89118] Illegal memory access in codecvt::out()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89118 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > I cannot reproduce the valgrind errors with any version of GCC, using > valgrind 3.14.0 > > My guess is that these are false positives from valgrind, because it doesn't > know about the SSE4 tricks in your glibc. In other words, this is not a GCC > bug (and probably not a bug at all). Looks like it was https://bugs.kde.org/show_bug.cgi?id=388862 which is fixed in valgrind 3.14.0
[Bug libstdc++/89118] Illegal memory access in codecvt::out()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89118
--- Comment #3 from Jonathan Wakely ---
The classic "C" locale does not use UTF-8, so the codecvt facet doesn't perform conversions to UTF-8.
If I use:
std::locale::global(std::locale("C.UTF-8"));
then the results are correct. I think that's the correct behaviour.
[Bug libstdc++/89118] Illegal memory access in codecvt::out()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89118 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-06 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- I cannot reproduce the valgrind errors with any version of GCC, using valgrind 3.14.0 My guess is that these are false positives from valgrind, because it doesn't know about the SSE4 tricks in your glibc. In other words, this is not a GCC bug (and probably not a bug at all). I'm not sure what comment 1 is saying, could you please provide a testcase?
[Bug target/78554] Internal Compiler Error in msp430 target with -mlarge, -O{s123}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78554 Jozef Lawrynowicz changed: What|Removed |Added CC||jozef.l at mittosystems dot com --- Comment #1 from Jozef Lawrynowicz --- The test case no longer ICEs on trunk, can someone please close this. Thanks, Jozef
[Bug target/78838] msp430 option -mcode-region=either, -ffunction-sections, and interrupt function attributes cause incorrect section to be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78838 Jozef Lawrynowicz changed: What|Removed |Added CC||jozef.l at mittosystems dot com --- Comment #5 from Jozef Lawrynowicz --- (In reply to Martin Liška from comment #4) > Nick: Can the bug be marked as resolved? Yes, the test case passes on trunk - ISRs are not put in .either.lowtext when compiling with -ffunction-sections and -mcode-region=either.
[Bug c++/89187] [7/8 Regression] ICE in initialize_argument_information, at calls.c:2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89187 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in |initialize_argument_informa |initialize_argument_informa |tion, at calls.c:2023 |tion, at calls.c:2023 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug fortran/84006] [7/8/9 Regression] ICE in storage_size() with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 --- Comment #4 from Dominique d'Humieres --- > Looks valid to me. > > F2018, 16.9.184 STORAGE_SIZE (A [, KIND]) > > 3 Arguments. > A shall be a data object of any type. If it is polymorphic it shall not > be an undefined pointer. If it is unlimited polymorphic or has > any deferred type parameters, it shall not be an unallocated > allocatable variable or a disassociated or undefined pointer. AFAIU class(t), allocatable :: t_alloc(:) rslt = storage_size(t_alloc) t_alloc is unallocated, hence the code is invalid.
[Bug libstdc++/89128] Missing CTAD deduction guides for std::stack and std::queue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89128 Jonathan Wakely changed: What|Removed |Added Version|unknown |8.2.0 Target Milestone|--- |8.3 --- Comment #2 from Jonathan Wakely --- Fixed on trunk so far, but I'll backport it for 8.3
[Bug libstdc++/89128] Missing CTAD deduction guides for std::stack and std::queue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89128 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Tue Feb 5 22:58:22 2019 New Revision: 268566 URL: https://gcc.gnu.org/viewcvs?rev=268566=gcc=rev Log: PR libstdc++/89128 add deduction guides for container adaptors PR libstdc++/89128 * include/bits/stl_queue.h (queue, priority_queue): Add deduction guides. * include/bits/stl_stack.h (stack): Likewise. * testsuite/23_containers/priority_queue/deduction.cc: New test. * testsuite/23_containers/queue/deduction.cc: New test. * testsuite/23_containers/stack/deduction.cc: New test. Added: trunk/libstdc++-v3/testsuite/23_containers/priority_queue/deduction.cc trunk/libstdc++-v3/testsuite/23_containers/queue/deduction.cc trunk/libstdc++-v3/testsuite/23_containers/stack/deduction.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_queue.h trunk/libstdc++-v3/include/bits/stl_stack.h
[Bug target/89213] Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213 Michael Meissner changed: What|Removed |Added Attachment #45611|0 |1 is obsolete|| --- Comment #2 from Michael Meissner --- Created attachment 45612 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45612=edit Revised proposed patch This patch also adds optimizations for V4SI for constant shifts in the 16..31 range on ISA 3.0 and also adds a test.
[Bug c++/89187] [7/8/9 Regression] ICE in initialize_argument_information, at calls.c:2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89187 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Tue Feb 5 22:28:25 2019 New Revision: 268564 URL: https://gcc.gnu.org/viewcvs?rev=268564=gcc=rev Log: PR c++/89187 * optimize.c (maybe_thunk_body): Clear TREE_ADDRESSABLE on PARM_DECLs of the thunk. * lambda.c (maybe_add_lambda_conv_op): Likewise. * g++.dg/opt/pr89187.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr89187.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/lambda.c trunk/gcc/cp/optimize.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/89077] ICE using * as len specifier for character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #12 from Harald Anlauf ---
Further variant:
==> f4.f90 <==
character(1), save :: y = transfer ([('a'(1:1),i=1,1)], 'x')
print *, y
end
generates exactly the same code as f3, although it passes along slightly
different pathes during simplification.
BTW, I noticed that f1 produces an IMHO insane dump-tree, with a call
to _gfortran_internal_pack!
I'd never expected to get such inefficient code in that case.
[Bug sanitizer/89215] New: UBSAN leaks memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89215 Bug ID: 89215 Summary: UBSAN leaks memory Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: mail at milianw dot de 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: --- ``` Direct leak of 8 byte(s) in 1 object(s) allocated from: #0 0x7f668faa7491 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:105 #1 0x7f666e7e5ad3 in d_growable_string_resize /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:3983 #2 0x7f666e7e5ad3 in d_growable_string_append_buffer /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4007 #3 0x7f666e7e5ad3 in d_growable_string_callback_adapter /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4024 #4 0x7f666e7ee822 in d_print_flush /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4222 #5 0x7f666e7ee822 in d_print_callback /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4308 #6 0x7f666e7ee822 in d_demangle_callback /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:6277 #7 0x7f666e7eead0 in d_demangle /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:6299 #8 0x7f666e7eead0 in __cxa_demangle /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:6363 #9 0x7f666dacd4f0 in __sanitizer::DemangleCXXABI(char const*) /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc:59 #10 0x7f666dacd4f0 in __sanitizer::DemangleCXXABI(char const*) /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc:51 #11 0x7f666dacd4f0 in __sanitizer::DemangleSwiftAndCXX(char const*) /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc:100 #12 0x7f666dacd4f0 in __sanitizer::DemangleSwiftAndCXX(char const*) /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc:96 #13 0x7f666dacc64b in __sanitizer::Symbolizer::Demangle(char const*) /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_symbolizer_libcdep.cc:143 #14 0x7f666dab035a in RenderText /build/gcc/src/gcc/libsanitizer/ubsan/ubsan_diag.cc:189 #15 0x7f666dab0e68 in __ubsan::Diag::~Diag() /build/gcc/src/gcc/libsanitizer/ubsan/ubsan_diag.cc:357 #16 0x7f666dab5bb1 in HandleDynamicTypeCacheMiss /build/gcc/src/gcc/libsanitizer/ubsan/ubsan_handlers_cxx.cc:67 #17 0x7f666dab5f14 in __ubsan_handle_dynamic_type_cache_miss /build/gcc/src/gcc/libsanitizer/ubsan/ubsan_handlers_cxx.cc:85 ``` Note that the `` points at my code, for which I got an UBSAN warning before. So it seems like UBSAN itself leaked the memory! Using sanitizers from gcc (GCC) 8.2.1 20181127 from Arch. I can reproduce this with a commercial project I'm working on, so if there's something I should try out I'm all ears.
[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89214 --- Comment #4 from Marek Polacek --- (Your GCC 8 didn't ICE because that was configured with --enable-checking=release.)
[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89214
--- Comment #3 from Marek Polacek ---
We're hitting
1198 /* "If T is a class type and the initializer list has a single
1199 element of type cv U, where U is T or a class derived from T,
1200 the object is initialized from that element." */
1201 if (flag_checking
1202 && cxx_dialect >= cxx11
1203 && BRACE_ENCLOSED_INITIALIZER_P (stripped_init)
1204 && CONSTRUCTOR_NELTS (stripped_init) == 1
1205 && ((CLASS_TYPE_P (type) && !CLASSTYPE_NON_AGGREGATE (type))
1206 || VECTOR_TYPE_P (type)))
1207 {
1208 tree elt = CONSTRUCTOR_ELT (stripped_init, 0)->value;
1209 if (reference_related_p (type, TREE_TYPE (elt)))
1210 /* We should have fixed this in reshape_init. */
1211 gcc_unreachable ();
1212 }
[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89214 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-05 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |7.5 Summary|ICE in digest_init_r, at|[7/8/9 Regression] ICE in |cp/typeck2.c:1211 with |digest_init_r, at |-std=c++17 |cp/typeck2.c:1211 with ||-std=c++17 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Started with r241187 actually, not a recent regression as I feared.
[Bug c++/89214] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89214 --- Comment #1 from Krzesimir Nowak --- For the record, the revision I tested was 268557.
[Bug rtl-optimization/11304] [3.3 Regression] Wrong code production with -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11304 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Tue Feb 5 22:00:29 2019 New Revision: 268562 URL: https://gcc.gnu.org/viewcvs?rev=268562=gcc=rev Log: PR rtl-optimization/11304 * gcc.target/i386/call-1.c (set_eax): Add "eax" clobber. * gcc.target/i386/call-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/call-2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/call-1.c
[Bug c++/89214] New: ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89214
Bug ID: 89214
Summary: ICE in digest_init_r, at cp/typeck2.c:1211 with
-std=c++17
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: qdlacz at gmail dot com
Target Milestone: ---
The following c++17 code fails to build on g++ 9.0.1, but builds fine on g++
(GCC) 8.2.1 20181215 (Red Hat 8.2.1-6).
Details about g++ 9.0.1:
~/gcc-trunk/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/krnowak/gcc-trunk/bin/g++
COLLECT_LTO_WRAPPER=/home/krnowak/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/krnowak/projects/gcc/trunk/build/../src/configure
--prefix=/home/krnowak/gcc-trunk --enable-languages=c,c++ : (reconfigured)
/home/krnowak/projects/gcc/trunk/build/../src/configure
--prefix=/home/krnowak/gcc-trunk --enable-languages=c,c++
Thread model: posix
gcc version 9.0.1 20190205 (experimental) (GCC)
Details about g++ 8.2.1:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.2.1 20181215 (Red Hat 8.2.1-6) (GCC)
I compiled the code with -std=c++17 -Wall -Wextra -Wpedantic. Adding -DOK
causes the compilation to succeed.
struct A
{
template
A (U&&);
};
#ifdef OK
struct B
{
A v;
};
#else
struct BB
{
A v;
};
struct B : BB
{};
#endif
auto
foo () -> B
{
return {{B {{42;
}
Backtrace I'm getting:
./test.cc: In function ‘B foo()’:
./test.cc:25:21: internal compiler error: in digest_init_r, at
cp/typeck2.c:1211
25 | return {{B {{42;
| ^
0x6a3a05 digest_init_r
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/typeck2.c:1211
0x8bf6be convert_like_real
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/call.c:7131
0x8c0bf9 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/call.c:11063
0xa8cfc9 convert_for_initialization(tree_node*, tree_node*, tree_node*, int,
impl_conv_rhs, tree_node*, int, int)
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/typeck.c:9167
0xa8e1b0 check_return_expr(tree_node*, bool*)
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/typeck.c:9741
0xa4734f finish_return_stmt(tree_node*)
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/semantics.c:895
0x9c5a67 cp_parser_jump_statement
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:12854
0x9c5a67 cp_parser_statement
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:11126
0x9c6168 cp_parser_statement_seq_opt
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:11592
0x9c6248 cp_parser_compound_statement
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:11546
0x9de2c5 cp_parser_function_body
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:22562
0x9de2c5 cp_parser_ctor_initializer_opt_and_function_body
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:22599
0x9deb4b cp_parser_function_definition_after_declarator
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:27666
0x9df899 cp_parser_function_definition_from_specifiers_and_declarator
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:27582
0x9df899 cp_parser_init_declarator
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:20205
0x9c2a52 cp_parser_simple_declaration
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:13476
0x9e5880 cp_parser_declaration
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:13173
0x9e5ffc cp_parser_translation_unit
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:4698
0x9e5ffc c_parse_file()
/home/krnowak/projects/gcc/trunk/build/../src/gcc/cp/parser.c:41039
0xaec1bb c_common_parse_file()
/home/krnowak/projects/gcc/
[Bug fortran/84006] [7/8/9 Regression] ICE in storage_size() with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 Thomas Koenig changed: What|Removed |Added Keywords||ice-on-valid-code CC||tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- Looks valid to me. F2018, 16.9.184 STORAGE_SIZE (A [, KIND]) 3 Arguments. A shall be a data object of any type. If it is polymorphic it shall not be an undefined pointer. If it is unlimited polymorphic or has any deferred type parameters, it shall not be an unallocated allocatable variable or a disassociated or undefined pointer.
[Bug c++/89212] [8/9 Regression] ICE in fold_convert_loc at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89212 --- Comment #5 from Marek Polacek --- ...which breaks elsewhere.
[Bug c++/89212] [8/9 Regression] ICE in fold_convert_loc at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89212 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- I think I have a fix.
[Bug rtl-optimization/89154] 5% degradation of CPU2006 473.astar starting with r266305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89154 --- Comment #3 from Pat Haugen --- (In reply to Segher Boessenkool from comment #1) > The new version needs to save r4 because it reuses the reg for storing r7+r8. > And we still don't wrap CR separately, sigh. Yes, and similar for r3 since it's reused in the block. Another thing that could be moved is the r1 adjustment, is that also a component that isn't handled separately?
[Bug c++/89158] [8 Regression] by-value capture of ICE variable isn't an lvalue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89158 Marek Polacek changed: What|Removed |Added Summary|[8/9 Regression] by-value |[8 Regression] by-value |capture of ICE variable |capture of ICE variable |isn't an lvalue?|isn't an lvalue? --- Comment #7 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/89158] [8/9 Regression] by-value capture of ICE variable isn't an lvalue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89158 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Tue Feb 5 21:30:51 2019 New Revision: 268561 URL: https://gcc.gnu.org/viewcvs?rev=268561=gcc=rev Log: PR c++/89158 - by-value capture of constexpr variable broken. * call.c (convert_like_real) : Call mark_exp_read instead of mark_rvalue_use. * g++.dg/cpp0x/lambda/lambda-89158.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-89158.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66089] [7/8/9 Regression] elemental dependency mishandling when derived types are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089 Thomas Koenig changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #31 from Thomas Koenig --- Meant to set it to "NEW" :-)
[Bug target/89213] Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213 Michael Meissner changed: What|Removed |Added Severity|normal |enhancement
[Bug target/89213] Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213 --- Comment #1 from Michael Meissner --- Created attachment 45611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45611=edit Proposed patch to fix the problem This patch adds combiner insns to match attempted vector long long shifts by a constant on ISA 3.0.
[Bug fortran/66089] [7/8/9 Regression] elemental dependency mishandling when derived types are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #30 from Thomas Koenig --- Hm, looks like a bit more complicated. I'll look at some other things first.
[Bug target/89213] Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-05 Ever confirmed|0 |1
[Bug fortran/67679] [7/8/9 Regression] -Wunitialized reports on compiler-generated variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Thomas Koenig --- Fixed on all open branches, closing.
[Bug fortran/67679] [7/8/9 Regression] -Wunitialized reports on compiler-generated variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679 --- Comment #9 from Thomas Koenig --- Author: tkoenig Date: Tue Feb 5 21:23:07 2019 New Revision: 268560 URL: https://gcc.gnu.org/viewcvs?rev=268560=gcc=rev Log: 2019-02-05 Thomas Koenig PR fortran/67679 Backport from trunk * trans-array.c (gfc_array_allocate): For setting the bounds on the new array, add a condition for a not previously allocated variable. 2019-02-05 Thomas Koenig PR fortran/67679 Backport from trunk * gfortran.dg/warn_undefined_1.f90: New test. * gfortran.dg/coarray_lock_7.f90: Fix patterns in test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/warn_undefined_1.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/trans-array.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray_lock_7.f90
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 67679, which changed state. Bug 67679 Summary: [7/8/9 Regression] -Wunitialized reports on compiler-generated variables https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/89077] ICE using * as len specifier for character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #11 from Harald Anlauf ---
I'm currently using the following minimal testcases for further debugging:
==> f1.f90 <==
character(1), parameter :: u = transfer ([('a'(i:i),i=1,1)], 'x')
print *, u
end
==> f2.f90 <==
character(1), save :: v = transfer ([('a'(i:i),i=1,1)], 'x')
print *, v
end
==> f3.f90 <==
character(1), save :: w = transfer ([('a' ,i=1,1)], 'x')
print *, w
end
f1 and f3 work, f2 does ICE.
[Bug fortran/67679] [7/8/9 Regression] -Wunitialized reports on compiler-generated variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679 --- Comment #8 from Thomas Koenig --- Author: tkoenig Date: Tue Feb 5 21:12:41 2019 New Revision: 268559 URL: https://gcc.gnu.org/viewcvs?rev=268559=gcc=rev Log: 2019-02-05 Thomas Koenig PR fortran/67679 Backport from trunk * trans-array.c (gfc_array_allocate): For setting the bounds on the new array, add a condition for a not previously allocated variable. 2019-02-05 Thomas Koenig PR fortran/67679 Backport from trunk * gfortran.dg/warn_undefined_1.f90: New test. * gfortran.dg/coarray_lock_7.f90: Fix patterns in test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/warn_undefined_1.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-array.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gfortran.dg/coarray_lock_7.f90
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 --- Comment #11 from David Malcolm --- Created attachment 45610 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45610=edit Partially reduced testcase This is 975366 bytes (decompressed) and takes 0.3-0.4 seconds to crash r265875's lto1, as compared to the ~15MB and 2.5 minutes it took for the original attachment.
[Bug lto/89207] Symbols missing in map file with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89207 --- Comment #4 from Liviu Ionescu --- The linker version is 2.31.51.20181231 (Arm Embedded GCC release)
[Bug target/89213] New: Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213
Bug ID: 89213
Summary: Optimize V2DI shifts by a constant on power8 & above
systems.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: g...@the-meissners.org
Target Milestone: ---
ISA 2.07 (i.e. -mcpu=power8) and above added support for doing various
operations on V2DI (i.e. vector long long) data types, including shifts.
If you generate code to shift a V2DI type by a constant, the compiler generates
sub-optimal code:
For example:
#include
typedef vector long long vi64_t;
typedef vector unsigned long long vui64_t;
vi64_t
shiftra_test64 (vi64_t a)
{
vui64_t x = {4, 4};
return (vi64_t) vec_vsrad (a, x);
}
Generates:
shiftra_test64:
xxspltib 0,4
xxlor 32,0,0
vextsb2d 0,0
vsrad 2,2,0
blr
when it could generate:
shiftra_test64:
vspltisw 0,4
vsrad 2,2,0
blr
This is true of all 3 shift operations (shift left, logical shift right, and
arithmetic shift right).
[Bug c++/89212] [8/9 Regression] ICE in fold_convert_loc at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89212
--- Comment #3 from Marek Polacek ---
Test without :
template using enable_if_t = int;
template
struct p
{
template>
p(T) { }
p() = default;
};
struct A
{
p i = 1;
void bar();
p j;
};
[Bug libstdc++/58142] _pthread_tsd_cleanup called before destructors are called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142 --- Comment #9 from Jonathan Wakely --- Yes, it's almost certainly not specific to OS X, but will affect other targets without __cxa_thread_atexit or __cxa_thread_atexit_impl in libc (possibly only ones with emulated TLS, I'm not sure).
[Bug libstdc++/58142] _pthread_tsd_cleanup called before destructors are called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142 --- Comment #8 from Ev Drikos --- (In reply to Iain Sandoe from comment #4) > ... > > A quick look says that __cxa_thread_atexit exists in libc from Darwin13, > macOS 10.9 / Mavericks onwards. > ... This is a very thorough analysis that essentially answers my question. Thanks BTW, perhaps this problem wasn't OS X specific only but was perhaps affecting MinGW users as well. The PR/80816 has been reported also with similar symptoms to PR/58142 as explained at: https://sourceforge.net/p/mingw-w64/bugs/727/ Ev. Drikos
[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106 --- Comment #19 from Arthur O'Dwyer --- Awesome! Thank you! :)
[Bug fortran/66089] [7/8/9 Regression] elemental dependency mishandling when derived types are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089 --- Comment #29 from Thomas Koenig --- This also fails: type :: t integer :: c end type t class(t), dimension(:), allocatable :: a, b class(t), dimension(:), allocatable :: c allocate (a(5), source=t(1)) allocate (b(5), source=t(7)) allocate(c(5), source=t(13)) c = plus(c(1), b) print *, c%c if (any(c%c /= 20)) call abort contains elemental function plus(lhs, rhs) class(t), intent(in) :: lhs, rhs type(t) :: plus plus%c = lhs%c + rhs%c end function plus end
[Bug fortran/66089] [7/8/9 Regression] elemental dependency mishandling when derived types are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #28 from Thomas Koenig ---
This patch
Index: dependency.c
===
--- dependency.c(Revision 268432)
+++ dependency.c(Arbeitskopie)
@@ -2100,10 +2100,26 @@ gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gf
while (lref && rref)
{
+ /* Skip any class components, we could be comparing a class and
+a corresponding type. */
+
+ if (lref->type == REF_COMPONENT && CLASS_DATA (lref->u.c.component))
+ {
+ lref = lref->next;
+ continue;
+ }
+
+ if (rref->type == REF_COMPONENT && CLASS_DATA (rref->u.c.component))
+ {
+ rref = rref->next;
+ continue;
+ }
+
/* We're resolving from the same base symbol, so both refs should be
the same type. We traverse the reference chain until we find ranges
that are not equal. */
gcc_assert (lref->type == rref->type);
+
switch (lref->type)
{
case REF_COMPONENT:
gets past the ICE, but now there is a wrong code, the
dependency is not handled correctly:
ig25@linux-p51k:~/Krempel/66089> cat a.f90
type :: t
integer :: c
end type t
type(t), dimension(5) :: a, b
class(t), dimension(:), allocatable :: c
a = t(1)
b = t(7)
allocate(c(5), source=t(13))
c = plus(c(1), b)
print *, c%c
if (any(c%c /= 20)) call abort
contains
elemental function plus(lhs, rhs)
class(t), intent(in) :: lhs, rhs
type(t) :: plus
plus%c = lhs%c + rhs%c
end function plus
end
ig25@linux-p51k:~/Krempel/66089> gfortran a.f90 && ./a.out
20 27 27 27 27
Program aborted. Backtrace:
#0 0x400dd6 in ???
#1 0x400e49 in ???
#2 0x7fbc0563d724 in ???
#3 0x400858 in ???
at ../sysdeps/x86_64/start.S:118
#4 0x in ???
Abgebrochen (Speicherabzug geschrieben)
[Bug fortran/89200] [9 Regression] Erroneous copying of a derived type with a deferred-length character array component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89200 --- Comment #4 from Damian Rouson --- Thanks, Paul!
[Bug c/89211] [8/9 Regression] ICE in int_mode_for_mode, at stor-layout.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89211 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 45609 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45609=edit gcc9-pr89211.patch Untested fix.
[Bug middle-end/89208] unaligned access expanded to memcpy with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208 --- Comment #12 from Andrew Pinski --- (In reply to Bernd Edlinger from comment #11) > (In reply to Andrew Pinski from comment #10) > > This is documented this way: > > https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Standards.html#index- > > ffreestanding > > > > Most of the compiler support routines used by GCC are present in libgcc, but > > there are a few exceptions. GCC requires the freestanding environment > > provide memcpy, memmove, memset and memcmp. Finally, if __builtin_trap is > > used, and the target does not implement the trap pattern, then GCC emits a > > call to abort. > > but this still transforms valid to invalid code, > since as Alexander pointer out, one can call "f(a,a);" which > gets translated to "memcpy(a,a,8);" which is not valid when > src, and dst overlaps, while *a = *a is. That is PR 32667 already.
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 --- Comment #8 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #6) > Note IIRC vec_extract came from the Cell BE C/C++ extension guide. I can't > seem to find that guide any more either :(. Try googling for "Language_Extensions_for_CBEA_2.4.pdf"? "The element that is specified by element is extracted from vector a and returned in scalar d. Depending on the size of the element, only a limited number of the least significant bits of the element index are used. Specifically for 1-, 2-, and 4-byte elements, only four, three, and two of the least significant bits are used, respectively."
[Bug tree-optimization/89209] [9 Regression] ICE in build_ref_for_model, at tree-sra.c:1791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89209 --- Comment #4 from Martin Jambor --- For the record, the following is the most likely fix, but let me think about it a bit more tomorrow before I submit it. diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c index e4851daaa3f..7efd0a62ebb 100644 --- a/gcc/tree-sra.c +++ b/gcc/tree-sra.c @@ -3548,7 +3548,8 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator *gsi) lhs = build_ref_for_model (loc, lhs, 0, racc, gsi, false); gimple_assign_set_lhs (stmt, lhs); } - else if (AGGREGATE_TYPE_P (TREE_TYPE (rhs)) + else if (lacc + && AGGREGATE_TYPE_P (TREE_TYPE (rhs)) && !contains_vce_or_bfcref_p (rhs)) rhs = build_ref_for_model (loc, rhs, 0, lacc, gsi, false);
[Bug c/89211] [8/9 Regression] ICE in int_mode_for_mode, at stor-layout.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89211 --- Comment #2 from Jakub Jelinek --- I bet it is the + if (d && TREE_CODE (d) == FUNCTION_DECL) + if (declarator->kind == cdk_function) + if (DECL_ARGUMENTS (d) == NULL_TREE) + DECL_ARGUMENTS (d) = declarator->u.arg_info->parms; part of that change.
[Bug tree-optimization/89209] [9 Regression] ICE in build_ref_for_model, at tree-sra.c:1791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89209 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #3 from Martin Jambor --- Which I suppose means it is mine.
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532
--- Comment #7 from Bill Schmidt ---
To be absolutely clear, code like
unsigned int get_auto_n_int ( vector unsigned int a, int n) { return
__builtin_vec_extract (a, n); }
is invalid. The second argument must be constant. This was not properly
documented in the ABI appendix, but should have been.
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 --- Comment #6 from Andrew Pinski --- Note IIRC vec_extract came from the Cell BE C/C++ extension guide. I can't seem to find that guide any more either :(. It does matter less these days as the ABI documents this intrinsics now too.
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 --- Comment #5 from Bill Schmidt --- To your second point, the new intrinsic programming reference under development already abandons the language about v[i], so that's covered. The next version of the ABI will drop vector API stuff (chapter 6 and Appendix A) in favor of the new document. I don't think we should change the error message, either. Even though we tolerate an out-of-range constant doesn't mean that we should advertise it on the error message. The present message is useful as is in my view. All present behavior is as I expect, so this is a bad test case. I'd say fix the test and close the issue.
[Bug c++/80864] [7/8 Regression] Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80864 --- Comment #11 from Marek Polacek --- Author: mpolacek Date: Tue Feb 5 18:57:26 2019 New Revision: 268555 URL: https://gcc.gnu.org/viewcvs?rev=268555=gcc=rev Log: PR c++/89083, c++/80864 - ICE with list initialization in template. * decl.c (reshape_init_r): Don't reshape a digested initializer. Return the initializer for COMPOUND_LITERAL_P. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist107.C branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist108.C branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist109.C branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist110.C branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist111.C branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist112.C branches/gcc-8-branch/gcc/testsuite/g++.dg/init/ptrfn4.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/decl.c
[Bug c++/80864] [7 Regression] Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80864 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[7/8 Regression]|[7 Regression] |Brace-initialization of a |Brace-initialization of a |constexpr variable of an|constexpr variable of an |array in a POD triggers ICE |array in a POD triggers ICE |from templates |from templates --- Comment #12 from Marek Polacek --- Fixed for 8 too.
[Bug tree-optimization/89209] [9 Regression] ICE in build_ref_for_model, at tree-sra.c:1791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89209 --- Comment #2 from Jakub Jelinek --- The change before esra due to the above revision is: - _1 = BIT_FIELD_REF ; + _1 = VIEW_CONVERT_EXPR(t.s); where t.s is struct S with two short fields and esra ICEs on it.
[Bug c++/89083] [9 Regression] ICE in reshape_init_r, at cp/decl.c:6172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89083 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Tue Feb 5 18:57:26 2019 New Revision: 268555 URL: https://gcc.gnu.org/viewcvs?rev=268555=gcc=rev Log: PR c++/89083, c++/80864 - ICE with list initialization in template. * decl.c (reshape_init_r): Don't reshape a digested initializer. Return the initializer for COMPOUND_LITERAL_P. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist107.C branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist108.C branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist109.C branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist110.C branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist111.C branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist112.C branches/gcc-8-branch/gcc/testsuite/g++.dg/init/ptrfn4.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/decl.c
[Bug tree-optimization/89209] [9 Regression] ICE in build_ref_for_model, at tree-sra.c:1791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89209 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |9.0
[Bug tree-optimization/89209] [9 Regression] ICE in build_ref_for_model, at tree-sra.c:1791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89209 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-05 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r262946.
[Bug c/89211] [8/9 Regression] ICE in int_mode_for_mode, at stor-layout.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89211 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-05 CC||dmalcolm at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org Target Milestone|--- |8.3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253411.
[Bug lto/89207] Symbols missing in map file with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89207 --- Comment #3 from Andrew Pinski --- This is most likely a bug in binutils rather than GCC.
[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856 --- Comment #21 from Andreas Krebbel --- (In reply to Jakub Jelinek from comment #17) > (In reply to Andreas Krebbel from comment #16) > > I'll commit a patch which just removes the splitter for now. I'll try to > > come up with a nicer testcase. > > All 3 s390 splitters that do this? I've only removed the load and test splitter for now. The other two are only used for access register setters. There is only that one user in Glibc and we have it that way since the very beginning. I will revisit these for GCC >9 but would rather leave them in for now.
[Bug middle-end/89210] [9 Regression] ICE tree check: expected integer_cst, have real_cst in to_wide, at tree.h:5600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89210 --- Comment #1 from Jakub Jelinek --- Created attachment 45608 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45608=edit gcc9-pr89210.patch Untested fix.
[Bug c++/89212] [8/9 Regression] ICE in fold_convert_loc at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89212 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-05 Target Milestone|--- |8.3 Summary|[8 regression] ICE in |[8/9 Regression] ICE in |fold_convert_loc at |fold_convert_loc at |fold-const.c:2552 |fold-const.c:2552 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Not a dup of PR88976.
[Bug c++/89212] New: [8 regression] ICE in fold_convert_loc at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89212
Bug ID: 89212
Summary: [8 regression] ICE in fold_convert_loc at
fold-const.c:2552
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: miklos.puspan at gmail dot com
Target Milestone: ---
compiling the following snippet with -std=c++14, from 8.0 - 8.1 - 8.2 - trunk
causes ICE (between 4.9 - 7.4 it worked fine)
(it conditionally creates a ctor when the class template parameter (member
function pointer non-type) is defaulted to nullptr.)
#include
template
struct p
{
template>
p(T) { }
p() = default;
};
struct A
{
p i = 1;
void bar();
p j;
};
i have seen several simmilar possible duplicates, but with very different
snippets, e.g. #88976 , but i am not sure.
[Bug c++/89212] [8 regression] ICE in fold_convert_loc at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89212 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Looks like it started with r256999.
[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 --- Comment #17 from Martin Sebor --- Just for reference, GCC goes to a lot of trouble to diagnose this sort of thing and issues one of three warnings for this code, depending on which one is enabled. The first two are issued by the wrestrict pass, the last one just before expansion in builtins.c. The last one looks pretty good, so I'll see if I can coax the wrestrict pass into printing something like it or into simply deferring these kinds of warnings to -Wstringop-overflow if it's enabled. By default GCC issues: ‘__builtin_strncpy’ pointer overflow between offset 0 and size [-1, 9223372036854775807] [-Warray-bounds] with -Wno-array-bounds it says: ‘__builtin_strncpy’ accessing 18446744073709551615 or more bytes at offsets 0 and 0 may overlap up to 9223372036854775808 bytes at offset -9223372036854775808 [-Wrestrict] and with -Wno-restrict: ‘__builtin_strncpy’ specified size 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
[Bug testsuite/86404] UNRESOLVED/UNSUPPORTED gcov test results due to Permission error mapping pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86404 --- Comment #4 from Andi Kleen --- Does something like this help? (untested, cut-n-pasted, possibly with other values) iff --git a/gcc/config/i386/gcc-auto-profile b/gcc/config/i386/gcc-auto-profile index 5da5c63cd845..8744b9f091df 100755 --- a/gcc/config/i386/gcc-auto-profile +++ b/gcc/config/i386/gcc-auto-profile @@ -67,4 +67,4 @@ model*:\ 53) E="cpu/event=0x88,umask=0x41/p$FLAGS" ;; echo >&2 "Unknown CPU. Run contrib/gen_autofdo_event.py --all --script to update script." exit 1 ;; esac -exec perf record -e $E -b "$@" +exec perf record -m 256K -e $E -b "$@"
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532
--- Comment #4 from kelvin at gcc dot gnu.org ---
Is this a bug or just "bad documentation"?
64-Bit ELF V2 ABI Specification says vec_extract (v, 3) is equivalent to v[3].
Then it clarifies that vec_extract (arg1, arg2) uses modular arithmetic on arg2
to determine the index position from which to extract the result. If v is
vector int, then vec_extract(vi, 10) equals vec_extract (vi, 10%4) which is
vec_extract (vi, 2).
I am familiar with the error messages reported for the test programs attached
to this problem report. The error messages are misleading and inconsistent
with actual implementation.
The following test reveals some of the current implementation behaviors.
#include
#include "altivec.h"
vector int vi;
extern void clobber ();
#ifdef ILLEGAL_CODE
//__attribute ((noinline))
int doextractbybuiltin (vector int vi, int index) {
/* Builtin expansion of vec_extract requires that index be a
compile-time constant. The generated error message says the selector
must be an integer constant in the range 0..3, which is not accurate. */
return vec_extract (vi, index);
}
#endif
//__attribute ((noinline))
int doextractbybrace (vector int vi, int index) {
return vi [index];
}
int main (int argc, char *argv)
{
vi[0] = 0x00ff00;
vi[1] = 0x01ff01;
vi[2] = 0x02ff02;
vi[3] = 0x03ff03;
printf ("a: 0x%x\n", doextractbybrace (vi, 3)); // outputs 0x3ff03
printf ("b: 0x%x\n", doextractbybrace (vi, 10)); // outputs 0
// (undefined behavior?)
// which, by the way, is not the same as vec_extract (vi, 10)
#ifdef ILLEGAL_CODE
printf ("c: 0x%x\n", doextractbybuiltin (vi, 3));
printf ("d: 0x%x\n", doextractbybuiltin (vi, 10));
#endif
printf ("e: 0x%x\n", vi[3]); // outputs 0x3ff03
printf ("f: 0x%x\n", vi[10]); // outputs 0 (undefined behavior?)
printf ("g: 0x%x\n", vec_extract(vi, 3)); // outputs 0x3ff03
printf ("h: 0x%x\n", vec_extract(vi, 10)); // outputs 0x2ff02
}
What do we want to change, if anything, about the current implementation?
My inclination:
Change the generated error message to require selector to be a constant (but
not specify that it be in the range 0..3
Change the ABI description to not claim that vec_extract (v, i) is equivalent
to v[i] and clarify that i must be a constant.
Do we want to do more?
[Bug c++/70637] Ambiguity error invoking a constructor with double brace initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70637 --- Comment #2 from Arthur O'Dwyer --- I should add, this is a bug in trunk, I don't know why the "Version" is set to GCC 5.2. :)
[Bug c++/70637] Ambiguity error invoking a constructor with double brace initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70637
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- Comment #1 from Arthur O'Dwyer ---
Confirmed. I ran into the same issue with a unit test that was trying to test
whether a given constructor was `explicit`.
// https://godbolt.org/z/STvgby
#include
struct S {
explicit S();
};
struct T {
T();
};
void foo(S) {}
void foo(T) {}
void bar()
{
foo({});
}
GCC says:
: In function 'void bar()':
:16:11: error: call of overloaded 'foo()' is ambiguous
16 | foo({});
| ^
:11:6: note: candidate: 'void foo(S)'
11 | void foo(S) {}
| ^~~
:12:6: note: candidate: 'void foo(T)'
12 | void foo(T) {}
| ^~~
[Bug middle-end/89210] [9 Regression] ICE tree check: expected integer_cst, have real_cst in to_wide, at tree.h:5600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89210 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-05 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug fortran/50410] [7/8/9 Regression] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #33 from Dominique d'Humieres --- > Some of the tests in this PR are fixed by the patch at > > https://gcc.gnu.org/ml/fortran/2019-01/msg00065.html Namely the original test does not ICE after r267820.
[Bug tree-optimization/88074] [7/8/9 Regression] g++ hangs on math expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074 Jakub Jelinek changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #26 from Jakub Jelinek --- Seems to me that the norm2_3.f90 testcase expects infinite precision, I'd say it is broken. Because norm2 ([real(qp) :: 1, 2, huge(3.0_qp)]) needs to be larger than huge(3.0_qp) and as huge(3.0_qp) should be the largest representable finite number in that kind, that norm2 should be really infinity and infinity minus huge(3.0_qp) is still infinity. So, either we acknowledge Fortran wants infinite precision and just set emin/emax temporarily around mpfr/mpc etc. calls in the middle-end temporarily, or we remove the questionable testcase parts.
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835 Zbigniew Jędrzejewski-Szmek changed: What|Removed |Added CC||zbyszek at in dot waw.pl --- Comment #6 from Zbigniew Jędrzejewski-Szmek --- Thanks for looking into the systemd warning. Indeed, the gcc warning was fine, but the code was alread fixed in https://github.com/systemd/systemd/commit/baa162cecd before the gcc warning was reported, and everybody was confused.
[Bug middle-end/89208] unaligned access expanded to memcpy with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208 --- Comment #11 from Bernd Edlinger --- (In reply to Andrew Pinski from comment #10) > This is documented this way: > https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Standards.html#index- > ffreestanding > > Most of the compiler support routines used by GCC are present in libgcc, but > there are a few exceptions. GCC requires the freestanding environment > provide memcpy, memmove, memset and memcmp. Finally, if __builtin_trap is > used, and the target does not implement the trap pattern, then GCC emits a > call to abort. but this still transforms valid to invalid code, since as Alexander pointer out, one can call "f(a,a);" which gets translated to "memcpy(a,a,8);" which is not valid when src, and dst overlaps, while *a = *a is.
[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856 --- Comment #20 from Andreas Krebbel --- Author: krebbel Date: Tue Feb 5 17:19:26 2019 New Revision: 268552 URL: https://gcc.gnu.org/viewcvs?rev=268552=gcc=rev Log: S/390: Remove load and test fp splitter gcc/ChangeLog: 2019-02-05 Andreas Krebbel Backport from mainline 2019-02-05 Andreas Krebbel PR target/88856 * config/s390/s390.md: Remove load and test FP splitter. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/s390/s390.md
[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856 --- Comment #19 from Andreas Krebbel --- Author: krebbel Date: Tue Feb 5 17:17:00 2019 New Revision: 268551 URL: https://gcc.gnu.org/viewcvs?rev=268551=gcc=rev Log: S/390: Remove load and test fp splitter gcc/ChangeLog: 2019-02-05 Andreas Krebbel Backport from mainline 2019-02-05 Andreas Krebbel PR target/88856 * config/s390/s390.md: Remove load and test FP splitter. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/s390/s390.md
[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856 --- Comment #18 from Andreas Krebbel --- Author: krebbel Date: Tue Feb 5 17:14:11 2019 New Revision: 268550 URL: https://gcc.gnu.org/viewcvs?rev=268550=gcc=rev Log: S/390: Remove load and test fp splitter gcc/ChangeLog: 2019-02-05 Andreas Krebbel PR target/88856 * config/s390/s390.md: Remove load and test FP splitter. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.md
[Bug lto/89207] Symbols missing in map file with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89207 --- Comment #2 from Andrew Pinski --- *** Bug 89206 has been marked as a duplicate of this bug. ***
