[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #300 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #297) > > > > && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG > > > && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG > > > && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG" > > > > Out of curiousity, why are these checks needed? > > Otherwise, operands[2-4] can be replaced by another register. I've seen that > in some cases. So the checks fail the pattern match unless all hard regs are in place and so if something tries to change the reg operands in the insn it will fail and will stay put? Is that what's happening there?
[Bug tree-optimization/116799] New: [14 Regression] Miscompiled code on s390x at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799
Bug ID: 116799
Summary: [14 Regression] Miscompiled code on s390x at -O2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamessan at jamessan dot com
Target Milestone: ---
With gcc-14, one of Vim's test_glob2regpat tests started failing on s390x when
compiled with -O2. I've minimized Vim's code down to the simple reproduction
below. When compile correctly this should output "** -> .*" but instead its
showing "** -> $".
Bisecting shows that the problem was introduced by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294
int printf(const char *, ...);
long unsigned int strlen(const char *s);
void file_pat_to_reg_pat(const char *pat, char *reg_pat)
{
const char * pat_end = pat + strlen(pat);
while (pat[0] == '*' && pat < pat_end - 1)
pat++;
const char * endp = pat_end - 1;
int add_dollar = 1;
if (endp >= pat)
{
while (endp - pat > 0 && *endp == '*')
endp--;
add_dollar = 0;
}
int i = 0;
for (const char * p = pat; *p && p <= endp; p++)
{
switch (*p)
{
case '*':
reg_pat[i++] = '.';
reg_pat[i++] = '*';
while (p[1] == '*')
++p;
break;
default:
reg_pat[i++] = *p;
break;
}
}
if (add_dollar)
reg_pat[i++] = '$';
reg_pat[i] = '\000';
}
int main()
{
char regpat[7] = {0};
file_pat_to_reg_pat("**", regpat);
printf("** -> %s\n", regpat);
return 0;
}
[Bug tree-optimization/116795] [15 regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_ssa failed since r15-3708-g2545a1abb77bd6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116795 --- Comment #2 from Li Pan --- Ack, and thanks for reporting, will take a look soon.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #298 from John Paul Adrian Glaubitz ---
Here is one ICE I have run into while building webkit2gtk with the latest
patches on top of an older GCC snapshot:
/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED
-DPAS_BMALLOC=1 -DSKCMS_DISABLE_HSW -DSKCMS_DISABLE_SKX -DSKIA_IMPLEMENTATION=1
-DSK_ASSUME_GL=0 -DSK_ASSUME_GL_ES=1 -DSK_ASSUME_WEBGL=0 -DSK_CODEC_DECODES_PNG
-DSK_DISABLE_LEGACY_GL_MAKE_NATIVE_INTERFACE
-DSK_DISABLE_LEGACY_IMAGE_READBUFFER -DSK_DISABLE_LEGACY_INIT_DECODERS
-DSK_DISABLE_LEGACY_PNG_WRITEBUFFER -DSK_DISABLE_TRACING
-DSK_DISABLE_WEBGL_INTERFACE -DSK_ENABLE_PRECOMPILE -DSK_GAMMA_APPLY_TO_A8
-DSK_GANESH -DSK_GL -DSK_R32_SHIFT=16 -DSK_RELEASE
-DSK_TYPEFACE_FACTORY_FREETYPE
-I/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia
-isystem /usr/include/freetype2 -fdiagnostics-color=always -Wextra -Wall -pipe
-fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow
-Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
-g1 -O2 -ffile-prefix-map=/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG
-DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti
-fcoroutines -ffunction-sections -fdata-sections -fPIC -fvisibility=hidden
-ffp-contract=off -fstrict-aliasing -Wno-attributes -Wno-cast-align
-Wno-dangling-reference -Wno-deprecated -Wno-psabi
-Wno-suggest-attribute=format -Wno-undef -Wno-uninitialized
-Wno-unused-parameter -std=c++23 -MD -MT
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkCubicMap.cpp.o -MF
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkCubicMap.cpp.o.d -o
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkCubicMap.cpp.o -c
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:
In constructor 'SkCubicMap::SkCubicMap(SkPoint, SkPoint)':
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:106:1:
error: unable to find a register to spill
106 | }
| ^
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:106:1:
error: this is the insn:
(insn 34 307 35 8 (parallel [
(set (reg:SF 170 [ prephitmp_18 ])
(reg:SF 335))
(use (reg:SI 154 fpscr0))
]) "/usr/lib/gcc-snapshot/include/c++/15/bits/stl_algobase.h":262:15
222 {movsf_ie_ra}
(expr_list:REG_DEAD (reg:SF 335)
(nil)))
during RTL pass: reload
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:106:1:
internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868
0x2b7c113f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x2b7c1223 __libc_start_main_impl
./csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See for instructions.
I am going to retest this with Kaz's tree which I am currently building.
While provide the preprocessed source in a follow-up comment.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #299 from John Paul Adrian Glaubitz --- Created attachment 59169 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59169&action=edit Preprocessed source from from comment #298
[Bug testsuite/116806] New: gcc.dg/cpp/charconst-3.c breakage on 16-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116806
Bug ID: 116806
Summary: gcc.dg/cpp/charconst-3.c breakage on 16-bit targets
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
The following is adapted from gcc.dg/cpp/charconst-3.c:
==snip==
void foo (int);
void __attribute__ ((__noreturn__)) _exit (int);
#define A '\234b'
#define B ((int) ((unsigned char) '\234' * scale + (unsigned char) 'b'))
int main (void)
{
int scale = 256;
foo (A);
foo (B);
if (A != B)
_exit (1);
return 0;
}
==snip==
Compiling this for a 16-bit target shows that (1) A and B evaluate to the same
runtime value, but (2) the two are statically considered to be different
causing an unconditional call to _exit.
Taking xstormy16 as an example, this is what gcc-14.2 generates for main:
main:
mov.w r2,#-25502
callf foo
mov.w r2,#-25502
callf foo
mov.w r2,#1
callf _exit
i.e., the values are the same yet somehow different. Other 16-bit targets show
the exact same pattern (tested avr, msp430, pdp11, rl78, and xstormy16).
Compiling for x86-64 shows different behaviour:
main:
.LFB0:
.cfi_startproc
pushq %rax
.cfi_def_cfa_offset 16
movl$40034, %edi
callfoo
movl$40034, %edi
callfoo
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
A and B still evaluate to the same runtime value, but this time gcc realizes
this and does not emit a call to _exit.
Found when debugging this test case on an out-of-tree port to a 16-bit target.
[Bug tree-optimization/116643] PHI_RESULT vs gimple_phi_result/gimple_phi_result_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116643 --- Comment #7 from Andrew Pinski --- here is a few more that should/can be changed: ``` #define USE_FROM_PTR(PTR) get_use_from_ptr (PTR) #define DEF_FROM_PTR(PTR) get_def_from_ptr (PTR) #define SET_USE(USE, V) set_ssa_use_from_ptr (USE, V) #define PHI_ARG_DEF_PTR(PHI, I) gimple_phi_arg_imm_use_ptr ((PHI), (I)) #define PHI_ARG_DEF(PHI, I) gimple_phi_arg_def ((PHI), (I)) #define PHI_ARG_DEF_FROM_EDGE(PHI, E) \ gimple_phi_arg_def_from_edge ((PHI), (E)) #define PHI_ARG_DEF_PTR_FROM_EDGE(PHI, E) \ gimple_phi_arg_imm_use_ptr_from_edge ((PHI), (E)) #define PHI_ARG_INDEX_FROM_USE(USE) phi_arg_index_from_use (USE) ``` One more thing is I noticed we do: gimple_phi_arg_def (phi, e2->dest_idx) All the time, when maybe we should just do: gimple_phi_arg_def_from_edge (phi, e2)
[Bug testsuite/116806] gcc.dg/cpp/charconst-3.c breakage on 16-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116806 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-09-21 Ever confirmed|0 |1 Keywords||testsuite-fail Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. (unsigned char) '\234' * (unsigned)scale has an overflow which causes the issue. Simple fix: ``` #define B ((int) ((unsigned char) '\234' * (unsigned)scale + (unsigned char) 'b')) ```
[Bug middle-end/116797] New: [15 Regression] ICE on libvpx-1.14.1 on -O3: during GIMPLE pass: vect: ICE in operator[], at vec.h:910
lp_scc_info, simple_hashmap_traits, slp_scc_info> >&, int&, vec<_slp_tree*, va_heap, vl_ptr>&) ???:0 0x15d9605 vect_schedule_scc(vec_info*, _slp_tree*, _slp_instance*, hash_map<_slp_tree*, slp_scc_info, simple_hashmap_traits, slp_scc_info> >&, int&, vec<_slp_tree*, va_heap, vl_ptr>&) ???:0 0x15d9d03 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr> const&) ???:0 0x159dc13 vect_transform_loop(_loop_vec_info*, gimple*) ???:0 0x15ece4d vect_transform_loops(hash_table*&, loop*, gimple*, function*) ???:0 0x15ed474 try_vectorize_loop(hash_table*&, unsigned int*, loop*, function*) ???:0 0x15ed73a (anonymous namespace)::pass_vectorize::execute(function*) ???:0 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Compiler details: $ gcc/xg++ -Bgcc -v Reading specs from gcc/specs COLLECT_GCC=gcc/xg++ COLLECT_LTO_WRAPPER=gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --disable-bootstrap --disable-lto --disable-libsanitizer --disable-libstdcxx-pch --enable-languages=c,c++ --disable-libgomp --disable-libquadmath --disable-libvtv CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0' LDFLAGS='-O1 -g0' Thread model: posix Supported LTO compression algorithms: zlib gcc version 15.0.0 20240921 (experimental) (GCC)
[Bug middle-end/116797] [15 Regression] ICE on libvpx-1.14.1 on -O3: during GIMPLE pass: vect: ICE in operator[], at vec.h:910
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116797 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 116791 ***
[Bug tree-optimization/116791] [15 Regression] ICE in operator[], at vec.h:910 since r15-3735-g664e0ce580a8f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116791 Andrew Pinski changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #8 from Andrew Pinski --- *** Bug 116797 has been marked as a duplicate of this bug. ***
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #297 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #296) > This sounds almost logical and easy to understand. > > > Adding explicit emit_clobber R4-R6 looks better than this to me, though. > > Having to use the "emit_clobber" when instantiating that pattern might be > easy to forget. It's easier to deal with it when it's all contained in one > place. Ideally a single 'emit_insn' should suffice, IMHO. Indeed. > > && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG > > && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG > > && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG" > > Out of curiousity, why are these checks needed? Otherwise, operands[2-4] can be replaced by another register. I've seen that in some cases.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #301 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #292) > (In reply to Kazumoto Kojima from comment #289) > > I've reconstructed patches as follows: > > > > [59157] a revised patch to movsf issue which splits movesf_ie_ra > > [59158] a revised patch to QIHI extend/move > > [59159] a revised workaround sfunc issue > > [59153] Alex's patch works magically for call_pcrel* issue. > > > > I've also created sh-lra-take2 branch of > > https://github.com/kazkojima/gcc.git > > with these patches for the reference. > > OK, I'm trying this branch now. I assume I won't need any other patches. I can confirm that I can successfully perform a full native bootstrap with the following languages enabled: - c,c++,fortran,objc,obj-c++,m2 There were no segfaults or comparison failures either. I can also confirm that this branch fixes the problems reported in comment #271, comment #273 and comment #298. Last will be verifying that Go and Ada still work. This is a huge step forward so far. Congratulations!
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #302 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #300) > (In reply to Kazumoto Kojima from comment #297) > > > > > > && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG > > > > && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG > > > > && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG" > > > > > > Out of curiousity, why are these checks needed? > > > > Otherwise, operands[2-4] can be replaced by another register. I've seen that > > in some cases. > > So the checks fail the pattern match unless all hard regs are in place and > so if something tries to change the reg operands in the insn it will fail > and will stay put? Is that what's happening there? Yes, that's what I suppose. If the operands of that pattern match with another registers, the instruction with the operands[2-4] other than r4-r6 would be recognizable. I'm not sure if my memory is correct, but such rewriting was attempted and succeeded at the RA or post reload stage. Another way would be to define a predicate sfunc_arg[012]_reg which matches r[456] only and use it in match_operand to avoid unexpected matching. (define_insn "block_lump_real_i4" [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r")) (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r"))) (use (match_operand:SI 0 "arith_reg_operand" "r,r")) (use (match_operand 1 "" "Z,Ccl")) (use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r")) ... (clobber (reg:SI R3_REG))] "TARGET_HARD_SH4" ... It also worked for me.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #303 from Kazumoto Kojima --- Created attachment 59174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59174&action=edit a patch replacing 59159 for sfunc issue No explicit clobber + sfunc_arg[012]_reg predicate version. Tested with libgcc/libstdc++v3 build and c testsuite only.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #304 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #302) > > Yes, that's what I suppose. If the operands of that pattern match with > another registers, the instruction with the operands[2-4] other than r4-r6 > would be recognizable. > I'm not sure if my memory is correct, but such rewriting was attempted and > succeeded at the RA or post reload stage. > Another way would be to define a predicate sfunc_arg[012]_reg which matches > r[456] only and use it in match_operand to avoid unexpected matching. > > (define_insn "block_lump_real_i4" > [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r")) > (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r"))) >(use (match_operand:SI 0 "arith_reg_operand" "r,r")) >(use (match_operand 1 "" "Z,Ccl")) >(use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r")) > ... >(clobber (reg:SI R3_REG))] >"TARGET_HARD_SH4" > ... > > It also worked for me. I think this is a bit clearer, thanks! One more question (define_insn "block_lump_real" [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r")) (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r"))) (use (match_operand:SI 0 "arith_reg_operand" "r,r")) (use (match_operand 1 "" "Z,Ccl")) (use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r")) (use (reg:SI R4_REG))<< (use (reg:SI R5_REG))<< (use (reg:SI R6_REG))<< (clobber (match_dup 2)) (clobber (match_dup 3)) (clobber (match_dup 4)) (clobber (reg:SI PR_REG)) Is it possible to do '(use (match_dup 2)' and so on instead of having the hard regs in there?
[Bug target/113945] Switch visium to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113945 Sam James changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #3 from Sam James --- Any objection to marking it obsolete? I'll handle that if it's where we want to go.
[Bug libstdc++/116802] Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802 --- Comment #9 from Tymi --- It is indeed not related to whether Clang compiles or not. I used clang as a reference that this is not an issue with other compilers, not as the base of the issue. The base of the issue, is that I have forgotten about ctype::is existence. After looking at the error message, I saw "__ct.is" and thought "reserved keyword, matched with a regular keyword probably an implementation-detail". Which was inherently wrong and naive of me. I apologise for taking your time.
[Bug c++/116793] [15 regression] ice in gimplify_var_or_parm_decl, at gimplify.cc:3309 since r15-3513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793 --- Comment #7 from David Binderman --- Created attachment 59172 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59172&action=edit gzipped C++ source code A second test case. It crashes in the same place as the first. Both are from package libunifex in Fedora Rawhide.
[Bug c++/116807] New: About c++ 20 module,chrono header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116807
Bug ID: 116807
Summary: About c++ 20 module,chrono header file
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wxy_it at 163 dot com
Target Milestone: ---
Created attachment 59173
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59173&action=edit
the code for reproduction
When both module A and module B include the header in the global
module, and module A imports module B, it will cause a bug.
I tried modifying the "auto" at line 2631 of
/usr/local/include/c++/14.2.0/format to the actual type
"_Sink<_CharT>::_Reservation", which can fix the bug.
The attached file contains the code for reproduction. I used CMake for the
build, and the runtime environment is the gcc:14.2.0-bookworm Docker image,
with the image ID 5b2fe0643fc9.
[main] Building folder: /root/workspace/module_test/build
[build] Starting build
[proc] Executing command: /root/cmake-3.30.3-linux-x86_64/bin/cmake --build
/root/workspace/module_test/build --config Debug --target all --
[build] [1/7 14% :: 0.039] Scanning /root/workspace/module_test/a.cpp for CXX
dependencies
[build] [2/7 28% :: 0.041] Generating CXX dyndep file
CMakeFiles/demo.dir/CXX.dd
[build] [3/4 75% :: 0.347] Building CXX object CMakeFiles/demo.dir/a.cpp.o
[build] FAILED: CMakeFiles/demo.dir/a.cpp.o
[build] /usr/local/bin/g++ -g -std=gnu++20 -MD -MT
CMakeFiles/demo.dir/a.cpp.o -MF CMakeFiles/demo.dir/a.cpp.o.d -fmodules-ts
-fmodule-mapper=CMakeFiles/demo.dir/a.cpp.o.modmap -MD -fdeps-format=p1689r5 -x
c++ -o CMakeFiles/demo.dir/a.cpp.o -c /root/workspace/module_test/a.cpp
[build] In file included from
/usr/local/include/c++/14.2.0/bits/chrono_io.h:39,
[build] from /usr/local/include/c++/14.2.0/chrono:3360,
[build] from /root/workspace/module_test/a.ixx:3,
[build] of module ModuleA, imported at /root/workspace/module_test/a.cpp:6:
[build] /usr/local/include/c++/14.2.0/bits/basic_string.tcc: In substitution of
'template constexpr typename std::remove_reference<_Tp>::type&&
std::move(_Tp&&) [with _Tp = std::__cxx11::to_string(int)::&]':
[build] /usr/local/include/c++/14.2.0/bits/basic_string.tcc:602:27: required
from 'constexpr void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::__resize_and_overwrite(size_type, _Operation) [with _Operation =
std::__cxx11::to_string(int)::; _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator; size_type =
long unsigned int]'
[build] 602 | auto __r = std::move(__op)(__p + 0, __n + 0);
[build] | ~^~
[build] /usr/local/include/c++/14.2.0/bits/basic_string.h:4249:33: required
from here
[build] 4249 | __str.__resize_and_overwrite(__neg + __len, [=](char* __p,
size_t __n) {
[build] |
^~~~
[build] 4250 | __p[0] = '-';
[build] | ~
[build] 4251 | __detail::__to_chars_10_impl(__p + (int)__neg, __len,
__uval);
[build] |
~~
[build] 4252 | return __n;
[build] | ~~~
[build] 4253 | });
[build] | ~~
[build] /usr/local/include/c++/14.2.0/format:2632:7: error: conflicting global
module declaration 'auto
std::__format::_Sink_iter@ModuleB<_CharT>::_M_reserve(std::size_t) const [with
_CharT = char; std::size_t = long unsigned int]'
[build] 2632 | _M_reserve(size_t __n) const
[build] | ^~
[build] In file included from
/usr/local/include/c++/14.2.0/bits/chrono_io.h:39,
[build] from /usr/local/include/c++/14.2.0/chrono:3360,
[build] from /root/workspace/module_test/b.ixx:3,
[build] of module ModuleB, imported at /root/workspace/module_test/a.ixx:6,
[build] of module ModuleA, imported at /root/workspace/module_test/a.cpp:6:
[build] /usr/local/include/c++/14.2.0/format:2632:7: note: existing declaration
'auto std::__format::_Sink_iter@ModuleB<_CharT>::_M_reserve(std::size_t) const
[with _CharT = char; std::size_t = long unsigned int]'
[build] 2632 | _M_reserve(size_t __n) const
[build] | ^~
[build] In file included from /usr/local/include/c++/14.2.0/string:55,
[build] from
/usr/local/include/c++/14.2.0/bits/locale_classes.h:40,
[build] from /usr/local/include/c++/14.2.0/bits/ios_base.h:41,
[build] from /usr/local/include/c++/14.2.0/ios:44,
[build] from /usr/local/include/c++/14.2.0/ostream:40,
[build] from /usr/local/include/c++/14.2.0/iostream:41,
[build] from /root/workspace/module_test/a.cpp:3:
[build] /usr/local/include/c++/14
[Bug c++/116807] About c++ 20 module,chrono header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116807 --- Comment #1 from Andrew Pinski --- Can you just provide the exact GCC commands that are invoked instead of a cmake file?
[Bug gcov-profile/116743] [12/13/14/15 regression] Commit r12-5817-g3d9e6767939e96 causes ~10% perf regression w AutoFDO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116743
--- Comment #7 from Rama Malladi ---
I haven't been successful to create a reproducer yet. A simple `test.cc` as
follows isn't showing this behavior as the compiler inlines these irrespective
(at `-O3`).
```
#include
#define N 30
void init_array(int *a, int x)
{
for (int i = 0; i < N*N*N; i++)
a[i] = i + x;
}
int D(int *arr, int n);
int C(int *a, int n)
{
for (int i = 0; i < N*N*N; i+=8){
n += a[i];
< unrolled 8 times>
}
return D(a,n);
}
int B(int *arr, int n)
{
int result = n;
for (int i = 0; i < N*N*N; i++)
result += arr[i];
result = C(arr, result);
return result;
}
int D(int *arr, int n)
{
}
int A(int *arr, int x)
{
int callerResult = x;
if (x > 99000)
callerResult += B(arr, x);
return callerResult;
}
int main(int argc, char* argv[])
{
int arr[N*N*N];
int outval = atoi(argv[1]);
init_array(arr, 2);
for(int i=0; i<10; i++)
outval += A(arr, i);
for(int i=0; i<10; i++)
outval += C(arr, outval);
outval += D(arr, outval);
std::cout< int
D(int*, int)/544, call is unlikely and code size would grow
test.cc:70:19: missed: not inlinable: int main(int, char**)/546 -> int
B(int*, int)/543, call is unlikely and code size would grow
test.cc:38:15: optimized: Inlined int C(int*, int)/1240 into int B(int*,
int)/543 which now has time 8335.001846 and size 91, net change of +42.
test.cc:21:10: optimized: Inlined int D(int*, int)/1241 into int C(int*,
int)/542 which now has time 12282.002762 and size 127, net change of +78.
```
I will continue to attempt creating a stand-alone test-case or if get a
compilation unit extracted from the MySQL code itself and upload it.
[Bug other/116801] Many fortran options missing in lang.opt.urls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116801
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Both manuals use
@defcodeindex op
rather than
@defindex op
so the code font in the Option Index is there by default.
The gcc/doc/ and d/ TexInfo files use e.g. @var in @opindex, but only for the
variable part of the names, no @code:
grep @opindex.*@ doc/*.texi d/*.texi
doc/invoke.texi:@opindex fstrict-flex-arrays=@var{level}
doc/invoke.texi:@opindex Wlarger-than-@var{byte-size}
doc/invoke.texi:@opindex fmin-function-alignment=@var{n}
doc/invoke.texi:@opindex fdump-rtl-@var{pass}
doc/invoke.texi:@opindex masm=@var{dialect}
doc/invoke.texi:@opindex missue-rate=@var{number}
doc/invoke.texi:@opindex mbranch-cost=@var{number}
doc/invoke.texi:@opindex mflush-trap=@var{number}
doc/invoke.texi:@opindex mflush-func=@var{name}
doc/invoke.texi:@opindex mcustom-@var{insn}
doc/invoke.texi:@opindex mno-custom-@var{insn}
doc/invoke.texi:@opindex matomic-model=@var{model}
doc/invoke.texi:@opindex multcost=@var{number}
doc/invoke.texi:@opindex mdiv=@var{strategy}
doc/invoke.texi:@opindex mdivsi3_libfunc=@var{name}
doc/invoke.texi:@opindex mbranch-cost=@var{num}
doc/invoke.texi:@opindex mdebug-main=@var{prefix}
doc/invoke.texi:@opindex mpointer-size=@var{size}
doc/invoke.texi:@opindex masm=@var{dialect}
doc/invoke.texi:@opindex mtune-ctrl=@var{feature-list}
doc/invoke.texi:@opindex mstringop-strategy=@var{alg}
doc/invoke.texi:@opindex mmemcpy-strategy=@var{strategy}
doc/invoke.texi:@opindex mmemset-strategy=@var{strategy}
So, I think fortran/*.texi should be fixed to remove those @code markings.
In most cases trivial change doable by a simple sed command, there are a few
harder
cases (guess the option word should go, if there is @code{...} just before
@var, then
just remove @code{ and }, if it is around everything and there are no spaces,
similarly remove the first @code{ and last }. If there are spaces, like the
isysroot etc. cases, I think doc/*.texi just uses @opindex isysroot
grep @opindex.*@[^c] fortran/*.texi
fortran/invoke.texi:@opindex @code{ffixed-line-length-}@var{n}
fortran/invoke.texi:@opindex @code{ffree-line-length-}@var{n}
fortran/invoke.texi:@opindex @code{fmax-identifier-length=}@var{n}
fortran/invoke.texi:@opindex @code{std=}@var{std} option
fortran/invoke.texi:@opindex @code{idirafter @var{dir}}
fortran/invoke.texi:@opindex @code{imultilib @var{dir}}
fortran/invoke.texi:@opindex @code{iprefix @var{prefix}}
fortran/invoke.texi:@opindex @code{isysroot @var{dir}}
fortran/invoke.texi:@opindex @code{iquote @var{dir}}
fortran/invoke.texi:@opindex @code{isystem @var{dir}}
fortran/invoke.texi:@opindex @code{A@var{predicate}=@var{answer}}
fortran/invoke.texi:@opindex @code{A-@var{predicate}=@var{answer}}
fortran/invoke.texi:@opindex @code{D@var{name}}
fortran/invoke.texi:@opindex @code{D@var{name}=@var{definition}}
fortran/invoke.texi:@opindex @code{U@var{name}}
fortran/invoke.texi:@opindex @code{fmax-errors=}@var{n}
fortran/invoke.texi:@opindex @code{ffpe-trap=}@var{list}
fortran/invoke.texi:@opindex @code{ffpe-summary=}@var{list}
fortran/invoke.texi:@opindex @code{I}@var{dir}
fortran/invoke.texi:@opindex @code{J}@var{dir}
fortran/invoke.texi:@opindex @code{M}@var{dir}
fortran/invoke.texi:@opindex @code{fintrinsic-modules-path} @var{dir}
fortran/invoke.texi:@opindex @code{fconvert=}@var{conversion}
fortran/invoke.texi:@opindex @code{frecord-marker=}@var{length}
fortran/invoke.texi:@opindex @code{fmax-subrecord-length=}@var{length}
[Bug testsuite/116806] gcc.dg/cpp/charconst-3.c breakage on 16-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116806 --- Comment #2 from Mikael Pettersson --- (In reply to Andrew Pinski from comment #1) > ``` > #define B ((int) ((unsigned char) '\234' * (unsigned)scale + (unsigned char) > 'b')) > ``` That fixes the test case on the five 16-bit targets. I'll prepare a patch tomorrow.
[Bug c++/116807] About c++ 20 module,chrono header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116807 --- Comment #3 from wxy_it at 163 dot com --- I obtained the following GCC command from the files generated by CMake. This command can also reproduce the bug. g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -xc++ -c b.ixx g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -xc++ -c a.ixx g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -c b.cpp g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -c a.cpp
[Bug c++/116807] About c++ 20 module,chrono header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116807 --- Comment #4 from wxy_it at 163 dot com --- I obtained the following GCC command from the files generated by CMake. This command can also reproduce the bug. g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -xc++ -c b.ixx g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -xc++ -c a.ixx g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -c b.cpp g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -c a.cpp
[Bug c++/116807] About c++ 20 module,chrono header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116807 --- Comment #5 from wxy_it at 163 dot com --- (In reply to wxy_it from comment #4) > I obtained the following GCC command from the files generated by CMake. This > command can also reproduce the bug. > g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -xc++ -c b.ixx > g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -xc++ -c a.ixx > g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -c b.cpp > g++ -std=c++20 -fmodules-ts -MD -fdeps-format=p1689r5 -c a.cpp mistake
[Bug c++/116807] About c++ 20 module,chrono header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116807 --- Comment #2 from Andrew Pinski --- >I used CMake for the build Please read https://gcc.gnu.org/bugs/#need : the complete command line that triggers the bug (this should be expanded to say not cmake or make command line though).
[Bug other/116801] Many fortran options missing in lang.opt.urls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116801 --- Comment #3 from Jakub Jelinek --- The TexInfo docs are https://www.gnu.org/software/texinfo/manual/texinfo/html_node/New-Indices.html and then look for grep 'defcodeindex\|printindex.op' */*.texi d/gdc.texi:@defcodeindex op d/gdc.texi:@printindex op doc/cpp.texi:@defcodeindex op doc/cpp.texi:@printindex op doc/gccint.texi:@defcodeindex op doc/gccint.texi:@printindex op doc/gcc.texi:@defcodeindex op doc/gcc.texi:@printindex op fortran/gfortran.texi:@defcodeindex op fortran/gfortran.texi:@printindex op
[Bug target/55295] [SH] Add support for fipr instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295 --- Comment #18 from Oleg Endo --- A rather recent case and request to add a __builtin_fipr function, when trying to optimize quaternion multiplication. This one includes hand-written inline asm and register pre-allocation. https://godbolt.org/z/EsbP3KTbs
[Bug target/116371] The SME2 svpext intrinsics are missing a _lane suffix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116371 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #3 from Tamar Christina --- svpsel_lane is also misnamed.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #295 from Kazumoto Kojima --- (In reply to Kazumoto Kojima from comment #285) > (In reply to Oleg Endo from comment #284) > > (In reply to Kazumoto Kojima from comment #283) > ... > > > It turned out that the c#276 version of block_lump_real_i4 works correctly > > > in only the limited cases. > > > > Have you tried writing the pattern as > > > > (define_insn "block_lump_real_i4" > > [(set (mem:BLK (match_operand:SI 2 "" "r,r")) > >(mem:BLK (match_operand:SI 3 "" "r,r"))) > >(use (match_operand:SI 0 "arith_reg_operand" "r,r")) > >(use (match_operand 1 "" "Z,Ccl")) > >... > > > > i.e. without the parallel in there? Sorry, maybe it's a stupid idea but ... > > The last time I tried it against slightly different patterns, there was no > difference. I'll try it again. It seems that there is no difference w/wo the explicit parallel pattern. BTW, a bit monstrous version of that pattern seems to work at least for gcc testsuite and our handy test case: (define_insn "block_lump_real_i4" [(set (mem:BLK (match_operand:SI 2 "" "=r,r")) (mem:BLK (match_operand:SI 3 "" "=r,r"))) (use (match_operand:SI 0 "arith_reg_operand" "r,r")) (use (match_operand 1 "" "Z,Ccl")) (use (match_operand:SI 4 "" "=r,r")) (use (reg:SI R4_REG)) (use (reg:SI R5_REG)) (use (reg:SI R6_REG)) (clobber (match_dup 2)) (clobber (match_dup 3)) (clobber (match_dup 4)) (clobber (reg:SI PR_REG)) (clobber (reg:SI T_REG)) (clobber (reg:SI R0_REG)) (clobber (reg:SI R1_REG)) (clobber (reg:SI R2_REG)) (clobber (reg:SI R3_REG))] "TARGET_HARD_SH4 && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG" "@ jsr @%0%# bsrf%0\n%O1:%#" [(set_attr "type" "sfunc") (set_attr "needs_delay_slot" "yes")]) The extra use patterns avoid allocating R4-R6 to operands[0]. Adding explicit emit_clobber R4-R6 looks better than this to me, though.
[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550
denisc at gcc dot gnu.org changed:
What|Removed |Added
CC||denisc at gcc dot gnu.org
--- Comment #2 from denisc at gcc dot gnu.org ---
Probably I found a bug in lra-constraints.cc
I can explain it later.
Johan can you test the patch ?
diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index fdcc07764a2..1f63113f321 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -680,7 +680,8 @@ get_reload_reg (enum op_type type, machine_mode mode, rtx
original,
used by reload instructions. */
if (REG_P (original)
&& (int) REGNO (original) >= new_regno_start
- && INSN_UID (curr_insn) >= new_insn_uid_start
+ && (INSN_UID (curr_insn) >= new_insn_uid_start
+ || ira_former_scratch_p (REGNO (original)))
&& in_class_p (original, rclass, &new_class, true))
{
unsigned int regno = REGNO (original);
[Bug tree-optimization/116796] [15 regression] ICE on valid code at -O3 with "-fno-tree-dominator-opts -fno-tree-vrp -fno-tree-ch" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116796 Sam James changed: What|Removed |Added Summary|[15 regression] ICE on |[15 regression] ICE on |valid code at -O3 with |valid code at -O3 with |"-fno-tree-dominator-opts |"-fno-tree-dominator-opts |-fno-tree-vrp -fno-tree-ch" |-fno-tree-vrp -fno-tree-ch" |on x86_64-linux-gnu: in |on x86_64-linux-gnu: in |check_loop_closed_ssa_def, |check_loop_closed_ssa_def, |at |at |tree-ssa-loop-manip.cc:647 |tree-ssa-loop-manip.cc:647 ||since ||r15-80-g0ade358cd72ffa CC||amacleod at redhat dot com --- Comment #1 from Sam James --- r15-80-g0ade358cd72ffa
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #296 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #295) > (In reply to Kazumoto Kojima from comment #285) > > (In reply to Oleg Endo from comment #284) > > > (In reply to Kazumoto Kojima from comment #283) > > ... > > > > It turned out that the c#276 version of block_lump_real_i4 works > > > > correctly > > > > in only the limited cases. > > > > > > Have you tried writing the pattern as > > > > > > (define_insn "block_lump_real_i4" > > > [(set (mem:BLK (match_operand:SI 2 "" "r,r")) > > > (mem:BLK (match_operand:SI 3 "" "r,r"))) > > >(use (match_operand:SI 0 "arith_reg_operand" "r,r")) > > >(use (match_operand 1 "" "Z,Ccl")) > > >... > > > > > > i.e. without the parallel in there? Sorry, maybe it's a stupid idea but > > > ... > > > > The last time I tried it against slightly different patterns, there was no > > difference. I'll try it again. > > It seems that there is no difference w/wo the explicit parallel pattern. > > BTW, a bit monstrous version of that pattern seems to work at least for gcc > testsuite and our handy test case: > > (define_insn "block_lump_real_i4" > [(set (mem:BLK (match_operand:SI 2 "" "=r,r")) > (mem:BLK (match_operand:SI 3 "" "=r,r"))) >(use (match_operand:SI 0 "arith_reg_operand" "r,r")) >(use (match_operand 1 "" "Z,Ccl")) >(use (match_operand:SI 4 "" "=r,r")) >(use (reg:SI R4_REG)) >(use (reg:SI R5_REG)) >(use (reg:SI R6_REG)) >(clobber (match_dup 2)) >(clobber (match_dup 3)) >(clobber (match_dup 4)) >(clobber (reg:SI PR_REG)) >(clobber (reg:SI T_REG)) >(clobber (reg:SI R0_REG)) >(clobber (reg:SI R1_REG)) >(clobber (reg:SI R2_REG)) >(clobber (reg:SI R3_REG))] > "TARGET_HARD_SH4 > && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG > && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG > && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG" > "@ > jsr @%0%# > bsrf%0\n%O1:%#" > [(set_attr "type" "sfunc") >(set_attr "needs_delay_slot" "yes")]) > > The extra use patterns avoid allocating R4-R6 to operands[0]. This sounds almost logical and easy to understand. > Adding explicit emit_clobber R4-R6 looks better than this to me, though. Having to use the "emit_clobber" when instantiating that pattern might be easy to forget. It's easier to deal with it when it's all contained in one place. Ideally a single 'emit_insn' should suffice, IMHO. > && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG > && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG > && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG" Out of curiousity, why are these checks needed?
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #25 from GCC Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:b6ea4f7b0e6f983376aac6ebcdbf4eb375b4f1d9 commit r15-3756-gb6ea4f7b0e6f983376aac6ebcdbf4eb375b4f1d9 Author: Mikael Morin Date: Sat Sep 21 18:32:10 2024 +0200 fortran: Add tests covering inline MINLOC/MAXLOC without DIM [PR90608] Add the tests covering the various cases for which we are about to implement inline expansion of MINLOC and MAXLOC. Those are cases where the DIM argument is not present. PR fortran/90608 gcc/testsuite/ChangeLog: * gfortran.dg/ieee/maxloc_nan_1.f90: New test. * gfortran.dg/ieee/minloc_nan_1.f90: New test. * gfortran.dg/maxloc_7.f90: New test. * gfortran.dg/maxloc_with_mask_1.f90: New test. * gfortran.dg/minloc_8.f90: New test. * gfortran.dg/minloc_with_mask_1.f90: New test.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #28 from GCC Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:dd5250384dc91b4db117c599095f47955b6dc124 commit r15-3761-gdd5250384dc91b4db117c599095f47955b6dc124 Author: Mikael Morin Date: Sat Sep 21 18:32:44 2024 +0200 fortran: Inline integral MINLOC/MAXLOC with no DIM and no MASK [PR90608] Enable generation of inline code for the MINLOC and MAXLOC intrinsic, if the ARRAY argument is of integral type and of any rank (only the rank 1 case was previously inlined), and neither DIM nor MASK arguments are present. This needs a few adjustments in gfc_conv_intrinsic_minmaxloc, mainly to replace the single variables POS and OFFSET, with collections of variables, one variable per dimension each. The restriction to integral ARRAY and absent MASK limits the scope of the change to the cases where we generate single loop inline code. The code generation for the second loop is only accessible with ARRAY of rank 1, so it can continue using a single variable. A later change will extend inlining to the double loop cases. There is some bounds checking code that was previously handled by the library, and that needed some changes in the scalarizer to avoid regressing. The bounds check code generation was already supported by the scalarizer, but it was only applying to array reference sections, checking both for array bound violation and for shape conformability between all the involved arrays. With this change, for MINLOC or MAXLOC, enable the conformability check between all the scalarized arrays, and disable the array bound violation check. PR fortran/90608 gcc/fortran/ChangeLog: * trans-array.cc (gfc_conv_ss_startstride): Set the MINLOC/MAXLOC result upper bound using the rank of the ARRAY argument. Ajdust the error message for intrinsic result arrays. Only check array bounds for array references. Move bound check decision code... (bounds_check_needed): ... here as a new predicate. Allow bound check for MINLOC/MAXLOC intrinsic results. * trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc): Change the result array upper bound to the rank of ARRAY. Update the NONEMPTY variable to depend on the non-empty extent of every dimension. Use one variable per dimension instead of a single variable for the position and the offset. Update their declaration, initialization, and update to affect the variable of each dimension. Use the first variable only in areas only accessed with rank 1 ARRAY argument. Set every element of the result using its corresponding variable. (gfc_inline_intrinsic_function_p): Return true for integral ARRAY and absent DIM and MASK. gcc/testsuite/ChangeLog: * gfortran.dg/maxloc_bounds_4.f90: Additionally accept the error message emitted by the scalarizer.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #26 from GCC Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:053cec9a5f4513537ca20a246c39d1bbfe6ce4be commit r15-3757-g053cec9a5f4513537ca20a246c39d1bbfe6ce4be Author: Mikael Morin Date: Sat Sep 21 18:32:19 2024 +0200 fortran: Disable frontend passes for inlinable MINLOC/MAXLOC [PR90608] Disable rewriting of MINLOC/MAXLOC expressions for which inline code generation is supported. Update the gfc_inline_intrinsic_function_p predicate (already existing) for that, with the current state of MINLOC/MAXLOC inlining support, that is only the cases of a scalar result and non-CHARACTER argument for now. This change has no effect currently, as the MINLOC/MAXLOC front-end passes only change expressions of rank 1, but the inlining control predicate gfc_inline_intrinsic_function_p returns false for those. However, later changes will extend MINLOC/MAXLOC inline expansion support to array expressions and update the inlining control predicate, and this will become effective. PR fortran/90608 gcc/fortran/ChangeLog: * frontend-passes.cc (optimize_minmaxloc): Skip if we can generate inline code for the unmodified expression. * trans-intrinsic.cc (gfc_inline_intrinsic_function_p): Add MINLOC and MAXLOC cases.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #27 from GCC Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:c313924c3bcb4fa672c7c1880fe686bd5af2cc7a commit r15-3758-gc313924c3bcb4fa672c7c1880fe686bd5af2cc7a Author: Mikael Morin Date: Sat Sep 21 18:32:25 2024 +0200 fortran: Inline MINLOC/MAXLOC with no DIM and ARRAY of rank 1 [PR90608] Enable inline code generation for the MINLOC and MAXLOC intrinsic, if the DIM argument is not present and ARRAY has rank 1. This case is similar to the case where the result is scalar (DIM present and rank 1 ARRAY), which already supports inline expansion of the intrinsic. Both cases return the same value, with the difference that the result is an array of size 1 if DIM is absent, whereas it's a scalar if DIM is present. So all there is to do for the new case to work is hook the inline expansion with the scalarizer. PR fortran/90608 gcc/fortran/ChangeLog: * trans-array.cc (gfc_conv_ss_startstride): Set the scalarization rank based on the MINLOC/MAXLOC rank if needed. Call the inline code generation and setup the scalarizer array descriptor info in the MINLOC and MAXLOC cases. * trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc): Return the result array element if the scalarizer is setup and we are inside the loops. Restrict library function call dispatch to the case where inline expansion is not supported. Declare an array result if the expression isn't scalar. Initialize the array result single element and return the result variable if the expression isn't scalar. (walk_inline_intrinsic_minmaxloc): New function. (walk_inline_intrinsic_function): Add MINLOC and MAXLOC cases, dispatching to walk_inline_intrinsic_minmaxloc. (gfc_add_intrinsic_ss_code): Add MINLOC and MAXLOC cases. (gfc_inline_intrinsic_function_p): Return true if ARRAY has rank 1, regardless of DIM.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #31 from GCC Commits ---
The master branch has been updated by Mikael Morin :
https://gcc.gnu.org/g:3c01ddc4ff0fdbaf32c22aed1c04d1d587821d91
commit r15-3764-g3c01ddc4ff0fdbaf32c22aed1c04d1d587821d91
Author: Mikael Morin
Date: Sat Sep 21 18:33:04 2024 +0200
fortran: Continue MINLOC/MAXLOC second loop where the first stopped
[PR90608]
Continue the second set of loops where the first one stopped in the
generated inline MINLOC/MAXLOC code in the cases where the generated code
contains two sets of loops. This fixes a regression that was introduced
when enabling the generation of inline MINLOC/MAXLOC code with ARRAY of
rank
greater than 1, no DIM argument, and either non-scalar MASK or floating-
point ARRAY.
In the cases where two sets of loops are generated as inline MINLOC/MAXLOC
code, we previously generated code such as (for rank 2 ARRAY, so with two
levels of nesting):
for (idx11 in lower1..upper1)
{
for (idx12 in lower2..upper2)
{
...
if (...)
{
...
goto second_loop;
}
}
}
second_loop:
for (idx21 in lower1..upper1)
{
for (idx22 in lower2..upper2)
{
...
}
}
which means we process the first elements twice, once in the first set
of loops and once in the second one. This change avoids this duplicate
processing by using a conditional as lower bound for the second set of
loops, generating code like:
second_loop_entry = false;
for (idx11 in lower1..upper1)
{
for (idx12 in lower2..upper2)
{
...
if (...)
{
...
second_loop_entry = true;
goto second_loop;
}
}
}
second_loop:
for (idx21 in (second_loop_entry ? idx11 : lower1)..upper1)
{
for (idx22 in (second_loop_entry ? idx12 : lower2)..upper2)
{
...
second_loop_entry = false;
}
}
It was expected that the compiler optimizations would be able to remove the
state variable second_loop_entry. It is the case if ARRAY has rank 1 (so
without loop nesting), the variable is removed and the loop bounds become
unconditional, which restores previously generated code, fully fixing the
regression. For larger rank, unfortunately, the state variable and
conditional loop bounds remain, but those cases were previously using
library calls, so it's not a regression.
PR fortran/90608
gcc/fortran/ChangeLog:
* trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc): Generate a set
of index variables. Set them using the loop indexes before leaving
the first set of loops. Generate a new loop entry predicate.
Initialize it. Set it before leaving the first set of loops.
Clear
it in the body of the second set of loops. For the second set of
loops, update each loop lower bound to use the corresponding index
variable if the predicate variable is set.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #32 from GCC Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:d6cb7794dcd7d97b77283fbbe0026e63521d2375 commit r15-3765-gd6cb7794dcd7d97b77283fbbe0026e63521d2375 Author: Mikael Morin Date: Sat Sep 21 18:33:11 2024 +0200 fortran: Add -finline-intrinsics flag for MINLOC/MAXLOC [PR90608] Introduce the -finline-intrinsics flag to control from the command line whether to generate either inline code or calls to the functions from the library, for the MINLOC and MAXLOC intrinsics. The flag allows to specify inlining either independently for each intrinsic (either MINLOC or MAXLOC), or all together. For each intrinsic, a default value is set if none was set. The default value depends on the optimization setting: inlining is avoided if not optimizing or if optimizing for size; otherwise inlining is preferred. There is no direct support for this behaviour provided by the .opt options framework. It is obtained by defining three different variants of the flag (finline-intrinsics, fno-inline-intrinsics, finline-intrinsics=) all using the same underlying option variable. Each enum value (corresponding to an intrinsic function) uses two identical bits, and the variable is initialized with alternated bits, so that we can tell whether the value was set or not by checking whether the two bits have different values. PR fortran/90608 gcc/ChangeLog: * flag-types.h (enum gfc_inlineable_intrinsics): New type. gcc/fortran/ChangeLog: * invoke.texi(finline-intrinsics): Document new flag. * lang.opt (finline-intrinsics, finline-intrinsics=, fno-inline-intrinsics): New flags. * options.cc (gfc_post_options): If the option variable controlling the inlining of MAXLOC (respectively MINLOC) has not been set, set it or clear it depending on the optimization option variables. * trans-intrinsic.cc (gfc_inline_intrinsic_function_p): Return false if inlining for the intrinsic is disabled according to the option variable. gcc/testsuite/ChangeLog: * gfortran.dg/minmaxloc_18.f90: New test. * gfortran.dg/minmaxloc_18a.f90: New test. * gfortran.dg/minmaxloc_18b.f90: New test. * gfortran.dg/minmaxloc_18c.f90: New test. * gfortran.dg/minmaxloc_18d.f90: New test.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #30 from GCC Commits ---
The master branch has been updated by Mikael Morin :
https://gcc.gnu.org/g:7d43b4e06786c1023210f90e5231bde947aef3af
commit r15-3763-g7d43b4e06786c1023210f90e5231bde947aef3af
Author: Mikael Morin
Date: Sat Sep 21 18:32:59 2024 +0200
fortran: Inline non-character MINLOC/MAXLOC with no DIM [PR90608]
Enable generation of inline MINLOC/MAXLOC code in the case where DIM
is not present, and either ARRAY is of floating point type or MASK is an
array. Those cases are the remaining bits to fully support inlining of
non-CHARACTER MINLOC/MAXLOC without DIM. They are treated together because
they generate similar code, the NANs for REAL types being handled a bit
like
a second level of masking. These are the cases for which we generate two
sets of loops.
This change affects the code generating the second loop, that was
previously
accessible only in the cases ARRAY has rank 1 only. The single variable
initialization and update are changed to apply to multiple variables, one
per dimension.
The code generated is as follows (if ARRAY has rank 2):
for (idx11 in lower1..upper1)
{
for (idx12 in lower2..upper2)
{
...
if (...)
{
...
goto second_loop;
}
}
}
second_loop:
for (idx21 in lower1..upper1)
{
for (idx22 in lower2..upper2)
{
...
}
}
This code leads to processing the first elements redundantly, both in the
first set of loops and in the second one. The loop over idx22 could
start from idx12 the first time it is run, but as it has to start from
lower2 for the rest of the runs, this change uses the same bounds for both
set of loops for simplicity. In the rank 1 case, this makes the generated
code worse compared to the inline code that was generated before. A later
change will introduce conditionals to avoid the duplicate processing and
restore the generated code in that case.
PR fortran/90608
gcc/fortran/ChangeLog:
* trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc): Initialize
and update all the variables. Put the label and goto in the
outermost scalarizer loop. Don't start the second loop where the
first stopped.
(gfc_inline_intrinsic_function_p): Also return TRUE for array MASK
or for any REAL type.
gcc/testsuite/ChangeLog:
* gfortran.dg/maxloc_bounds_5.f90: Additionally accept error
messages reported by the scalarizer.
* gfortran.dg/maxloc_bounds_6.f90: Ditto.
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #29 from GCC Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:5999d558e74b3531536c74976e8f05bb3ed31335 commit r15-3762-g5999d558e74b3531536c74976e8f05bb3ed31335 Author: Mikael Morin Date: Sat Sep 21 18:32:51 2024 +0200 fortran: Inline integral MINLOC/MAXLOC with no DIM and scalar MASK [PR90608] Enable the generation of inline code for MINLOC/MAXLOC when argument ARRAY is of integral type, DIM is not present, and MASK is present and is scalar (only absent MASK or rank 1 ARRAY were inlined before). Scalar masks are implemented with a wrapping condition around the code one would generate if MASK wasn't present, so they are easy to support once inline code without MASK is working. PR fortran/90608 gcc/fortran/ChangeLog: * trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc): Generate variable initialization for each dimension in the else branch of the toplevel condition. (gfc_inline_intrinsic_function_p): Return TRUE for scalar MASK. gcc/testsuite/ChangeLog: * gfortran.dg/maxloc_bounds_7.f90: Additionally accept the error message reported by the scalarizer.
[Bug tree-optimization/116808] New: Valgrind reports mismatched new/delete in value-range.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116808 Bug ID: 116808 Summary: Valgrind reports mismatched new/delete in value-range.h Product: gcc Version: 13.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- I see this with 13 and 14/15 are fine. Hit it when looking at https://bugs.gentoo.org/939997 (which I can't reproduce). ``` $ g++-13 -c z.ii -march=skylake -O2 -fPIC -wrapper valgrind,--track-origins=yes,--exit-on-first-error=yes,--error-exitcode=2 ==3378487== Memcheck, a memory error detector ==3378487== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==3378487== Using Valgrind-3.24.0.GIT and LibVEX; rerun with -h for copyright info ==3378487== Command: /usr/libexec/gcc/x86_64-pc-linux-gnu/13/cc1plus -fpreprocessed z.ii -quiet -dumpbase z.ii -dumpbase-ext .ii -march=skylake -O2 -fPIC -o /tmp/ccIEnzhk.s ==3378487== ==3378487== Mismatched new/delete size value: 8 ==3378487==at 0x484EDEE: operator delete(void*, unsigned long) (vg_replace_malloc.c:1181) ==3378487==by 0x2A37596: ~int_range (value-range.h:507) ==3378487==by 0x2A37596: ~Value_Range (value-range.h:538) ==3378487==by 0x2A37596: gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*) (gimple-range.cc:326) ==3378487==by 0x1CE3EFD: range_query::value_of_stmt(gimple*, tree_node*) (value-query.cc:134) ==3378487==by 0x1B6C27F: substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) (tree-ssa-propagate.cc:792) ==3378487==by 0x29F7A2E: dom_walker::walk(basic_block_def*) (domwalk.cc:311) ==3378487==by 0x1B6AF2E: substitute_and_fold_engine::substitute_and_fold(basic_block_def*) (tree-ssa-propagate.cc:971) ==3378487==by 0x1CA90E1: execute_ranger_vrp(function*, bool, bool) (tree-vrp.cc:1107) ==3378487==by 0x180C029: execute_one_pass(opt_pass*) (passes.cc:2651) ==3378487==by 0x180CE6A: execute_pass_list_1(opt_pass*) (passes.cc:2760) ==3378487==by 0x180D266: execute_pass_list_1 (passes.cc:2761) ==3378487==by 0x180D266: execute_pass_list(function*, opt_pass*) (passes.cc:2771) ==3378487==by 0x180DFFA: do_per_function_toporder (passes.cc:1780) ==3378487==by 0x180DFFA: do_per_function_toporder (passes.cc:1743) ==3378487==by 0x180DFFA: execute_ipa_pass_list(opt_pass*) (passes.cc:3105) ==3378487==by 0x1350733: ipa_passes (cgraphunit.cc:2210) ==3378487==by 0x1350733: symbol_table::compile() [clone .part.0] (cgraphunit.cc:2333) ==3378487== Address 0x86f62b0 is 0 bytes inside a block of size 4,080 alloc'd ==3378487==at 0x484CA4F: operator new[](unsigned long) (vg_replace_malloc.c:729) ==3378487==by 0x1CEB0F6: irange::maybe_resize(int) [clone .part.0] (value-range.h:496) ==3378487==by 0x1CF714A: maybe_resize (value-range.cc:2417) ==3378487==by 0x1CF714A: irange::irange_union(irange const&) (value-range.cc:2513) ==3378487==by 0x12D047C: irange::union_(vrange const&) (value-range.h:1059) ==3378487==by 0x2BA8F3F: range_operator::wi_fold_in_parts(irange&, tree_node*, generic_wide_int const&, generic_wide_int const&, generic_wide_int const&, generic_wide_int const&) const (range-op.cc:245) ==3378487==by 0x2BA9872: range_operator::fold_range(irange&, tree_node*, irange const&, irange const&, relation_trio) const (range-op.cc:296) ==3378487==by 0x2BA9B9E: operator_lshift::fold_range(irange&, tree_node*, irange const&, irange const&, relation_trio) const (range-op.cc:2403) ==3378487==by 0x2A491C0: fold_using_range::range_of_range_op(vrange&, gimple_range_op_handler&, fur_source&) (gimple-range-fold.cc:589) ==3378487==by 0x2A4A512: fold_using_range::fold_stmt(vrange&, gimple*, fur_source&, tree_node*) (gimple-range-fold.cc:489) ==3378487==by 0x2A37542: fold_range_internal (gimple-range.cc:257) ==3378487==by 0x2A37542: gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*) (gimple-range.cc:318) ==3378487==by 0x1CE3EFD: range_query::value_of_stmt(gimple*, tree_node*) (value-query.cc:134) ==3378487==by 0x1B6C27F: substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) (tree-ssa-propagate.cc:792) ==3378487== ==3378487== ==3378487== Exit program on first error (--exit-on-first-error=yes) ``` -- ``` $ gcc-13 -v Using built-in specs. COLLECT_GCC=gcc-13 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/13/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-13.3.1_p20240920/work/gcc-13-20240920/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/13 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man --infodir=/usr/share/gcc-data
[Bug tree-optimization/116808] Valgrind reports mismatched new/delete in value-range.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116808 --- Comment #1 from Sam James --- Created attachment 59175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59175&action=edit z.ii.xz
[Bug target/113945] Switch visium to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113945 --- Comment #4 from Eric Botcazou --- No objections.
[Bug libstdc++/116800] New: std::simd: poor code generation of AVX512 fused multiply-add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116800
Bug ID: 116800
Summary: std::simd: poor code generation of AVX512 fused
multiply-add
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pieter.p.dev at outlook dot com
Target Milestone: ---
The AVX512 implementation of the std::experimental::fma function appears to be
falling back on the AVX2 version, which results in very poor performance.
For example, compare the two functions below:
The 'fma_1' function uses standard arithmetic operators,
and the 'fma_2' function calls the std::experimental::fma function.
The 'fma_1' function compiles down to a single AVX512 vfmadd instruction (which
is the desired behavior), whereas the code for 'fma_2' moves the upper half of
the 512-bit arguments into separate 256-bit registers, then performs two
256-bit vfmadd instructions, and merges the results back into a single 512-bit
result.
#include
using simd = std::experimental::native_simd;
simd fma_1(simd x, simd y, simd z) {
return x * y + z;
}
simd fma_2(simd x, simd y, simd z) {
return fma(x, y, z);
}
Compiler explorer: https://godbolt.org/z/hMM83jh4o
In GCC 11 and 12, the situation is even worse: there the 'fma_2' code actually
performs eight individual FMAs, along with over 30 extraction/insertion
instructions! GCC 13 performs four 128-bit FMAs, and GCC 14 performs two
256-bit FMAs.
[Bug libstdc++/116802] Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802 --- Comment #3 from Andrew Pinski --- (In reply to Tymi from comment #2) > Oh, did not see that detail. It does compile with clang though. By clang you mean with libstd++ with clang or libc++?
[Bug c++/116803] New: Linkage fails if modules are compiled in a certain order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116803
Bug ID: 116803
Summary: Linkage fails if modules are compiled in a certain
order
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at richy dot net
Target Milestone: ---
richard@microserver:~/scratch/broken> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/richard/gcc/lib/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --host=x86_64-pc-linux-gnu
--prefix=/home/richard/gcc --enable-threads --enable-language=c,c++
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240917 (experimental) (GCC)
richard@microserver:~/scratch/broken> g++ -std=c++2b -fmodules-ts -fconcepts
-Wall -O3 -g -save-temps -fPIC -x c++-system-header algorithm
richard@microserver:~/scratch/broken> g++ -std=c++2b -fmodules-ts -fconcepts
-Wall -O3 -g -save-temps -fPIC -x c++-system-header execution
richard@microserver:~/scratch/broken> g++ -std=c++2b -fmodules-ts -fconcepts
-Wall -O3 -g -save-temps -fPIC -x c++-system-header vector
richard@microserver:~/scratch/broken> g++ -std=c++2b -fmodules-ts -fconcepts
-Wall -O3 -g -fPIC -save-temps -c ./example.cpp -o example.o
richard@microserver:~/scratch/broken> g++ -std=c++2b -fmodules-ts -fconcepts
-Wall -O3 -g -fPIC -save-temps -o ./example ./example.o
/usr/bin/ld: ./example.o: in function `main':
/home/richard/scratch/broken/./example.cpp:10:(.text.startup+0x10): undefined
reference to
`std::enable_if<__pstl::execution::v1::is_execution_policy::type>::type>::value, void>::type
std::sort<__pstl::execution::v1::parallel_unsequenced_policy const&,
__gnu_cxx::__normal_iterator > >
>(__pstl::execution::v1::parallel_unsequenced_policy const&,
__gnu_cxx::__normal_iterator > >,
__gnu_cxx::__normal_iterator > >)'
collect2: error: ld returned 1 exit status
If the algorithm module is built after the vector module, it will link
correctly. Sample code below, *.ii files attached.
import ;
import ;
import ;
using namespace std;
int main()
{
vector arr{};
sort(execution::par_unseq, arr.begin(), arr.end());
return 0;
}
Note this also breaks on 14.2.0 as provided via the docker container. This
15.0.0 is a hand-build for testing if the bug appeared on the trunk.
[Bug c++/116804] New: module order dependency with chrono and vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116804 Bug ID: 116804 Summary: module order dependency with chrono and vector Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc at richy dot net Target Milestone: --- Created attachment 59170 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59170&action=edit Collection of *.ii files richard@microserver:~/scratch/broken> gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/richard/gcc/lib/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --host=x86_64-pc-linux-gnu --prefix=/home/richard/gcc --enable-threads --enable-language=c,c++ --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20240917 (experimental) (GCC) Commands and output below, *.ii files attached. richard@microserver:~/scratch/broken> g++ -std=c++2b -fmodules-ts -fconcepts -fno-module-lazy -pthread -Wall -O3 -g -fPIC -save-temps -x c++-system-header vector richard@microserver:~/scratch/broken> g++ -std=c++2b -fmodules-ts -fconcepts -fno-module-lazy -pthread -Wall -O3 -g -fPIC -save-temps -x c++-system-header chrono /home/richard/gcc/include/c++/15.0.0/chrono:2981:39: error: wrong number of template arguments (1, should be 2) 2981 | _GLIBCXX_STD_C::vector links; | ^ In file included from /home/richard/gcc/include/c++/15.0.0/ostream:43, from /home/richard/gcc/include/c++/15.0.0/istream:41, from /home/richard/gcc/include/c++/15.0.0/sstream:40, from /home/richard/gcc/include/c++/15.0.0/chrono:49: /home/richard/gcc/include/c++/15.0.0/format:2642:36: note: provided for ‘template class std::vector’ 2642 | template class vector; |^~ /home/richard/gcc/include/c++/15.0.0/chrono:2981:23: error: ‘’ in namespace ‘std’ does not name a type 2981 | _GLIBCXX_STD_C::vector links; | ^ /home/richard/gcc/include/c++/15.0.0/chrono:2982:44: error: wrong number of template arguments (1, should be 2) 2982 | _GLIBCXX_STD_C::vector leap_seconds; |^ /home/richard/gcc/include/c++/15.0.0/format:2642:36: note: provided for ‘template class std::vector’ 2642 | template class vector; |^~ /home/richard/gcc/include/c++/15.0.0/chrono:2982:23: error: ‘’ in namespace ‘std’ does not name a type 2982 | _GLIBCXX_STD_C::vector leap_seconds; | ^~ /home/richard/gcc/include/c++/15.0.0/chrono:2983:41: error: wrong number of template arguments (1, should be 2) 2983 | | ^ /home/richard/gcc/include/c++/15.0.0/format:2642:36: note: provided for ‘template class std::vector’ 2642 | template class vector; |^~ /home/richard/gcc/include/c++/15.0.0/chrono:2983:23: error: ‘’ in namespace ‘std’ does not name a type 2983 | | ^ /home/richard/gcc/include/c++/15.0.0/chrono: In function ‘std::chrono::leap_second_info std::chrono::__detail::__get_leap_second_info(std::chrono::sys_seconds, bool)’: /home/richard/gcc/include/c++/15.0.0/chrono:3271:32: error: ‘const struct std::chrono::tzdb’ has no member named ‘leap_seconds’ 3271 | auto __last = __db->leap_seconds.end(); |^~~~ /home/richard/gcc/include/c++/15.0.0/chrono:3272:31: error: ‘const struct std::chrono::tzdb’ has no member named ‘leap_seconds’ 3272 | auto __pos = std::upper_bound(__first, __last, __ss); | ^~~~ Issue does not occur if chrono is compiled first. Note this also breaks on 14.2.0 as provided via the docker container. This 15.0.0 is a hand-build for testing if the bug appeared on the trunk.
[Bug libstdc++/116802] Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #6 from Xi Ruoyao --- (In reply to Tymi from comment #5) > (In reply to Andrew Pinski from comment #3) > > (In reply to Tymi from comment #2) > > > Oh, did not see that detail. It does compile with clang though. > > > > By clang you mean with libstd++ with clang or libc++? > > The default clang trunk implementation. Just double-tested as you sent this > message and turns out I made a typo while testing the clang version. This > issue is indeed invalid then. Sorry for trouble. "This issue is indeed invalid then" is misleading. Even if it compiles with Clang it's still invalid as comment 1 has already pointed out. A difference between GCC and Clang is not considered a bug just because it's a difference.
[Bug libstdc++/116802] Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- is a method of std::ctype https://en.cppreference.com/w/cpp/locale/ctype
[Bug libstdc++/116802] Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802 --- Comment #2 from Tymi --- Oh, did not see that detail. It does compile with clang though.
[Bug libstdc++/116802] New: Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802
Bug ID: 116802
Summary: Symbol `is` (non-standard) is user inside the library.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: wilczew.tymon at gmail dot com
Target Milestone: ---
All symbols that are not defined by the standard, should be reserved
identifiers. `is` is not a reserved identifier, yet it fails to compile. For
example compiling with -Dis= https://godbolt.org/z/cdan8r4b6.
```cpp
#define is
#include
int main(void)
{
return 0;
}
```
[Bug libstdc++/116802] Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802 --- Comment #4 from Andrew Pinski --- https://godbolt.org/z/d1s39v57v Does not work with either for me .
[Bug libstdc++/116802] Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802 --- Comment #5 from Tymi --- (In reply to Andrew Pinski from comment #3) > (In reply to Tymi from comment #2) > > Oh, did not see that detail. It does compile with clang though. > > By clang you mean with libstd++ with clang or libc++? The default clang trunk implementation. Just double-tested as you sent this message and turns out I made a typo while testing the clang version. This issue is indeed invalid then. Sorry for trouble.
[Bug libstdc++/116802] Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802 --- Comment #7 from Tymi --- "This issue is indeed invalid then" is not misleading. The issue is literally invalid. `is` is a standard function.
[Bug target/116800] std::simd: poor code generation of AVX512 fused multiply-add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116800 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-09-21 Blocks||53947 Status|UNCONFIRMED |NEW Component|libstdc++ |target Ever confirmed|0 |1 Target||x86_64-linux-gnu --- Comment #1 from Andrew Pinski --- /opt/compiler-explorer/gcc-trunk-20240921/include/c++/15.0.0/experimental/bits/simd.h:1869:86: note: starting SLP discovery for node 0x8d04280 /opt/compiler-explorer/gcc-trunk-20240921/include/c++/15.0.0/experimental/bits/simd.h:1869:86: note: Build SLP for _9 = fma (_7, _8, _6); /opt/compiler-explorer/gcc-trunk-20240921/include/c++/15.0.0/experimental/bits/simd.h:1869:86: note: get vectype for scalar type (group size 8): double /opt/compiler-explorer/gcc-trunk-20240921/include/c++/15.0.0/experimental/bits/simd.h:1869:86: note: vectype: vector(4) double /opt/compiler-explorer/gcc-trunk-20240921/include/c++/15.0.0/experimental/bits/simd.h:1869:86: note: nunits = 4 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug libstdc++/116802] Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802 --- Comment #8 from Xi Ruoyao --- (In reply to Tymi from comment #7) > "This issue is indeed invalid then" is not misleading. The issue is > literally invalid. `is` is a standard function. Yes it's already invalid because `is` is a standard function. I mean it's not related to if Clang compiles it or not.
[Bug libstdc++/116802] Symbol `is` (non-standard) is user inside the library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802
--- Comment #10 from Andrew Pinski ---
You only looked at the first error message and thought that.
I looked at:
/opt/compiler-explorer/gcc-trunk-20240921/include/c++/15.0.0/bits/locale_facets.h:2626:49:
error: expected unqualified-id before '(' token [-Wtemplate-body]
2626 | { return use_facet >(__loc).is(ctype_base::lower,
__c); }
To see where the problem would be.
[Bug target/116799] [14/15 Regression] Miscompiled code on s390x at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799 --- Comment #3 from Andrew Pinski --- (In reply to James McCoy from comment #2) > My initial bisect pointed to that, but I was using the Vim test suite as the > good/bad check. > > I'm rerunning now with just the minimal reproduction to double check the > results. I think you misunderstood, what I am saying is the x86 and s390x has the same IR at the point at expand and therefor the problem is not with the commit for PR 111294 itself but it is exposing an issue with something further along in the compiler. (hence calling it a latent bug). I have not looked further to see if the problem is in one of the RTL optimizations (which is exposed by the s390x backend) or in the s390x backend itself.
[Bug c++/116805] New: -fno-module-lazy breaks thread module when compiled after format module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116805
Bug ID: 116805
Summary: -fno-module-lazy breaks thread module when compiled
after format module
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at richy dot net
Target Milestone: ---
Created attachment 59171
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59171&action=edit
Collection of *.ii files
richard@microserver:~/scratch/broken> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/richard/gcc/lib/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --host=x86_64-pc-linux-gnu
--prefix=/home/richard/gcc --enable-threads --enable-language=c,c++
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240917 (experimental) (GCC)
Issued commands below, *.ii files attached.
g++ -std=c++2b -fmodules-ts -fconcepts -fno-module-lazy -Wall -O3 -g -fPIC
-save-temps -x c++-system-header format
g++ -std=c++2b -fmodules-ts -fconcepts -fno-module-lazy -Wall -O3 -g -fPIC
-save-temps -x c++-system-header thread
g++ -std=c++2b -fmodules-ts -fconcepts -fno-module-lazy -Wall -O3 -g -fPIC
-save-temps -c -o ex2.o -x c++ ex2.ixx
In module imported at ex2.ixx:3:1:
/home/richard/gcc/include/c++/15.0.0/thread: error: failed to read compiled
module cluster 1884: Bad file data
/home/richard/gcc/include/c++/15.0.0/thread: note: compiled module file is
‘gcm.cache/./home/richard/gcc/include/c++/15.0.0/thread.gcm’
/home/richard/gcc/include/c++/15.0.0/thread: error: failed to read compiled
module: Bad file data
/home/richard/gcc/include/c++/15.0.0/thread: fatal error: returning to the gate
for a mechanical issue
compilation terminated.
make: *** [Makefile:80: ex2.o] Error 1
Source code:
export module sorttools.sorts:foobar;
import ;
export namespace sorttools::sorts::foobar {
class Pieces {
public:
std::jthread hello{};
};
}
On 15.0.0 removing the -fno-module-lazy flag will allow this to compile, as
does swapping the order of format/thread.
[Bug c++/116793] [15 regression] ice in gimplify_var_or_parm_decl, at gimplify.cc:3309 since r15-3513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793
Jakub Jelinek changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
Looks like coro lowering bug to me. The ICE is on Aw0 VAR_DECL which is indeed
used before its declaration:
{
struct tuple & D.12700 [value-expr: frame_ptr->_D1_2_0];
int & i [value-expr: frame_ptr->i_1_2];
struct tuple D.14203 [value-expr: frame_ptr->_D1_2_1];
struct tuple D.14203 [value-expr: frame_ptr->_D1_2_1];
struct tuple & D.12700 [value-expr: frame_ptr->_D1_2_0];
TARGET_EXPR ;
if (<>)
{
<;
if (< (&Aw0,
TARGET_EXPR )>>)
{
<;
}
switch (<>)
{
case 0:;
<;
case 1:;
goto resume.4;
default:;
goto destroy.4;
}
destroy.4:;
goto coro.delete.promise;
}
resume.4:;
T002_2_3];
int T002 [value-expr: frame_ptr->T002_2_3];
All my patch changed is that instead of having one CLEANUP_POINT_EXPR around
the initialization of the unnamed structured binding
base variable and another one around the i there is one around the latter and
one around all that together, i.e. roughly
<)>
Aw0
Aw0 = TARGET_EXPR )>
{C::await_ready (&Aw0), C::await_suspend (&Aw0,
TARGET_EXPR ), <<< Unknown tree: aggr_init_expr
4
await_resume
D.14196
&Aw0 >>>}
0 >>>, (struct tuple &) &D.14203) >>>;
D.14220 = 1;>>;
int & i;
< (NON_LVALUE_EXPR )) >;
to:
<)>
Aw0
Aw0 = TARGET_EXPR )>
{C::await_ready (&Aw0), C::await_suspend (&Aw0,
TARGET_EXPR ), <<< Unknown tree: aggr_init_expr
4
await_resume
D.14196
&Aw0 >>>}
0 >>>, (struct tuple &) &D.14203) >>>;
D.14220 = 1;
int & i;
< (NON_LVALUE_EXPR )) >;>>;
and (some of the) cleanups on the outer one need to wait until a helper var (I
think D.14220 in this case) is set.
I know really nothing about coroutines.cc to find out what needs to be changed.
[Bug tree-optimization/116643] PHI_RESULT vs gimple_phi_result/gimple_phi_result_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116643 --- Comment #6 from Andrew Pinski --- here is the current list of files which have both PHI_RESULT and gimple_phi_result: gimple-streamer-out.cc tree-call-cdce.cc tree-cfg.cc tree-if-conv.cc tree-into-ssa.cc tree-parloops.cc tree-phinodes.cc tree-predcom.cc tree-scalar-evolution.cc tree-ssa-coalesce.cc tree-ssa-dom.cc tree-ssa-dse.cc tree-ssa-loop-ivopts.cc tree-ssa-loop-manip.cc tree-ssa-loop-unswitch.cc tree-ssa-math-opts.cc tree-ssa-sccvn.cc tree-ssa-threadupdate.cc tree-switch-conversion.cc tree-vect-loop-manip.cc tree-vect-loop.cc tree-vect-slp.cc
[Bug libstdc++/116777] error: 'current_zone' is not a member of 'std::chrono' with -D_GLIBCXX_USE_CXX11_ABI=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116777 --- Comment #9 from Sergey Fedorov --- (In reply to Iain Sandoe from comment #7) > as noted in several places; the long-term solution for Darwin (in general > since there's an installed /usr/lib/libstdc++.6.dylib even on modern > systems) - is for use to use an inline namespace for libstdc++ (always). > When that is done, there's no conflict with the older installed .6.dylib s. That would be awesome indeed.
[Bug c++/116798] New: requires expression can have an explicit object parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116798
Bug ID: 116798
Summary: requires expression can have an explicit object
parameter
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program
```
template
concept C = requires(this T u, this T v) {
u + v;
};
static_assert(C);
```
is accepted by GCC, but I believe it shall not, because explicit object
parameters (this) do not make any sense in requires expression. And even in
class functions, explicit object parameter can only appear as the first
parameter of the parameter list.
Clang rejects this program. Online demo: https://gcc.godbolt.org/z/G8xq7rd4x
[Bug target/113945] Switch visium to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113945 --- Comment #2 from Eric Botcazou --- This was explored some years ago but didn't come to fruition and there is little chance that another try will be given.
[Bug tree-optimization/116795] [15 regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_ssa failed since r15-3708-g2545a1abb77bd6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116795 Sam James changed: What|Removed |Added CC||pan2.li at intel dot com Summary|[15 regression] ICE on |[15 regression] ICE on |valid code at -O3 on|valid code at -O3 on |x86_64-linux-gnu: |x86_64-linux-gnu: |verify_ssa failed |verify_ssa failed since ||r15-3708-g2545a1abb77bd6 --- Comment #1 from Sam James --- r15-3708-g2545a1abb77bd6
[Bug tree-optimization/116799] [14/15 Regression] Miscompiled code on s390x at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Summary|[14 Regression] Miscompiled |[14/15 Regression] |code on s390x at -O2|Miscompiled code on s390x ||at -O2 Target Milestone|--- |14.3
[Bug target/116799] [14/15 Regression] Miscompiled code on s390x at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799 Andrew Pinski changed: What|Removed |Added Target||s390x Component|tree-optimization |target --- Comment #1 from Andrew Pinski --- The gimple IR between x86 ( -fno-tree-vectorize -O2 --param=logical-op-non-short-circuit=0) and s390x right before expanding is the same so this is either a RTL optimization issue or a target backend issue. That would mean the change that fixed PR 111294 would just have exposed this issue.
[Bug target/116799] [14/15 Regression] Miscompiled code on s390x at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799 --- Comment #2 from James McCoy --- My initial bisect pointed to that, but I was using the Vim test suite as the good/bad check. I'm rerunning now with just the minimal reproduction to double check the results.
[Bug other/116801] New: Many fortran options missing in lang.opt.urls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116801 Bug ID: 116801 Summary: Many fortran options missing in lang.opt.urls Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Target Milestone: --- There seems to be many options missing in fortran's lang.opt.urls. A possible problem is the presence of nested tags in the source of fortran's Option-Index.html gcc's Option-Index.html links: fpic fortran's Option-Index.html links: ffixed-form In fortran's links, the nested code tag has a space, so it is missed by the url update script.
[Bug other/116801] Many fortran options missing in lang.opt.urls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116801
--- Comment #1 from Mikael Morin ---
gcc's invoke.texi looks like:
@opindex fpic
@cindex global offset table
@cindex PIC
@item -fpic
whereas gfortran's invoke.texi has:
@opindex @code{ffree-form}
@opindex @code{ffixed-form}
@cindex options, Fortran dialect
@cindex file format, free
@cindex file format, fixed
@item -ffree-form
@itemx -ffixed-form
I haven't found this @opindex in the texinfo manual, but it seems plausible
that fixing the nested in the generated html would be as simple as
removing the @code as argument of @opindex.
[Bug driver/116794] gcc -pipe does not work on macOS with as from Xcode 16 (on macOS 15)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116794 Eric Gallager changed: What|Removed |Added Last reconfirmed||2024-09-21 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Ever confirmed|0 |1 Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #2 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > Fixed by r15-3737-g33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e . Reopening because Iain said he wanted to backport the change to older branches.
[Bug other/116613] RFE: support outputting diagnostics in *multiple* formats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- Yeah, in particular, I'd want to send text to stdout while also sending SARIF to a file that shares the input file's name, except with the .sarif extension. (i.e., compiling foo.c would create foo.sarif)
[Bug other/116792] RFE: should we be able to generate diagnostics in HTML format?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116792 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- clang requires a separate `scan-build` executable to do this, doesn't it? Or have they changed that? I'm not necessarily saying that GCC should do likewise, just that it might be worthwhile to compare...
