[Bug target/98112] Add -fdirect-access-external-data & drop HAVE_LD_PIE_COPYRELOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #4 from Segher Boessenkool ---
(In reply to Fangrui Song from comment #3)
> Are you happy with the option name -f[no-]direct-access-external-data ?
Not at all, no :-(
The name does not explain its purpose at all, and the whole concept only
makes sense for a fraction of all targets. A -mcopy-relocs ("generate copy
relocations if that is a good idea"), defined *per target*, would be a lot
better, or a -mpic-use-copy-relocs (since you say it is *not* just for pie),
or something like that. You want to have this a generic option, while it is
not clear at all what it would mean, what it would *do*, which is especially
important if you want this to be an option used by multiple compilers: if it
is not clear to every user what simple, sensible thing a flag is the knob
for, that flag simply cannot be used at all -- or worse, some users *will*
use it, but then their intentions are not clear to humans, and different
compilers can (and will!) think the user wanted something else!
[Bug preprocessor/98459] New: [11 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98459
Bug ID: 98459
Summary: [11 Regression] ICE in
linemap_position_for_line_and_column, at
libcpp/line-map.c:923
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-11.0.0-alpha20201227 snapshot (g:9a48892bea70a1e6a82e24b882f22807b73debe7)
ICEs when compiling gcc/testsuite/gcc.dg/pr89410-1.c:
% g++-11.0.0 -w -c gcc/testsuite/gcc.dg/pr89410-1.c
gcc/testsuite/gcc.dg/pr89410-1.c:1:1: internal compiler error: in
linemap_position_for_line_and_column, at libcpp/line-map.c:923
1 | /* { dg-options "" } */
| ^
0x1cc81aa linemap_position_for_line_and_column(line_maps*, line_map_ordinary
const*, unsigned int, unsigned int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/libcpp/line-map.c:923
0x1cc9ac1 linemap_position_for_loc_and_offset(line_maps*, unsigned int,
unsigned int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/libcpp/line-map.c:998
0xa6ce53 cp_lexer_new_main
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/parser.c:676
0xa6ce53 c_parse_file()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/cp/parser.c:45114
0xb93b2d c_common_parse_file()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201227/work/gcc-11-20201227/gcc/c-family/c-opts.c:1211
[Bug fortran/98458] New: implied do-loop used in initialization with RESHAPE throw ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98458 Bug ID: 98458 Summary: implied do-loop used in initialization with RESHAPE throw ICE Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xiao@compiler-dev.com Target Milestone: --- test case: program test implicit none integer :: i integer, parameter :: t(6) = [1,2,3,4,5,6] integer, parameter :: tmp(6,1) = reshape([(t(i:i+1),i=1,3)],[6,1]) print *, tmp end result: 6 | print *, tmp | internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:6162
[Bug driver/82955] ICE when using -fdump-passes -fdisable-tree-einline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82955 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot com --- Comment #2 from frankhb1989 at gmail dot com --- Both cases are not reproducible using current Arch Linux's GCC 10.2.0 now. Context: I'm dealing with some compiler performance issues on opt_local_passes for this specific source: https://github.com/FrankHB/YSLib/blob/master/YFramework/source/NPL/NPLA1Forms.cpp, with -O -fsanitizer= I've met endless compilation (> 4 hours) for this file combined with -g and optimization flags and -fno-var-tracking-assignments would work around, but this time it seems a different case.
[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457
--- Comment #1 from Witold Baryluk ---
Godbolt link: https://godbolt.org/z/q3bzhP
with gcc trunk 20201217 and a bit more diagnostic
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/core/time.d:2405:16:
error: static variable _ticksPerSecond cannot be read at compile time
2405 | return _ticksPerSecond[_clockIdx];
|^
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/core/time.d:2418:99:
note: called from here: ticksPerSecond()
2418 | return "MonoTime(" ~ signedToTempString(_ticks, 10) ~ "
ticks, " ~ signedToTempString(ticksPerSecond, 10) ~ " ticks per second)";
|
^
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/core/time.d:2418:98:
note: called from here: signedToTempString(ticksPerSecond(), 10u)
2418 | return "MonoTime(" ~ signedToTempString(_ticks, 10) ~ "
ticks, " ~ signedToTempString(ticksPerSecond, 10) ~ " ticks per second)";
|
^
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/std/format.d:3353:28:
note: called from here: val.toString()
3353 | put(w, val.toString());
| ^
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/std/format.d:3353:12:
note: called from here: put(w, val.toString())
3353 | put(w, val.toString());
|^
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/std/format.d:3672:21:
note: called from here: formatObject(w, val, f)
3672 | formatObject(w, val, f);
| ^
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/std/format.d:568:28:
note: called from here: formatValue(w, _param_2, spec)
568 | formatValue(w, args[i], spec);
| ^
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/std/format.d:5767:28:
note: called from here: formattedWrite(w, fmt, _param_1)
5767 | auto n = formattedWrite(w, fmt, args);
| ^
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/std/format.d:5729:16:
note: called from here: format("%s", MonoTimeImpl(0L))
5729 | .format(fmt, Args.init);
|^
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/std/format.d:5733:2:
note: called from here: (*function () => null)()
5733 | }();
| ^
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/std/stdio.d:3754:15:
error: template instance std.format.checkFormatException!("�}�",
MonoTimeImpl!cast(ClockType)0) error instantiating
3754 | alias e = checkFormatException!(fmt, A);
| ^
:4:14: note: instantiated from here: writef!("%s",
MonoTimeImpl!cast(ClockType)0)
4 | writef!"%s"(MonoTime.currTime());
| ^
/opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/std/stdio.d:3755:5:
note: while evaluating: static assert(!e)
3755 | static assert(!e, e.msg);
| ^
Compiler returned: 1
[Bug d/98457] New: [d] writef!"%s" doesn't work with MonoTime / SysTick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457
Bug ID: 98457
Summary: [d] writef!"%s" doesn't work with MonoTime / SysTick
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: witold.baryluk+gcc at gmail dot com
Target Milestone: ---
void main() {
import std.stdio;
import core.time : MonoTime;
writef!"%s"(MonoTime.currTime());
}
Doesn't compile with gdc 10.2.1:
$ gdc test_monotime.d
/usr/lib/gcc/x86_64-linux-gnu/10/include/d/core/time.d:2405:16: error: static
variable _ticksPerSecond cannot be read at compile time
2405 | return _ticksPerSecond[_clockIdx];
|^
/usr/lib/gcc/x86_64-linux-gnu/10/include/d/core/time.d:2418:99: note: called
from here: ticksPerSecond()
2418 | return "MonoTime(" ~ signedToTempString(_ticks, 10) ~ "
ticks, " ~ signedToTempString(ticksPerSecond, 10) ~ " ticks per second)";
|
^
/usr/lib/gcc/x86_64-linux-gnu/10/include/d/core/time.d:2418:98: note: called
from here: signedToTempString(ticksPerSecond(), 10u)
2418 | return "MonoTime(" ~ signedToTempString(_ticks, 10) ~ "
ticks, " ~ signedToTempString(ticksPerSecond, 10) ~ " ticks per second)";
|
^
/usr/lib/gcc/x86_64-linux-gnu/10/include/d/std/format.d:3353:28: note: called
from here: val.toString()
3353 | put(w, val.toString());
|^
/usr/lib/gcc/x86_64-linux-gnu/10/include/d/std/format.d:3353:12: note: called
from here: put(w, val.toString())
3353 | put(w, val.toString());
|^
/usr/lib/gcc/x86_64-linux-gnu/10/include/d/std/format.d:3672:21: note: called
from here: formatObject(w, val, f)
3672 | formatObject(w, val, f);
| ^
/usr/lib/gcc/x86_64-linux-gnu/10/include/d/std/format.d:568:28: note: called
from here: formatValue(w, _param_2, spec)
568 | formatValue(w, args[i], spec);
|^
/usr/lib/gcc/x86_64-linux-gnu/10/include/d/std/format.d:5767:28: note: called
from here: formattedWrite(w, fmt, _param_1)
5767 | auto n = formattedWrite(w, fmt, args);
|^
/usr/lib/gcc/x86_64-linux-gnu/10/include/d/std/format.d:5729:16: note: called
from here: format("%s", MonoTimeImpl(0L))
5729 | .format(fmt, Args.init);
|^
/usr/lib/gcc/x86_64-linux-gnu/10/include/d/std/format.d:5733:2: note: called
from here: (*function () => null)()
5733 | }();
| ^
(null):0: confused by earlier errors, bailing out
Adding manually .toString() makes it work (at the expense of possible extra
allocation).
No issues in ldc2 1.24.0 or dmd2 2.095.0-beta.1
It doesn't look like issue in phobos, but something deeper.
[Bug tree-optimization/96275] Vectorizer doesn't take into account bitmask condition from branch conditions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96275 --- Comment #3 from Witold Baryluk --- Thanks for looking into that. I just wanted to update that this still suboptimal in current gcc trunk 20201226. While clang produces superior code.
[Bug c++/98446] C++ modules test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98446 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #1 from Nathan Sidwell --- I regularly use make check-g++ -j24, so I'll suspect something else
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 --- Comment #8 from Steve Kargl --- On Sun, Dec 27, 2020 at 10:15:56PM +, ffadrique at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 > > --- Comment #6 from Fran Martinez Fadrique --- > I have raised the issue with respect to 4.5.3.4 of the ISO standard that > stablishes how the type component are initialized. Not just my expectations. > > I have further developed my test case and any local variable declared in any > function or subroutine in the scope of the module where the type is declared > fails to properly initialize its components according to the default > initializations (using the terminology of the standard). The intent(out) seems > to make the difference and subroutine parameters are properly initialized. > Any variable created outside the module declaring the type seems to properly > initialize the components. Putting your code in one file. module m_test implicit none type t_test integer :: unit = -1 integer :: def logical :: trace = .true. logical :: def_trace end type t_test interface test module procedure test_default end interface contains ! INVALID. ! Neither def not def_trace are set. Therefore, res is undefined. ! Function result is not defined on return. function test_default() result(res) type(t_test) :: res end function test_default end module m_test program driver_test use m_test implicit none type(t_test) :: x write(6,*) 'Before constructor' write(6,*) ' unit = ', x%unit write(6,*) ' default = ', x%def! Invalid. Undefined component. write(6,*) ' trace = ', x%trace write(6,*) ' def trace = ', x%def_trace ! Invalid. Undefined component. x = test() ! Invalid. ! All of the following can be anything as x is defined (and use defined ! here loosely) with an ! undefined function result. write(6,*) 'After constructor' write(6,*) ' unit = ', x%unit write(6,*) ' default = ', x%def write(6,*) ' trace = ', x%trace write(6,*) ' def trace = ', x%def_trace end program driver_test > I compile with -std=2018 so I would expect that invalid Fortran is flagged, at > least with a warning, which is not the case. The Fortran standard likely does not require a Fortran processor to detect the above programmer errors.
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 --- Comment #7 from Fran Martinez Fadrique --- By the way, thanks for the workaround. It cleanly solves the problem, at least temporarily.
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 --- Comment #6 from Fran Martinez Fadrique --- I have raised the issue with respect to 4.5.3.4 of the ISO standard that stablishes how the type component are initialized. Not just my expectations. I have further developed my test case and any local variable declared in any function or subroutine in the scope of the module where the type is declared fails to properly initialize its components according to the default initializations (using the terminology of the standard). The intent(out) seems to make the difference and subroutine parameters are properly initialized. Any variable created outside the module declaring the type seems to properly initialize the components. I compile with -std=2018 so I would expect that invalid Fortran is flagged, at least with a warning, which is not the case.
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #4) > Should be closed as invalid as the original code contains a number > of issues caused by invalid code. Steve, stop it! My reduced testcase shows that there is a real bug.
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #2) > I think there already exists at least one PR with issues with initializers. > > A reduced testcase shows that default initialization works for intent(out), > whereas you get random junk for function results. (code elide) > If you need a workaround, uncomment the indicated line. The code is invalid Fortran. gfortran can do anything. Your work around is invalid. gfortran can do anything. >From Fortran 2018: "If the function result is not a pointer, its value shall be defined by the function." and "A derived-type scalar object is defined if and only if all of its nonpointer components are defined." Should be closed as invalid as the original code contains a number of issues caused by invalid code.
[Bug fortran/98445] Bogus error: derived type used as an actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- OK, closing as invalid as suggested by the original submitter.
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 --- Comment #3 from anlauf at gcc dot gnu.org --- According to the tree-dump, adding a print *, res% unit to the function body invokes the implicit initializer, while the line res = t() actually invokes the initializer effectively twice!
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-12-27 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- I think there already exists at least one PR with issues with initializers. A reduced testcase shows that default initialization works for intent(out), whereas you get random junk for function results. module m_test implicit none type t integer :: unit = -1 end type t interface test module procedure test_fun end interface contains function test_fun() result(res) type(t) :: res !res = t() ! <-- workaround end function test_fun subroutine test_sub (res) type(t), intent(out) :: res end subroutine test_sub end module m_test program p use m_test implicit none type(t) :: x write(6,*) 'Before constructor' write(6,*) ' unit = ', x%unit x = test() write(6,*) 'After constructor (test_fun)' write(6,*) ' unit = ', x%unit call test_sub (x) write(6,*) 'After test_sub' write(6,*) ' unit = ', x%unit end program p If you need a workaround, uncomment the indicated line.
[Bug c++/98456] New: Use of std::get instead of get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98456 Bug ID: 98456 Summary: Use of std::get instead of get Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: moub.ahmed at hotmail dot com Target Milestone: --- This uses std::get : https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/ranges#L3050 Whereas the standard uses get: https://eel.is/c++draft/range.elements#view Since std::get is not overloadable, this bug prevents custom tuple-like types to interoperate with std::ranges::views::keys/values for instance.
[Bug fortran/85877] [8/9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85877 --- Comment #6 from anlauf at gcc dot gnu.org --- Digging some more, it appears that the logic in resolve.c is incomplete. There is some inconsistency between what is dealt with in resolve_symbol and in resolve_fl_procedure. resolve_symbol: 15637 if (sym->attr.is_bind_c && sym->attr.use_assoc == 0 15638 && sym->attr.dummy == 0 && sym->attr.flavor != FL_PROCEDURE 15639 && sym->attr.flavor != FL_DERIVED) Commenting out the second half of line 15638 (sym->attr.flavor != FL_PROCEDURE) fixed the issue, but hell breaks loose in regtesting...
[Bug libstdc++/98449] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-12-27 Status|UNCONFIRMED |SUSPENDED --- Comment #1 from Jonathan Wakely --- The issue hasn't been accepted yet.
[Bug c++/98441] [11 Regression] member function pointer incorrectly parsed as having trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98441 Jonathan Wakely changed: What|Removed |Added Summary|[10/11 Regression] member |[11 Regression] member |function pointer|function pointer |incorrectly parsed as |incorrectly parsed as |having trailing return type |having trailing return type Target Milestone|10.3|11.0 Known to fail|10.2.0 | --- Comment #3 from Jonathan Wakely --- (In reply to Daniel Santos from comment #0) > However, it builds on GCC 9 and is alleged to build on MSVC. The above > example is simplified from the original sources: Are you sure this fails with 10.2.0? I only see it fail with 11.0 and not gcc version 10.2.1 20201125 (but I didn't try a newer build from the gcc-10 branch).
[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827 Tobias Burnus changed: What|Removed |Added Status|RESOLVED|REOPENED Ever confirmed|0 |1 Resolution|WONTFIX |--- Last reconfirmed||2020-12-27 --- Comment #13 from Tobias Burnus --- (In reply to Matthias Klose from comment #12) > Fyi, this is still seen with LLVM 11.0.1 rc2 But the fix (commit 700baa009dc685a0adc5f94d258be4ae24742471) is included in llvmorg-11.0.1-rc2. If the issue is still present, something else goes wrong. What's the error message? Is it really identical to the one of comment 0?
[Bug c++/98441] [10/11 Regression] member function pointer incorrectly parsed as having trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98441 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.3 Status|UNCONFIRMED |NEW Keywords||rejects-valid Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Summary|member function pointer |[10/11 Regression] member |incorrectly parsed as |function pointer |having trailing return type |incorrectly parsed as ||having trailing return type Last reconfirmed||2020-12-27 --- Comment #2 from Jonathan Wakely --- Started to be rejected with r11-2085: c++: Improve checking of decls with trailing return type [PR95820] This is an ICE-on-invalid but I've been seeing it when reducing various testcases, so it's more important for me than usually. splice_late_return_type now checks that if we've seen a late return type, the function return type was auto. That's a fair assumption but grokdeclarator/cdk_function wasn't giving errors for function pointers and similar. So we want to perform various checks not only when funcdecl_p || inner_declarator == NULL. But only give the !late_return_type errors when funcdecl_p, to accept e.g. auto (*fp)() = f;
[Bug c++/98440] [9/10/11 Regression] Accepts ill-formed reinterpret_cast(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98440 Jonathan Wakely changed: What|Removed |Added Known to fail||10.1.0, 11.0, 9.2.0 Target Milestone|--- |9.4 Summary|Accepts ill-formed |[9/10/11 Regression] |reinterpret_cast(1) |Accepts ill-formed ||reinterpret_cast(1) CC||jason at gcc dot gnu.org Known to work||8.3.0 --- Comment #1 from Jonathan Wakely --- This was correctly rejected until r260622: Fix cast to rvalue reference from prvalue. * cvt.c (diagnose_ref_binding): Handle rvalue reference. * rtti.c (build_dynamic_cast_1): Don't try to build a reference to non-class type. Handle xvalue argument. * typeck.c (build_reinterpret_cast_1): Allow cast from prvalue to rvalue reference. * semantics.c (finish_compound_literal): Do direct-initialization, not cast, to initialize a reference.
[Bug c++/98440] Accepts ill-formed reinterpret_cast(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98440 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-12-27 Status|UNCONFIRMED |NEW
[Bug tree-optimization/98444] [10 Regression] compile error with -ftracer and -Werror=format-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98444
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Last reconfirmed||2020-12-27
Status|UNCONFIRMED |NEW
Known to work||11.0, 9.3.0
Ever confirmed|0 |1
Known to fail||10.2.0
--- Comment #1 from Martin Sebor ---
The warning is based on the IL below where the %s argument is null, so it's
working correctly. It doesn't consider the complex control flow (bb2 -> b10 ->
bb5) from which it could deduce the asprintf call with the null pointer is only
reachable conditionally to issue a more nuanced message, but that wouldn't
prevent it, only make its conditional nature more apparent (all warnings are
conditional on the function they're in being called). The assertion that the
runtime pointer is nonnull is in export_legacy_dbus_address's caller,
configure_runtime_directory,
which is inlined into its caller, and has no effect on the code in
export_legacy_dbus_address. Adding something like:
if (!runtime) __builtin_unreachable ();
just before the problematic call to asprintf() avoids the warning.
In GCC 9 or on trunk (GCC 11), jump threading doesn't introduce the the invalid
call so the warning doesn't trigger. So I can confirm this regression for GCC
10 but I don't expect to be able to do anything about it there. Longer term,
we're aware of these warnings for synthesized code but we're still looking for
a solution to avoid them.
export_legacy_dbus_address (struct pam_handle_t * handle, const char * runtime)
{
...
[local count: 397250656]:
t = 0B;
if (runtime_22(D) != 0B)
goto ; [94.50%]
else
goto ; [5.50%]
[local count: 382684072]:
_65 = strlen (runtime_22(D));
_n__16 = _65 + 5;
if (_n__16 > 4194304)
goto ; [10.58%]
else
goto ; [89.42%]
[local count: 39725066]:
log_assert_failed_realm (0, "sizeof(char)*_n_ <= ALLOCA_MAX",
&"../src/login/pam_elogind.c"[3], 311, &__PRETTY_FUNCTION__);
[local count: 7591956]:
_10 = asprintf (, "unix:path=%s/bus", 0B); <<< warning here
if (_10 < 0)
goto ; [26.36%]
else
goto ; [73.64%]
...
[local count: 21848788]:
_29 = __builtin_alloca (1);
*_29 = 0;
_appendees_ ={v} {CLOBBER};
_9 = access (_29, 0);
if (_9 < 0)
goto ; [42.09%]
else
goto ; [57.91%]
[Bug fortran/98445] Bogus error: derived type used as an actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445 --- Comment #3 from Rich Townsend --- OK, my code isn't valid -- it's not permitted to pass a generic procedure name as an actual argument. As such, gfortran is correct in its behavior. Happy for this one to be closed -- sorry for the false alarm!
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Your code is invalid Fortran for a few reasons. gfortran can do anything it wants with the code, which may or may not be what you expect. The bug should be closed with INVALID. I'll someone make that final determination.
[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93685 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:435e0cd4a06db5bdc5fc057e8cc7db21f4b3b421 commit r10-9177-g435e0cd4a06db5bdc5fc057e8cc7db21f4b3b421 Author: Harald Anlauf Date: Fri Dec 25 15:40:39 2020 +0100 PR fortran/93685 - ICE in gfc_constructor_append_expr, at fortran/constructor.c:135 Fix handling of F2018 enhancements to DATA statements that allows initialization of pointer components to derived types, and adjust error handling for the CHARACTER case. gcc/fortran/ChangeLog: * data.c (gfc_assign_data_value): Restrict use of create_character_initializer to constant initializers. * trans-expr.c (gfc_conv_initializer): Ensure that character initializer is constant, otherwise fall through to get the same error handling as for non-character cases. gcc/testsuite/ChangeLog: * gfortran.dg/pr93685_1.f90: New test. * gfortran.dg/pr93685_2.f90: New test. (cherry picked from commit 6e36772ba6a8173318c173508bd3254e4140b726)
[Bug rtl-optimization/97684] [11 Regression] ICE in reg_preferred_class, at reginfo.c:789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97684
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
Ever confirmed|0 |1
Last reconfirmed||2020-12-27
Status|UNCONFIRMED |NEW
--- Comment #2 from Uroš Bizjak ---
Confirmed as rtl-optimization PR.
Backtrace:
#2 0x006ac7a0 in reg_preferred_class (regno=regno@entry=170) at
../../git/gcc/gcc/reginfo.c:794
#3 0x00bebf37 in update_equiv_regs () at ../../git/gcc/gcc/ira.c:3521
#4 0x00bf23fb in ira (f=) at
../../git/gcc/gcc/ira.c:5554
where in reg_preferred_class, an assert is triggered:
789 reg_preferred_class (int regno)
790 {
791 if (reg_pref == 0)
792 return GENERAL_REGS;
793
794 gcc_assert (regno < reg_info_size);
795 return (enum reg_class) reg_pref[regno].prefclass;
796 }
(gdb) p regno
$4 = 170
(gdb) p reg_info_size
$5 = 167
where regno is outside reg_info_size.
[Bug rtl-optimization/98439] [11 Regression] ICE in final_scan_insn_1, at final.c:3096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98439 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'd say that is a backend bug that perhaps need some middle-end help, in particular the last split pass should set some flag and insns that require splitting should check that flag to avoid matching after the last splitting.
[Bug rtl-optimization/98439] [11 Regression] ICE in final_scan_insn_1, at final.c:3096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98439
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
Last reconfirmed||2020-12-27
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Uroš Bizjak ---
Confirmed as rtl-optimization problem.
Before sched2 pass, we have:
(insn 26 7 8 2 (set (reg:SI 0 ax [85])
(reg:SI 20 xmm0 [89])) "pr98439.c":9:10 75 {*movsi_internal}
(insn 8 26 39 2 (set (mem:SI (pre_modify:DI (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -8 [0xfff8]))) [0 S4 A32])
(reg:SI 0 ax [85])) "pr98439.c":9:10 53 {*pushsi2_rex64}
which is transformed by sched2 pass to:
(insn:TI 46 44 26 2 (set (mem:SI (pre_modify:DI (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -8 [0xfff8]))) [0 S4 A32])
(reg:SI 20 xmm0 [89])) 53 {*pushsi2_rex64}
(insn 26 46 15 2 (set (reg:SI 0 ax [85])
(reg:SI 20 xmm0 [89])) "pr98439.c":9:10 75 {*movsi_internal}
(insn 46) is defined in i386.md as:
(define_insn "*pushsi2_rex64"
[(set (match_operand:SI 0 "push_operand" "=X,X")
(match_operand:SI 1 "nonmemory_no_elim_operand" "re,*v"))]
"TARGET_64BIT"
"@
push{q}\t%q1
#"
[(set_attr "type" "push,multi")
(set_attr "mode" "DI")])
xmm0 is allowed by *v constraint, but the insn has to be split. Since sched2
pass comes after split3 pass, we hit the assert in final_scan_insn_1:
/* If the template is the string "#", it means that this insn must
be split. */
if (templ[0] == '#' && templ[1] == '\0')
{
rtx_insn *new_rtx = try_split (body, insn, 0);
/* If we didn't split the insn, go away. */
if (new_rtx == insn && PATTERN (new_rtx) == body)
fatal_insn ("could not split insn", insn);
/* If we have a length attribute, this instruction should have
been split in shorten_branches, to ensure that we would have
valid length info for the splitees. */
--> gcc_assert (!HAVE_ATTR_length);
return new_rtx;
}
As the comment says, this insn should have been split in shorten_branches, but:
/* The placement of the splitting that we do for shorten_branches
depends on whether regstack is used by the target or not. */
#if HAVE_ATTR_length && !defined (STACK_REGS)
return true;
#else
return false;
#endif
and nothing splits insns after sched2, because:
bool
pass_split_before_regstack::gate (function *)
{
#if HAVE_ATTR_length && defined (STACK_REGS)
/* If flow2 creates new instructions which need splitting
and scheduling after reload is not done, they might not be
split until final which doesn't allow splitting
if HAVE_ATTR_length. */
return !enable_split_before_sched2 ();
#else
return false;
#endif
}
and finally:
static bool
enable_split_before_sched2 (void)
{
#ifdef INSN_SCHEDULING
return optimize > 0 && flag_schedule_insns_after_reload;
#else
return false;
#endif
}
[Bug target/97684] [11 Regression] ICE in reg_preferred_class, at reginfo.c:789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97684
Arseny Solokha changed:
What|Removed |Added
Target|powerpc-*-linux-gnu |powerpc-*-linux-gnu,
||x86_64-unknown-linux-gnu
--- Comment #1 from Arseny Solokha ---
void
c5 (double);
void
g4 (int *n4)
{
double lp = 0.0;
int fn;
for (fn = 0; fn < 18; ++fn)
{
int as;
as = __builtin_abs (n4[fn]);
if (as > lp)
lp = as;
}
c5 (lp);
}
% x86_64-unknown-linux-gnu-gcc-11.0.0 -O1 -flive-range-shrinkage
-fschedule-insns -fselective-scheduling -funroll-all-loops -fno-web -c
s0owgzp5.c
during RTL pass: ira
s0owgzp5.c: In function 'g4':
s0owgzp5.c:20:1: internal compiler error: in reg_preferred_class, at
reginfo.c:794
20 | }
| ^
0x6b0710 reg_preferred_class(int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/reginfo.c:794
0xc0f2e8 update_equiv_regs
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/ira.c:3521
0xc154c5 ira
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/ira.c:5554
0xc154c5 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/ira.c:5945
(As of gcc-11.0.0-alpha20201220 snapshot,
g:18e86fae2a14f78e70aae06afce6bb9853068bb1.)
[Bug tree-optimization/98455] New: [11 Regression] ICE: verify_gimple failed (error: invalid 'PHI' argument; error: incompatible types in 'PHI' argument 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98455
Bug ID: 98455
Summary: [11 Regression] ICE: verify_gimple failed (error:
invalid 'PHI' argument; error: incompatible types in
'PHI' argument 2)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-11.0.0-alpha20201220 snapshot (g:18e86fae2a14f78e70aae06afce6bb9853068bb1)
ICEs when compiling the following testcase w/ -O1 -fno-tree-dce --param
case-values-threshold=1:
void
n4 (int io, int vb)
{
double uc[2] = { 1.0, 2.0, };
if (io == 0)
uc[0] = 0.0;
for (;;)
if (io == 0)
if (vb == 0)
uc[0] = uc[1];
else if (vb == 1)
uc[1] = 0.0;
}
% gcc-11.0.0 -O1 -fno-tree-dce --param case-values-threshold=1 -c y2iyiouv.c
y2iyiouv.c: In function 'n4':
y2iyiouv.c:15:1: error: invalid 'PHI' argument
15 | }
| ^
uc$1_12
y2iyiouv.c:15:1: error: incompatible types in 'PHI' argument 2
void
double
.MEM_2 = PHI <.MEM_3(D)(2), .MEM_2(5), uc$1_12(4), .MEM_2(3), .MEM_2(6)>
y2iyiouv.c:15:1: error: missing 'PHI' def
uc$1_12 = PHI <2.0e+0(2), uc$1_12(5), (4), uc$1_12(3), 0.0(6)>
during GIMPLE pass: iftoswitch
y2iyiouv.c:15:1: internal compiler error: verify_gimple failed
0xe4523a verify_gimple_in_cfg(function*, bool)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/tree-cfg.c:5467
0xd16c37 execute_function_todo
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/passes.c:2042
0xd1764b execute_todo
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/passes.c:2096
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 --- Comment #7 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c4a678981572c12d158709ace0d3f23dd04cf217 commit r11-6346-gc4a678981572c12d158709ace0d3f23dd04cf217 Author: Paul Thomas Date: Sun Dec 27 14:59:38 2020 + Fortran: Fix some select rank issues [PR97694 and 97723]. 2020-12-27 Paul Thomas gcc/fortran PR fortran/97694 PR fortran/97723 * check.c (allocatable_check): Select rank temporaries are permitted even though they are treated as associate variables. * resolve.c (gfc_resolve_code): Break on select rank as well as select type so that the block os resolved. * trans-stmt.c (trans_associate_var): Class associate variables that are optional dummies must use the backend_decl. gcc/testsuite/ PR fortran/97694 PR fortran/97723 * gfortran.dg/select_rank_5.f90: New test.
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 --- Comment #5 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c4a678981572c12d158709ace0d3f23dd04cf217 commit r11-6346-gc4a678981572c12d158709ace0d3f23dd04cf217 Author: Paul Thomas Date: Sun Dec 27 14:59:38 2020 + Fortran: Fix some select rank issues [PR97694 and 97723]. 2020-12-27 Paul Thomas gcc/fortran PR fortran/97694 PR fortran/97723 * check.c (allocatable_check): Select rank temporaries are permitted even though they are treated as associate variables. * resolve.c (gfc_resolve_code): Break on select rank as well as select type so that the block os resolved. * trans-stmt.c (trans_associate_var): Class associate variables that are optional dummies must use the backend_decl. gcc/testsuite/ PR fortran/97694 PR fortran/97723 * gfortran.dg/select_rank_5.f90: New test.
[Bug fortran/98454] New: Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 Bug ID: 98454 Summary: Apparent wrong initialization in function result Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fmartinez at gmv dot com Target Milestone: --- Created attachment 49845 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49845=edit Module with type implmentation and test driver Good morning. The components of a derived type seem to be wrongly initialized when they type is the output of a function (see code attached). I would expect that any declaration of the type type(t_test) :: x would lead to all components initialized with the values explicitly provided in the type declaration. It seem not to be the case in the attached example. Before constructor unit = -1 default =0 trace = T def trace = F After constructor unit = -1230083984 default =21901 trace = T def trace = F I have tried with Intel 19.1 and it provides the expected behaviour. Before constructor unit = -1 default =0 trace = T def trace = F After constructor unit = -1 default =0 trace = T def trace = F The same behaviour is observed in gfortran 11 Best regards, Fran
[Bug target/98453] New: aarch64: Missed opportunity for STP for vec_duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98453
Bug ID: 98453
Summary: aarch64: Missed opportunity for STP for vec_duplicate
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
typedef long long v2di __attribute__((vector_size (16)));
typedef int v2si __attribute__((vector_size (8)));
void
foo (v2di *x, long long a)
{
v2di tmp = {a, a};
*x = tmp;
}
void
foo2 (v2si *x, int a)
{
v2si tmp = {a, a};
*x = tmp;
}
at -O2 on aarch64 gives:
foo:
dup v0.2d, x1
str q0, [x0]
ret
foo2:
dup v0.2s, w1
str d0, [x0]
ret
These could just be: stp x1, x1, [x0] and stp w1, w1, [x0]
Combine already tries and fails to match:
(set (mem:V2DI (reg:DI 97) [1 *x_4(D)+0 S16 A128])
(vec_duplicate:V2DI (reg:DI 98)))
and
(set (mem:V2SI (reg:DI 97) [2 *x_4(D)+0 S8 A64])
(vec_duplicate:V2SI (reg:SI 98)))
So can be fixed by some new patterns in aarch64-simd.md.
We should make sure to handle the other 32-bit and 64-bit modes as well
[Bug c++/98452] New: error: unknown Compiled Module Interface: no such module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98452 Bug ID: 98452 Summary: error: unknown Compiled Module Interface: no such module Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: patrick.kox at commandoregel dot be Target Milestone: --- When following an article by Mr. Sidwell (link: https://accu.org/journals/overload/28/159/sidwell/#FN02) I did a copy & paste of his example 2 sourcecode (a simple hello world progam). When I just try to compile the hello.cc sourcefile there is an error message (as expected): hello.cc:5:8: error: unknown Compiled Module Interface: no such module 5 | export import ; |^~ In module imported at hello.cc:5:8: /opt/gcc-11/include/c++/11.0.0/string_view: error: failed to read compiled module: Unknown CMI mapping /opt/gcc-11/include/c++/11.0.0/string_view: note: imports must be built before being imported /opt/gcc-11/include/c++/11.0.0/string_view: fatal error: returning to the gate for a mechanical issue compilation terminated. To solve this he provides a compiler command to process string_view so it can be used in this example: The command for that is: g++ -fmodules-ts -std=c++20 -c -x c++-system-header string_view This works and creates a file string_view.gcm in a subdirectory of the gcm.cache directory. But when I try to compile hello.cc with the command that should follow this processing of string_view the compiler prints out a lot of error messages: hello.cc:5:8: error: unknown Compiled Module Interface: no such module 5 | export import ; |^~ In module imported at hello.cc:5:8: /opt/gcc-11/include/c++/11.0.0/string_view: error: failed to read compiled module: Unknown CMI mapping /opt/gcc-11/include/c++/11.0.0/string_view: note: imports must be built before being imported /opt/gcc-11/include/c++/11.0.0/string_view: fatal error: returning to the gate for a mechanical issue compilation terminated. patrick @ XPS8940 ➜ Example_02 $ g++ -fmodules-ts -std=c++20 -c -x c++-system-header string_view patrick @ XPS8940 ➜ Example_02 $ g++ -fmodules-ts -Wall -std=c++20 hello.cc -x -c In file included from /opt/gcc-11/include/c++/11.0.0/bits/move.h:57, from /opt/gcc-11/include/c++/11.0.0/bits/stl_pair.h:59, from /opt/gcc-11/include/c++/11.0.0/bits/stl_algobase.h:64, from /opt/gcc-11/include/c++/11.0.0/bits/char_traits.h:39, from /opt/gcc-11/include/c++/11.0.0/string_view:41, of module /opt/gcc-11/include/c++/11.0.0/string_view, imported at /opt/gcc-11/include/c++/11.0.0/bits/basic_string.h:48, included from /opt/gcc-11/include/c++/11.0.0/string:55, from /opt/gcc-11/include/c++/11.0.0/bits/locale_classes.h:40, from /opt/gcc-11/include/c++/11.0.0/bits/ios_base.h:41, from /opt/gcc-11/include/c++/11.0.0/ios:42, from /opt/gcc-11/include/c++/11.0.0/ostream:38, from /opt/gcc-11/include/c++/11.0.0/iostream:39, from hello.cc:3: /opt/gcc-11/include/c++/11.0.0/type_traits:634:31: error: conflicting global module declaration ‘template using __void_t = void’ 634 | template using __void_t = void; | ^~~~ In file included from /opt/gcc-11/include/c++/11.0.0/bits/move.h:57, from /opt/gcc-11/include/c++/11.0.0/bits/nested_exception.h:40, from /opt/gcc-11/include/c++/11.0.0/exception:148, from /opt/gcc-11/include/c++/11.0.0/ios:39, from /opt/gcc-11/include/c++/11.0.0/ostream:38, from /opt/gcc-11/include/c++/11.0.0/iostream:39, from hello.cc:3: /opt/gcc-11/include/c++/11.0.0/type_traits:634:31: note: existing declaration ‘template using __void_t = void’ 634 | template using __void_t = void; | ^~~~ In file included from /opt/gcc-11/include/c++/11.0.0/string:55, from /opt/gcc-11/include/c++/11.0.0/bits/locale_classes.h:40, from /opt/gcc-11/include/c++/11.0.0/bits/ios_base.h:41, from /opt/gcc-11/include/c++/11.0.0/ios:42, from /opt/gcc-11/include/c++/11.0.0/ostream:38, from /opt/gcc-11/include/c++/11.0.0/iostream:39, from hello.cc:3: /opt/gcc-11/include/c++/11.0.0/bits/basic_string.h:94:26: note: during load of binding ‘__gnu_cxx::__normal_iterator’ 94 | typedef __gnu_cxx::__normal_iterator iterator; | ^ In file included from /opt/gcc-11/include/c++/11.0.0/bits/stl_iterator_base_types.h:71, from /opt/gcc-11/include/c++/11.0.0/bits/stl_algobase.h:65, from
[Bug c++/98451] New: Re-exporting iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98451 Bug ID: 98451 Summary: Re-exporting iostream Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: patrick.kox at commandoregel dot be Target Milestone: --- I'm following an article by Mr. Sidwell on C++ Modules (link: https://accu.org/journals/overload/28/159/sidwell/#FN02) Around Example 02 he processes string_view to be able to use it in example 02, this command works with string_view, but it fails with iostream the command is: g++ -fmodules-ts -std=c++20 -c -x c++-system-header string_view when string_view is copied to the source directory this creates a gcm file in a subdirectory of gcm.cache using this command with iostream there is the following output: In file included from /opt/gcc-11/include/c++/11.0.0/bits/move.h:57, from /opt/gcc-11/include/c++/11.0.0/bits/stl_pair.h:59, from /opt/gcc-11/include/c++/11.0.0/bits/stl_algobase.h:64, from /opt/gcc-11/include/c++/11.0.0/bits/char_traits.h:39, from /opt/gcc-11/include/c++/11.0.0/string_view:41, of module /opt/gcc-11/include/c++/11.0.0/string_view, imported at /opt/gcc-11/include/c++/11.0.0/bits/basic_string.h:48, included from /opt/gcc-11/include/c++/11.0.0/string:55, from /opt/gcc-11/include/c++/11.0.0/bits/locale_classes.h:40, from /opt/gcc-11/include/c++/11.0.0/bits/ios_base.h:41, from /opt/gcc-11/include/c++/11.0.0/ios:42, from /opt/gcc-11/include/c++/11.0.0/ostream:38, from /opt/gcc-11/include/c++/11.0.0/iostream:39: /opt/gcc-11/include/c++/11.0.0/type_traits:634:31: error: conflicting global module declaration ‘template using __void_t = void’ 634 | template using __void_t = void; | ^~~~ In file included from /opt/gcc-11/include/c++/11.0.0/bits/move.h:57, from /opt/gcc-11/include/c++/11.0.0/bits/nested_exception.h:40, from /opt/gcc-11/include/c++/11.0.0/exception:148, from /opt/gcc-11/include/c++/11.0.0/ios:39, from /opt/gcc-11/include/c++/11.0.0/ostream:38, from /opt/gcc-11/include/c++/11.0.0/iostream:39: /opt/gcc-11/include/c++/11.0.0/type_traits:634:31: note: existing declaration ‘template using __void_t = void’ 634 | template using __void_t = void; | ^~~~ In file included from /opt/gcc-11/include/c++/11.0.0/string:55, from /opt/gcc-11/include/c++/11.0.0/bits/locale_classes.h:40, from /opt/gcc-11/include/c++/11.0.0/bits/ios_base.h:41, from /opt/gcc-11/include/c++/11.0.0/ios:42, from /opt/gcc-11/include/c++/11.0.0/ostream:38, from /opt/gcc-11/include/c++/11.0.0/iostream:39: /opt/gcc-11/include/c++/11.0.0/bits/basic_string.h:94:26: note: during load of binding ‘__gnu_cxx::__normal_iterator’ 94 | typedef __gnu_cxx::__normal_iterator iterator; | ^ In file included from /opt/gcc-11/include/c++/11.0.0/bits/stl_iterator_base_types.h:71, from /opt/gcc-11/include/c++/11.0.0/bits/stl_algobase.h:65, from /opt/gcc-11/include/c++/11.0.0/bits/char_traits.h:39, from /opt/gcc-11/include/c++/11.0.0/string_view:41, of module /opt/gcc-11/include/c++/11.0.0/string_view, imported at /opt/gcc-11/include/c++/11.0.0/bits/basic_string.h:48, included from /opt/gcc-11/include/c++/11.0.0/string:55, from /opt/gcc-11/include/c++/11.0.0/bits/locale_classes.h:40, from /opt/gcc-11/include/c++/11.0.0/bits/ios_base.h:41, from /opt/gcc-11/include/c++/11.0.0/ios:42, from /opt/gcc-11/include/c++/11.0.0/ostream:38, from /opt/gcc-11/include/c++/11.0.0/iostream:39: /opt/gcc-11/include/c++/11.0.0/bits/iterator_concepts.h:76:11: error: conflicting global module declaration ‘template using iter_reference_t = decltype (* declval<_Tp&>())’ 76 | using iter_reference_t = decltype(*std::declval<_Tp&>()); | ^~~~ In file included from /opt/gcc-11/include/c++/11.0.0/bits/stl_iterator_base_types.h:71, from /opt/gcc-11/include/c++/11.0.0/bits/stl_algobase.h:65, from /opt/gcc-11/include/c++/11.0.0/bits/char_traits.h:39, from /opt/gcc-11/include/c++/11.0.0/ios:40, from /opt/gcc-11/include/c++/11.0.0/ostream:38, from /opt/gcc-11/include/c++/11.0.0/iostream:39: /opt/gcc-11/include/c++/11.0.0/bits/iterator_concepts.h:76:11: note: existing declaration ‘template requires __dereferenceable<_Tp> using iter_reference_t = decltype
[Bug fortran/92976] [8 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #6 from Ev Drikos --- Hello Thomas, It's my impression that the solution in this PR may be a prerequisite for other PRs, ie PR/92065. Are there any plans for updating also the branch gcc-8, or it has been closed? Ev. Drikos
