clang not observing -fno-signed-char, and other triple realted issues

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

clang not observing -fno-signed-char, and other triple realted issues

shirley breuer via cfe-dev
Hi:

After successfully and easily compiling a project in Windows with clang-cl I wanted to change the command to clang. clang itself lies in Linux (WSL 2.0) and the C library to be used is that of MSVC. Eventually I learned about the triple, but by that time I had almost succeeded. I run into several issues:

|1.| (Seems a bug). -fno-signed-char (or -funsigned-char) is ignored depending on the triple settings:

targeting Linux, default option for the triple   O.K.
targeting Windows, x86_64-windows-windows-msvc<xx.xx.x>     O.K.
targeting Windows, x86_64-windows-windows-gnu     wrong

and there were some other combination where it was also wrong. The compiler insists in char being signed, which generates me hundreds of warnings.

|2.| <abi> in the triple

According to CrossCompilation.rst, "Finally, the ABI option is something that will pick default CPU/FPU,
define the specific behaviour of your code (PCS, extensions), and also choose the correct library calls, etc."

So, it seems it is not what defines the format of the generated object files (what I would expect given its "abi" name). Since I had already managed to make clang compile the sources by specifying the -isystem directories, and I wanted to avoid any windows related magic as much as possible, I tried to specify x86_64-windows-windows-none or x86_64-pc-windows-none, but "none" there, or "unknown" always got replaced by msvc19.11.0. Maybe it does not make sense to have the abi unknown? Therefore I finally compiled with x86_64-windows-windows-gnu, although gnu had nothing to do with my compilation.

I would expect that the application binary interface specification on the command line (or elsewhere) is what would make llvm generate object files for either or other consumer, but having seen that specifying "gnu" there generates .obj files just as specifying "msvc"; i.e., object files that Windows' link program handles well, it seems it is not.

So the question is: what in the triple is what makes the backend generate object files in one or the other format?

Except for the architecture part of the triple, which is clear what it means, I have found the documentation for the other parts (when I at last could find it) unclear in what they change or determine in a compilation process.

So, compiling with x86_64-windows-windows-gnu -fno-builtin -fms-compatibility -fshort-wchar -Wno-pointer-sign -fvisibility-ms-compat

and a bunch of defines like -D _M_X64=100, everything runs fine and linking the objects from Windows, with its link command, works properly, just as if I had compiled with x86_64-windows-windows-msvc19.16.00, EXCEPT for the function

___chk_stk_ms

which the linker cannot find. This function is inserted by the compiler when a function requires a large amount of stack space. I solved this by declaring the problematic objects static, but I'd like to know why this happens.

By the way, even without -fms-compatibility, just with -fdeclspec and some #defines in the code, I also succeeded in compiling.

|4.| -fms-compatibility vs. -fms-extensions

The help which is displayed by clang -help says

  -fms-compatibility      Enable full Microsoft Visual C++ compatibility
  -fms-extensions         Accept some non-standard constructs supported by the Microsoft compiler

which is not very informative. Which one enables less stuff? Is one a superset of the other. "Enable full Microsoft Visual C++ compatibility" seems to imply that this indeed is a superset of the other, but considering that even compiling with clang-cl there are the options /Ze and /Za which enable o disable Microsoft extensions, one is lead to think that the -fms-extensions are beyond the compatibility provided by -fms-compatibility. What, then?

|5.| -m... options.

I know that once I have specified my architecture to be x86_64 there are options that can improve the performance of the binaries: "Once your target is specified, it's time to pick the hardware you'll
be compiling to. For every architecture, a default set of CPU/FPU/ABI will be chosen, so you'll almost always have to change it via flags."
Where can the available flags be found? If they are so important and can have such an impact on the program, why is the documentation for them so difficult to find? (Specially if you are working off-line as I use to).


In general, it seems that a good, thought document explaining each of the parts of the "triple" AND what the determine in the compilation process, and those -m flags would be very welcome, and if clang -help would point where that documentation could be found that would be very helpful also. Just browse the internet for Q&A related to the triple, and you'll find that "official" explanations should definitely be easier to find.

Thanks in advance

-- Javier A. Múgica

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang not observing -fno-signed-char, and other triple realted issues

shirley breuer via cfe-dev
1. Re: funsigned-char, it seems to work for me:

$ cat t.cpp
static_assert((int)((char)255) == 255, "char should be unsigned");

$ clang -c --target=x86_64-windows-windows-gnu -funsigned-char t.cpp   
# success

Removing the flag makes it fail.


2. The meaning of the "ABI" part of the triple

I had not encountered that CrossCompiling.rst document until today. This is what I see in the Triple.h document:
ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT
In the code, the fourth component is referred to as the "environment". The environment is kind of a catch-all extension of the triple, which normally has three components: ISA, vendor, OS. The environment allows some more target customization, and everyone uses it for different purposes. I think it's hard to come up with a unified theory of what the triple environment really is. As you can see, we encode the MSVC CRT version in there, because sometimes the backend needs to know it. Some targets have an object file format override in the environment. You can see this in triples that end in -elf or -macho.

