Hi, I just dl'ed AmiDog's FPSE-SDK (plugins) and trying to recompile with latest SDK and GCC 5. Almost no buig issues, just suome deprecated functions, but it stops here (removing from main makefile -Werror "solves" it), but is there a "proper" way to "fix" such problem (by casting or dunot whatelse):
- gmake: Entering directory '/Utilidades/Programar/SDK/ejemplos/FPSE-SDK/cdrom'
- ppc-amigaos-gcc -DMSB_FIRST -I. -I../ -D__USE_INLINE__ -gstabs -Wall -Wsign-compare -Werror -O3 -fomit-frame-pointer -ffast-math -c cd.c -o obj/os4/cd.o
- cd.c: In function 'init_sub_channel':
- cd.c:920:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
- tmp_sub->chn.AMinute = ((CDLoc *)&tmp)->minute;
- cd.c:921:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
- tmp_sub->chn.ASecond = ((CDLoc *)&tmp)->second;
- cd.c:922:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
- tmp_sub->chn.AFrame = ((CDLoc *)&tmp)->frame;
- cc1: all warnings being treated as errors
Here's is what the latest CodeBench version will give you as an explanation to this error:
"When enabling strict-aliasing via the compiler switches, the compiler attempts to make some optimisations to the resulting code. If you receive this error, your code may well have some problems that can lead to undefined behaviour in the finished code. "Aliasing" basically means several different pointer variables referencing the same data. You cannot, for example, reference a 4 element array of char as a LONG. This is called "type-punning" and it will break the aliasing rules set out in the C standards. There are lots of explanations for this type of error available on the internet. This error needs to be fixed, it can, and will, lead to problems, especially in portable code."
The simplest way without changing the code would be to disable strict-aliasing optimisation with "-fno-strict-aliasing".
Without knowing the rest of the code it's hard to say exactly what changes would be needed to make the code conform to strict-aliasing rules but it might involve defining tmp as a union of CDLoc and whatever type it is defined as now.
Yes, we're all eagerly awaiting this fabled latest CodeBench version ;-)
ok thx all, Will try to see what happens adding "-fno-strict-aliasing" and/or createing such UNION variable.
All plugins seems to compile without big issues (apart of posted).
Will try to see what happens with "recompiled" plugins and some PSX games.
Perhaps just having a true CDLoc * pointer will be enough something like
tmp_sub->chn.AMinute = cdl->minute;
Tried UNION and Alan Thelier code, it compiles ok, but when enabling suhc plugin, it tries to load/search (maybe only oringial has such file/structure) for:
SBI 'subq/020a5801.sbi' not found
SUB 'subq/020a5801.sub' not found
Dunnot if code works :-/ will have to burn some PSX isos and see what happens.
THX anyway guys.
PS: recompiled rest of FPSE's plugins and at least they don't crash when starting a PSX game iso image, a bit slow as I dont have Warp3D on my SAM460ex, but it looks fine. :-)
I have an FPSE/subq directory but it is empty and FPSE works
Those CD image works for me (no need to burn a real cd) :
All are 3D games using the warp3D fpse plugin
Tomb Raider III.bin
Crash Bandicoot (E) (No EDC) [SCES-00344].bin
Soul Blade (E) [SCES-00577].bin
Legacy of Kain - Soul Reaver (E) [SLES-01301].bin
Parasite Eve [Disc1of2] [SLUS-00662].img
Parasite Eve [Disc2of2] [SLUS-00668].img
I have let other files .ccd .sub .cue in the same FPSE directory
Hi, didn't notice but you're right CD images do look for such files too.
It looks it some kind on patch for use orginal images with emulation. Will try to see what happens with such patch/file and what result/ouput I get.
Hi again, seems "fix" by Alain Thelier (#6 http://www.os4coding.net/comment/2982#comment-2982) solves the warning issue.
I hope you are not using it unmodified because he left out an important ampersand, without which the code will most likely crash.
After fixing this you will probably be getting the warning again because it's the "(CDLoc *)&tmp" expression that gcc doesn't like.
THX for pointing it. Compiling using "cdl = (CDLoc *)&tmp;" I don't get any warning. Maybe is the casting "mode/method" GCC doesn't like in " ((CDLoc *)&tmp)->minute"? ¿:-/
Only when using:
Will do some tests with/without "&" and see what I get on such variables, and if it crashes. THX.
There's no reason to test without "&" to see if it crashes. Whether it crashes or not depends on the contents of the tmp variable and if this happens to correspond to a valid memory location or not. Even if you are "lucky" enough that it doesn't cause Grim Reaper to report a DSI it will not be working as intended.
Salass00 is right : I made a typo . The & is needed
Ok THX both.