[Bug other/63509] Misleading error message when building gcc without C++ compiler installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63509 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-02 CC||wilson at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Jim Wilson --- Confirmed. Except that current sources now say configure: error: uint64_t or int64_t not found We have a configure check to verify that the C compiler works. We are missing one for the C++ compiler. In configure we have $as_echo_n "checking whether the C compiler works... " >&6; } and there is no equivalent for the C++ compiler.
[Bug c++/90307] -Wuninitialized only at -O1, not at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90307
--- Comment #1 from Andrew Pinski ---
SRA decided to do this:
[t88.c:27:24] x.u.internal = [t88.c:27:30] [t88.c:27:28] MEM[(const struct
sstring &)[t88.c:49:17] ].u.internal;
[t88.c:27:24] x$u$external$str_24 = [t88.c:27:24] MEM[(union contents *)];
[t88.c:27:24] x$u$external$size_64 = [t88.c:27:24] MEM[(union contents *) +
8B];
[t88.c:25:31] MEM[(struct &)[t88.c:51:12] ] ={v} {CLOBBER};
[t88.c:27:24] [t88.c:27:24] MEM[(union contents *)] = x$u$external$str_24;
[t88.c:27:24] [t88.c:27:24] MEM[(union contents *) + 8B] =
x$u$external$size_64;
[t88.c:27:24] [t88.c:27:24] MEM[(union contents *) + 15B] = 5;
[Bug c++/90307] New: -Wuninitialized only at -O1, not at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90307 Bug ID: 90307 Summary: -Wuninitialized only at -O1, not at -O2 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rafael at espindo dot la CC: mjambor at suse dot cz Target Milestone: --- Created attachment 46271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46271=edit testcase Starting at 00ee3e3e4fea0457ef84bada636ae26ffcc95fff -Wall -O1 on the attached testcase will print distributed_test.ii:27:24: warning: ‘*((void*)& s +8)’ is used uninitialized in this function [-Wuninitialized] But the warning goes away at -O2 an higher. Should this perhaps be in -Wmaybe-uninitialized?
[Bug pch/90306] New: ICE when using precompiled headers with -MD and -fpch-deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90306 Bug ID: 90306 Summary: ICE when using precompiled headers with -MD and -fpch-deps Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- I've seen this issue both with GCC 8.1.0 and the latest GCC 9.0.1 20190430 pre-release, on GNU/Linux x86_64 with binutils 2.30 and 2.32 (not that I suppose that matters here). Some info on the mailing list: https://gcc.gnu.org/ml/gcc/2019-04/msg00289.html and into May: https://gcc.gnu.org/ml/gcc/2019-05/msg1.html I don't have a reproducible case since it doesn't happen every time for me. But I can reproduce it locally on certain systems so I'm happy to participate in some directed debugging. Here's what I've discovered so far: IT WORKS FINE: If I build my PCH file like this: g++ -o obj/foo_pch.h.gch -x c++-header foo_pch.h And I build my source code like this: g++ -Winvalid-pch -iquote"obj" --include=foo_pch.h -o obj/foo.cpp.o foo.cpp I GET ICEs: _Sometimes_ get ICE errors if I build as below on _some_ systems. It appears possibly related to the speed of the system; it never fails on my local system (which is very beefy) but often fails on our (older, less beefy) build servers. First, when building the PCH file I add the -MD flag: g++ -MD -o obj/foo_pch.h.gch -x c++-header foo_pch.h Second, when compiling my source code I add the -fpch-deps flag: g++ -fpch-deps -Winvalid-pch -iquote"obj" --include=foo_pch.h -o obj/foo.cpp.o foo.cpp Then I get ICE failures (this is from GCC 9.0.1-20190430): : internal compiler error: Segmentation fault 0x9d4fdb crash_signal /work/src/cc/gcc-9.0.1-RC-20190430/gcc/toplev.c:326 0x12f6144 apply_vpath /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:127 0x12f648e deps_add_dep(deps*, char const*) /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:258 0x12f699c deps_restore(deps*, _IO_FILE*, char const*) /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:432 0x12f7cca cpp_read_state(cpp_reader*, char const*, _IO_FILE*, save_macro_data*) /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/pch.c:859 0x59971c c_common_read_pch(cpp_reader*, char const*, int, char const*) /work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-pch.c:365 0x12e9d3c should_stack_file /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:814 0x12e9f33 _cpp_stack_file /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:900 0x12ea0ee _cpp_stack_include /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:1063 0x12ea5a6 cpp_push_include(cpp_reader*, char const*) /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:1498 0x597015 push_command_line_include /work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1502 0x59741b c_finish_options /work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1471 0x598dbc c_common_parse_file() /work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1150 Please submit a full bug report, Debugging with GDB and follow-fork, I can see this backtrace: (gdb) set follow-fork child (gdb) run Starting program: /tools/x86_64-linux/cc/unknown/bin/x86_64-unknown-linux-gnu-g++ ... -fpch-deps -Winvalid-pch -iquote/src/dir --include=foo_pch.h -o foo.cpp.o -c foo.cpp [Attaching after process 310 vfork to child process 317] [New inferior 2 (process 317)] [Detaching vfork parent process 310 after child exec] [Inferior 1 (process 310) detached] process 317 is executing new program: /tools/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/9.0.1/cc1plus Thread 2.1 "cc1plus" received signal SIGSEGV, Segmentation fault. [Switching to process 317] apply_vpath (d=d@entry=0x0, t=t@entry=0x20a4530 "/src/foo_pch.h") at /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:127 127 /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c: No such file or directory. (gdb) bt #0 apply_vpath (d=d@entry=0x0, t=t@entry=0x20a4530 "/sec/foo_pch.h") at /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:127 #1 0x012f648f in deps_add_dep (d=d@entry=0x0, t=t@entry=0x20a4530 "/src/foo_pch.h") at /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:258 #2 0x012f699d in deps_restore (deps=0x0, fd=fd@entry=0x20a1420, self=self@entry=0x2039780 "/src/obj/foo_pch.h.gch") at /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:432 #3 0x012f7ccb in cpp_read_state (r=r@entry=0x2027b70, name=name@entry=0x2039780 "/src/obj/foo_pch.h.gch", f=f@entry=0x20a1420, data=) at /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/pch.c:859 #4 0x0059971d in c_common_read_pch (pfile=0x2027b70, name=0x2039780 "/src/obj/foo_pch.h.gch", fd=, orig_name=)
[Bug fortran/90133] [7/8/9/10 Regression] Linker error from accessing event_type via use association outside associate/block scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90133 --- Comment #3 from Dominique d'Humieres --- > So this is fixed on GCC 6? But not Trunk? (Or more recent releases?) A regression is something working at revision n and broken at revision n+1. Here it seems that a GCC7 revision broke the gfortran and has been backported to GCC6.
[Bug fortran/90133] [7/8/9/10 Regression] Linker error from accessing event_type via use association outside associate/block scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90133 --- Comment #2 from Zaak --- Hi Dominique, So this is fixed on GCC 6? But not Trunk? (Or more recent releases?)
[Bug fortran/90305] ASSOCIATE with a substring of a deferred-length character selector yields garbage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90305 --- Comment #1 from Damian Rouson --- The code gives the expected output "f" with GCC 9.
[Bug target/87833] [9/10 Regression] Intel MIC (emulated) offloading: "relocation [...] can not be used when making a shared object; recompile with -fPIC"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87833 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from H.J. Lu --- Do you have a testcase?
[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968 Thomas Koenig changed: What|Removed |Added Status|REOPENED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #8 from Thomas Koenig --- Index: interface.c === --- interface.c (Revision 270622) +++ interface.c (Arbeitskopie) @@ -2989,7 +2989,8 @@ polymorphic formal arguments. */ if (UNLIMITED_POLY (f->sym) && a->expr->ts.type != BT_DERIVED - && a->expr->ts.type != BT_CLASS) + && a->expr->ts.type != BT_CLASS + && a->expr->ts.type != BT_ASSUMED) gfc_find_vtab (>expr->ts); if (a->expr->expr_type == EXPR_NULL seems to do the trick.
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 --- Comment #9 from Nathan Sidwell --- Thanks for the context. Clang intends to, but does not yet, implement DR2061. which is why you're seeing the different behaviour there, at least. Continuig discussion on the C++ Core list,
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #10 from Tom Tromey --- I have been looking at this again recently, for Ada, and now I think perhaps the approach that GCC takes should be preferred. At first I was thinking maybe the compiler could linearize the members of the emitted structure, but I tried modifying the example in comment #2 to add multiple variants with different discriminators: package Pck is type Rec (I : Integer; J: Integer) is record case I is when Positive => C : Character; case J is when 0 => null; when others => N : Natural; end case; when others => S : String (1 .. 10); end case; end record; R : Rec (1, 2); end Pck; ... this seems to work and I think means that nested variant parts is indeed a sensible way to go.
[Bug fortran/90305] New: ASSOCIATE with a substring of a deferred-length character selector yields garbage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90305 Bug ID: 90305 Summary: ASSOCIATE with a substring of a deferred-length character selector yields garbage Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at sourceryinstitute dot org Target Milestone: --- An ASSOCIATE construct with a substring of a deferred-length character selector yields garbage with gfortran 8.3.0: $ cat associate.f90 character(len=:), allocatable :: string string = "f" associate( substring => string(:) ) print*,substring end associate end $ gfortran associate.f90 $ ./a.out P $ gfortran --version GNU Fortran (GCC) 8.3.0
[Bug c++/90304] -O3 vectorization gets worse when code is moved into main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90304 --- Comment #1 from Andrew Pinski --- There is another bug that is similar; the issue is restrict related.
[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968 --- Comment #7 from Thomas Koenig --- Hmm... some analysis. This is a strange piece of code... interface subroutine test_lib (a, len) bind(C, name="test") use iso_c_binding, only: c_size_t !GCC$ ATTRIBUTES NO_ARG_CHECK :: a type(*), dimension(*) :: a OK, so type(*) in a C binding just means a void * pointer on the C side. But that does not matter: If the BIND(C) is removed, the assembly failure still happens. The failure does _not_ happen with interface test procedure :: test_32 !procedure :: test_array end interface test And if we replace the call to the generic "test" with a call to the non-generic test_32, all is well. With the following diff --- pr1.f90 2019-05-01 22:05:46.317369154 +0200 +++ pr2.f90 2019-05-01 22:05:42.829339353 +0200 @@ -36,5 +36,5 @@ use testmod type(*), dimension(*) :: a integer(c_int32_t), value :: len -call test (a, len) +call test_32 (a, len) end subroutine between two files (pr1 calls the generic function, pr2 the non-generic one) we get the following diff in the dumps: --- pr1.dump2019-05-01 22:06:07.257548088 +0200 +++ pr2.dump2019-05-01 22:06:14.577610648 +0200 @@ -137,24 +137,10 @@ symtree: '__iso_c_binding'|| symbol: '__iso_c_binding' type spec : (UNKNOWN 0) attributes: (MODULE INTRINSIC) - symtree: '__vtab_TYPE(*)_0_'|| symbol: '__vtab_TYPE(*)_0_' -type spec : (DERIVED __vtype_TYPE(*)_0_) -attributes: (VARIABLE PUBLIC IMPLICIT-SAVE TARGET) -value: __vtype_TYPE(*)_0_(49723565 , 8_8 , NULL() , NULL() , __copy_TYPE(*)_0_:__copy_TYPE(*)_0_ , NULL()) symtree: '__vtab__STAR'|| symbol: '__vtab__STAR' type spec : (DERIVED __vtype__STAR) attributes: (VARIABLE IMPLICIT-SAVE TARGET USE-ASSOC(testmod)) value: __vtype__STAR(0 , () , () , () , () , NULL() , ()) - symtree: '__vtype_TYPE(*)_0_'|| symbol: '__vtype_TYPE(*)_0_' -type spec : (UNKNOWN 0) -attributes: (DERIVED PUBLIC ) -components: -(_hash (INTEGER 4) () PRIVATE) -(_size (INTEGER 8) () PRIVATE) -(_extends (VOID 0) POINTER () PRIVATE) -(_def_init (VOID 0) POINTER () PRIVATE) -(_copy (UNKNOWN 0) PPC () PRIVATE) -(_final (UNKNOWN 0) PPC () PRIVATE) symtree: '__vtype__STAR'|| symbol: '__vtype__STAR' type spec : (UNKNOWN 0) attributes: (DERIVED USE-ASSOC(testmod)) @@ -212,23 +198,5 @@ code: CALL test_32 ((test_32_:a(FULL)) (test_32_:len)) -CONTAINS - - Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) - procedure name = __copy_TYPE(*)_0_ -symtree: '__copy_TYPE(*)_0_'|| symbol: '__copy_TYPE(*)_0_' - type spec : (UNKNOWN 0) - attributes: (PROCEDURE SUBROUTINE ELEMENTAL PURE) - Formal arglist: src dst -symtree: 'dst' || symbol: 'dst' - type spec : (TYPE(*)) - attributes: (VARIABLE DUMMY(INOUT)) -symtree: 'src' || symbol: 'src' - type spec : (TYPE(*)) - attributes: (VARIABLE DUMMY(IN)) - -code: -ASSIGN __copy_TYPE(*)_0_:dst __copy_TYPE(*)_0_:src - so there is indeed a bogus vtab being generated somewhere and somehow.
[Bug c++/90304] New: -O3 vectorization gets worse when code is moved into main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90304 Bug ID: 90304 Summary: -O3 vectorization gets worse when code is moved into main() Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: john.boyer at tutanota dot com Target Milestone: --- The following code will get much better assembly if it is not in main(): for (int i = 0; i < 1024; ++i) result[i] = first[i] * second[i]; It simply multiplies two integers and stores the result. When this code is moved into main(), it appears part of the loop no longer gets vectorized and uses imul instead. This does not happen when the loop is moved to it's own function. The two left panes contain the assembly of both versions of this code: https://godbolt.org/z/pNdbE5 NOTE: the noinline attribute has no effect on this issue, it is simply to make the assembly more readable.
[Bug c++/90303] [9/10 Regression] ICE in hash_odr_name with fastcall attribute starting with r267359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90303 Jakub Jelinek changed: What|Removed |Added Component|tree-optimization |c++ --- Comment #1 from Jakub Jelinek --- Seems TYPE_CANONICAL is NULL on the RECORD_TYPE B as well as its TYPE_MAIN_VARIANT.
[Bug tree-optimization/90303] [9/10 Regression] ICE in hash_odr_name with fastcall attribute starting with r267359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90303 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |9.2
[Bug tree-optimization/90303] New: [9/10 Regression] ICE in hash_odr_name with fastcall attribute starting with r267359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90303
Bug ID: 90303
Summary: [9/10 Regression] ICE in hash_odr_name with fastcall
attribute starting with r267359
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
struct A { virtual void foo (); };
template class B : A {};
typedef void (__attribute__((fastcall)) F) ();
B e;
ICEs with -m32 on x86_64-linux (and on i686-linux), starting with r267359.
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 --- Comment #8 from Igor A. Goussarov --- P.S. It seems that different compilers have different ideas about inline namespaces. If godbolt.org can be trusted, clang-8.0 and msvc 2017 do not merge namespaces in described scenario.
[Bug fortran/60144] Misleading error message when missing "then" after "if" and "else if"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60144
--- Comment #7 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed May 1 17:40:22 2019
New Revision: 270776
URL: https://gcc.gnu.org/viewcvs?rev=270776=gcc=rev
Log:
2019-05-01 Dominique d'Humieres
PR fortran/60144
* match.c (gfc_match_parens): Change the location for missing ')'.
(gfc_match_if): Detect a missing '('. Remove the spurious named
constant error. Change the wording of some errors.
(gfc_match_else): Change the wording of an error.
(gfc_match_elseif): Detect a missing '('. Improve the matching
process to get a better syntax analysis.
PR fortran/60144
* gfortran.dg/block_name_2.f90: Adjust dg-error.
* gfortran.dg/dec_type_print_3.f90.f90: Likewise
* gfortran.dg/pr60144.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/pr60144.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/block_name_2.f90
trunk/gcc/testsuite/gfortran.dg/dec_type_print_3.f90
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 --- Comment #7 from Igor A. Goussarov --- The intent is to have a lot of services, each defined in its dedicated namespace. The hierarchy of those namespaces can grow to arbitrary depth: component component::service_a component::group_b::service_c component::group_b::service_d component::third_party::domain::service_e Each service may have header-only public part and private part. Private part must be placed in namespace `detail` under the namespace of its corresponding service. So we have: component::detail component::service_a::detail component::group_b::service_c::detail component::group_b::service_d::detail component::third_party::domain::service_e::detail Now, if some team decided to put their service in an inline namespace (say, if their service is common enough), the identity of detail namespaces is ruined because they start merging with each other, subject to the order of header files inclusion. And that leads to ODR violation and weird linker errors...
[Bug tree-optimization/88797] [7/8/9 Regression] Unneeded branch added when function is inlined (function runs faster if not inlined)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88797 Jeffrey A. Law changed: What|Removed |Added Summary|[7/8/9/10 Regression] |[7/8/9 Regression] Unneeded |Unneeded branch added when |branch added when function |function is inlined |is inlined (function runs |(function runs faster if|faster if not inlined) |not inlined)| --- Comment #9 from Jeffrey A. Law --- Fixed on the trunk.
[Bug tree-optimization/88797] [7/8/9/10 Regression] Unneeded branch added when function is inlined (function runs faster if not inlined)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88797 --- Comment #8 from Jeffrey A. Law --- Author: law Date: Wed May 1 17:33:32 2019 New Revision: 270775 URL: https://gcc.gnu.org/viewcvs?rev=270775=gcc=rev Log: PR tree-optimization/88797 * gimple-ssa-split-paths (is_feasible_trace): Reject cases where the PHI feeds a conditional on the RHS of an assignment. PR tree-optimization/88797 * g++.dg/tree-ssa/pr88797.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr88797.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-split-paths.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968 --- Comment #6 from Dominique d'Humieres --- On darwin I don't see the "Assembler messages".
[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968
--- Comment #5 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #4)
> With gcc-9, gcc-8 and trunk I get
To be more precise, with a current gcc-9 snapshot:
$ gfortran -c pr61968.f90
/tmp/ccqFh8vs.s: Assembler messages:
/tmp/ccqFh8vs.s:121: Error: unrecognized symbol type ""
/tmp/ccqFh8vs.s:121: Error: junk at end of line, first unrecognized character
is `('
/tmp/ccqFh8vs.s:122: Error: invalid character '(' in mnemonic
/tmp/ccqFh8vs.s:142: Error: expected comma after name `__copy_TYPE' in .size
directive
/tmp/ccqFh8vs.s:171: Error: unrecognized symbol type ""
/tmp/ccqFh8vs.s:171: Error: junk at end of line, first unrecognized character
is `('
/tmp/ccqFh8vs.s:172: Error: expected comma after name `__vtab_TYPE' in .size
directive
/tmp/ccqFh8vs.s:173: Error: invalid character '(' in mnemonic
/tmp/ccqFh8vs.s:179: Error: junk at end of line, first unrecognized character
is `('
$ gfortran -c -O pr61968.f90
$
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291
--- Comment #6 from Igor A. Goussarov ---
Yes, this is a slightly modified excerpt from real code.
Perhaps a less abridged example would make more sense:
// Code in logger.h
namespace component
{
inline namespace utility
{
namespace detail // (1)
{
// Private implementation details
void LogImpl();
}
// Facade
inline void LogEvent()
{
detail::LogImpl();
}
}
}
// Code in service.h
namespace component
{
namespace detail// (2)
{
// Private implementation details
void ServiceImpl();
}
// Facade
inline void DoService()
{
detail::ServiceImpl();
}
}
// Code in service_impl.cpp
#include "service.h"
namespace component
{
namespace detail
{
// This defines `component::detail::ServiceImpl()`.
void ServiceImpl()
{
}
}
}
// Code in other_source.cpp
#include "logger.h"
#include "service.h"
// When both headers are included, namespace (2) is
// merged with namespace (1), which results in
// inline function `component::DoService()` calling
// `component::utility::detail::ServiceImpl()`
// which obviously isn't defined.
// Not to say that ODR for component::DoService()
// is violated.
[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968
Thomas Koenig changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||tkoenig at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #4 from Thomas Koenig ---
With gcc-9, gcc-8 and trunk I get
/tmp/ccyyPrsg.s: Assembler messages:
/tmp/ccyyPrsg.s:121: Error: unrecognized symbol type ""
/tmp/ccyyPrsg.s:121: Error: junk at end of line, first unrecognized character
is `('
/tmp/ccyyPrsg.s:122: Error: invalid character '(' in mnemonic
/tmp/ccyyPrsg.s:142: Error: expected comma after name `__copy_TYPE' in .size
directive
/tmp/ccyyPrsg.s:171: Error: unrecognized symbol type ""
/tmp/ccyyPrsg.s:171: Error: junk at end of line, first unrecognized character
is `('
/tmp/ccyyPrsg.s:172: Error: expected comma after name `__vtab_TYPE' in .size
directive
/tmp/ccyyPrsg.s:173: Error: invalid character '(' in mnemonic
/tmp/ccyyPrsg.s:179: Error: junk at end of line, first unrecognized character
is `('
[Bug middle-end/90302] Implement __builtin_warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90302 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-01 CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89337, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=48655 Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- As Jeff said this would be useful to avoid false positives in cases like bug 89337 comment #12.
[Bug fortran/90133] [7/8/9/10 Regression] Linker error from accessing event_type via use association outside associate/block scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90133 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-01 Known to work||5.5.0 Summary|Linker error from accessing |[7/8/9/10 Regression] |event_type via use |Linker error from accessing |association outside |event_type via use |associate/block scope |association outside ||associate/block scope Ever confirmed|0 |1 Known to fail||10.0, 6.5.0, 7.4.0, 8.3.0, ||9.0 --- Comment #1 from Dominique d'Humieres --- AFAICT this is a regression which occurred between revisions r243909 (2016-12-23, links) and r244868 (2017-01-24, does not link) and has been back ported to the GCC6 branch.
[Bug middle-end/90302] Implement __builtin_warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90302 --- Comment #1 from Andrew Pinski --- Error can be implement using the error attribute on a function.
[Bug middle-end/90302] New: Implement __builtin_warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90302 Bug ID: 90302 Summary: Implement __builtin_warning Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- It would be useful to implement a __builtin_warning function to delay a warning which may be removed later by dead code elimination. One application could be PR48655, where warnings are issued about temporary Fortran arrays which are eliminated by the middle end. See the discussion at https://gcc.gnu.org/ml/gcc/2019-04/msg00275.html . (Come to think of it, a __builtin_error function could also be useful in some contexts).
[Bug fortran/90207] Debugging generated tree code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90207 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2019-05-01 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Dominique d'Humieres --- This does not look specific to gfortran.
[Bug fortran/90297] gcc/fortran/resolve.c: 2 * possibly redundant code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-01 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed.
[Bug c++/90301] New: RangeV3 usage, ICE internal compiler error: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90301
Bug ID: 90301
Summary: RangeV3 usage, ICE internal compiler error: canonical
types differ for identical types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cuzdav at gmail dot com
Target Milestone: ---
Created attachment 46270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46270=edit
full output from compiler (since it's long)
On Godbolt, version 8.3 and releases before it, this compiles. It compiles in
Clang from trunk back to version 5.
On the current g++ TRUNK version, it fails in -std=c++17 mode and -std=c++2a
mode.
(But it SUCCEEDS in TRUNK -std=c++14 mode)
I didn't dig into rangeV3 implementation, so it may resemble some other
existing reports:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89766
Here's the complete, minimal, reproducible extraction of the code triggering
the bug
//-
#include
#include
int g() {
int v[]{1, 2, 3};
return ranges::v3::accumulate(
v | ranges::v3::view::filter([](int){return true;}),
0);
}
//-
side-by-side on Godbolt:
https://godbolt.org/z/q9z4mI
OUTPUT:
/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/utility/compressed_pair.hpp:51:27:
internal compiler error: canonical types differ for identical types
'std::integral_constant::type::value ...> >' and 'std::integral_constant::type::value ...> >'
51 | constexpr compressed_tuple_(Args &&... args)
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/86538] GCC should define a macro to specify if LSE is enabled or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86538 Ramana Radhakrishnan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Ramana Radhakrishnan --- Now fixed on trunk and all release branches.
[Bug target/86538] GCC should define a macro to specify if LSE is enabled or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86538 --- Comment #7 from Ramana Radhakrishnan --- Author: ramana Date: Wed May 1 15:27:40 2019 New Revision: 270770 URL: https://gcc.gnu.org/viewcvs?rev=270770=gcc=rev Log: [Patch AArch64] Add __ARM_FEATURE_ATOMICS This keeps coming up repeatedly and the ACLE has finally added __ARM_FEATURE_ATOMICS for the LSE feature in GCC. This is now part of the latest ACLE release (https://developer.arm.com/docs/101028/latest/5-feature-test-macros) I know it's late for GCC-9 but this is a simple macro which need not wait for another year. Ok for trunk and to backport to all release branches ? Tested with a simple build and a smoke test. Backport from mainline. PR target/86538 * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define __ARM_FEATURE_ATOMICS Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/aarch64/aarch64-c.c
[Bug c++/90300] "control reaches end of non-void function" warning despite exhaustive switch for enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90300 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 85714 and many others. *** This bug has been marked as a duplicate of bug 85714 ***
[Bug c++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85714 Andrew Pinski changed: What|Removed |Added CC||maic23 at live dot de --- Comment #6 from Andrew Pinski --- *** Bug 90300 has been marked as a duplicate of this bug. ***
[Bug c++/90300] "control reaches end of non-void function" warning despite exhaustive switch for enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90300 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- enum class can still have values that are outside of the defined values and that is not undefined code.
[Bug c++/90300] New: "control reaches end of non-void function" warning despite exhaustive switch for enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90300
Bug ID: 90300
Summary: "control reaches end of non-void function" warning
despite exhaustive switch for enum class
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maic23 at live dot de
Target Milestone: ---
GCC can determine if a switch statement on an enum class does not cover all
possible cases. However, even if all cases are covered, GCC will produce a
warning that control may reach the end of a non void function, which is
incorrect.
Steps to reproduce:
$ g++ --version
g++ (GCC) 9.0.1 20190312 (Red Hat 9.0.1-0.10)
$ echo '
enum class Test { A };
int test_to_int(const Test ) {
switch (t) {
case Test::A:
return 4;
}
}
int main() {}' | g++ -x c++ -
: In function ‘int test_to_int(const Test&)’:
:8:1: warning: control reaches end of non-void function [-Wreturn-type]
I am aware that this warning can be worked around by adding a `default:` case,
but that would also disable the warning that not all cases of an enum class are
covered.
[Bug c++/87249] Undefined reference within a header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87249 Andreas Schwab changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #88 from Tamar Christina --- Thanks Jakub!
[Bug libstdc++/90299] New: std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90299
Bug ID: 90299
Summary: std::filesystem::absolute("") and
std::filesystem::absolute("", ec) behave differently
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ssh at pobox dot com
Target Milestone: ---
Verified on GCC 8.x on macOS, Ubuntu and Wandbox HEAD
(https://wandbox.org/permlink/8OKSXauY3GpcfE8C):
#include
#include
namespace fs = std::filesystem;
int main()
{
std::error_code ec;
std::cout << fs::absolute("", ec);
std::cout << (ec ? " error" : " no error") << std::endl;
std::cout << fs::absolute("");
}
Current result:
"" error
"/home/jail/"
For the given two calls:
std::filesystem::absolute("", ec)
std::filesystem::absolute("")
The first one returns an empty path and signals a ENOENT error while the second
one returns the usual POSIX current_path() / "". I think they should return the
same result (actually the non-error one) and I find nothing in the standard
suggesting different.
Additionally the note "Implementations are strongly encouraged to [...] not
consider !exists(p) an error" suggests that "not-found" is the one error that
nobody would expect.
[Bug c++/87249] Undefined reference within a header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87249 Dimitris Eftaxiopoulos changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dimitris Eftaxiopoulos --- The bug was related to the application source code and not to gcc/g++. It was resolved by the developers of the application.
[Bug fortran/90297] gcc/fortran/resolve.c: 2 * possibly redundant code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297
--- Comment #2 from paul.richard.thomas at gmail dot com ---
dh! Thanks.
Paul
On Wed, 1 May 2019 at 08:27, dcb314 at hotmail dot com
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297
>
> David Binderman changed:
>
>What|Removed |Added
>
> CC||pault at gcc dot gnu.org
>
> --- Comment #1 from David Binderman ---
> svn blame says:
>
> 182796 pault for (args= e->value.function.actual; args; args =
> args->next)
> 182796 pault {
> 182796 pault if (expr == args->expr)
> 182796 pault expr = args->expr;
> 182796 pault }
>
> so this code looks pretty old.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug c++/89422] [8 Regression] ICE in field_byte_offset, at dwarf2out.c:19086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89422 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- .
[Bug c++/84655] internal compiler error: unexpected expression 'a' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84655 --- Comment #4 from David Binderman --- I tried out various versions of gcc trunk, from revision 269700 to 270600 and could see no ice. I'd be interested to find out what Marek did to reproduce it.
[Bug other/90251] missing spaces in string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90251 --- Comment #2 from Roland Illig --- I posted an updated version of the linter to bug 79618, and I will post further updates only there.
[Bug c/45358] Diagnostic could be issued for old C style a =+ b and similar cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45358 Eric Gallager changed: What|Removed |Added Blocks||87403 --- Comment #6 from Eric Gallager --- making this block the "new-warning" meta-bug Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug lto/51765] [9/10 Regression] Testsuite ICEs with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51765 --- Comment #10 from Arseny Solokha --- (In reply to Jan Hubicka from comment #8) > FAIL: gcc.dg/nested-func-12.c (internal compiler error) > FAIL: gcc.dg/nested-func-9.c (internal compiler error) I cannot reproduce these as for now. I believe it makes sense to finally close this PR and maybe mark PR83997 as a regression in turn.
[Bug c++/89422] [8 Regression] ICE in field_byte_offset, at dwarf2out.c:19086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89422 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #6 from Arseny Solokha --- This is fixed on both affected branches, so can be closed now.
[Bug c++/84655] internal compiler error: unexpected expression 'a' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84655 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #3 from Arseny Solokha --- I cannot reproduce the ICE w/ any released version of gcc, from 8.1.0 through the current trunk.
[Bug c/80130] Wrong diagnostic: dereferencing type-punned pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80130 Eric Gallager changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Richard Biener from comment #3) > (In reply to Eric Gallager from comment #2) > > I only get 1 warning on (1) and only with -Wstrict-aliasing=1. > > -Wstrict-aliasing=2 and -Wstrict-aliasing=3 are both silent. > > > > (In reply to Richard Biener from comment #1) > > > The warning implementation is incredibly stupid, don't use it. It doesn't > > > have any context (so the two stmt variant is different from the single > > > stmt > > > one). > > > > It'd still be nice if it could be improved though. Although, maybe it > > already has been? > > I don't see how it can be improved. Iff the compiler can detect an > aliasing violation it may as well try to be conservative (which in > fact we do later during optimization). > > Jakub has attempted to do a TBAA sanitizer, not sure how far that went though, > it is quite meta-data heavy to do "correctly". Still tracking the dynamic > type of storage at runtime and then instrumenting each access is the only > way to reliably detect TBAA violations (without false positives). cc-ing Jakub then to see how far he got with it
[Bug c/77331] incorrect range location in -Wformat with a concatenated format literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77331 Eric Gallager changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #4 from Eric Gallager --- cc-ing other diagnostics maintainer
[Bug translation/90118] Missing space between words
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Eric Gallager --- (In reply to Roland Illig from comment #9) > The particular issue has been fixed, the linter has been updated in bug > 90176, therefore I think this bug can be closed. OK.
[Bug translation/90118] Missing space between words
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118 --- Comment #9 from Roland Illig --- The particular issue has been fixed, the linter has been updated in bug 90176, therefore I think this bug can be closed.
[Bug translation/79618] prevent missing space in multiline string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618 --- Comment #7 from Roland Illig --- Created attachment 46269 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46269=edit linter for string literals The attached linter detects: * multiline string literals that have the space at the start of the line instead of the end of the line. (In the whole GCC source there are 800 instances of "prev" " curr" and 5500 instances of "prev " "curr". Therefore there's a clear preference towards having the space always at the end.) * multiline string literals in which neither has a space at the boundary * multiline string literals in which both have a space at the boundary These checks are not 100% perfect, they need manual inspection. But at least they show where the possible bugs are.
[Bug c/90296] C11 anonymous struct not liked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90296
Fred J. Tydeman changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Fred J. Tydeman ---
User misunderstood C standard. struct b should be:
struct b {
int x;
struct { /* anonymous */
int y;
};
int z;
};
[Bug c/88568] [7 Regression] 'dllimport' no longer implies 'extern' in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568 --- Comment #27 from jon_y <10walls at gmail dot com> --- Thanks Jakub.
[Bug libquadmath/90298] libquadmath/math/catanhq.c:113: possibly redundant code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90298 --- Comment #2 from David Binderman --- Same thing in different file in same library. libquadmath/math/catanq.c:92]: (style) Assignment 'den=0' is redundant with condition 'den==0'. svn blame says: 265822 jsm28 if (den == 0) 265822 jsm28 den = 0;
[Bug libquadmath/90298] libquadmath/math/catanhq.c:113: possibly redundant code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90298 David Binderman changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #1 from David Binderman --- svn blame says 265822 jsm28 if (den == 0) 265822 jsm28 den = 0;
[Bug libquadmath/90298] New: libquadmath/math/catanhq.c:113: possibly redundant code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90298 Bug ID: 90298 Summary: libquadmath/math/catanhq.c:113: possibly redundant code ? Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- libquadmath/math/catanhq.c:113] -> [trunk/libquadmath/math/catanhq.c:114]: (style) Assignment 'den=0' is redundant with condition 'den==0'. Source code is if (den == 0) den = 0; Strange code. Should this code be removed or should an explanatory comment be added ?
[Bug fortran/90297] gcc/fortran/resolve.c: 2 * possibly redundant code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297
David Binderman changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #1 from David Binderman ---
svn blame says:
182796 pault for (args= e->value.function.actual; args; args =
args->next)
182796 pault {
182796 pault if (expr == args->expr)
182796 pault expr = args->expr;
182796 pault }
so this code looks pretty old.
[Bug fortran/90297] New: gcc/fortran/resolve.c: 2 * possibly redundant code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297
Bug ID: 90297
Summary: gcc/fortran/resolve.c: 2 * possibly redundant code ?
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
1.
trunk/gcc/fortran/resolve.c:6482] -> [trunk/gcc/fortran/resolve.c:6483]:
(style) Assignment 'expr=args->expr' is redundant with condition
'expr==args->expr'.
Source code is
for (args= e->value.function.actual; args; args = args->next)
{
if (expr == args->expr)
expr = args->expr;
}
If X == Y, then X = Y looks pointless to me.
2.
trunk/gcc/fortran/resolve.c:6617] -> [trunk/gcc/fortran/resolve.c:6618]:
(style) Assignment 'expr=args->expr' is redundant with condition
'expr==args->expr'.
Source code is
for (; args; args = args->next)
if (expr == args->expr)
expr = args->expr;
Duplicate.
[Bug debug/90273] [10 Regression] GCC runs out of memory building Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] GCC runs |[10 Regression] GCC runs |out of memory building |out of memory building |Firefox |Firefox --- Comment #29 from Jakub Jelinek --- Fixed on gcc-9-branch, trunk commits left for Richard.
[Bug rtl-optimization/90026] [8 Regression] ICE: verify_flow_info failed (error: missing barrier after block 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90026 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- .
[Bug tree-optimization/90208] [7 Regression] error: EH landing pad label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90208 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1 Summary|[7/8 Regression] error: EH |[7 Regression] error: EH |landing pad label |landing pad label Known to fail|8.3.1 |8.3.0 --- Comment #5 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug target/90193] [8 Regression] asm goto with TLS "m" input operand generates incorrect assembler in O1 and O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90193 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.3.1 Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug c++/90108] ICE: Segmentation fault (in c_tree_chain_next)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90108 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1 --- Comment #7 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug target/90187] [8 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug tree-optimization/90090] [7 Regression] ICE in mark_reachable_handlers, at tree-eh.c:3938 since r219202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90090 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1 Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |mark_reachable_handlers, at |mark_reachable_handlers, at |tree-eh.c:3938 since|tree-eh.c:3938 since |r219202 |r219202 --- Comment #6 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug c++/90010] [8 Regression] valgrind error with snprintf and -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90010 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.3.1, 9.0 Resolution|--- |FIXED Known to fail|9.0 | --- Comment #8 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug rtl-optimization/90026] [8 Regression] ICE: verify_flow_info failed (error: missing barrier after block 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90026 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1 --- Comment #7 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug rtl-optimization/89965] [8 Regression] wrong code with -O -mtune=nano-x2 -fcaller-saves -fexpensive-optimizations -fno-tree-dce -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.3.1 Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug c/89946] [8 Regression] ICE in assemble_start_function, at varasm.c:1871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89946 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug middle-end/89998] [7 regression] ICE: verify_gimple failed in printf-return-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89998 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 regression] ICE: |[7 regression] ICE: |verify_gimple failed in |verify_gimple failed in |printf-return-value |printf-return-value --- Comment #12 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug sanitizer/89869] -fsanitize=undefined miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89869 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1 --- Comment #9 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug c++/89796] Incorrect warning generated with OpenMP atomic capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 --- Comment #9 from Jakub Jelinek --- Fixed for 9.1+ and 8.4+ so far.
[Bug c/89933] [7 Regression] ICE in merge_decls, at c/c-decl.c:2517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89933 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |merge_decls, at |merge_decls, at |c/c-decl.c:2517 |c/c-decl.c:2517 --- Comment #7 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug c/89872] [7 Regression] GCC does not generate read access to volatile compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89872 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] GCC does |[7 Regression] GCC does not |not generate read access to |generate read access to |volatile compound literal |volatile compound literal --- Comment #6 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug c++/89767] [8 Regression] ICE with tuple and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89767 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.3.1, 9.0 Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug rtl-optimization/89768] [7 Regression] ICE in compare_and_jump_seq at loop-unroll.c:838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89768 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1, 9.0 Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |compare_and_jump_seq at |compare_and_jump_seq at |loop-unroll.c:838 |loop-unroll.c:838 Known to fail|9.0 | --- Comment #7 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug target/89752] [8 Regression] ICE in emit_move_insn, at expr.c:3723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.3.1, 9.0 Resolution|--- |FIXED Known to fail|8.3.1, 9.0 |8.3.0 --- Comment #18 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug tree-optimization/89703] [8 Regression] ICE in compare_values_warnv, at tree-vrp.c:997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89703 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|9.0 |8.4 --- Comment #6 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug c/89734] [7 Regression] const qualifier on return type not erased inside __typeof__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89734 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1, 9.0 Summary|[7/8 Regression] const |[7 Regression] const |qualifier on return type|qualifier on return type |not erased inside |not erased inside |__typeof__ |__typeof__ --- Comment #6 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug target/89726] [7 Regression] Incorrect inlined version of 'ceil' for 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89726 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] Incorrect |[7 Regression] Incorrect |inlined version of 'ceil' |inlined version of 'ceil' |for 32bit |for 32bit --- Comment #11 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug debug/89704] [7 Regression] ICE in add_const_value_attribute, at dwarf2out.c:19685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89704 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |add_const_value_attribute, |add_const_value_attribute, |at dwarf2out.c:19685|at dwarf2out.c:19685 --- Comment #6 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug rtl-optimization/89679] [7 Regression] wrong code with -Og -frerun-cse-after-loop -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89679 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1, 9.0 Summary|[7/8 Regression] wrong code |[7 Regression] wrong code |with -Og|with -Og |-frerun-cse-after-loop |-frerun-cse-after-loop |-fno-tree-fre |-fno-tree-fre Known to fail|8.3.1, 9.0 |8.3.0 --- Comment #9 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug ipa/89684] [8 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89684 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug middle-end/89621] [7 Regression] ICE with allocatable character and openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89621 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] ICE with |[7 Regression] ICE with |allocatable character and |allocatable character and |openmp |openmp --- Comment #8 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug middle-end/89663] [7 Regression] ICE in expand_builtin_int_roundingfn_2, at builtins.c:2831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89663 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1 Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |expand_builtin_int_rounding |expand_builtin_int_rounding |fn_2, at builtins.c:2831|fn_2, at builtins.c:2831 --- Comment #7 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug fortran/89651] OpenMP private array uninitialized warning with -O flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89651 --- Comment #11 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug target/89587] gcc's rs6000 configuration unconditionally sets MULTIARCH_DIRNAME, even when multiarch is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89587 --- Comment #5 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug middle-end/89590] [7 Regression] ICE in maybe_emit_free_warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89590 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |maybe_emit_free_warning |maybe_emit_free_warning --- Comment #6 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug c++/89512] [7 Regression] ICE in get_expr_operands, at tree-ssa-operands.c:882
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89512 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1, 9.0 Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |get_expr_operands, at |get_expr_operands, at |tree-ssa-operands.c:882 |tree-ssa-operands.c:882 Known to fail||7.4.0, 8.3.0 --- Comment #7 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug c/89520] [7 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in convert_to_integer_1, at convert.c:668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89520 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] ICE tree |[7 Regression] ICE tree |check: accessed operand 4 |check: accessed operand 4 |of call_expr with 3 |of call_expr with 3 |operands in |operands in |convert_to_integer_1, at|convert_to_integer_1, at |convert.c:668 |convert.c:668 --- Comment #9 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug middle-end/89412] [7 Regression] gcc ICE in simplify_subreg, at simplify-rtx.c:6273 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1 Summary|[7/8 Regression] gcc ICE in |[7 Regression] gcc ICE in |simplify_subreg, at |simplify_subreg, at |simplify-rtx.c:6273 on |simplify-rtx.c:6273 on |i686-linux-gnu |i686-linux-gnu --- Comment #10 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug debug/89498] [8 Regression] ICE in AT_loc_list, at dwarf2out.c:4871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89498 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.3.1, 9.0 Resolution|--- |FIXED Known to fail||8.3.0 --- Comment #8 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug c++/89403] [7 Regression] ICE in maybe_clone_body, at cp/optimize.c:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89403 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1, 9.0 Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |maybe_clone_body, at|maybe_clone_body, at |cp/optimize.c:693 |cp/optimize.c:693 Known to fail||8.3.0 --- Comment #7 from Jakub Jelinek --- Fixed for 8.4+ too.
[Bug middle-end/88588] ICE in make_decl_rtl, at varasm.c:1329
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88588 Jakub Jelinek changed: What|Removed |Added Known to work||8.3.1 --- Comment #6 from Jakub Jelinek --- Fixed for 8.4+ too.
