[cfe-users] Clang compilation options to solve the comaptible issue?
Hi,
I just stat using clang 8 not long ago. I need to compile our old c++
source without changing it. It is compiled with Visual Studio before. Now I
want to migrate to clang as the compiler.
The following code segement can be compiled by clang:
1) for (int i = 0 ; i < 6 ; i++ ) {
}
int k = i ; // compiler error
2) unsigned short *s =
wchar_t *t = s ; // compiler error
I tried -ffor-scope and -fshort-wchar, but does not solve the issues.
are there clang compilation options to solve the issues?
Thanks for your help very much,
Guofeng
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang-tidy bug?
On Wed, Oct 30, 2019 at 9:23 PM David Blaikie wrote:
>
> Two separate issues here
>
> 1) the fixit hint, as one of a set of alternatives, isn't likely to be
> removed/changed - the (albeit quirky) convention of using extra () to
> indicate an intentional assignment in a condition has been around for a
> while. So if you use the extra parens without writing an assignment, the
> compiler's going to suggest you resolve this "conflict" with the style -
> either you didn't intend the extra (), or you intended to use assignment.
> Those are the two alternative suggestions being made.
>
> 2) automatically applying one fixit hint of several ambiguous ones seems like
> a bug to me - Aaron - do you know anything about this? Is this
> accurate/intended/etc?
I also think that's a bug. It looks like it's coming from
Sema::DiagnoseEqualityWithExtraParens(). It looks like it presents
both fixits, which strikes me as a bad thing to do when automatically
applying fixits.
~Aaron
>
> On Tue, Oct 29, 2019 at 10:13 AM Robert Ankeney wrote:
>>
>> This was just a example of what I ran into when I used run-clang-tidy.py
>> across a compilation database with a -export-fixes=fix.yaml and then ra
>> clang-apply-replacements. Mainly I object to the suggestion+fixit to switch
>> to an assignment. Most coding standards would disallow assignments
>> in if conditionals. If anything, I would think a suggestion of "if (true ==
>> isValid)" would be more appropriate.
>>
>> Thanks for the feedback!
>> Robert
>>
>> On Mon, Oct 28, 2019 at 2:17 PM David Blaikie wrote:
>>>
>>> clang-tidy in the command line you gave didn't seem to modify the file for
>>> me, did it modify the file for you?
>>>
>>> Are you objecting to the suggestion, or that it was automatically applied?
>>> I would think it'd be a bug to apply any fixit/hint if there are multiple
>>> possible suggestions.
>>>
>>> But the existence of the suggestion (without the application of it) to the
>>> user seems right to me. The use of extra () to suppress the
>>> assignment-in-conditional warning (-Wparentheses) has been around for quite
>>> a while, so it's possible that the user intended assignment rather than
>>> comparison when they added the extra parentheses.
>>>
>>> - Dave
>>>
>>> On Sun, Oct 27, 2019 at 11:32 AM Robert Ankeney via cfe-users
>>> wrote:
For the following code (wrong.cpp):
bool check(bool isValid)
{
bool retVal = false;
if (( isValid == true ))
{
retVal = true;
}
return retVal;
}
when I run:
clang-tidy -checks=modernize-use-default-member-init wrong.cpp
I get:
4 warnings and 1 error generated.
Error while processing /llvm/match/ctBad/wrong.cpp.
/llvm/match/ctBad/wrong.cpp:5:19: error: equality comparison with
extraneous parentheses [clang-diagnostic-parentheses-equality]
if (( isValid == true ))
~ ^~ ~
=
/llvm/match/ctBad/wrong.cpp:5:19: note: remove extraneous parentheses
around the comparison to silence this warning
/llvm/match/ctBad/wrong.cpp:5:19: note: use '=' to turn this equality
comparison into an assignment
Note it turns the if into:
if ( isValid = true )
Seems like a very bad idea. Removing the redundant parentheses seems fine,
but changing the comparison to an assignment does not. Is this a bug?
Thanks,
Robert
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang-tidy bug?
On Thu, Oct 31, 2019 at 8:45 AM Aaron Ballman
wrote:
> On Wed, Oct 30, 2019 at 9:23 PM David Blaikie wrote:
> >
> > Two separate issues here
> >
> > 1) the fixit hint, as one of a set of alternatives, isn't likely to be
> removed/changed - the (albeit quirky) convention of using extra () to
> indicate an intentional assignment in a condition has been around for a
> while. So if you use the extra parens without writing an assignment, the
> compiler's going to suggest you resolve this "conflict" with the style -
> either you didn't intend the extra (), or you intended to use assignment.
> Those are the two alternative suggestions being made.
> >
> > 2) automatically applying one fixit hint of several ambiguous ones seems
> like a bug to me - Aaron - do you know anything about this? Is this
> accurate/intended/etc?
>
> I also think that's a bug. It looks like it's coming from
> Sema::DiagnoseEqualityWithExtraParens(). It looks like it presents
> both fixits, which strikes me as a bad thing to do when automatically
> applying fixits.
>
These fixits should be attached to notes, though, right? & Clang produces
all sorts of fixits on notes that are not semantics-preserving, I think?
("oh, I think you meant to write this other thing")
My understanding is that the fixits are correct (in the clang diagnostic
experience - "here's a warning, here are some ideas of what you might've
intended that would address the warning") - but it seems incorrect to
automatically apply especially ambiguous suggesitons like this. How would
clang-tidy choose between the two alternatives?
>
> ~Aaron
>
> >
> > On Tue, Oct 29, 2019 at 10:13 AM Robert Ankeney
> wrote:
> >>
> >> This was just a example of what I ran into when I used
> run-clang-tidy.py across a compilation database with a
> -export-fixes=fix.yaml and then ra
> >> clang-apply-replacements. Mainly I object to the suggestion+fixit to
> switch to an assignment. Most coding standards would disallow assignments
> >> in if conditionals. If anything, I would think a suggestion of "if
> (true == isValid)" would be more appropriate.
> >>
> >> Thanks for the feedback!
> >> Robert
> >>
> >> On Mon, Oct 28, 2019 at 2:17 PM David Blaikie
> wrote:
> >>>
> >>> clang-tidy in the command line you gave didn't seem to modify the file
> for me, did it modify the file for you?
> >>>
> >>> Are you objecting to the suggestion, or that it was automatically
> applied? I would think it'd be a bug to apply any fixit/hint if there are
> multiple possible suggestions.
> >>>
> >>> But the existence of the suggestion (without the application of it) to
> the user seems right to me. The use of extra () to suppress the
> assignment-in-conditional warning (-Wparentheses) has been around for quite
> a while, so it's possible that the user intended assignment rather than
> comparison when they added the extra parentheses.
> >>>
> >>> - Dave
> >>>
> >>> On Sun, Oct 27, 2019 at 11:32 AM Robert Ankeney via cfe-users <
> cfe-users@lists.llvm.org> wrote:
>
> For the following code (wrong.cpp):
>
> bool check(bool isValid)
> {
> bool retVal = false;
>
> if (( isValid == true ))
> {
> retVal = true;
> }
>
> return retVal;
> }
>
> when I run:
> clang-tidy -checks=modernize-use-default-member-init wrong.cpp
>
> I get:
> 4 warnings and 1 error generated.
> Error while processing /llvm/match/ctBad/wrong.cpp.
> /llvm/match/ctBad/wrong.cpp:5:19: error: equality comparison with
> extraneous parentheses [clang-diagnostic-parentheses-equality]
> if (( isValid == true ))
> ~ ^~ ~
> =
> /llvm/match/ctBad/wrong.cpp:5:19: note: remove extraneous parentheses
> around the comparison to silence this warning
> /llvm/match/ctBad/wrong.cpp:5:19: note: use '=' to turn this equality
> comparison into an assignment
>
> Note it turns the if into:
> if ( isValid = true )
>
> Seems like a very bad idea. Removing the redundant parentheses seems
> fine, but changing the comparison to an assignment does not. Is this a bug?
>
> Thanks,
> Robert
>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang9 UBSan and GMP
On Thu, Oct 31, 2019 at 2:30 AM Hans Åberg wrote:
>
> > On 31 Oct 2019, at 01:53, David Blaikie wrote:
> >
> >> Yes, but assuming that the GMP adheres to the C standard, there should
> be no difference in the arithmetical values produced.
> >
> > Not necessarily - C (well, I don't know the C standard as well as I know
> the C++ standard, admittedly) does allow various variations (implementation
> and unspecified behavior, for instance). eg: order of evaluation of
> function arguments (not that this is likely to vary due to optimizations -
> and doesn't with clang to the best of my knowledge, but as an example of
> the /sort/ of thing):
> >
> > int f() {
> > static int i = 0;
> > return i++;
> > }
> > int f2(int i, int j) {
> > return i;
> > }
> > int main() {
> > return f2(f(), f());
> > }
> >
> > This program could exit with 0 or 1 - both results are valid
> interpretations of the program per the standard. (again, I don't know the C
> spec quite as well, so I'm not sure exactly what it says about this code)
>
> Right, but that is something one would avoid when computing arithmetical
> results.
>
One would try to, yes - but that's sort of what the whole discussion is
resolving around: Is the code correct? I don't know. I wouldn't assume it
is (I'm not assuming it isn't either) - but without a reduced test case
that gets to the root of the difference in behavior, we don't know if the
code is correct.
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang-tidy bug?
On Thu, Oct 31, 2019 at 1:31 PM David Blaikie wrote:
>
>
>
> On Thu, Oct 31, 2019 at 8:45 AM Aaron Ballman wrote:
>>
>> On Wed, Oct 30, 2019 at 9:23 PM David Blaikie wrote:
>> >
>> > Two separate issues here
>> >
>> > 1) the fixit hint, as one of a set of alternatives, isn't likely to be
>> > removed/changed - the (albeit quirky) convention of using extra () to
>> > indicate an intentional assignment in a condition has been around for a
>> > while. So if you use the extra parens without writing an assignment, the
>> > compiler's going to suggest you resolve this "conflict" with the style -
>> > either you didn't intend the extra (), or you intended to use assignment.
>> > Those are the two alternative suggestions being made.
>> >
>> > 2) automatically applying one fixit hint of several ambiguous ones seems
>> > like a bug to me - Aaron - do you know anything about this? Is this
>> > accurate/intended/etc?
>>
>> I also think that's a bug. It looks like it's coming from
>> Sema::DiagnoseEqualityWithExtraParens(). It looks like it presents
>> both fixits, which strikes me as a bad thing to do when automatically
>> applying fixits.
>
>
> These fixits should be attached to notes, though, right? & Clang produces all
> sorts of fixits on notes that are not semantics-preserving, I think? ("oh, I
> think you meant to write this other thing")
Yes, they're both attached to notes but the notes point to the same
location as the error.
> My understanding is that the fixits are correct (in the clang diagnostic
> experience - "here's a warning, here are some ideas of what you might've
> intended that would address the warning") - but it seems incorrect to
> automatically apply especially ambiguous suggesitons like this. How would
> clang-tidy choose between the two alternatives?
I don't think it has a way to select between alternatives; I don't
think that was a use case we had envisioned for automatically applying
fix-its.
~Aaron
>
>>
>>
>> ~Aaron
>>
>> >
>> > On Tue, Oct 29, 2019 at 10:13 AM Robert Ankeney wrote:
>> >>
>> >> This was just a example of what I ran into when I used run-clang-tidy.py
>> >> across a compilation database with a -export-fixes=fix.yaml and then ra
>> >> clang-apply-replacements. Mainly I object to the suggestion+fixit to
>> >> switch to an assignment. Most coding standards would disallow assignments
>> >> in if conditionals. If anything, I would think a suggestion of "if (true
>> >> == isValid)" would be more appropriate.
>> >>
>> >> Thanks for the feedback!
>> >> Robert
>> >>
>> >> On Mon, Oct 28, 2019 at 2:17 PM David Blaikie wrote:
>> >>>
>> >>> clang-tidy in the command line you gave didn't seem to modify the file
>> >>> for me, did it modify the file for you?
>> >>>
>> >>> Are you objecting to the suggestion, or that it was automatically
>> >>> applied? I would think it'd be a bug to apply any fixit/hint if there
>> >>> are multiple possible suggestions.
>> >>>
>> >>> But the existence of the suggestion (without the application of it) to
>> >>> the user seems right to me. The use of extra () to suppress the
>> >>> assignment-in-conditional warning (-Wparentheses) has been around for
>> >>> quite a while, so it's possible that the user intended assignment rather
>> >>> than comparison when they added the extra parentheses.
>> >>>
>> >>> - Dave
>> >>>
>> >>> On Sun, Oct 27, 2019 at 11:32 AM Robert Ankeney via cfe-users
>> >>> wrote:
>>
>> For the following code (wrong.cpp):
>>
>> bool check(bool isValid)
>> {
>> bool retVal = false;
>>
>> if (( isValid == true ))
>> {
>> retVal = true;
>> }
>>
>> return retVal;
>> }
>>
>> when I run:
>> clang-tidy -checks=modernize-use-default-member-init wrong.cpp
>>
>> I get:
>> 4 warnings and 1 error generated.
>> Error while processing /llvm/match/ctBad/wrong.cpp.
>> /llvm/match/ctBad/wrong.cpp:5:19: error: equality comparison with
>> extraneous parentheses [clang-diagnostic-parentheses-equality]
>> if (( isValid == true ))
>> ~ ^~ ~
>> =
>> /llvm/match/ctBad/wrong.cpp:5:19: note: remove extraneous parentheses
>> around the comparison to silence this warning
>> /llvm/match/ctBad/wrong.cpp:5:19: note: use '=' to turn this equality
>> comparison into an assignment
>>
>> Note it turns the if into:
>> if ( isValid = true )
>>
>> Seems like a very bad idea. Removing the redundant parentheses seems
>> fine, but changing the comparison to an assignment does not. Is this a
>> bug?
>>
>> Thanks,
>> Robert
>>
>> ___
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-us
Re: [cfe-users] clang-tidy bug?
On Thu, Oct 31, 2019 at 11:19 AM Aaron Ballman
wrote:
> On Thu, Oct 31, 2019 at 1:31 PM David Blaikie wrote:
> >
> >
> >
> > On Thu, Oct 31, 2019 at 8:45 AM Aaron Ballman
> wrote:
> >>
> >> On Wed, Oct 30, 2019 at 9:23 PM David Blaikie
> wrote:
> >> >
> >> > Two separate issues here
> >> >
> >> > 1) the fixit hint, as one of a set of alternatives, isn't likely to
> be removed/changed - the (albeit quirky) convention of using extra () to
> indicate an intentional assignment in a condition has been around for a
> while. So if you use the extra parens without writing an assignment, the
> compiler's going to suggest you resolve this "conflict" with the style -
> either you didn't intend the extra (), or you intended to use assignment.
> Those are the two alternative suggestions being made.
> >> >
> >> > 2) automatically applying one fixit hint of several ambiguous ones
> seems like a bug to me - Aaron - do you know anything about this? Is this
> accurate/intended/etc?
> >>
> >> I also think that's a bug. It looks like it's coming from
> >> Sema::DiagnoseEqualityWithExtraParens(). It looks like it presents
> >> both fixits, which strikes me as a bad thing to do when automatically
> >> applying fixits.
> >
> >
> > These fixits should be attached to notes, though, right? & Clang
> produces all sorts of fixits on notes that are not semantics-preserving, I
> think? ("oh, I think you meant to write this other thing")
>
> Yes, they're both attached to notes but the notes point to the same
> location as the error.
>
> > My understanding is that the fixits are correct (in the clang diagnostic
> experience - "here's a warning, here are some ideas of what you might've
> intended that would address the warning") - but it seems incorrect to
> automatically apply especially ambiguous suggesitons like this. How would
> clang-tidy choose between the two alternatives?
>
> I don't think it has a way to select between alternatives; I don't
> think that was a use case we had envisioned for automatically applying
> fix-its.
>
I wasn't thinking a way to select - but I'd expect an automated tool to,
when presented with an ambiguity, decide that not doing anything was the
best course of action (same as if the warning had no notes).
>
> ~Aaron
>
> >
> >>
> >>
> >> ~Aaron
> >>
> >> >
> >> > On Tue, Oct 29, 2019 at 10:13 AM Robert Ankeney
> wrote:
> >> >>
> >> >> This was just a example of what I ran into when I used
> run-clang-tidy.py across a compilation database with a
> -export-fixes=fix.yaml and then ra
> >> >> clang-apply-replacements. Mainly I object to the suggestion+fixit
> to switch to an assignment. Most coding standards would disallow assignments
> >> >> in if conditionals. If anything, I would think a suggestion of "if
> (true == isValid)" would be more appropriate.
> >> >>
> >> >> Thanks for the feedback!
> >> >> Robert
> >> >>
> >> >> On Mon, Oct 28, 2019 at 2:17 PM David Blaikie
> wrote:
> >> >>>
> >> >>> clang-tidy in the command line you gave didn't seem to modify the
> file for me, did it modify the file for you?
> >> >>>
> >> >>> Are you objecting to the suggestion, or that it was automatically
> applied? I would think it'd be a bug to apply any fixit/hint if there are
> multiple possible suggestions.
> >> >>>
> >> >>> But the existence of the suggestion (without the application of it)
> to the user seems right to me. The use of extra () to suppress the
> assignment-in-conditional warning (-Wparentheses) has been around for quite
> a while, so it's possible that the user intended assignment rather than
> comparison when they added the extra parentheses.
> >> >>>
> >> >>> - Dave
> >> >>>
> >> >>> On Sun, Oct 27, 2019 at 11:32 AM Robert Ankeney via cfe-users <
> cfe-users@lists.llvm.org> wrote:
> >>
> >> For the following code (wrong.cpp):
> >>
> >> bool check(bool isValid)
> >> {
> >> bool retVal = false;
> >>
> >> if (( isValid == true ))
> >> {
> >> retVal = true;
> >> }
> >>
> >> return retVal;
> >> }
> >>
> >> when I run:
> >> clang-tidy -checks=modernize-use-default-member-init wrong.cpp
> >>
> >> I get:
> >> 4 warnings and 1 error generated.
> >> Error while processing /llvm/match/ctBad/wrong.cpp.
> >> /llvm/match/ctBad/wrong.cpp:5:19: error: equality comparison with
> extraneous parentheses [clang-diagnostic-parentheses-equality]
> >> if (( isValid == true ))
> >> ~ ^~ ~
> >> =
> >> /llvm/match/ctBad/wrong.cpp:5:19: note: remove extraneous
> parentheses around the comparison to silence this warning
> >> /llvm/match/ctBad/wrong.cpp:5:19: note: use '=' to turn this
> equality comparison into an assignment
> >>
> >> Note it turns the if into:
> >> if ( isValid = true )
> >>
> >> Seems like a very bad idea. Removing the redundant parentheses
> seems fine, but changing
Re: [cfe-users] clang-tidy bug?
On Thu, Oct 31, 2019 at 2:28 PM David Blaikie wrote:
>
>
>
> On Thu, Oct 31, 2019 at 11:19 AM Aaron Ballman wrote:
>>
>> On Thu, Oct 31, 2019 at 1:31 PM David Blaikie wrote:
>> >
>> >
>> >
>> > On Thu, Oct 31, 2019 at 8:45 AM Aaron Ballman
>> > wrote:
>> >>
>> >> On Wed, Oct 30, 2019 at 9:23 PM David Blaikie wrote:
>> >> >
>> >> > Two separate issues here
>> >> >
>> >> > 1) the fixit hint, as one of a set of alternatives, isn't likely to be
>> >> > removed/changed - the (albeit quirky) convention of using extra () to
>> >> > indicate an intentional assignment in a condition has been around for a
>> >> > while. So if you use the extra parens without writing an assignment,
>> >> > the compiler's going to suggest you resolve this "conflict" with the
>> >> > style - either you didn't intend the extra (), or you intended to use
>> >> > assignment. Those are the two alternative suggestions being made.
>> >> >
>> >> > 2) automatically applying one fixit hint of several ambiguous ones
>> >> > seems like a bug to me - Aaron - do you know anything about this? Is
>> >> > this accurate/intended/etc?
>> >>
>> >> I also think that's a bug. It looks like it's coming from
>> >> Sema::DiagnoseEqualityWithExtraParens(). It looks like it presents
>> >> both fixits, which strikes me as a bad thing to do when automatically
>> >> applying fixits.
>> >
>> >
>> > These fixits should be attached to notes, though, right? & Clang produces
>> > all sorts of fixits on notes that are not semantics-preserving, I think?
>> > ("oh, I think you meant to write this other thing")
>>
>> Yes, they're both attached to notes but the notes point to the same
>> location as the error.
>>
>> > My understanding is that the fixits are correct (in the clang diagnostic
>> > experience - "here's a warning, here are some ideas of what you might've
>> > intended that would address the warning") - but it seems incorrect to
>> > automatically apply especially ambiguous suggesitons like this. How would
>> > clang-tidy choose between the two alternatives?
>>
>> I don't think it has a way to select between alternatives; I don't
>> think that was a use case we had envisioned for automatically applying
>> fix-its.
>
>
> I wasn't thinking a way to select - but I'd expect an automated tool to, when
> presented with an ambiguity, decide that not doing anything was the best
> course of action (same as if the warning had no notes).
I agree. I've CCed Alex in case he has opinions as well.
~Aaron
>
>>
>>
>> ~Aaron
>>
>> >
>> >>
>> >>
>> >> ~Aaron
>> >>
>> >> >
>> >> > On Tue, Oct 29, 2019 at 10:13 AM Robert Ankeney
>> >> > wrote:
>> >> >>
>> >> >> This was just a example of what I ran into when I used
>> >> >> run-clang-tidy.py across a compilation database with a
>> >> >> -export-fixes=fix.yaml and then ra
>> >> >> clang-apply-replacements. Mainly I object to the suggestion+fixit to
>> >> >> switch to an assignment. Most coding standards would disallow
>> >> >> assignments
>> >> >> in if conditionals. If anything, I would think a suggestion of "if
>> >> >> (true == isValid)" would be more appropriate.
>> >> >>
>> >> >> Thanks for the feedback!
>> >> >> Robert
>> >> >>
>> >> >> On Mon, Oct 28, 2019 at 2:17 PM David Blaikie
>> >> >> wrote:
>> >> >>>
>> >> >>> clang-tidy in the command line you gave didn't seem to modify the
>> >> >>> file for me, did it modify the file for you?
>> >> >>>
>> >> >>> Are you objecting to the suggestion, or that it was automatically
>> >> >>> applied? I would think it'd be a bug to apply any fixit/hint if there
>> >> >>> are multiple possible suggestions.
>> >> >>>
>> >> >>> But the existence of the suggestion (without the application of it)
>> >> >>> to the user seems right to me. The use of extra () to suppress the
>> >> >>> assignment-in-conditional warning (-Wparentheses) has been around for
>> >> >>> quite a while, so it's possible that the user intended assignment
>> >> >>> rather than comparison when they added the extra parentheses.
>> >> >>>
>> >> >>> - Dave
>> >> >>>
>> >> >>> On Sun, Oct 27, 2019 at 11:32 AM Robert Ankeney via cfe-users
>> >> >>> wrote:
>> >>
>> >> For the following code (wrong.cpp):
>> >>
>> >> bool check(bool isValid)
>> >> {
>> >> bool retVal = false;
>> >>
>> >> if (( isValid == true ))
>> >> {
>> >> retVal = true;
>> >> }
>> >>
>> >> return retVal;
>> >> }
>> >>
>> >> when I run:
>> >> clang-tidy -checks=modernize-use-default-member-init wrong.cpp
>> >>
>> >> I get:
>> >> 4 warnings and 1 error generated.
>> >> Error while processing /llvm/match/ctBad/wrong.cpp.
>> >> /llvm/match/ctBad/wrong.cpp:5:19: error: equality comparison with
>> >> extraneous parentheses [clang-diagnostic-parentheses-equality]
>> >> if (( isValid == true ))
>> >> ~ ^~ ~
>> >> =
>> >> /
Re: [cfe-users] Clang9 UBSan and GMP
On Thu, Oct 31, 2019 at 12:00 PM Hans Åberg wrote: > > > On 31 Oct 2019, at 18:40, David Blaikie wrote: > > > >> Right, but that is something one would avoid when computing > arithmetical results. > > > > One would try to, yes - but that's sort of what the whole discussion is > resolving around: Is the code correct? I don't know. I wouldn't assume it > is (I'm not assuming it isn't either) - but without a reduced test case > that gets to the root of the difference in behavior, we don't know if the > code is correct. > > Nor whether it is a compiler bug. > Indeed - but you can imagine that, on average (just due to there being way more code compiled by the compiler, than the code of the compiler itself) the bug is in external code, not the compiler. Such that it's not practical for the compiler developers to do all the leg work of investigating 3rd party code bugs to determine if it's a bug in the compiler. It doesn't scale/we wouldn't have any time to work on the compiler & most of the time we'd be finding user bugs, not compiler bugs. Apologies for the snark in the title of this article, but it covers some of the ideas: https://blog.codinghorror.com/the-first-rule-of-programming-its-always-your-fault/ & other articles around discuss similar ideas. Yes, there are compiler bugs - but you've sort of got to continue under the assumption that that's not the issue until you've got some fairly compelling evidence of one (very narrow test case where you can look at all the code & visually inspect/discuss/reason about its standards conformance - currently "all of GMP" is too big to apply that level of scrutiny). - Dave ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang9 UBSan and GMP
On Thu, Oct 31, 2019 at 1:51 PM Hans Åberg wrote: > > > On 31 Oct 2019, at 21:40, David Blaikie wrote: > > > >> On Thu, Oct 31, 2019 at 12:00 PM Hans Åberg wrote: > >> > >> > On 31 Oct 2019, at 18:40, David Blaikie wrote: > >> > > >> >> Right, but that is something one would avoid when computing > arithmetical results. > >> > > >> > One would try to, yes - but that's sort of what the whole discussion > is resolving around: Is the code correct? I don't know. I wouldn't assume > it is (I'm not assuming it isn't either) - but without a reduced test case > that gets to the root of the difference in behavior, we don't know if the > code is correct. > >> > >> Nor whether it is a compiler bug. > > > > Indeed - but you can imagine that, on average (just due to there being > way more code compiled by the compiler, than the code of the compiler > itself) the bug is in external code, not the compiler. > > GMP is not the average program, though. > > > Such that it's not practical for the compiler developers to do all the > leg work of investigating 3rd party code bugs to determine if it's a bug in > the compiler. It doesn't scale/we wouldn't have any time to work on the > compiler & most of the time we'd be finding user bugs, not compiler bugs. > > The GMP developers feel exactly the same, dropping Clang support. It is > mostly a problem for MacOS users that do not have access to GCC. > Yep, that's certainly their call - there's a cost to maintaining compatibility with each compiler/toolchain/platform, etc. If you have a personal interest in GMP on MacOS, then perhaps the cost falls to you, if you're willing to pay it, to investigate this sort of thing & help support this particular library+compiler combination, if it's worth your time to do so. > > Apologies for the snark in the title of this article, but it covers some > of the ideas: > https://blog.codinghorror.com/the-first-rule-of-programming-its-always-your-fault/ > & other articles around discuss similar ideas. > > This article is pretty naive: Yes, it is a good starting point to check > ones own code first, but eventually one learns to identify compiler bugs as > well. It is very time consuming, though. > Certainly - which is why it's not practical for compiler engineers to be spending all that time on everyone's bugs, right? > > Yes, there are compiler bugs - but you've sort of got to continue under > the assumption that that's not the issue until you've got some fairly > compelling evidence of one (very narrow test case where you can look at all > the code & visually inspect/discuss/reason about its standards conformance > - currently "all of GMP" is too big to apply that level of scrutiny). > > GMP is indeed very complex, not only from a programming point of view, but > also the underlying algorithms. > Yep - which makes it all the harder for me or someone else on the LLVM project to likely be able to find any potential compiler bugs in it. - Dave ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] does clang support option like MSVC's /Zc:forScope-
Hi, In early versions of C++, the scope of a variable defined in a for loop header extended to the end of the block containing the loop. Is there way for clang to compile this old source? Thanks, Guofeng ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
