[bug #34832] enable tls variable in windows code for newish gcc

Update of bug #34832 (project make): Status:None => Fixed ___ Reply to this item at: ___ Messag

[bug #34832] enable tls variable in windows code for newish gcc

Update of bug #34832 (project make): Open/Closed:Open => Closed Fixed Release:None => CVS ___ Follow-up Comment #23: I fixed this by remov

[bug #34832] enable tls variable in windows code for newish gcc

Update of bug #34832 (project make): Assigned to:None => eliz Triage Status:None => Small Effort ___ Reply to this item at:

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #22, bug #34832 (project make): Propagating the tls functionality to gcc-builds won't hurt, but as I already said, please just remove it altogether if it isn't helping with anything (which it certainly looks that way) and that will stop any future confusions. ___

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #21, bug #34832 (project make): Ozkan, I don't understand the emotions. This is supposed to be a technical discussion. If I said something that sounded offensive, I apologize. More to the point: I don't know why it is there. 1996 is way before I started to be interested in t

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #20, bug #34832 (project make): > As for TLS availability for MSVC being a proof that it works, > I have my doubts: Well, why the hell is it there, then? I assume you are the one who is supposed to know that, and not me. If it is unnecessary or obsolete or whatever, removing i

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #19, bug #34832 (project make): You can provide a stack buffer from the caller like char * tmp[1000]; fprintf(..., map_windows32_error_to_string (tmp, er)); And the functions that call map_windows32_error_to_string from threads are not used. ___

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #18, bug #34832 (project make): All the uses pointed out by Paul are from a single thread. The only problem, if there is one, is with the calls from sub_proc.c. As for TLS availability for MSVC being a proof that it works, I have my doubts: with most of calls to the function co

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #17, bug #34832 (project make): It is used: make-cvs$ grep map_windows32_error_to_string *.c commands.c:ierr, map_windows32_error_to_string (ierr)); job.c: error_string = map_windows32_error_to_string (er); job.c: e, map_w

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #16, bug #34832 (project make): You can't easily simulate errors in a function that is not used from anywhere. ___ Reply to this item at: __

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #15, bug #34832 (project make): > We could get rid of that static buffer, or we could use the > __thread declaration, but my point is: if we are enabling to > produce error message strings from several threads, we might > as well actually do that and see that it works, e.g., by >

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #14, bug #34832 (project make): > if the benefits are worth the complexity. IMO, _definitely_ not. Side notes: the winsock errors check can definitely be removed from there along with the tls usage for msvc special case. And the function needs returning const.

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #13, bug #34832 (project make): We could get rid of that static buffer, or we could use the __thread declaration, but my point is: if we are enabling to produce error message strings from several threads, we might as well actually do that and see that it works, e.g., by uncomment

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #12, bug #34832 (project make): The reason the buffer is static is that if you allocate a dynamic buffer, someone has to free it. In POSIX we use the strerror() function which returns a const pointer to a static string that never needs to be freed so there's no facility in the c

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #11, bug #34832 (project make): > Why don't you rewrite the code do get rid of that static buffer > in the first place. That's certainly a good idea (had we known who you are, it would been even better, I guess.) Another cleanup would be removing the pointless winsock error cod

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #9, bug #34832 (project make): Then __declspec(thread) isn't actually needed, not for msvc, not for gcc either. As for thread-safety, I first though that that I caught glimpses of CreateThread(), but hmm, those turned out to be CreateProcess(). There are calls to _beginthreade

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #8, bug #34832 (project make): Paul, The Windows build of Make does use more than a single thread. Ozkan, Yes, I know that functions in the top-level directory call map_windows32_error_to_string, but those functions all run in a single thread. The only functions that don't ar

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #7, bug #34832 (project make): That function is used a lot in job.c, main.c, commands.c. But I agree with Eli: what's the need for having this variable be thread-safe in the first place? GNU make is not multithreaded (there would be a LOT of work needed to make that possible).

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #6, bug #34832 (project make): Are you looking at code from 1996? Have ever you tried grepping under top level *.c files for map_windows32_error_to_string ? ___ Reply to this item at:

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #5, bug #34832 (project make): Which multiple threads in Make might try to access the same static buffer concurrently? And under what circumstances? All but one call to map_windows32_error_to_string in sub_proc.c are commented out.

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #4, bug #34832 (project make): Because at the time that code was writtten, a __declspec(thread) equivalent wasn't available for gcc: that's the original author's skills in making a useful comment you are seeing. TLS is obviously necessary for that static array to make multiple t

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #3, bug #34832 (project make): Thanks. I know what TLS means. I meant to ask why it is useful for map_windows32_error_to_string to use thread local storage? What will that gain for Make? The comment there said it was only needed for MSVC. ___

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #2, bug #34832 (project make): The patch enables thread local storage in map_windows32_error_to_string() not only for MSVC, but also for gcc-built make binaries. It also constifies the returned value from the function, because the returned string is always used as read-only argum

[bug #34832] enable tls variable in windows code for newish gcc

Follow-up Comment #1, bug #34832 (project make): Thanks. However, you didn't explain what does this patch try to accomplish, and there's no ChangeLog entry in sight to help me understand that. Could you please describe the rationale? Also, please don't make gratuitous changes of whitespace, the

[bug #34832] enable tls variable in windows code for newish gcc

URL: Summary: enable tls variable in windows code for newish gcc Project: make Submitted by: sezero Submitted on: Tue 15 Nov 2011 04:06:15 PM GMT Severity: 3 - Normal Ite