So, to answer your question about what part of the triple controls the object file format, there's no real good answer. It's not a well designed piece of infrastructure. :( Mainly, though, it's the OS that defines the object file format.

For Windows, there are two main environments: msvc and gnu. Both use COFF objects, but with slightly different contents. Generally, for plain C code, VC link.exe can handle GNU COFF objects. However, if you start doing interesting things (C++, __attribute__((weak)), some other things) eventually you will run into some incompatibilities. If you plan to use the Visual C++ linker, I would recommend using the msvc environment.


3. __chkstk_ms

This is a good example of the ways that -gnu and -msvc change LLVM's behavior. __chkstk_ms is provided by mingw's version of libgcc, I believe. Using the gnu environment makes LLVM use this helper.

chkstk and chkst_ms touch all the stack pages, similar to GCC's -fstack-clash-protector feature. Making objects static moved them from the stack to globals, reducing your stack frame size, avoiding the need for this helper.

You could fix this issue by linking against LLVM's compiler-rt which provides both helpers.


4. fms-compatibility vs fms-extensions

The idea behind these options is that fms-compatibility is the set of compatibility hacks that we would prefer to avoid, and fms-extensions is the set of language extensions that fit in the language well. For example, fms-extensions should enable a variety of builtin intrinsic functions, like _InterlockedCompareExchange, __fastfail, __noop. It enables __declspec(align).

fms-compatibility usually has more to do with forcing the compiler to accept certain invalid C++ code patterns involving templates. However, in practice it controls far more than that.


5. Docs on -m* flags

Yeah, I don't know what to say. There isn't really a singular point of responsibility in the community for keeping the docs up to date, consistent, and easy to find. As you've seen, things tend to be pretty spotty. clang --help probably isn't the right place for in-depth documentation, but there should be some central place that we can hook everything into. We have a UsersManual, but even a single web page can't describe every feature of clang. It's certainly an area for improvement.

I think -m micro-architectural flags, in particular, are the kind of thing that gets added on a case-by-case basis without any documentation or review. Every architecture has its own world of options.

On Sat, Nov 28, 2020 at 12:53 PM Javier Múgica via cfe-dev <[hidden email]> wrote:
Hi:

After successfully and easily compiling a project in Windows with clang-cl I wanted to change the command to clang. clang itself lies in Linux (WSL 2.0) and the C library to be used is that of MSVC. Eventually I learned about the triple, but by that time I had almost succeeded. I run into several issues:

|1.| (Seems a bug). -fno-signed-char (or -funsigned-char) is ignored depending on the triple settings:

targeting Linux, default option for the triple   O.K.
targeting Windows, x86_64-windows-windows-msvc<xx.xx.x>     O.K.
targeting Windows, x86_64-windows-windows-gnu     wrong

and there were some other combination where it was also wrong. The compiler insists in char being signed, which generates me hundreds of warnings.

|2.| <abi> in the triple

According to CrossCompilation.rst, "Finally, the ABI option is something that will pick default CPU/FPU,
define the specific behaviour of your code (PCS, extensions), and also choose the correct library calls, etc."

So, it seems it is not what defines the format of the generated object files (what I would expect given its "abi" name). Since I had already managed to make clang compile the sources by specifying the -isystem directories, and I wanted to avoid any windows related magic as much as possible, I tried to specify x86_64-windows-windows-none or x86_64-pc-windows-none, but "none" there, or "unknown" always got replaced by msvc19.11.0. Maybe it does not make sense to have the abi unknown? Therefore I finally compiled with x86_64-windows-windows-gnu, although gnu had nothing to do with my compilation.

I would expect that the application binary interface specification on the command line (or elsewhere) is what would make llvm generate object files for either or other consumer, but having seen that specifying "gnu" there generates .obj files just as specifying "msvc"; i.e., object files that Windows' link program handles well, it seems it is not.

So the question is: what in the triple is what makes the backend generate object files in one or the other format?

Except for the architecture part of the triple, which is clear what it means, I have found the documentation for the other parts (when I at last could find it) unclear in what they change or determine in a compilation process.

So, compiling with x86_64-windows-windows-gnu -fno-builtin -fms-compatibility -fshort-wchar -Wno-pointer-sign -fvisibility-ms-compat

and a bunch of defines like -D _M_X64=100, everything runs fine and linking the objects from Windows, with its link command, works properly, just as if I had compiled with x86_64-windows-windows-msvc19.16.00, EXCEPT for the function

___chk_stk_ms

which the linker cannot find. This function is inserted by the compiler when a function requires a large amount of stack space. I solved this by declaring the problematic objects static, but I'd like to know why this happens.

By the way, even without -fms-compatibility, just with -fdeclspec and some #defines in the code, I also succeeded in compiling.

|4.| -fms-compatibility vs. -fms-extensions

The help which is displayed by clang -help says

  -fms-compatibility      Enable full Microsoft Visual C++ compatibility
  -fms-extensions         Accept some non-standard constructs supported by the Microsoft compiler

which is not very informative. Which one enables less stuff? Is one a superset of the other. "Enable full Microsoft Visual C++ compatibility" seems to imply that this indeed is a superset of the other, but considering that even compiling with clang-cl there are the options /Ze and /Za which enable o disable Microsoft extensions, one is lead to think that the -fms-extensions are beyond the compatibility provided by -fms-compatibility. What, then?

|5.| -m... options.

I know that once I have specified my architecture to be x86_64 there are options that can improve the performance of the binaries: "Once your target is specified, it's time to pick the hardware you'll
be compiling to. For every architecture, a default set of CPU/FPU/ABI will be chosen, so you'll almost always have to change it via flags."
Where can the available flags be found? If they are so important and can have such an impact on the program, why is the documentation for them so difficult to find? (Specially if you are working off-line as I use to).


In general, it seems that a good, thought document explaining each of the parts of the "triple" AND what the determine in the compilation process, and those -m flags would be very welcome, and if clang -help would point where that documentation could be found that would be very helpful also. Just browse the internet for Q&A related to the triple, and you'll find that "official" explanations should definitely be easier to find.

Thanks in advance

-- Javier A. Múgica

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang not observing -fno-signed-char, and other triple realted issues

shirley breuer via cfe-dev
On Thu, 3 Dec 2020 at 13:55, Reid Kleckner via cfe-dev <[hidden email]> wrote:
1. Re: funsigned-char, it seems to work for me:

$ cat t.cpp
static_assert((int)((char)255) == 255, "char should be unsigned");

$ clang -c --target=x86_64-windows-windows-gnu -funsigned-char t.cpp   
# success

Removing the flag makes it fail.


2. The meaning of the "ABI" part of the triple

I had not encountered that CrossCompiling.rst document until today. This is what I see in the Triple.h document:
ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT
In the code, the fourth component is referred to as the "environment". The environment is kind of a catch-all extension of the triple, which normally has three components: ISA, vendor, OS. The environment allows some more target customization, and everyone uses it for different purposes. I think it's hard to come up with a unified theory of what the triple environment really is. As you can see, we encode the MSVC CRT version in there, because sometimes the backend needs to know it. Some targets have an object file format override in the environment. You can see this in triples that end in -elf or -macho.

So, to answer your question about what part of the triple controls the object file format, there's no real good answer. It's not a well designed piece of infrastructure. :( Mainly, though, it's the OS that defines the object file format.

For Windows, there are two main environments: msvc and gnu. Both use COFF objects, but with slightly different contents. Generally, for plain C code, VC link.exe can handle GNU COFF objects. However, if you start doing interesting things (C++, __attribute__((weak)), some other things) eventually you will run into some incompatibilities. If you plan to use the Visual C++ linker, I would recommend using the msvc environment.


3. __chkstk_ms

This is a good example of the ways that -gnu and -msvc change LLVM's behavior. __chkstk_ms is provided by mingw's version of libgcc, I believe. Using the gnu environment makes LLVM use this helper.

chkstk and chkst_ms touch all the stack pages, similar to GCC's -fstack-clash-protector feature. Making objects static moved them from the stack to globals, reducing your stack frame size, avoiding the need for this helper.

You could fix this issue by linking against LLVM's compiler-rt which provides both helpers.


4. fms-compatibility vs fms-extensions

The idea behind these options is that fms-compatibility is the set of compatibility hacks that we would prefer to avoid, and fms-extensions is the set of language extensions that fit in the language well. For example, fms-extensions should enable a variety of builtin intrinsic functions, like _InterlockedCompareExchange, __fastfail, __noop. It enables __declspec(align).

fms-compatibility usually has more to do with forcing the compiler to accept certain invalid C++ code patterns involving templates. However, in practice it controls far more than that.


5. Docs on -m* flags

Yeah, I don't know what to say. There isn't really a singular point of responsibility in the community for keeping the docs up to date, consistent, and easy to find. As you've seen, things tend to be pretty spotty. clang --help probably isn't the right place for in-depth documentation, but there should be some central place that we can hook everything into. We have a UsersManual, but even a single web page can't describe every feature of clang. It's certainly an area for improvement.

In addition to the UsersManual, there's http://clang.llvm.org/docs/ClangCommandLineReference.html, which aims to be a complete listing of all the command line flags. It's generated from the .td file, so it shouldn't miss out any flags (except the ones that are specified as being hidden), but as you'll see, there is no documentation whatsoever for many of the flags, and in most cases this reference contains no information beyond what's in the terse `--help` output.

So that's far from ideal; it can at least answer the "what -m flags exist?" question, but not the follow-up question "what do they do?".
 
I think -m micro-architectural flags, in particular, are the kind of thing that gets added on a case-by-case basis without any documentation or review. Every architecture has its own world of options.

On Sat, Nov 28, 2020 at 12:53 PM Javier Múgica via cfe-dev <[hidden email]> wrote:
Hi:

After successfully and easily compiling a project in Windows with clang-cl I wanted to change the command to clang. clang itself lies in Linux (WSL 2.0) and the C library to be used is that of MSVC. Eventually I learned about the triple, but by that time I had almost succeeded. I run into several issues:

|1.| (Seems a bug). -fno-signed-char (or -funsigned-char) is ignored depending on the triple settings:

targeting Linux, default option for the triple   O.K.
targeting Windows, x86_64-windows-windows-msvc<xx.xx.x>     O.K.
targeting Windows, x86_64-windows-windows-gnu     wrong

and there were some other combination where it was also wrong. The compiler insists in char being signed, which generates me hundreds of warnings.

|2.| <abi> in the triple

According to CrossCompilation.rst, "Finally, the ABI option is something that will pick default CPU/FPU,
define the specific behaviour of your code (PCS, extensions), and also choose the correct library calls, etc."

So, it seems it is not what defines the format of the generated object files (what I would expect given its "abi" name). Since I had already managed to make clang compile the sources by specifying the -isystem directories, and I wanted to avoid any windows related magic as much as possible, I tried to specify x86_64-windows-windows-none or x86_64-pc-windows-none, but "none" there, or "unknown" always got replaced by msvc19.11.0. Maybe it does not make sense to have the abi unknown? Therefore I finally compiled with x86_64-windows-windows-gnu, although gnu had nothing to do with my compilation.

I would expect that the application binary interface specification on the command line (or elsewhere) is what would make llvm generate object files for either or other consumer, but having seen that specifying "gnu" there generates .obj files just as specifying "msvc"; i.e., object files that Windows' link program handles well, it seems it is not.

So the question is: what in the triple is what makes the backend generate object files in one or the other format?

Except for the architecture part of the triple, which is clear what it means, I have found the documentation for the other parts (when I at last could find it) unclear in what they change or determine in a compilation process.

So, compiling with x86_64-windows-windows-gnu -fno-builtin -fms-compatibility -fshort-wchar -Wno-pointer-sign -fvisibility-ms-compat

and a bunch of defines like -D _M_X64=100, everything runs fine and linking the objects from Windows, with its link command, works properly, just as if I had compiled with x86_64-windows-windows-msvc19.16.00, EXCEPT for the function

___chk_stk_ms

which the linker cannot find. This function is inserted by the compiler when a function requires a large amount of stack space. I solved this by declaring the problematic objects static, but I'd like to know why this happens.

By the way, even without -fms-compatibility, just with -fdeclspec and some #defines in the code, I also succeeded in compiling.

|4.| -fms-compatibility vs. -fms-extensions

The help which is displayed by clang -help says

  -fms-compatibility      Enable full Microsoft Visual C++ compatibility
  -fms-extensions         Accept some non-standard constructs supported by the Microsoft compiler

which is not very informative. Which one enables less stuff? Is one a superset of the other. "Enable full Microsoft Visual C++ compatibility" seems to imply that this indeed is a superset of the other, but considering that even compiling with clang-cl there are the options /Ze and /Za which enable o disable Microsoft extensions, one is lead to think that the -fms-extensions are beyond the compatibility provided by -fms-compatibility. What, then?

|5.| -m... options.

I know that once I have specified my architecture to be x86_64 there are options that can improve the performance of the binaries: "Once your target is specified, it's time to pick the hardware you'll
be compiling to. For every architecture, a default set of CPU/FPU/ABI will be chosen, so you'll almost always have to change it via flags."
Where can the available flags be found? If they are so important and can have such an impact on the program, why is the documentation for them so difficult to find? (Specially if you are working off-line as I use to).


In general, it seems that a good, thought document explaining each of the parts of the "triple" AND what the determine in the compilation process, and those -m flags would be very welcome, and if clang -help would point where that documentation could be found that would be very helpful also. Just browse the internet for Q&A related to the triple, and you'll find that "official" explanations should definitely be easier to find.

Thanks in advance

-- Javier A. Múgica

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang not observing -fno-signed-char, and other triple realted issues

shirley breuer via cfe-dev
In reply to this post by shirley breuer via cfe-dev
Kleckner,

Your answer is very good. Thank you very much for it. You have made me clear what I was doubtful or ignorant about better than I could have expected.

1. Regarding -funsigned-char.

A minimum example also works for me, but I am sure I got those warnings, so I wet through it and here is a different kind of minimum example:

typedef unsigned char char8_t;

int func(const char8_t *s){return 0;}
int main(void){
        char8_t *s="Some text"; //-Wpointer-sign
        return func("Some text"); //-Wpointer-sign
}

As you can see, the bug is restricted to the type Clang assigns to string literals. Curiously, now I have not been able to set the compilation flags in such a way that the warning does not show up, the --target does not seem to have any effect, but when I compile my code in Linux the warnings do not appear (and they have not been turned off).


3. " Making objects static ..." .

Yes, I know, I made them static on the purpose.

4. "fms-compatibility is the set of compatibility hacks that we would prefer to avoid"

You could not have explained it better. Fortunately, I turns out that I don't need those hacks for my code to compile, whatever they be.


Regards

-- Javier A. Múgica



_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang not observing -fno-signed-char, and other triple realted issues

shirley breuer via cfe-dev
On Thu, Dec 17, 2020 at 8:13 PM Javier Múgica via cfe-dev <[hidden email]> wrote:
Kleckner,

Your answer is very good. Thank you very much for it. You have made me clear what I was doubtful or ignorant about better than I could have expected.

1. Regarding -funsigned-char.

A minimum example also works for me, but I am sure I got those warnings, so I wet through it and here is a different kind of minimum example:

typedef unsigned char char8_t;

int func(const char8_t *s){return 0;}
int main(void){
        char8_t *s="Some text"; //-Wpointer-sign
        return func("Some text"); //-Wpointer-sign
}

As you can see, the bug is restricted to the type Clang assigns to string literals. Curiously, now I have not been able to set the compilation flags in such a way that the warning does not show up, the --target does not seem to have any effect, but when I compile my code in Linux the warnings do not appear (and they have not been turned off).
This might just be bad message text. "char" is never the same type as "signed char" or "unsigned char", so that there is a warning is intended.
 


3. " Making objects static ..." .

Yes, I know, I made them static on the purpose.

4. "fms-compatibility is the set of compatibility hacks that we would prefer to avoid"

You could not have explained it better. Fortunately, I turns out that I don't need those hacks for my code to compile, whatever they be.


Regards

-- Javier A. Múgica



_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang not observing -fno-signed-char, and other triple realted issues

shirley breuer via cfe-dev
In reply to this post by shirley breuer via cfe-dev
On Thu, Dec 3, 2020 at 2:06 PM Richard Smith via cfe-dev
<[hidden email]> wrote:

>
> On Thu, 3 Dec 2020 at 13:55, Reid Kleckner via cfe-dev <[hidden email]> wrote:
>>
>> 1. Re: funsigned-char, it seems to work for me:
>>
>> $ cat t.cpp
>> static_assert((int)((char)255) == 255, "char should be unsigned");
>>
>> $ clang -c --target=x86_64-windows-windows-gnu -funsigned-char t.cpp
>> # success
>>
>> Removing the flag makes it fail.
>>
>>
>> 2. The meaning of the "ABI" part of the triple
>>
>> I had not encountered that CrossCompiling.rst document until today. This is what I see in the Triple.h document:
>> ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT
>> In the code, the fourth component is referred to as the "environment". The environment is kind of a catch-all extension of the triple, which normally has three components: ISA, vendor, OS. The environment allows some more target customization, and everyone uses it for different purposes. I think it's hard to come up with a unified theory of what the triple environment really is. As you can see, we encode the MSVC CRT version in there, because sometimes the backend needs to know it. Some targets have an object file format override in the environment. You can see this in triples that end in -elf or -macho.
>>
>> So, to answer your question about what part of the triple controls the object file format, there's no real good answer. It's not a well designed piece of infrastructure. :( Mainly, though, it's the OS that defines the object file format.
>>
>> For Windows, there are two main environments: msvc and gnu. Both use COFF objects, but with slightly different contents. Generally, for plain C code, VC link.exe can handle GNU COFF objects. However, if you start doing interesting things (C++, __attribute__((weak)), some other things) eventually you will run into some incompatibilities. If you plan to use the Visual C++ linker, I would recommend using the msvc environment.
>>
>>
>> 3. __chkstk_ms
>>
>> This is a good example of the ways that -gnu and -msvc change LLVM's behavior. __chkstk_ms is provided by mingw's version of libgcc, I believe. Using the gnu environment makes LLVM use this helper.
>>
>> chkstk and chkst_ms touch all the stack pages, similar to GCC's -fstack-clash-protector feature. Making objects static moved them from the stack to globals, reducing your stack frame size, avoiding the need for this helper.
>>
>> You could fix this issue by linking against LLVM's compiler-rt which provides both helpers.
>>
>>
>> 4. fms-compatibility vs fms-extensions
>>
>> The idea behind these options is that fms-compatibility is the set of compatibility hacks that we would prefer to avoid, and fms-extensions is the set of language extensions that fit in the language well. For example, fms-extensions should enable a variety of builtin intrinsic functions, like _InterlockedCompareExchange, __fastfail, __noop. It enables __declspec(align).
>>
>> fms-compatibility usually has more to do with forcing the compiler to accept certain invalid C++ code patterns involving templates. However, in practice it controls far more than that.
>>
>>
>> 5. Docs on -m* flags
>>
>> Yeah, I don't know what to say. There isn't really a singular point of responsibility in the community for keeping the docs up to date, consistent, and easy to find. As you've seen, things tend to be pretty spotty. clang --help probably isn't the right place for in-depth documentation, but there should be some central place that we can hook everything into. We have a UsersManual, but even a single web page can't describe every feature of clang. It's certainly an area for improvement.
>
>
> In addition to the UsersManual, there's http://clang.llvm.org/docs/ClangCommandLineReference.html, which aims to be a complete listing of all the command line flags. It's generated from the .td file, so it shouldn't miss out any flags (except the ones that are specified as being hidden), but as you'll see, there is no documentation whatsoever for many of the flags, and in most cases this reference contains no information beyond what's in the terse `--help` output.
>
> So that's far from ideal; it can at least answer the "what -m flags exist?" question, but not the follow-up question "what do they do?".

Jan has some recent refactorings to Options.td . Perhaps Jan has some
ideas for improving the documentation?

>>
>> I think -m micro-architectural flags, in particular, are the kind of thing that gets added on a case-by-case basis without any documentation or review. Every architecture has its own world of options.
>>
>> On Sat, Nov 28, 2020 at 12:53 PM Javier Múgica via cfe-dev <[hidden email]> wrote:
>>>
>>> Hi:
>>>
>>> After successfully and easily compiling a project in Windows with clang-cl I wanted to change the command to clang. clang itself lies in Linux (WSL 2.0) and the C library to be used is that of MSVC. Eventually I learned about the triple, but by that time I had almost succeeded. I run into several issues:
>>>
>>> |1.| (Seems a bug). -fno-signed-char (or -funsigned-char) is ignored depending on the triple settings:
>>>
>>> targeting Linux, default option for the triple   O.K.
>>> targeting Windows, x86_64-windows-windows-msvc<xx.xx.x>     O.K.
>>> targeting Windows, x86_64-windows-windows-gnu     wrong
>>>
>>> and there were some other combination where it was also wrong. The compiler insists in char being signed, which generates me hundreds of warnings.
>>>
>>> |2.| <abi> in the triple
>>>
>>> According to CrossCompilation.rst, "Finally, the ABI option is something that will pick default CPU/FPU,
>>> define the specific behaviour of your code (PCS, extensions), and also choose the correct library calls, etc."
>>>
>>> So, it seems it is not what defines the format of the generated object files (what I would expect given its "abi" name). Since I had already managed to make clang compile the sources by specifying the -isystem directories, and I wanted to avoid any windows related magic as much as possible, I tried to specify x86_64-windows-windows-none or x86_64-pc-windows-none, but "none" there, or "unknown" always got replaced by msvc19.11.0. Maybe it does not make sense to have the abi unknown? Therefore I finally compiled with x86_64-windows-windows-gnu, although gnu had nothing to do with my compilation.
>>>
>>> I would expect that the application binary interface specification on the command line (or elsewhere) is what would make llvm generate object files for either or other consumer, but having seen that specifying "gnu" there generates .obj files just as specifying "msvc"; i.e., object files that Windows' link program handles well, it seems it is not.
>>>
>>> So the question is: what in the triple is what makes the backend generate object files in one or the other format?
>>>
>>> Except for the architecture part of the triple, which is clear what it means, I have found the documentation for the other parts (when I at last could find it) unclear in what they change or determine in a compilation process.
>>>
>>> So, compiling with x86_64-windows-windows-gnu -fno-builtin -fms-compatibility -fshort-wchar -Wno-pointer-sign -fvisibility-ms-compat
>>>
>>> and a bunch of defines like -D _M_X64=100, everything runs fine and linking the objects from Windows, with its link command, works properly, just as if I had compiled with x86_64-windows-windows-msvc19.16.00, EXCEPT for the function
>>>
>>> ___chk_stk_ms
>>>
>>> which the linker cannot find. This function is inserted by the compiler when a function requires a large amount of stack space. I solved this by declaring the problematic objects static, but I'd like to know why this happens.
>>>
>>> By the way, even without -fms-compatibility, just with -fdeclspec and some #defines in the code, I also succeeded in compiling.
>>>
>>> |4.| -fms-compatibility vs. -fms-extensions
>>>
>>> The help which is displayed by clang -help says
>>>
>>>   -fms-compatibility      Enable full Microsoft Visual C++ compatibility
>>>   -fms-extensions         Accept some non-standard constructs supported by the Microsoft compiler
>>>
>>> which is not very informative. Which one enables less stuff? Is one a superset of the other. "Enable full Microsoft Visual C++ compatibility" seems to imply that this indeed is a superset of the other, but considering that even compiling with clang-cl there are the options /Ze and /Za which enable o disable Microsoft extensions, one is lead to think that the -fms-extensions are beyond the compatibility provided by -fms-compatibility. What, then?
>>>
>>> |5.| -m... options.
>>>
>>> I know that once I have specified my architecture to be x86_64 there are options that can improve the performance of the binaries: "Once your target is specified, it's time to pick the hardware you'll
>>> be compiling to. For every architecture, a default set of CPU/FPU/ABI will be chosen, so you'll almost always have to change it via flags."
>>> Where can the available flags be found? If they are so important and can have such an impact on the program, why is the documentation for them so difficult to find? (Specially if you are working off-line as I use to).
>>>
>>>
>>> In general, it seems that a good, thought document explaining each of the parts of the "triple" AND what the determine in the compilation process, and those -m flags would be very welcome, and if clang -help would point where that documentation could be found that would be very helpful also. Just browse the internet for Q&A related to the triple, and you'll find that "official" explanations should definitely be easier to find.
>>>
>>> Thanks in advance
>>>
>>> -- Javier A. Múgica
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



--
宋方睿
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang not observing -fno-signed-char, and other triple realted issues

shirley breuer via cfe-dev
I think people creating new command line options should be responsible for documenting them (at least via HelpText in the TableGen file). Ensuring this happens should be part of the code review process, but that seems hard to do consistently. Maybe we could enforce this via regression tests (e.g. no patch is allowed to increase the number of options without HelpText)?

Cheers,
Jan

On Dec 18, 2020, at 10:07 PM, Fāng-ruì Sòng <[hidden email]> wrote:

On Thu, Dec 3, 2020 at 2:06 PM Richard Smith via cfe-dev
<[hidden email]> wrote:

On Thu, 3 Dec 2020 at 13:55, Reid Kleckner via cfe-dev <[hidden email]> wrote:

1. Re: funsigned-char, it seems to work for me:

$ cat t.cpp
static_assert((int)((char)255) == 255, "char should be unsigned");

$ clang -c --target=x86_64-windows-windows-gnu -funsigned-char t.cpp
# success

Removing the flag makes it fail.


2. The meaning of the "ABI" part of the triple

I had not encountered that CrossCompiling.rst document until today. This is what I see in the Triple.h document:
ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT
In the code, the fourth component is referred to as the "environment". The environment is kind of a catch-all extension of the triple, which normally has three components: ISA, vendor, OS. The environment allows some more target customization, and everyone uses it for different purposes. I think it's hard to come up with a unified theory of what the triple environment really is. As you can see, we encode the MSVC CRT version in there, because sometimes the backend needs to know it. Some targets have an object file format override in the environment. You can see this in triples that end in -elf or -macho.

So, to answer your question about what part of the triple controls the object file format, there's no real good answer. It's not a well designed piece of infrastructure. :( Mainly, though, it's the OS that defines the object file format.

For Windows, there are two main environments: msvc and gnu. Both use COFF objects, but with slightly different contents. Generally, for plain C code, VC link.exe can handle GNU COFF objects. However, if you start doing interesting things (C++, __attribute__((weak)), some other things) eventually you will run into some incompatibilities. If you plan to use the Visual C++ linker, I would recommend using the msvc environment.


3. __chkstk_ms

This is a good example of the ways that -gnu and -msvc change LLVM's behavior. __chkstk_ms is provided by mingw's version of libgcc, I believe. Using the gnu environment makes LLVM use this helper.

chkstk and chkst_ms touch all the stack pages, similar to GCC's -fstack-clash-protector feature. Making objects static moved them from the stack to globals, reducing your stack frame size, avoiding the need for this helper.

You could fix this issue by linking against LLVM's compiler-rt which provides both helpers.


4. fms-compatibility vs fms-extensions

The idea behind these options is that fms-compatibility is the set of compatibility hacks that we would prefer to avoid, and fms-extensions is the set of language extensions that fit in the language well. For example, fms-extensions should enable a variety of builtin intrinsic functions, like _InterlockedCompareExchange, __fastfail, __noop. It enables __declspec(align).

fms-compatibility usually has more to do with forcing the compiler to accept certain invalid C++ code patterns involving templates. However, in practice it controls far more than that.


5. Docs on -m* flags

Yeah, I don't know what to say. There isn't really a singular point of responsibility in the community for keeping the docs up to date, consistent, and easy to find. As you've seen, things tend to be pretty spotty. clang --help probably isn't the right place for in-depth documentation, but there should be some central place that we can hook everything into. We have a UsersManual, but even a single web page can't describe every feature of clang. It's certainly an area for improvement.


In addition to the UsersManual, there's http://clang.llvm.org/docs/ClangCommandLineReference.html, which aims to be a complete listing of all the command line flags. It's generated from the .td file, so it shouldn't miss out any flags (except the ones that are specified as being hidden), but as you'll see, there is no documentation whatsoever for many of the flags, and in most cases this reference contains no information beyond what's in the terse `--help` output.

So that's far from ideal; it can at least answer the "what -m flags exist?" question, but not the follow-up question "what do they do?".

Jan has some recent refactorings to Options.td . Perhaps Jan has some
ideas for improving the documentation?


I think -m micro-architectural flags, in particular, are the kind of thing that gets added on a case-by-case basis without any documentation or review. Every architecture has its own world of options.

On Sat, Nov 28, 2020 at 12:53 PM Javier Múgica via cfe-dev <[hidden email]> wrote:

Hi:

After successfully and easily compiling a project in Windows with clang-cl I wanted to change the command to clang. clang itself lies in Linux (WSL 2.0) and the C library to be used is that of MSVC. Eventually I learned about the triple, but by that time I had almost succeeded. I run into several issues:

|1.| (Seems a bug). -fno-signed-char (or -funsigned-char) is ignored depending on the triple settings:

targeting Linux, default option for the triple   O.K.
targeting Windows, x86_64-windows-windows-msvc<xx.xx.x>     O.K.
targeting Windows, x86_64-windows-windows-gnu     wrong

and there were some other combination where it was also wrong. The compiler insists in char being signed, which generates me hundreds of warnings.

|2.| <abi> in the triple

According to CrossCompilation.rst, "Finally, the ABI option is something that will pick default CPU/FPU,
define the specific behaviour of your code (PCS, extensions), and also choose the correct library calls, etc."

So, it seems it is not what defines the format of the generated object files (what I would expect given its "abi" name). Since I had already managed to make clang compile the sources by specifying the -isystem directories, and I wanted to avoid any windows related magic as much as possible, I tried to specify x86_64-windows-windows-none or x86_64-pc-windows-none, but "none" there, or "unknown" always got replaced by msvc19.11.0. Maybe it does not make sense to have the abi unknown? Therefore I finally compiled with x86_64-windows-windows-gnu, although gnu had nothing to do with my compilation.

I would expect that the application binary interface specification on the command line (or elsewhere) is what would make llvm generate object files for either or other consumer, but having seen that specifying "gnu" there generates .obj files just as specifying "msvc"; i.e., object files that Windows' link program handles well, it seems it is not.

So the question is: what in the triple is what makes the backend generate object files in one or the other format?

Except for the architecture part of the triple, which is clear what it means, I have found the documentation for the other parts (when I at last could find it) unclear in what they change or determine in a compilation process.

So, compiling with x86_64-windows-windows-gnu -fno-builtin -fms-compatibility -fshort-wchar -Wno-pointer-sign -fvisibility-ms-compat

and a bunch of defines like -D _M_X64=100, everything runs fine and linking the objects from Windows, with its link command, works properly, just as if I had compiled with x86_64-windows-windows-msvc19.16.00, EXCEPT for the function

___chk_stk_ms

which the linker cannot find. This function is inserted by the compiler when a function requires a large amount of stack space. I solved this by declaring the problematic objects static, but I'd like to know why this happens.

By the way, even without -fms-compatibility, just with -fdeclspec and some #defines in the code, I also succeeded in compiling.

|4.| -fms-compatibility vs. -fms-extensions

The help which is displayed by clang -help says

 -fms-compatibility      Enable full Microsoft Visual C++ compatibility
 -fms-extensions         Accept some non-standard constructs supported by the Microsoft compiler

which is not very informative. Which one enables less stuff? Is one a superset of the other. "Enable full Microsoft Visual C++ compatibility" seems to imply that this indeed is a superset of the other, but considering that even compiling with clang-cl there are the options /Ze and /Za which enable o disable Microsoft extensions, one is lead to think that the -fms-extensions are beyond the compatibility provided by -fms-compatibility. What, then?

|5.| -m... options.

I know that once I have specified my architecture to be x86_64 there are options that can improve the performance of the binaries: "Once your target is specified, it's time to pick the hardware you'll
be compiling to. For every architecture, a default set of CPU/FPU/ABI will be chosen, so you'll almost always have to change it via flags."
Where can the available flags be found? If they are so important and can have such an impact on the program, why is the documentation for them so difficult to find? (Specially if you are working off-line as I use to).


In general, it seems that a good, thought document explaining each of the parts of the "triple" AND what the determine in the compilation process, and those -m flags would be very welcome, and if clang -help would point where that documentation could be found that would be very helpful also. Just browse the internet for Q&A related to the triple, and you'll find that "official" explanations should definitely be easier to find.

Thanks in advance

-- Javier A. Múgica

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



-- 
宋方睿


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang not observing -fno-signed-char, and other triple realted issues

shirley breuer via cfe-dev
I think most options need more than just one sentence of help text.

What Aaron did for attribute reference documentation worked well. The documentation is written in a separate file, and all attributes (command line flags in our case) must be documented or carry an "undocumented" attribute. Screening patches for undocumented attributes is trivial, and even automatable.

I don't like the ergonomics of writing ReST or markdown in a tablegen file, but the system worked, and today we have pretty comprehensive attribute documentation.

On Mon, Dec 21, 2020 at 1:31 AM Jan Svoboda <[hidden email]> wrote:
I think people creating new command line options should be responsible for documenting them (at least via HelpText in the TableGen file). Ensuring this happens should be part of the code review process, but that seems hard to do consistently. Maybe we could enforce this via regression tests (e.g. no patch is allowed to increase the number of options without HelpText)?

Cheers,
Jan

On Dec 18, 2020, at 10:07 PM, Fāng-ruì Sòng <[hidden email]> wrote:

On Thu, Dec 3, 2020 at 2:06 PM Richard Smith via cfe-dev
<[hidden email]> wrote:

On Thu, 3 Dec 2020 at 13:55, Reid Kleckner via cfe-dev <[hidden email]> wrote:

1. Re: funsigned-char, it seems to work for me:

$ cat t.cpp
static_assert((int)((char)255) == 255, "char should be unsigned");

$ clang -c --target=x86_64-windows-windows-gnu -funsigned-char t.cpp
# success

Removing the flag makes it fail.


2. The meaning of the "ABI" part of the triple

I had not encountered that CrossCompiling.rst document until today. This is what I see in the Triple.h document:
ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT
In the code, the fourth component is referred to as the "environment". The environment is kind of a catch-all extension of the triple, which normally has three components: ISA, vendor, OS. The environment allows some more target customization, and everyone uses it for different purposes. I think it's hard to come up with a unified theory of what the triple environment really is. As you can see, we encode the MSVC CRT version in there, because sometimes the backend needs to know it. Some targets have an object file format override in the environment. You can see this in triples that end in -elf or -macho.

So, to answer your question about what part of the triple controls the object file format, there's no real good answer. It's not a well designed piece of infrastructure. :( Mainly, though, it's the OS that defines the object file format.

For Windows, there are two main environments: msvc and gnu. Both use COFF objects, but with slightly different contents. Generally, for plain C code, VC link.exe can handle GNU COFF objects. However, if you start doing interesting things (C++, __attribute__((weak)), some other things) eventually you will run into some incompatibilities. If you plan to use the Visual C++ linker, I would recommend using the msvc environment.


3. __chkstk_ms

This is a good example of the ways that -gnu and -msvc change LLVM's behavior. __chkstk_ms is provided by mingw's version of libgcc, I believe. Using the gnu environment makes LLVM use this helper.

chkstk and chkst_ms touch all the stack pages, similar to GCC's -fstack-clash-protector feature. Making objects static moved them from the stack to globals, reducing your stack frame size, avoiding the need for this helper.

You could fix this issue by linking against LLVM's compiler-rt which provides both helpers.


4. fms-compatibility vs fms-extensions

The idea behind these options is that fms-compatibility is the set of compatibility hacks that we would prefer to avoid, and fms-extensions is the set of language extensions that fit in the language well. For example, fms-extensions should enable a variety of builtin intrinsic functions, like _InterlockedCompareExchange, __fastfail, __noop. It enables __declspec(align).

fms-compatibility usually has more to do with forcing the compiler to accept certain invalid C++ code patterns involving templates. However, in practice it controls far more than that.


5. Docs on -m* flags

Yeah, I don't know what to say. There isn't really a singular point of responsibility in the community for keeping the docs up to date, consistent, and easy to find. As you've seen, things tend to be pretty spotty. clang --help probably isn't the right place for in-depth documentation, but there should be some central place that we can hook everything into. We have a UsersManual, but even a single web page can't describe every feature of clang. It's certainly an area for improvement.


In addition to the UsersManual, there's http://clang.llvm.org/docs/ClangCommandLineReference.html, which aims to be a complete listing of all the command line flags. It's generated from the .td file, so it shouldn't miss out any flags (except the ones that are specified as being hidden), but as you'll see, there is no documentation whatsoever for many of the flags, and in most cases this reference contains no information beyond what's in the terse `--help` output.

So that's far from ideal; it can at least answer the "what -m flags exist?" question, but not the follow-up question "what do they do?".

Jan has some recent refactorings to Options.td . Perhaps Jan has some
ideas for improving the documentation?


I think -m micro-architectural flags, in particular, are the kind of thing that gets added on a case-by-case basis without any documentation or review. Every architecture has its own world of options.

On Sat, Nov 28, 2020 at 12:53 PM Javier Múgica via cfe-dev <[hidden email]> wrote:

Hi:

After successfully and easily compiling a project in Windows with clang-cl I wanted to change the command to clang. clang itself lies in Linux (WSL 2.0) and the C library to be used is that of MSVC. Eventually I learned about the triple, but by that time I had almost succeeded. I run into several issues:

|1.| (Seems a bug). -fno-signed-char (or -funsigned-char) is ignored depending on the triple settings:

targeting Linux, default option for the triple   O.K.
targeting Windows, x86_64-windows-windows-msvc<xx.xx.x>     O.K.
targeting Windows, x86_64-windows-windows-gnu     wrong

and there were some other combination where it was also wrong. The compiler insists in char being signed, which generates me hundreds of warnings.

|2.| <abi> in the triple

According to CrossCompilation.rst, "Finally, the ABI option is something that will pick default CPU/FPU,
define the specific behaviour of your code (PCS, extensions), and also choose the correct library calls, etc."

So, it seems it is not what defines the format of the generated object files (what I would expect given its "abi" name). Since I had already managed to make clang compile the sources by specifying the -isystem directories, and I wanted to avoid any windows related magic as much as possible, I tried to specify x86_64-windows-windows-none or x86_64-pc-windows-none, but "none" there, or "unknown" always got replaced by msvc19.11.0. Maybe it does not make sense to have the abi unknown? Therefore I finally compiled with x86_64-windows-windows-gnu, although gnu had nothing to do with my compilation.

I would expect that the application binary interface specification on the command line (or elsewhere) is what would make llvm generate object files for either or other consumer, but having seen that specifying "gnu" there generates .obj files just as specifying "msvc"; i.e., object files that Windows' link program handles well, it seems it is not.

So the question is: what in the triple is what makes the backend generate object files in one or the other format?

Except for the architecture part of the triple, which is clear what it means, I have found the documentation for the other parts (when I at last could find it) unclear in what they change or determine in a compilation process.

So, compiling with x86_64-windows-windows-gnu -fno-builtin -fms-compatibility -fshort-wchar -Wno-pointer-sign -fvisibility-ms-compat

and a bunch of defines like -D _M_X64=100, everything runs fine and linking the objects from Windows, with its link command, works properly, just as if I had compiled with x86_64-windows-windows-msvc19.16.00, EXCEPT for the function

___chk_stk_ms

which the linker cannot find. This function is inserted by the compiler when a function requires a large amount of stack space. I solved this by declaring the problematic objects static, but I'd like to know why this happens.

By the way, even without -fms-compatibility, just with -fdeclspec and some #defines in the code, I also succeeded in compiling.

|4.| -fms-compatibility vs. -fms-extensions

The help which is displayed by clang -help says

 -fms-compatibility      Enable full Microsoft Visual C++ compatibility
 -fms-extensions         Accept some non-standard constructs supported by the Microsoft compiler

which is not very informative. Which one enables less stuff? Is one a superset of the other. "Enable full Microsoft Visual C++ compatibility" seems to imply that this indeed is a superset of the other, but considering that even compiling with clang-cl there are the options /Ze and /Za which enable o disable Microsoft extensions, one is lead to think that the -fms-extensions are beyond the compatibility provided by -fms-compatibility. What, then?

|5.| -m... options.

I know that once I have specified my architecture to be x86_64 there are options that can improve the performance of the binaries: "Once your target is specified, it's time to pick the hardware you'll
be compiling to. For every architecture, a default set of CPU/FPU/ABI will be chosen, so you'll almost always have to change it via flags."
Where can the available flags be found? If they are so important and can have such an impact on the program, why is the documentation for them so difficult to find? (Specially if you are working off-line as I use to).


In general, it seems that a good, thought document explaining each of the parts of the "triple" AND what the determine in the compilation process, and those -m flags would be very welcome, and if clang -help would point where that documentation could be found that would be very helpful also. Just browse the internet for Q&A related to the triple, and you'll find that "official" explanations should definitely be easier to find.

Thanks in advance

-- Javier A. Múgica

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



-- 
宋方睿


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang not observing -fno-signed-char, and other triple realted issues

shirley breuer via cfe-dev
In reply to this post by shirley breuer via cfe-dev

> > 1. Regarding -funsigned-char.
> >
> > A minimum example also works for me, but I am sure I got those warnings,
> > so I wet through it and here is a different kind of minimum example:
> >
> > typedef unsigned char char8_t;
> >
> > int func(const char8_t *s){return 0;}
> > int main(void){
> >         char8_t *s="Some text"; //-Wpointer-sign
> >         return func("Some text"); //-Wpointer-sign
> > }
> >
> > As you can see, the bug is restricted to the type Clang assigns to string
> > literals [...]
> >
> This might just be bad message text. "char" is never the same type as
> "signed char" or "unsigned char", so that there is a warning is intended.
>

I know "char" is always a different type than "signed char" or "unsigned char". If "char" has been set to be unsigned there is no sign mismatch in an assignment like char8_t *s="Some text"; above, so the warning is certainly wrong. It is very annoying, and removing it is not a very good idea because a pointer-sign mismatch is really worth having reported when it actually happens.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev