[Bug fortran/108168] New: ICE in a simple module that almost any change eliminates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108168 Bug ID: 108168 Summary: ICE in a simple module that almost any change eliminates Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Extracted a reproducer that is only a few lines from a large module, but do not see what is going on. Even moving the order of the subroutines, declaring i in the subroutine instead of the top of the module, or just about any change eliminates the problem, and it does not occur on my machine with version 10 of gfortran. module m_module integer :: i contains subroutine subaaa() do i=1,2 call su() enddo end subroutine subaaa subroutine su() call random_number(r) end subroutine su subroutine subccc() call subaaa() end subroutine subccc end module m_module gfortran -c M_module.f90 951: internal compiler error: Segmentation fault 0x14f925f1108f ??? /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x14f925ef2082 __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. gfortran --version GNU Fortran (Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Linux mercury 5.4.0-132-generic #148-Ubuntu SMP Mon Oct 17 16:02:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
[Bug d/108167] New: d: internal compiler error: in binary_op, at d/expr.cc:117
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108167
Bug ID: 108167
Summary: d: internal compiler error: in binary_op, at
d/expr.cc:117
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gcc dot gnu.org
Target Milestone: ---
auto gdcTrunkICE(const(ubyte[32])[] a)
{
return cast(const(ubyte)*)&a[1][0];
}
Caused by a front-end change that changed `&a[1][0]` into `&a[1] + null`.
[Bug tree-optimization/108166] [12/13 Regression] Wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.3
Last reconfirmed||2022-12-18
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed.
# iftmp.2_17 = PHI
if (iftmp.2_17 != 0)
goto ; [INV]
else
goto ; [INV]
:
:
# iftmp.1_16 = PHI
_7 = _4 > iftmp.1_16;
_8 = (int) _7;
c = _8;
D.3392 ={v} {CLOBBER(eol)};
D.3393 ={v} {CLOBBER(eol)};
_11 = iftmp.2_17 != 0;
And then _11 gets replaced with:
_6 = iftmp.2_10 != 0;
I can't figure out why though.
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|13.0|10.5
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.0
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-13, and on all open branches. Closing. Thanks for the report, and to Paul for the fix!
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6f2f588377e6437ae23fb83aa2c85e03e1f41678 commit r10-11127-g6f2f588377e6437ae23fb83aa2c85e03e1f41678 Author: Paul Thomas Date: Fri Dec 9 22:13:45 2022 +0100 Fortran: ICE on recursive derived types with allocatable components [PR107872] gcc/fortran/ChangeLog: PR fortran/107872 * resolve.c (derived_inaccessible): Skip over allocatable components to prevent an infinite loop. gcc/testsuite/ChangeLog: PR fortran/107872 * gfortran.dg/pr107872.f90: New test. (cherry picked from commit 01254aa2eb766c7584fd047568d7277d4d65d067)
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:cc956b955d12881c9b2b970ee52b337d1ef44930 commit r11-10427-gcc956b955d12881c9b2b970ee52b337d1ef44930 Author: Paul Thomas Date: Fri Dec 9 22:13:45 2022 +0100 Fortran: ICE on recursive derived types with allocatable components [PR107872] gcc/fortran/ChangeLog: PR fortran/107872 * resolve.c (derived_inaccessible): Skip over allocatable components to prevent an infinite loop. gcc/testsuite/ChangeLog: PR fortran/107872 * gfortran.dg/pr107872.f90: New test. (cherry picked from commit 01254aa2eb766c7584fd047568d7277d4d65d067)
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7a9741d7322357c4e777450891e43db27e067817 commit r12-8991-g7a9741d7322357c4e777450891e43db27e067817 Author: Paul Thomas Date: Fri Dec 9 22:13:45 2022 +0100 Fortran: ICE on recursive derived types with allocatable components [PR107872] gcc/fortran/ChangeLog: PR fortran/107872 * resolve.cc (derived_inaccessible): Skip over allocatable components to prevent an infinite loop. gcc/testsuite/ChangeLog: PR fortran/107872 * gfortran.dg/pr107872.f90: New test. (cherry picked from commit 01254aa2eb766c7584fd047568d7277d4d65d067)
[Bug tree-optimization/108166] New: [12/13 Regression] Wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166
Bug ID: 108166
Summary: [12/13 Regression] Wrong code with -O2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskiy at gmail dot com
Target Milestone: ---
Link to the Compiler Explorer: https://godbolt.org/z/j8coqj375
Reproducer:
#include
bool a, b;
int d, c;
const int &e(const int &f, const int &g) { return !f ? f : g; }
int main() {
c = e(b, 0) > ((b ? d : b) ?: 8);
a = b ? d : b;
printf("%d\n", a);
if (a != 0)
__builtin_abort();
}
Error:
>$ g++ -O2 driver.cpp && ./a.out
1
Aborted (core dumped)
>$ g++ -O0 driver.cpp && ./a.out
0
gcc version 13.0.0 20221216 (2fdc8546b5c6cb1fe254e40b5bdd19ed6fbb44da)
[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=znver3 since r13-4685-g4834e9360f7bf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
Manuel Lauss changed:
What|Removed |Added
CC||manuel.lauss at googlemail dot
com
--- Comment #12 from Manuel Lauss ---
Created attachment 54122
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54122&action=edit
unreduced test case
I've attached another testcase:
-O2 and -march with AVX support are essential to trigger it:
moya ~ # g++ -c ipa-param-manipulation.i -O1 -march=core-avx-i
moya ~ # g++ -c ipa-param-manipulation.i -O3 -march=core-avx-i
moya ~ # g++ -c ipa-param-manipulation.i -O2 -march=core-avx-i
during IPA pass: inline
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/tuple:41,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/unique_ptr.h:36,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/memory:78,
from src/mongo/util/background.h:32,
from src/mongo/util/background.cpp:34:
In function 'constexpr _Res std::__invoke_impl(__invoke_other, _Fn&&, _Args&&
...) [with _Res = void; _Fn =
mongo::logv2::detail::doLog::FMT_COMPILE_STRING,
14, NamedArg,
std::allocator >&>, NamedArg > >
>(int32_t, const mongo::logv2::LogSeverity&, const mongo::logv2::LogOptions&,
const
mongo::{anonymous}::PeriodicTaskRunner::_runTask(mongo::PeriodicTask*)FMT_COMPILE_STRING&,
const char (&)[14], const NamedArg&>&,
const NamedArg > >&)::; _Args = {const mongo::logv2::detail::NamedArg, allocator >&>&, const
mongo::logv2::detail::NamedArg > >&}]',
inlined from 'constexpr typename std::__invoke_result<_Functor,
_ArgTypes>::type std::__invoke(_Callable&&, _Args&& ...) [with _Callable =
mongo::logv2::detail::doLog::FMT_COMPILE_STRING,
14, NamedArg,
std::allocator >&>, NamedArg > >
>(int32_t, const mongo::logv2::LogSeverity&, const mongo::logv2::LogOptions&,
const
mongo::{anonymous}::PeriodicTaskRunner::_runTask(mongo::PeriodicTask*)FMT_COMPILE_STRING&,
const char (&)[14], const NamedArg&>&,
const NamedArg > >&)::; _Args = {const mongo::logv2::detail::NamedArg, allocator >&>&, const
mongo::logv2::detail::NamedArg > >&}]' at
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/invoke.h:96:40,
inlined from 'constexpr decltype(auto) std::__apply_impl(_Fn&&, _Tuple&&,
index_sequence<_Idx ...>) [with _Fn =
mongo::logv2::detail::doLog::FMT_COMPILE_STRING,
14, NamedArg,
std::allocator >&>, NamedArg > >
>(int32_t, const mongo::logv2::LogSeverity&, const mongo::logv2::LogOptions&,
const
mongo::{anonymous}::PeriodicTaskRunner::_runTask(mongo::PeriodicTask*)FMT_COMPILE_STRING&,
const char (&)[14], const NamedArg&>&,
const NamedArg > >&)::; _Tuple = tuple, allocator >&>&, const
mongo::logv2::detail::NamedArg > >&>; long
unsigned int ..._Idx = {0, 1}]' at
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/tuple:2287:27,
inlined from 'constexpr decltype(auto) std::apply(_Fn&&, _Tuple&&) [with
_Fn =
mongo::logv2::detail::doLog::FMT_COMPILE_STRING,
14, NamedArg,
std::allocator >&>, NamedArg > >
>(int32_t, const mongo::logv2::LogSeverity&, const mongo::logv2::LogOptions&,
const
mongo::{anonymous}::PeriodicTaskRunner::_runTask(mongo::PeriodicTask*)FMT_COMPILE_STRING&,
const char (&)[14], const NamedArg&>&,
const NamedArg > >&)::; _Tuple = tuple, allocator >&>&, const
mongo::logv2::detail::NamedArg > >&>]' at
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/tuple:2298:31,
inlined from 'void mongo::logv2::detail::doLog(int32_t, const
mongo::logv2::LogSeverity&, const mongo::logv2::LogOptions&, const S&, const
char (&)[N], const Args& ...) [with S =
mongo::{anonymous}::PeriodicTaskRunner::_runTask(mongo::PeriodicTask*)FMT_COMPILE_STRING;
long unsigned int N = 14; Args = {NamedArg, std::allocator
>&>, NamedArg > >}]' at
src/mongo/logv2/log_detail.h:121:15,
inlined from 'void
mongo::{anonymous}::PeriodicTaskRunner::_runTask(mongo::PeriodicTask*)' at
src/mongo/util/background.cpp:358:440:
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/invoke.h:61:36:
internal compiler error: in modify_call, at ipa-param-manipulation.cc:700
61 | { return std::forward<_Fn>(__f)(std::forward<_Args>(__args)...); }
| ~~^~~~
0x1ced1ad internal_error(char const*, ...)
???:0
0x6be47f fancy_abort(char const*, int, char const*)
???:0
0x9bfc8e cgraph_edge::redirect_call_stmt_to_callee(cgraph_edge*)
???:0
0xe54a9b redirect_all_calls(copy_body_data*, basic_block_def*)
???:0
0xe601bb optimize_inline_calls(tree_node*)
???:0
0xbbd42b inline_transform(cgraph_node*)
???:0
0xd125df execute_all_ipa_transforms(bool)
???:0
0x9c640f cgraph_node::expand()
???:0
0x9c9f77 symbol_table::finalize_compilation_unit()
???:0
[Bug c++/108165] -Wdangling-reference false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165 --- Comment #3 from Romain Geissler --- In my real life case B was std::string and used a "string literal" at call site, and I guess using the implicit conversion from const char[] to std::string is something that might happen in many call sites in big code bases. Is it expected that -Wdangling-reference doesn't take into account the definition of f ? The problem of dangling reference in general needs function definitions to be effective, otherwise I fear there might be quite some false positives.
[Bug c++/108165] -Wdangling-reference false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165 --- Comment #2 from Andrew Pinski --- or is it because of the different types? GCC does not look into that either and does not look into if they are castable either ...
[Bug c++/108165] -Wdangling-reference false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165 --- Comment #1 from Andrew Pinski --- So at the warning is not flow sensitive at all and does not take into account the definition of f; only the call location of f is taken into account. In this case, the call site of f has a temporary and the warning is saying possibly because a temporary is made in the call arguments of f.
[Bug tree-optimization/108164] [12/13 Regression] wrong code with "-O3 -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108164 Andrew Pinski changed: What|Removed |Added Known to fail||12.1.0 Keywords||needs-bisection Known to work||11.3.0 --- Comment #2 from Andrew Pinski --- Seems vectorizer related ...
[Bug tree-optimization/108164] [12/13 Regression] wrong code with "-O3 -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108164 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/108165] New: -Wdangling-reference false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165 Bug ID: 108165 Summary: -Wdangling-reference false positive Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, The following snippet issues a wrong -Wdangling-reference warning when compiled with -Wall with current gcc trunk: <: In function 'const A& g(const A&)': :13:14: warning: possibly dangling reference to a temporary [-Wdangling-reference] 13 | const A& result = f(a, 42); | ^~ :13:24: note: the temporary was destroyed at the end of the full expression 'f((* & a), B(42))' 13 | const A& result = f(a, 42); | ~^~~ ASM generation compiler returned: 0 : In function 'const A& g(const A&)': :13:14: warning: possibly dangling reference to a temporary [-Wdangling-reference] 13 | const A& result = f(a, 42); | ^~ :13:24: note: the temporary was destroyed at the end of the full expression 'f((* & a), B(42))' 13 | const A& result = f(a, 42); | ~^~~
[Bug tree-optimization/108164] [12/13 Regression] wrong code with "-O3 -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108164 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Summary|wrong code with "-O3|[12/13 Regression] wrong |-fno-tree-dce" on |code with "-O3 |x86_64-linux-gnu|-fno-tree-dce" on ||x86_64-linux-gnu Target Milestone|--- |12.3
[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147 --- Comment #13 from Segher Boessenkool --- (In reply to Gaius Mulley from comment #11) > Yes is looks as if '%' could be propagated though into the first parameter. > Changes could be made to m2linemap.cc to bump the parameters as you say with > "%s" as the first. Compiling with -Wformat-security points out such problems. This is included in -Wformat=2 which should be in -Wextra at least (but isn't), and would be good to have in -Wall even imo.
[Bug tree-optimization/108164] New: wrong code with "-O3 -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108164
Bug ID: 108164
Summary: wrong code with "-O3 -fno-tree-dce" on
x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a regression from 11.*, and affects 12.* and the trunk.
Compiler Explorer: https://godbolt.org/z/Ko61s9WP4
[580] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221218 (experimental) [master r13-4763-g92bc3617572] (GCC)
[581] %
[581] % gcctk -O3 small.c; ./a.out
[582] %
[582] % gcctk -O3 -fno-tree-dce small.c
[583] % ./a.out
Floating point exception
[584] %
[584] % cat small.c
int a, b, c;
int main() {
int e = -1;
short f = -1;
for (; c < 1; c++)
while (f >= e)
f++;
for (; a < 2; a++) {
short g = ~(~b | ~f);
int h = -g;
int i = (3 / ~h) / ~b;
b = i;
}
return 0;
}
[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 --- Comment #10 from Rimvydas (RJ) --- Created attachment 54121 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54121&action=edit testcase fix
[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 Rimvydas (RJ) changed: What|Removed |Added CC||rimvydas.jas at gmail dot com --- Comment #9 from Rimvydas (RJ) --- Newly added testcase has few typos in dg-error directives and results in testsuite failures (fixes are trivial): Running target unix FAIL: gfortran.dg/pr107397.f90 -O (test for errors, line 7) FAIL: gfortran.dg/pr107397.f90 -O (test for excess errors)
[Bug modula2/108122] gcc/testsuite/gm2/pimcoroutines/run/pass/testtime.mod runs too long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108122 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Gaius Mulley --- patch applied and PR closed.
[Bug modula2/108153] Profiled lto bootstrap failure with modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 --- Comment #3 from Gaius Mulley --- On x86_64 the build succeed using MAKEFLAGS=profiledbootstrap-lean CONFIGFLAGS=--with-build-config=bootstrap-lto-lean however I do see many ODR violations (from the output of the bootstrap tool mc). It would be interesting to double check there is no use of varags here.
[Bug c/108054] C2X auto with struct defined in statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108054
--- Comment #3 from Martin Uecker ---
It is a major usability issue for its intended use in macros if it then
sometimes breaks due to arbitrary constraints (which __auto_type does not have,
so do not seem to be essential).
Also with the new tag rules in C2X you could also write this without 'auto'
because one could redeclare the type:
void foo(void)
{
struct foo { int x; } a = (struct foo { int x; }){ 0 };
}
Finally, this example also does not work:
int foo(void)
{
auto x = ({ struct foo { int x; } a = { }; a.x; });
// int x = ({ struct foo { int x; } a = { }; a.x; });
}
Again, regular use of ({ }) in macros would not work without problems with
'auto' and cause random problem.s
int foo(void)
{
int x = FOO(0); // works
auto y = FOO(0); // mit break when FOO uses ({ })
}
