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

64-bit compiler doesn't like SSE/SSE2 flags, they are implied. #18

Merged
merged 1 commit into from
May 10, 2015
Merged

64-bit compiler doesn't like SSE/SSE2 flags, they are implied. #18

merged 1 commit into from
May 10, 2015

Conversation

tvandijck
Copy link
Contributor

No description provided.

@TurkeyMan
Copy link
Contributor

LGTM, except do you need to update gmake too?

This creates a disparity between vs and gmake builds?
Perhaps it would be better to filter these out in the bake, then all generators will get the fix?

@tvandijck
Copy link
Contributor Author

The gcc/clang compilers are perfectly fine with the option... it's only the msvc compiler that complains... even though I agree that the option on gcc/clang may be entirely ignored.

@TurkeyMan
Copy link
Contributor

Fair enough.

TurkeyMan
TurkeyMan reviewed Apr 17, 2015
View reviewed changes
src/actions/vstudio/vs2010_vcxproj.lua
v = "StreamingSIMDExtensions2"
elseif x == "SSE" then
v = "StreamingSIMDExtensions"
elseif cfg.architecture ~= "x64" then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to pull this, but a recent change has renamed x32->x86 and x64->x86_64
This needs to be updated to x86_64.

I also wonder if it should be == "x86" rather than ~= "x86_64", since it's precisely one architecture that supports this, not 'anything other than x86_64'.
Is there a possible 'unspecified' case for architecture that the ~= also catches?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I can certainly rename the if to x86_64.... I think x86 would be wrong however, since we still want this enabled on 32-bit platforms, where this feature is not implied... old x86 processors don't always have SSE2, although you have to go back in history quite a bit for that you still have to explicitly enable this in Visual Studio.

starkos added a commit that referenced this pull request May 10, 2015
@starkos
Merge pull request #18 from Blizzard/pr12
dc31274 
64-bit compiler doesn't like SSE/SSE2 flags, they are implied.
@starkos starkos merged commit dc31274 into premake:master May 10, 2015
@TurkeyMan
Copy link
Contributor

@starkos You did see that this uses the compatibility alias rather than the modern "x86_64" yeah?

@tvandijck tvandijck deleted the pr12 branch May 11, 2015 17:08
martin-traverse pushed a commit to martin-traverse/premake-core that referenced this pull request Apr 19, 2016
@starkos
Merge pull request premake#18 from starkos/rename-solution-to-workspace
3417efd 
Rename solution to workspace everywhere
tvandijck pushed a commit to tvandijck/premake-core that referenced this pull request May 11, 2016
@starkos
Merge pull request premake#18 from starkos/rename-solution-to-workspace
293e7bd 
Rename solution to workspace everywhere
@samsinsane samsinsane mentioned this pull request Feb 10, 2019
Closed
vadz added a commit to vadz/premake-core that referenced this pull request Aug 27, 2023
@vadz
Fix crash when enabling debugger under Linux
e739d88 
Rename buffer_init() to avoid clashing with a function with the same
name in luasocket code: under Linux, due to the of "flat" ELF
namespaces, when luasocket shared library is loaded into premake process
the existing premake function is used instead of the function defined in
luasocket code, resulting in luasocket buffer not being properly
initialized which, in turn, leads to mysterious crashes as soon as it's
used, e.g. dereferencing null timeout field:

	(gdb) bt
	#0  0x00007ffff7cce642 in timeout_markstart (tm=0x0) at ../../binmodules/luasocket/src/timeout.c:116
	premake#1  0x00007ffff7cc7618 in buffer_meth_receive (L=0x5555557882a8, buf=0x5555559044a0) at ../../binmodules/luasocket/src/buffer.c:113
	premake#2  0x00007ffff7ccd545 in meth_receive (L=0x5555557882a8) at ../../binmodules/luasocket/src/tcp.c:135
	premake#3  0x000055555558c1cc in luaD_precall (L=0x5555557882a8, func=0x5555558e36b0, nresults=1) at ../../contrib/lua/src/ldo.c:434
	premake#4  0x00005555555a971f in luaV_execute (L=0x5555557882a8) at ../../contrib/lua/src/lvm.c:1134
	premake#5  0x000055555558c555 in luaD_call (L=0x5555557882a8, func=0x5555558e3640, nResults=0) at ../../contrib/lua/src/ldo.c:499
	premake#6  0x000055555558c5b3 in luaD_callnoyield (L=0x5555557882a8, func=0x5555558e3640, nResults=0) at ../../contrib/lua/src/ldo.c:509
	premake#7  0x0000555555588af5 in lua_callk (L=0x5555557882a8, nargs=2, nresults=0, ctx=0, k=0x0) at ../../contrib/lua/src/lapi.c:925
	premake#8  0x00005555555af4f2 in hookf (L=0x5555557882a8, ar=0x7fffffffd270) at ../../contrib/lua/src/ldblib.c:316
	premake#9  0x000055555558bafb in luaD_hook (L=0x5555557882a8, event=2, line=273) at ../../contrib/lua/src/ldo.c:269
	premake#10 0x000055555558b284 in luaG_traceexec (L=0x5555557882a8) at ../../contrib/lua/src/ldebug.c:687
	premake#11 0x00005555555a6b71 in luaV_execute (L=0x5555557882a8) at ../../contrib/lua/src/lvm.c:801
	premake#12 0x000055555558c555 in luaD_call (L=0x5555557882a8, func=0x555555889360, nResults=1) at ../../contrib/lua/src/ldo.c:499
	premake#13 0x000055555558c5b3 in luaD_callnoyield (L=0x5555557882a8, func=0x555555889360, nResults=1) at ../../contrib/lua/src/ldo.c:509
	premake#14 0x0000555555588b60 in f_call (L=0x5555557882a8, ud=0x7fffffffdbb0) at ../../contrib/lua/src/lapi.c:943
	premake#15 0x000055555558b5a5 in luaD_rawrunprotected (L=0x5555557882a8, f=0x555555588b2b <f_call>, ud=0x7fffffffdbb0)
	    at ../../contrib/lua/src/ldo.c:142
	premake#16 0x000055555558cd85 in luaD_pcall (L=0x5555557882a8, func=0x555555588b2b <f_call>, u=0x7fffffffdbb0, old_top=64, ef=48)
	    at ../../contrib/lua/src/ldo.c:729
	premake#17 0x0000555555588c28 in lua_pcallk (L=0x5555557882a8, nargs=0, nresults=1, errfunc=3, ctx=0, k=0x0)
	    at ../../contrib/lua/src/lapi.c:969
	premake#18 0x0000555555584734 in premake_pcall (L=0x5555557882a8, nargs=0, nresults=1) at ../../src/host/premake.c:287
	premake#19 0x0000555555584867 in premake_execute (L=0x5555557882a8, argc=5, argv=0x7fffffffdd98,
	    script=0x555555685052 "src/_premake_main.lua") at ../../src/host/premake.c:316
	premake#20 0x000055555558535e in main (argc=5, argv=0x7fffffffdd98) at ../../src/host/premake_main.c:19

For consistency, rename all the other buffer_xxx functions too, even
though they don't conflict with anything right now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@tvandijck @TurkeyMan @starkos