Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZDINX on RV32 uses odd offset pairs #7

Open
bluewww opened this issue Jul 27, 2021 · 5 comments
Open

ZDINX on RV32 uses odd offset pairs #7

bluewww opened this issue Jul 27, 2021 · 5 comments

Comments

@bluewww
Copy link

bluewww commented Jul 27, 2021

This seems to happen in some gcc tests. The current draft of the zfinx reserves passing double arguments in odd offset register pairs.

Here are some tests I saw failing:

FAIL: gcc.c-torture/execute/20000731-1.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/20021120-1.c   -O1  execution test
FAIL: gcc.c-torture/execute/20021120-1.c   -O2  execution test
FAIL: gcc.c-torture/execute/20021120-1.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  execution test
FAIL: gcc.c-torture/execute/20021120-1.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: gcc.c-torture/execute/20021120-1.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/20021120-1.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/980709-1.c   -O0  execution test
FAIL: gcc.c-torture/execute/980709-1.c   -O1  execution test
FAIL: gcc.c-torture/execute/980709-1.c   -O2  execution test
FAIL: gcc.c-torture/execute/980709-1.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  execution test
FAIL: gcc.c-torture/execute/980709-1.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: gcc.c-torture/execute/980709-1.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/980709-1.c   -Os  execution test
FAIL: gcc.c-torture/execute/memset-2.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/execute/pr47538.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/pr59643.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/cdce1.c execution test
FAIL: gcc.dg/pow-sqrt-1.c execution test
FAIL: gcc.dg/pow-sqrt-2.c execution test
FAIL: gcc.dg/pow-sqrt-3.c execution test
FAIL: gcc.dg/pr28796-2.c execution test
FAIL: gcc.dg/pr46728-12.c execution test
FAIL: gcc.dg/pr54919.c execution test
FAIL: gcc.dg/pr82004.c execution test
FAIL: c-c++-common/torture/complex-sign-add.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: c-c++-common/torture/complex-sign-mixed-add.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: c-c++-common/torture/complex-sign-mixed-div.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: c-c++-common/torture/complex-sign-mixed-mul.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: c-c++-common/torture/complex-sign-mixed-sub.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: c-c++-common/torture/complex-sign-mul-one.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: c-c++-common/torture/complex-sign-mul.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: c-c++-common/torture/complex-sign-sub.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/torture/builtin-math-7.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/torture/pr41094.c   -O0  execution test
FAIL: gcc.dg/torture/pr53366-1.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/torture/pr53366-1.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr54877.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -O1  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -O2  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -O3 -g  execution test
FAIL: gcc.dg/torture/type-generic-1.c   -Os  execution test
@pz9115
Copy link
Owner

pz9115 commented Jul 28, 2021

Thank you for your test, I had reported it in yesterday's meeting to Mark, and now asking our simulator collegue to fix it.

gcc.txt

@pz9115
Copy link
Owner

pz9115 commented Aug 31, 2021

We had fix the register reserves problem, and here still exist qemu problem cause execution result errors. I commulated with the qemu team to fix them, maybe it will fix within Sep I guess, and I will keep catch this.

zfinx-gcc.log

@pz9115
Copy link
Owner

pz9115 commented Oct 18, 2021

@bluewww We had fix all known bugs in qemu and you can check it with the qemu support in— https://github.com/plctlab/plct-qemu/commits/plct-zfinx-dev, here is a shell for test zdinx on rv32:

#!/bin/bash

apt-get install git build-essential tcl expect flex texinfo bison libpixman-1-dev libglib2.0-dev pkg-config zlib1g-dev ninja-build

git clone https://github.com/riscv/riscv-gnu-toolchain 
cd riscv-gnu-toolchain
git submodule update --init

cd riscv-gcc
git remote | grep -q zfinx || git remote add zfinx https://github.com/pz9115/riscv-gcc.git
git fetch zfinx
git checkout -f zfinx/riscv-gcc-10.2.0-zfinx
cd ../riscv-binutils
git remote | grep -q zfinx || git remote add zfinx https://github.com/pz9115/riscv-binutils-gdb.git
git fetch zfinx
git checkout zfinx/riscv-binutils-2.35-zfinx
cd ../qemu
git remote | grep -q plct-qemu || git remote add plct-qemu https://github.com/plctlab/plct-qemu.git || true
git fetch plct-qemu
git checkout plct-qemu/plct-zfinx-dev
cd ..

## set QEMU args
sed -i '15c qemu-riscv$xlen -cpu rv32,Zdinx=true -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} "$@"' scripts/wrapper/qemu/riscv32-unknown-elf-run 

make clean || echo "No need to clean"
# for rv32:
./configure --prefix=$PWD/opt-rv32/ --with-arch=rv32imaczdinx --with-abi=ilp32 --with-multilib-generator="rv32imaczdinx-ilp32--"

# you can use make -j* to make speed up
make -j $(nproc) report-gcc-newlib
make -j $(nproc) report-binutils-newlib

