[Bug modula2/110631] Bug in FIO.WriteCardinal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110631 --- Comment #2 from Gaius Mulley --- Created attachment 55600 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55600&action=edit Proposed fix Here is a proposed fix - which will be applied (if/when) bootstrapping completes successfully.
[Bug bootstrap/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #7 from AlexK --- Created attachment 55601 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55601&action=edit applyed patch for Makefile.in to configure with --enable-shared and without --enable-static options
[Bug bootstrap/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #8 from AlexK --- Created attachment 55602 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55602&action=edit applyed patch for libgcc/Makefile.in to make shared library
[Bug bootstrap/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #9 from AlexK --- Created attachment 55603 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55603&action=edit applyed patch for libiberty/Makefile.in to make shared library
[Bug bootstrap/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #10 from AlexK --- Created attachment 55604 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55604&action=edit applyed patch for libdecnumber/Makefile.in to make shared library
[Bug bootstrap/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #11 from AlexK --- Created attachment 55605 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55605&action=edit applyed patch for libcody/Makefile.in to make shared library
[Bug bootstrap/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #12 from AlexK --- Created attachment 55606 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55606&action=edit applyed patch for libbacktrace/Makefile.in to make shared library
[Bug bootstrap/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #13 from AlexK --- Created attachment 55607 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55607&action=edit applyed patch for libcpp/Makefile.in to make shared library
[Bug bootstrap/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #14 from AlexK --- Created attachment 55608 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55608&action=edit applyed patch for gcc/Makefile.in to make shared library
[Bug bootstrap/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #15 from AlexK --- I have attached all patches I have made to several Makefile.in in different folders (I created them with `diff` tool) after that I made building directory: installdir=/tools/gcc-12.2.0 install -v -d mybuild cd mybuild ../configure --prefix="$installdir" --without-build-config LD=ld --enable-libssp --enable-bootstrap --enable-lto --with-isl=/usr/local --with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local --with-system-zlib --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-gcov --enable-languages=c,c++,fortran,objc,obj-c++,jit,go --enable-host-shared --disable-multilib --enable-shared a few changes to Makefile: sed -i 's/^\(@endif bfd\)$/#\1/' Makefile sed -i 's/^\(@endif opcodes\)$/#\1/' Makefile # !!! https://stackru.com/questions/63879492/bez-sbrosa-kompilyatsiya-gcc-na-crostini-zavershaetsya-s-oshibkoj-s-neizvestnoj unset LIBRARY_PATH CPATH C_INCLUDE_PATH PKG_CONFIG_PATH CPLUS_INCLUDE_PATH INCLUDE LD_LIBRARY_PATH make stage1 was successfully finished
[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #7 from Aurelien Jarno --- Created attachment 55609 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55609&action=edit crtbeginT.o GCC 12 version
[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #8 from Aurelien Jarno --- Created attachment 55610 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55610&action=edit crtbeginT.o GCC 12 version
[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #9 from Aurelien Jarno --- (In reply to Andrew Pinski from comment #5) > Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again? Yep, I'll do that, but it will probably take some time to get the results. (In reply to Andrew Pinski from comment #6) > Also can you attach the two versions of crtbeginT.o (the one from GCC 12 and > one from GCC 13). > If anything there has to be some extra null pointer happening ... I have just done that.
[Bug libstdc++/109921] [13 Regression] c++17/floating_from_chars.cc: compile error: ‘from_chars_strtod’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109921 --- Comment #12 from Jonathan Wakely --- Excellent, thanks for checking.
[Bug modula2/110631] Bug in FIO.WriteCardinal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110631 --- Comment #3 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:73cc6ce1294ec35e9322b1bbc91009cfc76f732b commit r14-2725-g73cc6ce1294ec35e9322b1bbc91009cfc76f732b Author: Gaius Mulley Date: Sat Jul 22 10:01:02 2023 +0100 PR modula2/110631 Bugfix to FIO WriteCardinal FIO.WriteCardinal fails to write binary data. This patch fixes two bugs in FIO.mod and provides a testcase which writes and reads binary cardinals. There was an off by one error when using HIGH (a) to determine the number of bytes and the dest/src pointers were switched when calling memcpy. gcc/m2/ChangeLog: PR modula2/110631 * gm2-libs/FIO.def (ReadAny): Correct comment as HIGH (a) + 1 is number of bytes. (WriteAny): Correct comment as HIGH (a) + 1 is number of bytes. * gm2-libs/FIO.mod (ReadAny): Correct comment as HIGH (a) + 1 is number of bytes. Also pass HIGH (a) + 1 to BufferedRead. (WriteAny): Correct comment as HIGH (a) + 1 is number of bytes. Also pass HIGH (a) + 1 to BufferedWrite. (BufferedWrite): Rename parameter a to src, rename variable t to dest. Correct parameter order to memcpy. gcc/testsuite/ChangeLog: PR modula2/110631 * gm2/pimlib/run/pass/testfiobinary.mod: New test. Signed-off-by: Gaius Mulley
[Bug modula2/110631] Bug in FIO.WriteCardinal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110631 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Gaius Mulley --- Closing now that the patch has been applied.
[Bug modula2/110174] Using illegal constraints for builtin return_address gives ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110174 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2023-07-22 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Gaius Mulley --- Confirmed - thanks for the bug report and test code - will fix!
[Bug libgcc/110775] [12/13/14 Regression] abort define causing issues in tsystem.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775 Sebastian Huber changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #2 from Sebastian Huber --- In tsystem.h we have: #ifdef inhibit_libc ... #ifndef abort #define abort() __builtin_trap () #endif Does it make sense to define inhibit_libc and then later use and ?
[Bug middle-end/110757] [14 Regression] 7% parest regression on zen3 -Ofast -march=native -flto between g:4dbb3af1efe55174 (2023-07-14 00:54) and g:a5088dc3f5ef73c8 (2023-07-17 03:24)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110757 Martin Jambor changed: What|Removed |Added CC||lili.cui at intel dot com, ||rguenth at gcc dot gnu.org Last reconfirmed||2023-07-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Martin Jambor --- And while I am at it, the 2.5% slowdown in April was caused by Richi's r14-332-g24905a4bd1375c (Adjust costing of emulated vectorized gather/scatter) and the 2.8% regression in May by 2.8% is caused by r14-1371-ge5405f065bace0 (Handle FMA friendly in reassoc pass). Both are small and so may not warrant their own bug-report but together they make up almost 6% and we are now 13% slower than GCC 13 on zen 3 and 2 (on the Intel machine in LNT it is just 2.7% and I see no regression on the Aarch64 one).
[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #10 from Aurelien Jarno --- (In reply to Aurelien Jarno from comment #9) > (In reply to Andrew Pinski from comment #5) > > Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again? > > Yep, I'll do that, but it will probably take some time to get the results. > I built a cross-compiler so it went faster than expected. However reverting that commit doesn't change anything, the generated crtbeginT.o is unchanged, so the issue is still there.
[Bug tree-optimization/110766] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in gimple_phi_arg_def_from_edge, at gimple.h:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110766 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #2 from David Binderman --- I see this also, except with -O2. The bug first seems to occur sometime between g:43fefc1f832a8037 and g:b5138df96a93d3b5, a range of 31 commits. I have a reduction running.
[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #11 from Aurelien Jarno --- I have bisected the issue, and I found it has been introduced by the following commit: commit 3cd08f7168c196d7a481b9ed9f4289fd1f14eea8 Author: Andreas Schwab Date: Wed Jan 25 12:00:09 2023 +0100 riscv: Enable -fasynchronous-unwind-tables by default on Linux This follows the example of aarch64. gcc/: * common/config/riscv/riscv-common.cc (riscv_option_optimization_table) [TARGET_DEFAULT_ASYNC_UNWIND_TABLES]: Enable -fasynchronous-unwind-tables and -funwind-tables. * config.gcc (riscv*-*-linux*): Define TARGET_DEFAULT_ASYNC_UNWIND_TABLES.
[Bug target/110772] strange code generated for bit-field access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
--- Comment #5 from Roland Illig ---
Sorry for the confusing description. Let me try again.
NetBSD lint includes a yacc parser for C code. This parser contains the rules
'block_item_list' and 'block_item':
https://github.com/NetBSD/src/blob/7ebcd1679b455e619909ec9c128e8ad7f103ded9/usr.bin/xlint/lint1/cgram.y#L1804
> block_item_list: /* C99 6.8.2 */
> block_item
> | block_item_list block_item {
> if ($1 && !$2)
> /* declarations after statements is a C99 feature */
> c99ism(327);
> $$ = $1 || $2;
> }
The rule 'block_item' remembers in 'y_seen_statement' whether the item was a
statement, so that the parser rule 'block_item_list' can warn in C90 mode.
In another part of the parser, the rule 'gcc_attribute' handles the keyword
'const', by accessing 'y_type_qualifiers.tq_const', which on 2023-07-15 was a
_Bool bit-field member in 'struct type_qualifiers'.
https://github.com/NetBSD/src/blob/7ebcd1679b455e619909ec9c128e8ad7f103ded9/usr.bin/xlint/lint1/cgram.y#L2197
> gcc_attribute:
> | type_qualifier {
> if (!$1.tq_const)
> yyerror("Bad attribute");
> }
On big-endian arm and powerpc, the code that GCC 10.5.0 generates for the
'block_item_list' parser rule depends on whether the 'gcc_attribute' parser
rule accesses a bit-field member or not. This does not make sense to me, as I
expect the parser rules to be independent.
When I compile this parser on arm with -O2 and run lint in C90 mode, it not
only warns about declarations after statements, but also about statements after
statements.
$ gcc -O2 -ftrapv -fPIE -std=gnu99 -S cgram.c -o cgram.casmv -fverbose-asm
The code that is generated for the condition '$1 && !$2' is:
> @ cgram.y:1802: if ($1 && !$2)
> ldr r6, .L580+796
> add r6, pc, r6
> ldr r4, [r6, #20]
> ldrbr3, [r4, #-8] @ $1.y_seen_statement
> cmp r3, #0
> beq .L368
> @ cgram.y:550: $$ = build_unary($2 == INC ? INCAFT : DECAFT, $3, $1);
> ldrbr3, [r4]
> @ cgram.y:1802:
> lsrsr3, r3, #7 @ $2.y_type_qualifiers.tq_const
> beq .L562
(Annotations hand-edited by me.)
Two strange things happen here:
1. The code from cgram.y:550 is completely unrelated, so it should not have
been mentioned here. The 'ldrb' is correct, so maybe it's just the attribution
that is wrong.
2. The expressions '$1' and '$2' both have type _Bool. Nevertheless, the second
bool is accessed as if it were a bit-field. Due to this access, no matter
whether '$2 as bool' is 1 or 0, the the expression '($2 as bit-field) >> 7'
always evaluates to 0, so the condition '$1 && !$2' evaluates to true, which
results in the additional warnings from lint.
Instead of lsrs, GCC should have generated a cmp instruction.
I don't have any other GCC version installed on the machine, so I cannot test
whether GCC 11.4.0 behaves differently.
[Bug target/110772] strange code generated for bit-field access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772 Roland Illig changed: What|Removed |Added Attachment #55598|0 |1 is obsolete|| Attachment #55599|0 |1 is obsolete|| --- Comment #6 from Roland Illig --- Created attachment 55611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55611&action=edit Precompiled source from comment 5
[Bug target/110772] strange code generated for bit-field access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772 --- Comment #7 from Roland Illig --- Created attachment 55612 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55612&action=edit Preprocessed source from comment 5
[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #12 from Aurelien Jarno ---
Backtrace with debug symbols in libgcc_eh.a:
Program received signal SIGSEGV, Segmentation fault.
classify_object_over_fdes (ob=0xe2da0 , this_fde=0x1000530e6,
range=0x3ff310) at ../../../gcc/libgcc/unwind-dw2-fde.c:727
727 ../../../gcc/libgcc/unwind-dw2-fde.c: No such file or directory.
(gdb) bt full
#0 classify_object_over_fdes (ob=0xe2da0 , this_fde=0x1000530e6,
range=0x3ff310) at ../../../gcc/libgcc/unwind-dw2-fde.c:727
last_cie = 0x8a43a
count = 1
encoding = 0
base = 0
#1 0x0005277c in __register_frame_info_bases (dbase=0x0, tbase=0x0,
ob=0xe2da0 , begin=) at
../../../gcc/libgcc/unwind-dw2-fde.c:129
range = {4294854026, 4294854042}
range =
#2 __register_frame_info_bases (dbase=0x0, tbase=0x0, ob=0xe2da0 ,
begin=) at ../../../gcc/libgcc/unwind-dw2-fde.c:109
range =
range =
#3 __register_frame_info (begin=, ob=0xe2da0 ) at
../../../gcc/libgcc/unwind-dw2-fde.c:145
No locals.
#4 0x00010728 in frame_dummy ()
No symbol table info available.
#5 0x00010a2a in call_init (envp=0x3ff3d0, argv=0x3ff3b8,
argc=2) at libc-start.c:189
i = 0
size =
size =
size =
i =
i =
#6 __libc_start_main_impl (main=0x105f8 , argc=2, argv=0x3ff3b8,
init=, fini=, rtld_fini=,
stack_end=)
at libc-start.c:355
ev = 0x3ff3d0
auxvec =
stack_chk_guard =
pointer_chk_guard =
#7 0x00010638 in _start () at ../sysdeps/riscv/start.S:61
[Bug target/110776] New: [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776 Bug ID: 110776 Summary: [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- The ICE seems to be because rs6000_builtin_vectorization_cost () is called with a request for a misaligned load (which we do not support), It reproduces on a cross from x86_64. This is in compiling libgfortran generated code (so nothing Darwin-specific, other than being an Altivec platform). A philosophical question; if a request is made for the cost of doing something unsupported - should we not return "infinity" rather than ICEing? Presumably, the alternative is that the middle end needs to know that some kinds of operation are not supported and therefore not to try and cost them (speculation here; I have no knowledge of the relevant code). = /gcc/cc1 -fpreprocessed .libs/reshape_i4.i -feliminate-unused-debug-symbols -fPIC -quiet -dumpdir .libs/ -dumpbase reshape_i4.c -dumpbase-ext .c -m64 -mmacosx-version-min=10.5 -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -Wunknown-pragmas -std=gnu11 -std=gnu11 -version -fcx-fortran-rules -ffunction-sections -fdata-sections -fno-common -o .libs/reshape_i4.s backtrace: * frame #0: 0x000101d840cd cc1`internal_error(gmsgid="in %s, at %s:%d") at diagnostic.cc:2166:25 frame #1: 0x000101d845b3 cc1`fancy_abort(file="/src-local/gcc-master/gcc/config/rs6000/rs6000.cc", line=5069, function="rs6000_builtin_vectorization_cost") at diagnostic.cc:2296:18 frame #2: 0x000101accf54 cc1`::rs6000_builtin_vectorization_cost(type_of_cost=unaligned_load, vectype=0x000115045a80, misalign=-1) at rs6000.cc:5069:4 frame #3: 0x0001019bb55c cc1`builtin_vectorization_cost(type_of_cost=unaligned_load, vectype=0x000115045a80, misalign=-1) at tree-vectorizer.h:1789:55 frame #4: 0x000101903b4f cc1`::record_stmt_cost(body_cost_vec=0x000308b11a00, count=1, kind=unaligned_load, stmt_info=0x000111a0e210, node=0x, vectype=0x000115045a80, misalign=-1, where=vect_body) at tree-vect-stmts.cc:113:35 frame #5: 0x000101903b9e cc1`record_stmt_cost(body_cost_vec=0x000308b11a00, count=1, kind=unaligned_load, stmt_info=0x000111a0e210, vectype=0x000115045a80, misalign=-1, where=vect_body) at tree-vect-stmts.cc:122:27 frame #6: 0x00010197ea64 cc1`record_stmt_cost(body_cost_vec=0x000308b11a00, count=1, kind=unaligned_load, stmt_info=0x000111a0e210, misalign=-1, where=vect_body) at tree-vectorizer.h:2210:27 frame #7: 0x0001019073f6 cc1`vect_get_load_cost((null)=0x000111a0d110, stmt_info=0x000111a0e210, ncopies=1, alignment_support_scheme=dr_unaligned_supported, misalignment=-1, add_realign_cost=false, inside_cost=0x000308b10ac4, prologue_cost=0x, prologue_cost_vec=0x000308b11a00, body_cost_vec=0x000308b11a00, record_prologue_costs=true) at tree-vect-stmts.cc:1307:35 frame #8: 0x00010192b199 cc1`::vectorizable_load(vinfo=0x000111a0d110, stmt_info=0x000111a0e210, gsi=0x, vec_stmt=0x, slp_node=0x, cost_vec=0x000308b11a00) at tree-vect-stmts.cc:9989:26 frame #9: 0x0001019329be cc1`vect_analyze_stmt(vinfo=0x000111a0d110, stmt_info=0x000111a0e210, need_to_vectorize=0x000308b11a0f, node=0x, node_instance=0x, cost_vec=0x000308b11a00) at tree-vect-stmts.cc:12124:25 frame #10: 0x00010194622e cc1`::vect_analyze_loop_operations(loop_vinfo=0x000111a0d110) at tree-vect-loop.cc:2083:23 frame #11: 0x000101948c6e cc1`::vect_analyze_loop_2(loop_vinfo=0x000111a0d110, fatal=0x000308b1292f, suggested_unroll_factor=0x000308b1276c, slp_done_for_suggested_uf=0x000308b1276b) at tree-vect-loop.cc:2880:37 frame #12: 0x00010194a49b cc1`::vect_analyze_loop_1(loop=0x000115007200, shared=0x000308b12ce0, loop_form_info=0x000308b129f0, main_loop_vinfo=0x, vector_modes=0x000308b129b0, mode_i=0x000308b1299c, autodetected_vector_mode=0x000308b129ac, fatal=0x000308b1292f) at tree-vect-loop.cc:3316:40 frame #13: 0x00010194b036 cc1`vect_analyze_loop(loop=0x000115007200, shared=0x000308b12ce0) at tree-vect-loop.cc:3470:24 frame #14: 0x0001019be5c5 cc1`::try_vectorize_loop_1(simduid_to_vf_htab=0x000308b12f30, num_vectorized_loops=0x000308b12f3c, loop=0x000115007200, loop_vectorized_call=0x0001150e61b0, loop_dist_alias_call=0x, f
[Bug target/110741] vec_ternarylogic intrinsic generates incorrect code on POWER10 target when compiled with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110741 --- Comment #3 from Peter Bergner --- (In reply to Kewen Lin from comment #2) > It exposed one issue on xxeval output vsx operands' format, can be fixed > with: > > diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md > index 0c269e4e8d9..1a87f1c0b63 100644 > --- a/gcc/config/rs6000/vsx.md > +++ b/gcc/config/rs6000/vsx.md > @@ -6586,7 +6586,7 @@ (define_insn "xxeval" >(match_operand:QI 4 "u8bit_cint_operand" "n")] > UNSPEC_XXEVAL))] > "TARGET_POWER10" > - "xxeval %0,%1,%2,%3,%4" > + "xxeval %x0,%x1,%x2,%x3,%4" > [(set_attr "type" "vecperm") > (set_attr "prefixed" "yes")]) Good catch. I consider that an "obvious" fix. Please check for needed backports.
[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776 --- Comment #1 from Iain Sandoe --- Created attachment 55613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55613&action=edit preprocessed (not reduced, but the function is not large)
[Bug target/110772] strange code generated for bit-field access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772 --- Comment #8 from Roland Illig --- When I compile the attached code with "ARM GCC 10.5.0" and "-O2 -fPIE -ftrapv" on godbolt.org, the generated code is correct (you can search for "#327" in the output and then go back one branch). The code generated by godbolt.org "ARM GCC 11.4.0" with "-O2 -fPIE -ftrapv" looks good as well. So it could also be that the NetBSD version of GCC is missing a bug-fix or two.
[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Summary|[RISC-V] Segment fault if |[13/14 Regression] [RISC-V] |compiled with -static -pg |Segment fault if compiled ||with -static -pg Target Milestone|--- |13.2 Keywords||EH, wrong-code Last reconfirmed||2023-07-22 Status|UNCONFIRMED |NEW --- Comment #13 from Andrew Pinski --- Confirmed. I will be adding a patch for someone to test out ...
[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #14 from Andrew Pinski --- Created attachment 55614 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55614&action=edit patch for someone to test out The problem is the similar across many targets so I basically copied what was done for another target.
[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776 Andrew Pinski changed: What|Removed |Added Keywords||build Target Milestone|--- |14.0
[Bug tree-optimization/110766] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in gimple_phi_arg_def_from_edge, at gimple.h:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110766
--- Comment #3 from David Binderman ---
Reduced C++ code seems to be:
template struct _Base_bitset {
unsigned long _M_w[_Nw];
unsigned long &_M_getword() { return _M_w[0]; }
};
struct bitset : _Base_bitset<0> {
int _Unchecked_set___val;
void set() {
long __trans_tmp_4;
if (_Unchecked_set___val)
_M_getword() |= __trans_tmp_4;
}
void reset() {
long __trans_tmp_5, __trans_tmp_3;
__trans_tmp_5 = 1 << __trans_tmp_3;
_M_getword() &= __trans_tmp_5;
}
};
using PlayBehaviourSet = bitset;
struct CSoundFile {
PlayBehaviourSet m_playBehaviour;
void UpgradeModule();
};
void CSoundFile::UpgradeModule() {
for (int i = 0; i < 5; i++) {
m_playBehaviour.set();
m_playBehaviour.reset();
}
}
cvise $ ~/gcc/results/bin/gcc -c -O2 bug943.cc
during GIMPLE pass: sccp
bug943.cc: In member function ‘void CSoundFile::UpgradeModule()’:
bug943.cc:23:6: internal compiler error: in gimple_phi_arg_def_from_edge, at
gimple.h:4699
23 | void CSoundFile::UpgradeModule() {
| ^~
0x123f7dc final_value_replacement_loop(loop*)
../../trunk.year/gcc/tree-scalar-evolution.cc:0
0x12fdfb7 (anonymous namespace)::pass_scev_cprop::execute(function*)
../../trunk.year/gcc/tree-ssa-loop.cc:411
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug fortran/110677] UBSAN error: load of value 1818451807, which is not a valid value for type 'expr_t' when compiling pr49213.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110677 Martin Jambor changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #1 from Martin Jambor --- I believe the testcase fails with UBSAN since its introduction in r14-2160-g3521768e8e3c44 (Fortran: Enable class expressions in structure constructors [PR49213]). It can be reproduced without UBSAN by adding an assert like: diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index 8e018b6e7e8..66735e163b3 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -1392,6 +1392,10 @@ resolve_structure_cons (gfc_expr *expr, int init) } } + gcc_assert (cons->expr->ts.type != BT_CHARACTER + || !comp->ts.u.cl + || !comp->ts.u.cl->length + || comp->ts.u.cl->length->expr_type != 1818451807); /* For strings, the length of the constructor should be the same as the one of the structure, ensure this if the lengths are known at compile time and when we are dealing with PARAMETER or structure
[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #15 from Aurelien Jarno --- (In reply to Andrew Pinski from comment #14) > Created attachment 55614 [details] > patch for someone to test out > > The problem is the similar across many targets so I basically copied what > was done for another target. Thanks for the patch, unfortunately it doesn't work as is. However, as commit 3cd08f7168c196d7a481b9ed9f4289fd1f14eea8 enabled both -fno-asynchronous-unwind-tables and -fno-unwind-tables, I have tried to add -fno-unwind-tables to riscv/t-crtstuff and that works.
[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #16 from Andrew Pinski --- (In reply to Aurelien Jarno from comment #15) > (In reply to Andrew Pinski from comment #14) > > Created attachment 55614 [details] > > patch for someone to test out > > > > The problem is the similar across many targets so I basically copied what > > was done for another target. > > Thanks for the patch, unfortunately it doesn't work as is. However, as > commit 3cd08f7168c196d7a481b9ed9f4289fd1f14eea8 enabled both > -fno-asynchronous-unwind-tables and -fno-unwind-tables, I have tried to add > -fno-unwind-tables to riscv/t-crtstuff and that works. Ok, I will add -fno-unwind-tables and submit the patch then. Thanks for testing the patch and improving it.
[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #17 from Andreas Schwab --- I don't think you need -fno-omit-frame-pointer.
[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #18 from Aurelien Jarno --- (In reply to Andreas Schwab from comment #17) > I don't think you need -fno-omit-frame-pointer. I confirm that CRTSTUFF_T_CFLAGS += -fno-asynchronous-unwind-tables -fno-unwind-tables is enough to fix the issue.
[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #19 from Andreas Schwab --- Probably also needed for aarch64.
[Bug analyzer/110433] ASAN reports mismatching new/delete when compiling analyzer testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110433 --- Comment #5 from Martin Jambor --- Indeed, the error is no longer reported. Thanks.
[Bug c/110777] New: ice: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777
Bug ID: 110777
Summary: ice: SSA corruption
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C code
int *findOrAddBackgroundInPalette_palette_pnm;
static void findOrAddBackgroundInPalette(unsigned *paletteSizeP,
int *backgroundIndexP) {
if (*paletteSizeP) {
*backgroundIndexP = (*paletteSizeP)++;
pm_message();
}
pm_message(findOrAddBackgroundInPalette_palette_pnm[*backgroundIndexP]);
}
void computeColorMap(int *backgroundIndexP) {
unsigned paletteSize;
findOrAddBackgroundInPalette(&paletteSize, backgroundIndexP);
}
int main() {
unsigned backgroundIndex;
_setjmp();
computeColorMap(&backgroundIndex);
}
with recent gcc trunk, does this:
$ ~/gcc/results/bin/gcc -c -O3 -w ~/cvise/bug944.c
Unable to coalesce ssa_names 27 and 31 which are marked as MUST COALESCE.
paletteSize_27(ab) and paletteSize_31(ab)
during RTL pass: expand
/home/dcb38/cvise/bug944.c: In function ‘main’:
/home/dcb38/cvise/bug944.c:14:5: internal compiler error: SSA corruption
14 | int main() {
| ^~~~
0xf95b19 fail_abnormal_edge_coalesce(int, int)
../../trunk.year/gcc/tree-ssa-coalesce.cc:1003
0xf95b19 coalesce_partitions(_var_map*, ssa_conflicts*, coalesce_list*,
_IO_FILE*)
../../trunk.year/gcc/tree-ssa-coalesce.cc:1425
The bug first seems to occur sometime between g:b2cfe5233e682fc0
and g:f32518726ee8e836, a range of 30 commits.
[Bug tree-optimization/110777] [14 Regression] ice: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777 Andrew Pinski changed: What|Removed |Added Summary|ice: SSA corruption |[14 Regression] ice: SSA ||corruption Keywords||ice-on-valid-code Target Milestone|--- |14.0 Component|c |tree-optimization Version|unknown |14.0
[Bug tree-optimization/110777] [14 Regression] ice: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777 --- Comment #1 from Andrew Pinski --- Is this reduced from some other code? Because the testcase here depends on an uninitialized variable.
[Bug tree-optimization/110777] [14 Regression] ice: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777 --- Comment #2 from David Binderman --- Created attachment 55615 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55615&action=edit C source code Original pre-reduction source code.
[Bug tree-optimization/110777] [14 Regression] ice: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777 --- Comment #3 from David Binderman --- Attempting bisection. Trying g:85a4e4f93ff251f2
[Bug tree-optimization/110777] [14 Regression] ice: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777 --- Comment #4 from David Binderman --- Current range seems to be g:23ad5ed7432bea7c to g:85a4e4f93ff251f2. Trying g:b6b72562d116bd0a
[Bug tree-optimization/110777] [14 Regression] ice: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777 David Binderman changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #5 from David Binderman --- $ git bisect good c5bd0e5870aed178 d0de3bf9175877d6c51c94fe04662c6e031876e1 is the first bad commit commit d0de3bf9175877d6c51c94fe04662c6e031876e1 Author: Richard Biener Date: Mon Jul 17 12:15:29 2023 +0200 tree-optimization/110204 - second level redundancy and simplification
[Bug tree-optimization/110777] [14 Regression] ice: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-07-22 --- Comment #6 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/110755] [13/14 Regression] Wrong optimization of fabs on ppc64el at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755 --- Comment #7 from Aurelien Jarno --- (In reply to Jakub Jelinek from comment #6) > Created attachment 55594 [details] > gcc14-pr110755.patch > > Untested patch. Thanks for the patch, I confirm it works as expected, now the result is a positive 0 when using -frounding-math.
[Bug target/110778] New: Alpha targets broken since r14-2587-gd8105b10fff951 (undefined reference to extended_count)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110778 Bug ID: 110778 Summary: Alpha targets broken since r14-2587-gd8105b10fff951 (undefined reference to extended_count) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: ubizjak at gmail dot com Target Milestone: --- Host: x86_64-linux-gnu Target: alpha-linux-gnu Since revision r14-2587-gd8105b10fff951 (combine: Change return type of predicate functions from int to bool), very simple attempts to build a cross-compiler for alpha targets fail. I configure the compiler with: ../src/configure --target=alpha-linux-gnu --disable-bootstrap --enable-languages=c,c++ --disable-multilib --enable-obsolete and then run: make all-host CXXFLAGS="-O0 -g" CFLAGS="-O0 -g" which fails with: g++ -no-pie -O0 -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -no-pie -static-libstdc++ -static-libgcc -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o glibc-c.o \ cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lisl -lmpc -lmpfr -lgmp -rdynamic -L./../zlib -lz -lzstd /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: insn-emit.o: in function `gen_split_31(rtx_insn*, rtx_def**)': /home/mjambor/gcc/mine/obj/gcc/../../src/gcc/config/alpha/alpha.md:2976: undefined reference to `extended_count(rtx_def const*, machine_mode, int)' /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: /home/mjambor/gcc/mine/obj/gcc/../../src/gcc/config/alpha/alpha.md:2977: undefined reference to `extended_count(rtx_def const*, machine_mode, int)' /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: insn-emit.o: in function `gen_split_32(rtx_insn*, rtx_def**)': /home/mjambor/gcc/mine/obj/gcc/../../src/gcc/config/alpha/alpha.md:3022: undefined reference to `extended_count(rtx_def const*, machine_mode, int)' /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: /home/mjambor/gcc/mine/obj/gcc/../../src/gcc/config/alpha/alpha.md:3023: undefined reference to `extended_count(rtx_def const*, machine_mode, int)'
[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #20 from Andrew Pinski --- (In reply to Andreas Schwab from comment #19) > Probably also needed for aarch64. Testing that and will submit both patches after that finishes.
[Bug target/110778] [14 Regression] Alpha targets broken since r14-2587-gd8105b10fff951 (undefined reference to extended_count)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110778 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Summary|Alpha targets broken since |[14 Regression] Alpha |r14-2587-gd8105b10fff951|targets broken since |(undefined reference to |r14-2587-gd8105b10fff951 |extended_count) |(undefined reference to ||extended_count) Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2023-07-22 Target Milestone|--- |14.0 --- Comment #1 from Andrew Pinski --- I have the simple/obvious fix to rtl.h.
[Bug target/110778] [14 Regression] Alpha targets broken since r14-2587-gd8105b10fff951 (undefined reference to extended_count)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110778 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:659d856e1d424ea8ef634844a7bd08b86ec7344b commit r14-2729-g659d856e1d424ea8ef634844a7bd08b86ec7344b Author: Andrew Pinski Date: Sat Jul 22 20:34:41 2023 + Fix alpha building The problem is after r14-2587-gd8105b10fff951, the definition of extended_count now takes a bool as its last argument but we only have a declaration for the version which takes an int as the last argument. This fixes the problem by changing the declaration to be a bool too. Committed as obvious after building a cross to alpha-linux-gnu. gcc/ChangeLog: PR target/110778 * rtl.h (extended_count): Change last argument type to bool.
[Bug target/110778] [14 Regression] Alpha targets broken since r14-2587-gd8105b10fff951 (undefined reference to extended_count)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110778 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed.
[Bug target/110533] [x86-64] naked with -O0 and register-passed struct/int128 clobbers parameters/callee-saved regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110533
--- Comment #5 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:8125b12f846b41f26e58c0fe3b218d654f65d1c8
commit r14-2730-g8125b12f846b41f26e58c0fe3b218d654f65d1c8
Author: Roger Sayle
Date: Sat Jul 22 21:52:55 2023 +0100
i386: Don't use insvti_{high,low}part with -O0 (for compile-time).
This patch attempts to help with PR rtl-optimization/110587, a regression
of -O0 compile time for the pathological pr28071.c. My recent patch helps
a bit, but hasn't returned -O0 compile-time to where it was before my
ix86_expand_move changes. The obvious solution/workaround is to guard
these new TImode parameter passing optimizations with "&& optimize", so
they don't trigger when compiling with -O0. The very minor complication
is that "&& optimize" alone leads to the regression of pr110533.c, where
our improved TImode parameter passing fixes a wrong-code issue with naked
functions, importantly, when compiling with -O0. This should explain
the one line fix below "&& (optimize || ix86_function_naked (cfun))".
I've an additional fix/tweak or two for this compile-time issue, but
this change eliminates the part of the regression that I've caused.
2023-07-22 Roger Sayle
gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_expand_move): Disable the
64-bit insertions into TImode optimizations with -O0, unless
the function has the "naked" attribute (for PR target/110533).
[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587
--- Comment #13 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:8125b12f846b41f26e58c0fe3b218d654f65d1c8
commit r14-2730-g8125b12f846b41f26e58c0fe3b218d654f65d1c8
Author: Roger Sayle
Date: Sat Jul 22 21:52:55 2023 +0100
i386: Don't use insvti_{high,low}part with -O0 (for compile-time).
This patch attempts to help with PR rtl-optimization/110587, a regression
of -O0 compile time for the pathological pr28071.c. My recent patch helps
a bit, but hasn't returned -O0 compile-time to where it was before my
ix86_expand_move changes. The obvious solution/workaround is to guard
these new TImode parameter passing optimizations with "&& optimize", so
they don't trigger when compiling with -O0. The very minor complication
is that "&& optimize" alone leads to the regression of pr110533.c, where
our improved TImode parameter passing fixes a wrong-code issue with naked
functions, importantly, when compiling with -O0. This should explain
the one line fix below "&& (optimize || ix86_function_naked (cfun))".
I've an additional fix/tweak or two for this compile-time issue, but
this change eliminates the part of the regression that I've caused.
2023-07-22 Roger Sayle
gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_expand_move): Disable the
64-bit insertions into TImode optimizations with -O0, unless
the function has the "naked" attribute (for PR target/110533).
[Bug target/110748] RISC-V: optimize store of DF 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #14 from CVS Commits ---
The master branch has been updated by Vineet Gupta :
https://gcc.gnu.org/g:ecfa870ff29d979bd2c3d411643b551f2b6915b0
commit r14-2731-gecfa870ff29d979bd2c3d411643b551f2b6915b0
Author: Vineet Gupta
Date: Thu Jul 20 11:15:37 2023 -0700
RISC-V: optim const DF +0.0 store to mem [PR/110748]
Fixes: ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT")
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to optimize
it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
| ret
With patch
| sd zero,0(a0)
| ret
The fix updates predicate const_0_operand() so reg_or_0_operand () now
includes const_double, enabling movdf expander -> riscv_legitimize_move ()
to generate below vs. an intermediate set (reg:DF) const_double:DF
| (insn 6 3 0 2 (set (mem:DF (reg/v/f:DI 134 [ d ])
|(const_double:DF 0.0 [0x0.0p+0]))
This change also enables such insns to be recog() by later passes.
The md pattern "*movdf_hardfloat_rv64" despite already supporting the
needed constraints {"m","G"} mem/const 0.0 was failing to match because
the additional condition check reg_or_0_operand() was failing due to
missing const_double.
This failure to recog() was triggering an ICE when testing the in-flight
f-m-o patches and is how all of this started, but then was deemed to be
an independent optimization of it's own [1].
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624857.html
Its worthwhile to note all the set peices were already there and working
up until my own commit mentioned at top regressed the whole thing.
Ran thru full multilib testsuite and no surprises. There was 1 false
failure due to random string "lw" appearing in lto build assembler output,
which is also fixed here.
gcc/ChangeLog:
PR target/110748
* config/riscv/predicates.md (const_0_operand): Add back
const_double.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr110748-1.c: New Test.
* gcc.target/riscv/xtheadfmv-fmv.c: Add '\t' around test
patterns to avoid random string matches.
Signed-off-by: Vineet Gupta
[Bug tree-optimization/100864] (a&!b) | b is not opimized to a | b for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-July/62 ||5289.html Keywords||patch --- Comment #7 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625289.html
[Bug middle-end/107737] seemly looking off code in gimplify_call_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737 --- Comment #2 from Andrew Pinski --- So far gimplify_vla_decl does not set the location on the call expression it creates. It should be set to the same as the decl source location. Testing that ...
[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #21 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625290.html
[Bug middle-end/107737] seemly looking off code in gimplify_call_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737
--- Comment #3 from Andrew Pinski ---
A C++ front-end does not set the call for deconstructor for the following
testcase:
```
struct s{ ~s(); };
void f()
{
s{};
}
```
[Bug tree-optimization/110769] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769
Zhendong Su changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Comment #2 from Zhendong Su ---
Another related test:
[591] % gcctk -O3 small.c
during GIMPLE pass: ch_vect
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in adjust_loop_info_after_peeling, at
tree-ssa-loop-ivcanon.cc:1023
2 | int main() {
| ^~~~
0x821ffd adjust_loop_info_after_peeling(loop*, int, bool)
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1023
0x1142471 copy_headers
../../gcc-trunk/gcc/tree-ssa-loop-ch.cc:1110
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/110066] [13/14 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #22 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:bbc1a102735c72e3c5a4dede8ab382813d12b058 commit r14-2733-gbbc1a102735c72e3c5a4dede8ab382813d12b058 Author: Andrew Pinski Date: Sat Jul 22 08:52:42 2023 -0700 Fix PR 110066: crash with -pg -static on riscv The problem -fasynchronous-unwind-tables is on by default for riscv linux We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__ point to .eh_frame data from crtbeginT.o instead of the user-defined object during static linking. This turns it off. OK? libgcc/ChangeLog: * config.host (riscv*-*-linux*): Add t-crtstuff to tmake_file. (riscv*-*-freebsd*): Likewise. * config/riscv/t-crtstuff: New file.
[Bug target/110066] [13 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 Andrew Pinski changed: What|Removed |Added Known to work||12.3.0, 14.0 Summary|[13/14 Regression] [RISC-V] |[13 Regression] [RISC-V] |Segment fault if compiled |Segment fault if compiled |with -static -pg|with -static -pg Known to fail||13.1.0 --- Comment #23 from Andrew Pinski --- Fixed on the trunk will backport to GCC 13 after 13.2.0 is released (since the branch is frozen except for RM approvals).
[Bug target/110588] btl (on x86_64) not always generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110588 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Roger Sayle --- This is now fixed on mainline for GCC 14.
