mixed -O3 and -O2 flags in app-emulation/dxvk #11

New Issue

stefson · 2021-01-09T12:39:19+01:00

stefson commented

2021-01-09 12:39:19 +01:00

hey there, I just noticed this by incident:

[249/264] x86_64-w64-mingw32-g++ -Isrc/d3d9/d3d9.dll.p -Isrc/d3d9 -I../dxvk-1.7.3/src/d3d9 -I../dxvk-1.7.3/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O3 -DNOMINMAX -O2 -march=znver1 -mno-avx -MD -MQ src/d3d9/d3d9.dll.p/d3d9_texture.cpp.obj -MF src/d3d9/d3d9.dll.p/d3d9_texture.cpp.obj.d -o src/d3d9/d3d9.dll.p/d3d9_texture.cpp.obj -c ../dxvk-1.7.3/src/d3d9/d3d9_texture.cpp

where it mixes optimization flags it seems: -std=c++17 -O3 -DNOMINMAX -O2 -march=znver1

can this possibly be correct behaviour?

My default from make.conf is: CFLAGS="-O2 -march=znver1 -pipe"

hey there, I just noticed this by incident: `` [249/264] x86_64-w64-mingw32-g++ -Isrc/d3d9/d3d9.dll.p -Isrc/d3d9 -I../dxvk-1.7.3/src/d3d9 -I../dxvk-1.7.3/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O3 -DNOMINMAX -O2 -march=znver1 -mno-avx -MD -MQ src/d3d9/d3d9.dll.p/d3d9_texture.cpp.obj -MF src/d3d9/d3d9.dll.p/d3d9_texture.cpp.obj.d -o src/d3d9/d3d9.dll.p/d3d9_texture.cpp.obj -c ../dxvk-1.7.3/src/d3d9/d3d9_texture.cpp `` where it mixes optimization flags it seems: ``-std=c++17 -O3 -DNOMINMAX -O2 -march=znver1`` can this possibly be correct behaviour? My default from make.conf is: CFLAGS="-O2 -march=znver1 -pipe"

stefson commented

2021-01-09 12:41:18 +01:00

here is my full emerge --info

I'm using your ebuilds, and this happens with both dxvk-1.7.3 stable and latest git

thank you for your time :)

here is my full emerge --info I'm using your ebuilds, and this happens with both dxvk-1.7.3 stable and latest git thank you for your time :)

emerge-info.zip

3.6 KiB

tastytea commented

2021-01-09 13:01:21 +01:00

The -O3 seems to come from DXVK, but I can't figure out where it is specified.

However, the manpage of gcc states:

If you use multiple -O options, with or without level numbers, the last such option is the one that is effective.

So the -O3 is ignored.

The `-O3` seems to come from DXVK, but I can't figure out where it is specified. However, the manpage of gcc states: > If you use multiple -O options, with or without level numbers, the last such option is the one that is effective. So the `-O3` is ignored.

stefson commented

2021-01-09 13:10:16 +01:00

here is my full build log, to show that the whole build is affected.

I think the -O2 comes from my make.conf, and maybe this boils down to your add-compiler-flags.patch? Not sure what it actually does, but this seems like a placeholder to put in the global cflags from make.conf: +c_args = @CFLAGS@

115529e38b/app-emulation/dxvk/files/dxvk-1.7.3_add-compiler-flags.patch (L40)

here is my full build log, to show that the whole build is affected. I think the -O2 comes from my make.conf, and maybe this boils down to your add-compiler-flags.patch? Not sure what it actually does, but this seems like a placeholder to put in the global cflags from make.conf: +c_args = @CFLAGS@ https://schlomp.space/tastytea/overlay/src/commit/115529e38b640398be113db2351181581e6761af/app-emulation/dxvk/files/dxvk-1.7.3_add-compiler-flags.patch#L40

dxvk-build.log.zip

16 KiB

stefson commented

2021-01-09 13:49:57 +01:00

hey, thanks for your fast reply.

your latest commit has not been working for me, the -O2 is sourced from my gentoo make.conf and I got only rid of it by adding special env file with these entries only:

CFLAGS="-march=zenver1 -pipe"
CXXFLAGS="${CFLAGS}"

p.s: the -pipe gets lost as well, but it's not of any concern

hey, thanks for your fast reply. your latest commit has not been working for me, the -O2 is sourced from my gentoo make.conf and I got only rid of it by adding special env file with these entries only: ``` CFLAGS="-march=zenver1 -pipe" CXXFLAGS="${CFLAGS}" ``` p.s: the -pipe gets lost as well, but it's not of any concern

tastytea commented

2021-01-09 14:10:06 +01:00

The add-compiler-flags.patch makes sure that the ${CXXFLAGS} and ${CFLAGS} from your make.conf are used.

your latest commit has not been working for me, the -O2 is sourced from my gentoo make.conf

Yes, that's how it is supposed to work. Your flags overwrite the ones from the project. My last commit was to stop replacing -O3 with -O2 in your flags (I think there was a bug a while ago that lead to errors when building with -O3).

the -pipe gets lost as well

It is used, I see it in your build log. 🙂

If you want to use -O3 for DXVK but -O2 for everything else, you'll need a special env.

The `add-compiler-flags.patch` makes sure that the `${CXXFLAGS}` and `${CFLAGS}` from your make.conf are used. > your latest commit has not been working for me, the -O2 is sourced from my gentoo make.conf Yes, that's how it is supposed to work. Your flags overwrite the ones from the project. My last commit was to stop replacing `-O3` with `-O2` in your flags (I think there was a bug a while ago that lead to errors when building with `-O3`). > the -pipe gets lost as well It is used, I see it in your build log. 🙂 If you want to use `-O3` for DXVK but `-O2` for everything else, you'll need a special env.

stefson commented

2021-01-09 14:49:01 +01:00

ok, I see. dxvk has it's own ideas about optimization and chooses -O3, while your patch allows to append anything that is in CFLAGS of make.conf. However, the default is not replaced and thus gcc takes the last value of -O2 it can find and everything works as expected.

I noticed this since gcc-10 has -O3 optimization that is partially broken, and I wanted to test the dxvk codebase. Will now do that with gcc-10 toolchain, again thank you for your explanation above. closing

ok, I see. dxvk has it's own ideas about optimization and chooses -O3, while your patch allows to append anything that is in CFLAGS of make.conf. However, the default is not replaced and thus gcc takes the last value of -O2 it can find and everything works as expected. I noticed this since gcc-10 has -O3 optimization that is partially broken, and I wanted to test the dxvk codebase. Will now do that with gcc-10 toolchain, again thank you for your explanation above. closing

stefson closed this issue

2021-01-09 14:49:01 +01:00

Sign in to join this conversation.