@bluewww
Copy link
Author

bluewww commented Oct 18, 2021

@pz9115 thanks for the update. I see if I find time to run this since I have only centos7 machines available and probably will need to change this script a bit.

Liaoshihua pushed a commit to Liaoshihua/riscv-gcc that referenced this issue Jan 12, 2022
Fixes:

==129444==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000666ca5c at pc 0x000000ef094b bp 0x7fffffff8180 sp 0x7fffffff8178
READ of size 4 at 0x00000666ca5c thread T0
    #0 0xef094a in parse_optimize_options ../../gcc/d/d-attribs.cc:855
    pz9115#1 0xef0d36 in d_handle_optimize_attribute ../../gcc/d/d-attribs.cc:916
    #2 0xef107e in d_handle_optimize_attribute ../../gcc/d/d-attribs.cc:887
    pz9115#3 0xff85b1 in decl_attributes(tree_node**, tree_node*, int, tree_node*) ../../gcc/attribs.c:829
    pz9115#4 0xef2a91 in apply_user_attributes(Dsymbol*, tree_node*) ../../gcc/d/d-attribs.cc:427
    pz9115#5 0xf7b7f3 in get_symbol_decl(Declaration*) ../../gcc/d/decl.cc:1346
    pz9115#6 0xf87bc7 in get_symbol_decl(Declaration*) ../../gcc/d/decl.cc:967
    pz9115#7 0xf87bc7 in DeclVisitor::visit(FuncDeclaration*) ../../gcc/d/decl.cc:808
    pz9115#8 0xf83db5 in DeclVisitor::build_dsymbol(Dsymbol*) ../../gcc/d/decl.cc:146

for the following test-case: gcc/testsuite/gdc.dg/attr_optimize1.d.

gcc/d/ChangeLog:

	* d-attribs.cc (parse_optimize_options): Check index before
	accessing cl_options.
Liaoshihua pushed a commit to Liaoshihua/riscv-gcc that referenced this issue Jan 12, 2022
…imize or target pragmas [PR103012]

The following testcases ICE when an optimize or target pragma
is followed by a long line (4096+ chars).
This is because on such long lines we can't use columns anymore,
but the cpp_define calls performed by c_cpp_builtins_optimize_pragma
or from the backend hooks for target pragma are done on temporary
buffers and expect to get columns from whatever line they appear on
(which happens to be the long line after optimize/target pragma),
and we run into:
 #0  fancy_abort (file=0x3abec67 "../../libcpp/line-map.c", line=502, function=0x3abecfc "linemap_add") at ../../gcc/diagnostic.c:1986
 pz9115#1  0x0000000002e7c335 in linemap_add (set=0x7ffff7fca000, reason=LC_RENAME, sysp=0, to_file=0x41287a0 "pr103012.i", to_line=3) at ../../libcpp/line-map.c:502
 #2  0x0000000002e7cc24 in linemap_line_start (set=0x7ffff7fca000, to_line=3, max_column_hint=128) at ../../libcpp/line-map.c:827
 pz9115#3  0x0000000002e7ce2b in linemap_position_for_column (set=0x7ffff7fca000, to_column=1) at ../../libcpp/line-map.c:898
 pz9115#4  0x0000000002e771f9 in _cpp_lex_direct (pfile=0x40c3b60) at ../../libcpp/lex.c:3592
 pz9115#5  0x0000000002e76c3e in _cpp_lex_token (pfile=0x40c3b60) at ../../libcpp/lex.c:3394
 pz9115#6  0x0000000002e610ef in lex_macro_node (pfile=0x40c3b60, is_def_or_undef=true) at ../../libcpp/directives.c:601
 pz9115#7  0x0000000002e61226 in do_define (pfile=0x40c3b60) at ../../libcpp/directives.c:639
 pz9115#8  0x0000000002e610b2 in run_directive (pfile=0x40c3b60, dir_no=0, buf=0x7fffffffd430 "__OPTIMIZE__ 1\n", count=14) at ../../libcpp/directives.c:589
 pz9115#9  0x0000000002e650c1 in cpp_define (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2513
 pz9115#10 0x0000000002e65100 in cpp_define_unused (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2522
 pz9115#11 0x0000000000f50685 in c_cpp_builtins_optimize_pragma (pfile=0x40c3b60, prev_tree=<optimization_node 0x7fffea042000>, cur_tree=<optimization_node 0x7fffea042020>)
     at ../../gcc/c-family/c-cppbuiltin.c:600
assertion that LC_RENAME doesn't happen first.

I think the right fix is emit those predefined macros upon
optimize/target pragmas with BUILTINS_LOCATION, like we already do
for those macros at the start of the TU, they don't appear in columns
of the next line after it.  Another possibility would be to force them
at the location of the pragma.

2021-12-30  Jakub Jelinek  <[email protected]>

	PR c++/103012
