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.

Sign up for GitHub

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

Jump to bottom

ICE (segfault) #1

Closed
sezero opened this issue Jul 17, 2017 · 2 comments
Closed

ICE (segfault) #1

sezero opened this issue Jul 17, 2017 · 2 comments
Assignees
@bebbo

Comments

@sezero
Copy link

sezero commented Jul 17, 2017 •
edited
Loading

Built the m68k cross-toolchain from your fork with --gcc=6 --bibutils=2.14 .
Trying to build uhexen2 source (https://sf.net/p/uhexen2/ or github mirror at
https://github.com/svn2github/uhexen2.git) with this, gcc segfaults in our cl_demo.c:

cd uhexen2/engine/hexen2/
m68k-amigaos-gcc -c -I. -I../h2shared -I../../common -I../../oslibs/amigaos/include -Wall -O2 -DNDEBUG=1 -ffast-math -fomit-frame-pointer -noixemul -m68020-60 -o cl_demo.o cl_demo.c
*** Error in `/home/me/m68k/libexec/gcc/m68k-amigaos/6.3.1b/cc1': malloc(): memory corruption: 0x0000000003b896b0 ***
*** Error in `/home/me/m68k/libexec/gcc/m68k-amigaos/6.3.1b/cc1': malloc(): memory corruption: 0x0000000003b896b0 ***
*** Error in `/home/me/m68k/libexec/gcc/m68k-amigaos/6.3.1b/cc1': malloc(): memory corruption (fast): 0x0000000003ba96a0 ***
m68k-amigaos-gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Attached the preprocessed source here.
cl_demo.i.zip
@bebbo bebbo self-assigned this Jul 17, 2017
@bebbo
Copy link
Owner

bebbo commented Jul 17, 2017

The attached precompiled source is a very good idea. Thanks!

Fix in progress.

@sezero
Copy link
Author

sezero commented Jul 18, 2017

Don't know whether this is host-os specific: For what it's worth, this issue happened to me
on my x86_64-linux (fedora 20).

@sezero sezero mentioned this issue Aug 2, 2017
Open
@bebbo bebbo closed this as completed in cfa7b74 Aug 20, 2017
@MBeijer MBeijer mentioned this issue Feb 8, 2018
Closed
@arczi84 arczi84 mentioned this issue Feb 10, 2021
Closed
@githubaf githubaf mentioned this issue Jun 11, 2022
Closed
@GunnarVB GunnarVB mentioned this issue Jan 8, 2024
Closed
bebbo pushed a commit that referenced this issue Jan 21, 2024
@Stammark
arm: Stop vadcq, vsbcq intrinsics from overwriting the FPSCR NZ flags
1ad81fc 
Hi all,

We noticed that calls to the vadcq and vsbcq intrinsics, both of
which use __builtin_arm_set_fpscr_nzcvqc to set the Carry flag in
the FPSCR, would produce the following code:

```
< r2 is the *carry input >
vmrs	r3, FPSCR_nzcvqc
bic	r3, r3, #536870912
orr	r3, r3, r2, lsl #29
vmsr	FPSCR_nzcvqc, r3
```

when the MVE ACLE instead gives a different instruction sequence of:
```
< Rt is the *carry input >
VMRS Rs,FPSCR_nzcvqc
BFI Rs,Rt,#29,#1
VMSR FPSCR_nzcvqc,Rs
```

the bic + orr pair is slower and it's also wrong, because, if the
*carry input is greater than 1, then we risk overwriting the top two
bits of the FPSCR register (the N and Z flags).

This turned out to be a problem in the header file and the solution was
to simply add a `& 1x0u` to the `*carry` input: then the compiler knows
that we only care about the lowest bit and can optimise to a BFI.

Ok for trunk?

Thanks,
Stam Markianos-Wright

gcc/ChangeLog:

	* config/arm/arm_mve.h (__arm_vadcq_s32): Fix arithmetic.
	(__arm_vadcq_u32): Likewise.
	(__arm_vadcq_m_s32): Likewise.
	(__arm_vadcq_m_u32): Likewise.
	(__arm_vsbcq_s32): Likewise.
	(__arm_vsbcq_u32): Likewise.
	(__arm_vsbcq_m_s32): Likewise.
	(__arm_vsbcq_m_u32): Likewise.
	* config/arm/mve.md (get_fpscr_nzcvqc): Make unspec_volatile.

gcc/testsuite/ChangeLog:
	* gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c: New.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bebbo bebbo

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@sezero @bebbo