Closed p5pRT closed 4 years ago
See attached patches. perl will not build with my clang-cl 3.5.0 with these patches since I left out all the workarounds around clang bugs\, but these patches take care of most of the warnings that clang shows+makefile support to actually use clang-cl.exe. Fixing the clang warnings helps all the other non-clang compiler builds of perl\, which is half the point of these patches.
On Thu Sep 03 22:43:06 2015\, bulk88 wrote:
This is a bug report for perl from bulk88@hotmail.com\, generated with the help of perlbug 1.40 running under perl 5.23.0.
----------------------------------------------------------------- [Please describe your issue here]
See attached patches. perl will not build with my clang-cl 3.5.0 with these patches since I left out all the workarounds around clang bugs\, but these patches take care of most of the warnings that clang shows+makefile support to actually use clang-cl.exe. Fixing the clang warnings helps all the other non-clang compiler builds of perl\, which is half the point of these patches.
rebased+clang-as-VC un-support added to makefile.mk\, although Clang-as-GCC is missing from makefile.mk\, some provisions exist for it in the makefile in the relationship between CCTYPE and CLANG macro.
-- bulk88 ~ bulk88 at hotmail.com
On Wed Sep 09 13:34:58 2015\, bulk88 wrote:
On Thu Sep 03 22:43:06 2015\, bulk88 wrote:
This is a bug report for perl from bulk88@hotmail.com\, generated with the help of perlbug 1.40 running under perl 5.23.0.
----------------------------------------------------------------- [Please describe your issue here]
See attached patches. perl will not build with my clang-cl 3.5.0 with these patches since I left out all the workarounds around clang bugs\, but these patches take care of most of the warnings that clang shows+makefile support to actually use clang-cl.exe. Fixing the clang warnings helps all the other non-clang compiler builds of perl\, which is half the point of these patches.
rebased+clang-as-VC un-support added to makefile.mk\, although Clang- as-GCC is missing from makefile.mk\, some provisions exist for it in the makefile in the relationship between CCTYPE and CLANG macro.
No patches were posted\, resending.
-- bulk88 ~ bulk88 at hotmail.com
On Wed Sep 09 13:35:46 2015\, bulk88 wrote:
No patches were posted\, resending.
This mostly makes sense to me.
I do wonder why you're using two separate macros for clang support:
+!IF "$(CLANG)" != "" && "$(CLANG)" != "undef" +__clang__= define +!ELSE +__clang__= undef +!ENDIF
where other macros are handled by setting defaults only if the macro is undefined:
!IF "$(USE_64_BIT_INT)" == "" USE_64_BIT_INT = undef !ENDIF
win32.c(2048\,13) : warning: format specifies type 'int' but the argument has type 'DWORD' (aka 'unsigned long') [-Wformat] g_osver.dwMajorVersion\, g_osver.dwMinorVersion); ^
~~~~~ win32.c(2048\,37) : warning: format specifies type 'int' but the argument has type 'DWORD' (aka 'unsigned long') [-Wformat] g_osver.dwMajorVersion\, g_osver.dwMinorVersion); ^~~~~~ win32.c(2052\,13) : warning: format specifies type 'int' but the argument has type 'DWORD' (aka 'unsigned long') [-Wformat] g_osver.dwPlatformId == VER_PLATFORM_WIN32_NTchange %d to %u\, negative version numbers dont make sense\, warning still remains since the compiler still warns that "unsigned long" isnt "unsigned int"\, but they are the same on Win32/Win64\, so it is a possible clang bug. This code will never run on unix so portability doesn't matter.
It's not a bug\, they may be different types\, but the code is still incorrect.
Splitting part 3 into pieces wouldn't hurt.
Tony
The RT System itself - Status changed from 'new' to 'open'
@bulk88 these patch no longer applies cleanly. I'm putting words in his mouth, but I think @tonycoz was ok with some of this so it might be worth pursuing. Could you please rebase and submit this as a pull request?
Migrated from rt.perl.org#125982 (status was 'open')
Searchable as RT125982$