gcc/
	* config/i386/i386-c.c (ix86_pragma_target_parse): Perform
	cpp_define/cpp_undef calls with forced token locations
	BUILTINS_LOCATION.
	* config/arm/arm-c.c (arm_pragma_target_parse): Likewise.
	* config/aarch64/aarch64-c.c (aarch64_pragma_target_parse): Likewise.
	* config/s390/s390-c.c (s390_pragma_target_parse): Likewise.
gcc/c-family/
	* c-cppbuiltin.c (c_cpp_builtins_optimize_pragma): Perform
	cpp_define_unused/cpp_undef calls with forced token locations
	BUILTINS_LOCATION.
gcc/testsuite/
	PR c++/103012
	* g++.dg/cpp/pr103012.C: New test.
	* g++.target/i386/pr103012.C: New test.
Liaoshihua pushed a commit to Liaoshihua/riscv-gcc that referenced this issue Feb 23, 2022
…04617]

On
 #define A(n) int foo1##n(void) { return 1##n; }
 #define B(n) A(n##0) A(n#pz9115#1) A(n##2) A(n#pz9115#3) A(n#pz9115#4) A(n#pz9115#5) A(n#pz9115#6) A(n#pz9115#7) A(n#pz9115#8) A(n#pz9115#9)
 #define C(n) B(n##0) B(n#pz9115#1) B(n##2) B(n#pz9115#3) B(n#pz9115#4) B(n#pz9115#5) B(n#pz9115#6) B(n#pz9115#7) B(n#pz9115#8) B(n#pz9115#9)
 #define D(n) C(n##0) C(n#pz9115#1) C(n##2) C(n#pz9115#3) C(n#pz9115#4) C(n#pz9115#5) C(n#pz9115#6) C(n#pz9115#7) C(n#pz9115#8) C(n#pz9115#9)
 #define E(n) D(n##0) D(n#pz9115#1) D(n##2) D(n#pz9115#3) D(n#pz9115#4) D(n#pz9115#5) D(n#pz9115#6) D(n#pz9115#7) D(n#pz9115#8) D(n#pz9115#9)
 E(0) E(1) E(2) D(30) D(31) C(320) C(321) C(322) C(323) C(324) C(325)
 B(3260) B(3261) B(3262) B(3263) A(32640) A(32641) A(32642)
testcase with
./xgcc -B ./ -c -g -fpic -ffat-lto-objects -flto  -O0 -o foo1.o foo1.c -ffunction-sections
./xgcc -B ./ -shared -g -fpic -flto -O0 -o foo1.so foo1.o
/tmp/ccTW8mBm.debug.temp.o: file not recognized: file format not recognized
(testcase too slow to be included into testsuite).
The problem is clearly reported by readelf:
readelf: foo1.o.debug.temp.o: Warning: Section 2 has an out of range sh_link value of 65321
readelf: foo1.o.debug.temp.o: Warning: Section 5 has an out of range sh_link value of 65321
readelf: foo1.o.debug.temp.o: Warning: Section 10 has an out of range sh_link value of 65323
readelf: foo1.o.debug.temp.o: Warning: [ 2]: Link field (65321) should index a symtab section.
readelf: foo1.o.debug.temp.o: Warning: [ 5]: Link field (65321) should index a symtab section.
readelf: foo1.o.debug.temp.o: Warning: [10]: Link field (65323) should index a string section.
because simple_object_elf_copy_lto_debug_sections doesn't adjust sh_info and
sh_link fields in ElfNN_Shdr if they are in between SHN_{LO,HI}RESERVE
inclusive.  Not adjusting those is incorrect though, SHN_{LO,HI}RESERVE
range is only relevant to the 16-bit fields, mainly st_shndx in ElfNN_Sym
where if one needs >= SHN_LORESERVE section number, SHN_XINDEX should be
used instead and .symtab_shndx section should contain the real section
index, and in ElfNN_Ehdr e_shnum and e_shstrndx fields, where if >=
SHN_LORESERVE value is needed it should put those into
Shdr[0].sh_{size,link}.  But, sh_{link,info} are 32-bit fields which can
contain any section index.

Note, as simple-object-elf.c mentions, binutils from 2.12 to 2.18 (so before
2011) used to mishandle the > 63.75K sections case and assumed there is a
hole in between the sections, but what
simple_object_elf_copy_lto_debug_sections does wouldn't help in that case
for the debug temp object creation, we'd need to detect the case also in
that routine and take it into account in the remapping etc.  I think
it is not worth it given that it is over 10 years, if somebody needs
63.75K or more sections, better use more recent binutils.

2022-02-22  Jakub Jelinek  <[email protected]>

	PR lto/104617
	* simple-object-elf.c (simple_object_elf_match): Fix up URL
	in comment.
	(simple_object_elf_copy_lto_debug_sections): Remap sh_info and
	sh_link even if they are in the SHN_LORESERVE .. SHN_HIRESERVE
	range (inclusive).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants