[Bug target/115158] pru: undefined reference to _getentropy after r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158 Dimitar Dimitrov changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Dimitar Dimitrov --- Closing
[Bug target/115158] pru: undefined reference to _getentropy after r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158 Dimitar Dimitrov changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Dimitar Dimitrov --- Fixed in GNU linker by https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a606ff9b090a88b19eaf95914618274041f164c4
[Bug target/115158] pru: undefined reference to _getentropy after r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158 --- Comment #2 from Dimitar Dimitrov --- Before r15-518-g99b1daae18c095, getentropy usage is disabled, as expected: pru-gcc-build/pru/libstdc++-v3/include/pru/bits/c++config.h:/* #undef _GLIBCXX_HAVE_GETENTROPY */ With r15-518-g99b1daae18c095, the generated code appears to be slightly bigger (similar to PR115144). The "hello world" check in config/no-executables.m4 has been already close to the default IMEM limit of 8K, so the link now begins to fail due to IMEM region overflow. Thus the configure script switches to "gcc_no_link=yes". Newlib does not gate the getentropy() function declaration. Hence a simple compile check succeeds and erroneously enables it for libstdc++: pru-gcc-build/pru/libstdc++-v3/include/pru/bits/c++config.h:#define _GLIBCXX_HAVE_GETENTROPY 1 As a fix, I plan to increase the IMEM size in the default linker script.
[Bug target/115158] pru: undefined reference to _getentropy after r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158 Dimitar Dimitrov changed: What|Removed |Added Ever confirmed|0 |1 Target||pru Last reconfirmed||2024-05-19 Assignee|unassigned at gcc dot gnu.org |dimitar at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug target/115158] New: pru: undefined reference to _getentropy after r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158 Bug ID: 115158 Summary: pru: undefined reference to _getentropy after r15-518-g99b1daae18c095 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dimitar at gcc dot gnu.org Target Milestone: --- Commit r15-518-g99b1daae18c095 appears to have uncovered a latent issue in the PRU backend. Many C++ test cases started failing due to a missing symbol: /home/dinux/projects/pru/testbot-workspace/pru-opt/pru/bin/ld: /home/dinux/projects/pru/testbot-workspace/pru-opt/lib/gcc/pru/15.0.0/../../../../pru/lib/libc.a(libc_a-getentropyr.o): in function `_getentropy_r': /home/dinux/projects/pru/testbot-workspace/newlib/newlib/libc/reent/getentropyr.c:47:(.text._getentropy_r+0x28): undefined reference to `_getentropy' collect2: error: ld returned 1 exit status compiler exited with status 1 FAIL: g++.dg/coroutines/torture/func-params-08.C (test for excess errors) Indeed, that syscall has not been defined by PRU's libgloss. Naive solutions would be to either enable -gc-sections by default for PRU, or define the getentropy syscall for PRU in newlib. I'm filing this bug report because I'd like to investigate a bit why it used to work before.
[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013 --- Comment #6 from Dimitar Dimitrov --- Created attachment 58194 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58194=edit tentative fix for PRU The PRU requires a further target adjustment to fix SMALL_REGISTER_CLASS_P. The attached patch fixes the dg.exp=pr71478.c regression. I'm doing full regression tests now, and will commit if there are no objections.
[Bug target/113156] New: AVR build broken due to ICE while compiling libgcc, started with r14-6201-gf0a90c7d7333fc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113156
Bug ID: 113156
Summary: AVR build broken due to ICE while compiling libgcc,
started with r14-6201-gf0a90c7d7333fc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitar at gcc dot gnu.org
Target Milestone: ---
AVR target build is broken after r14-6201-gf0a90c7d7333fc :
/mnt/nvme/dinux/local-workspace/gcc/libgcc/strub.c:91:1: internal compiler
error: 'global_options' are modified in local context
91 | {
| ^
0xda0b43 cl_optimization_compare(gcc_options*, gcc_options*)
/mnt/nvme/dinux/local-workspace/avr-gcc-build/gcc/options-save.cc:13414
0x94230c handle_optimize_attribute
/mnt/nvme/dinux/local-workspace/gcc/gcc/c-family/c-attribs.cc:5972
0x8224a4 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/mnt/nvme/dinux/local-workspace/gcc/gcc/attribs.cc:891
0x828bad c_decl_attributes
/mnt/nvme/dinux/local-workspace/gcc/gcc/c/c-decl.cc:5425
0x840acb start_function(c_declspecs*, c_declarator*, tree_node*)
/mnt/nvme/dinux/local-workspace/gcc/gcc/c/c-decl.cc:10255
0x8ab355 c_parser_declaration_or_fndef
/mnt/nvme/dinux/local-workspace/gcc/gcc/c/c-parser.cc:2912
0x8b663b c_parser_external_declaration
/mnt/nvme/dinux/local-workspace/gcc/gcc/c/c-parser.cc:2046
0x8b7023 c_parser_translation_unit
/mnt/nvme/dinux/local-workspace/gcc/gcc/c/c-parser.cc:1900
0x8b7023 c_parse_file()
/mnt/nvme/dinux/local-workspace/gcc/gcc/c/c-parser.cc:26713
0x929101 c_common_parse_file()
/mnt/nvme/dinux/local-workspace/gcc/gcc/c-family/c-opts.cc:1301
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111928 Dimitar Dimitrov changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #9 from Dimitar Dimitrov --- Confirmed it is fixed.
[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111928 --- Comment #5 from Dimitar Dimitrov --- > thanks, please could you post your configure line? $ /mnt/nvme/dinux/local-workspace/gcc/configure --prefix=/mnt/nvme/dinux/local-workspace/arm-opt --target=arm-none-eabi --with-newlib --enable-languages=c,c++ --enable-checking=yes,rtl --disable-libssp
[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111928 --- Comment #4 from Dimitar Dimitrov --- If I remove the "AC_CHECK_LIBM" line from libquadmath/configure.ac, and re-generate autoconf there, then the build passes. I don't understand why that line was added. Just a few lines below I see checks for specific functions from libm.
[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111928 --- Comment #2 from Dimitar Dimitrov --- I confirm that build works fine with r14-4820-g11f50716eee812, no maintainer mode, for pru and arm targets. I'm using x86_64-pc-linux-gnu build and host machine.
[Bug libquadmath/111928] New: Build broken for baremetal targets after r14-4825-g6a6d3817afa02b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111928 Bug ID: 111928 Summary: Build broken for baremetal targets after r14-4825-g6a6d3817afa02b Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: dimitar at gcc dot gnu.org Target Milestone: --- Following configure error is observed for pru-unknown-elf, arm-none-eabi, and probably other baremetal targets: Checking multilib configuration for libquadmath... mkdir -p -- pru/libquadmath Configuring in pru/libquadmath checking for cos in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [Makefile:13877: configure-target-libquadmath] Error 1 Issue probably started with r14-4825-g6a6d3817afa02b
[Bug target/106562] PRU: Inefficient code for zero check of 64-bit (boolean) AND result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562 Dimitar Dimitrov changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Dimitar Dimitrov --- Should be fixed now in trunk.
[Bug target/106562] PRU: Inefficient code for zero check of 64-bit (boolean) AND result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562 --- Comment #6 from Dimitar Dimitrov --- https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599276.html gives a good analysis why deferring expansion decisions to the backend is preferred. Most backends already define cstore patterns, so it would not be valuable to add a generic code in emit_store_flag_int() as a fallback if cstore expansion fails. Such fallback would simply not be utilized on most architectures. Hence I intend do add a cstore pattern for PRU as a non-intrusive fix for this PR.
[Bug target/109725] [14 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_print_operand, at config/riscv/riscv.cc:4430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109725 Dimitar Dimitrov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Dimitar Dimitrov --- Should be fixed now.
[Bug target/106562] PRU: Inefficient code for zero check of 64-bit (boolean) AND result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562
--- Comment #4 from Dimitar Dimitrov ---
The ideal PRU code sequence for the snippet would be:
char test(uint64_t a, uint64_t b)
{
return a && b;
}
or r14, r14, r15
or r16, r16, r17
uminr14, r14, 1
uminr14, r14, r16
ret
Thus I'm trying to implementing the following conversion in
emit_store_flag_int():
"X != 0" -> "UMIN (X, 1)
[Bug target/110144] New: cris-unknown-elf cross build fails with ICE if RTL checking is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110144 Bug ID: 110144 Summary: cris-unknown-elf cross build fails with ICE if RTL checking is enabled Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dimitar at gcc dot gnu.org Target Milestone: --- I'm trying to cross build the current trunk: $ configure --target=cris-unknown-elf --with-newlib --without-headers --enable-languages=c --disable-nls --disable-libssp --enable-checking=yes,rtl But the configure stage for libgcc fails with: configure:3814: /home/dinux/projects/pru/local-workspace/cris-gcc-build/./gcc/xgcc -B/home/dinux/projects/pru/local-workspace/cris-gcc-build/./gcc/ -B/usr/local/cris-unknown-elf/bin/ -B/usr/local/cris-unknown-elf/lib/ -isystem /usr/local/cris-unknown-elf/include -isystem /usr/local/cris-unknown-elf/sys-include-c -g -O2 conftest.c >&5 during RTL pass: mach2 conftest.c: In function 'main': conftest.c:16:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx note) in PATTERN, at rtl.h:1511 16 | } | ^ 0x6c9a81 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*, int, char const*) ../../gcc/gcc/rtl.cc:907 0x767bb8 PATTERN(rtx_def*) ../../gcc/gcc/rtl.h:1511 0x768158 PATTERN(rtx_def*) ../../gcc/gcc/rtl.h:1479 0x768158 cris_postdbr_cmpelim ../../gcc/gcc/config/cris/cris.cc:378 0x768158 execute ../../gcc/gcc/config/cris/cris.cc:331 Note that without "--enable-checking=yes,rtl" the cross toolchain compilation is successful.
[Bug target/109236] [avr] Invalid code of signed 16-bit compare optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109236 Dimitar Dimitrov changed: What|Removed |Added CC||dimitar at gcc dot gnu.org --- Comment #1 from Dimitar Dimitrov --- Pass the -Wstrict-overflow=4 option to GCC and see that compiler assumes no integer overlow will happen: test.c:3:12: warning: assuming signed overflow does not occur when simplifying 'X - Y <= 0' to 'X <= Y' [-Wstrict-overflow] 3 | return (x-y <= 0); Consider using "__builtin_sub_overflow" for a strictly defined behaviour when integer overflow happens.
[Bug target/106562] PRU: Inefficient code for zero check of 64-bit (boolean) AND result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562 --- Comment #2 from Dimitar Dimitrov --- With cbranchdi4 defined, the generated code is now 10 instructions: test: qbne.L5, r15, 0 qbeq.L4, r14, 0 .L5: rsb r0, r16, 0 rsc r1, r17, 0 or r0, r0, r16 or r1, r1, r17 lsr r14, r1, 31 ret .L4: ldi r14, 0 ret Defining BRANCH_COST=0, as avr backend does, shrinks the above to only 7 instructions.
[Bug target/106562] PRU: Inefficient code for zero check of 64-bit (boolean) AND result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562 --- Comment #1 from Dimitar Dimitrov --- I explored setting REGMODE_NATURAL_SIZE=4 for PRU. This required adjustments in many places in middle end to use REGMODE_NATURAL_SIZE instead of word_mode. That however proved too intrusive. And I don't see how other targets would benefit. I'll instead go with defining an expansion of cbranchdi4 for PRU. That would be contained in the PRU backend only, and thus safer.
[Bug target/106564] PRU: Inefficient zero-extend from 32-bit to 64-bit unsigned values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106564 Dimitar Dimitrov changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Dimitar Dimitrov --- Fixed.
[Bug target/106564] PRU: Inefficient zero-extend from 32-bit to 64-bit unsigned values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106564 Dimitar Dimitrov changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-08-08 Status|UNCONFIRMED |ASSIGNED
[Bug target/106564] New: PRU: Inefficient zero-extend from 32-bit to 64-bit unsigned values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106564
Bug ID: 106564
Summary: PRU: Inefficient zero-extend from 32-bit to 64-bit
unsigned values
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitar at gcc dot gnu.org
Target Milestone: ---
Compiler uses 8-bit constant loads instead of 32-bit constant load to
zero-extend 32-bit unsigned values.
uint64_t test(uint32_t a)
{
return a;
}
test:
mov r0, r14
ldi r1.b0, (0) & 0x
ldi r1.b1, (0) & 0x
ldi r1.b2, (0) & 0x
ldi r1.b3, (0) & 0x
mov r14, r0
mov r15, r1
ret
[Bug target/106562] PRU: Inefficient code for zero check of 64-bit AND result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562 Dimitar Dimitrov changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-08-08 Assignee|unassigned at gcc dot gnu.org |dimitar at gcc dot gnu.org
[Bug target/106562] New: PRU: Inefficient code for zero check of 64-bit AND result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562
Bug ID: 106562
Summary: PRU: Inefficient code for zero check of 64-bit AND
result
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitar at gcc dot gnu.org
Target Milestone: ---
GCC generates inefficient code for the following C snippet:
char test(uint64_t a, uint64_t b)
{
return a && b;
}
test:
or r0.b0, r14.b0, r14.b1
or r0.b0, r0.b0, r14.b2
or r0.b0, r0.b0, r14.b3
or r0.b0, r0.b0, r15.b0
or r0.b0, r0.b0, r15.b1
or r0.b0, r0.b0, r15.b2
or r0.b0, r0.b0, r15.b3
qbeq.L4, r0.b0, 0
mov r14, r16
mov r15, r17
sub r2, r2, 2
rsb r0, r16, 0
rsc r1, r17, 0
mov r17, r14
mov r18, r15
sbbor3.b2, r2, 0, 2
ldi r16.b0, (63) & 0x
or r14, r0, r17
or r15, r1, r18
call%label(__pruabi_lsrll)
lbbor3.b2, r2, 0, 2
add r2, r2, 2
ret
