What's the rationale to continue declare compatibility with GCC 4.2.1?

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

What's the rationale to continue declare compatibility with GCC 4.2.1?

Gavin Cui via cfe-dev
Hi,

Recently I get a request to implement in Clang a MIPS-related feature
which exists in GCC pre 4.4 and removed in later versions. There is a
rationale behind such strange request -- third-party software checks a
compiler's compatibility using __GNUC__,__GNUC_MINOR__ macros and
selects code dedicated for obsoleted version of GCC.

As to me I would use for __GNUC__,__GNUC_MINOR__,__GNUC_PATCHLEVEL__
macros defined in the InitializePredefinedMacros function the same
values as a minimal GCC version required for building LLVM/Clang [1].
Now it's 5.1.0.

Is there any rationale to continue declare compatibility with old GCC 4.2.1?

[1] https://llvm.org/docs/GettingStarted.html#software

--
Simon Atanasyan
_______________________________________________
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: What's the rationale to continue declare compatibility with GCC 4.2.1?

Gavin Cui via cfe-dev
The reason has always been that changing it would undoubtedly break some software which uses features of newer GCCs that aren't implemented in Clang. And there are indeed some of those features, even if they are weird edge cases.

Also, by this point, Clang is a widely-enough used compiler, that I'd expect most maintained software to be attempting to support it explicitly -- best via __has_builtin/__has_feature/__has_attribute/etc tests as applicable, falling back to the GCC version check if those macros don't exist.

On Wed, Jul 17, 2019 at 7:22 AM Simon Atanasyan via cfe-dev <[hidden email]> wrote:
Hi,

Recently I get a request to implement in Clang a MIPS-related feature
which exists in GCC pre 4.4 and removed in later versions. There is a
rationale behind such strange request -- third-party software checks a
compiler's compatibility using __GNUC__,__GNUC_MINOR__ macros and
selects code dedicated for obsoleted version of GCC.

As to me I would use for __GNUC__,__GNUC_MINOR__,__GNUC_PATCHLEVEL__
macros defined in the InitializePredefinedMacros function the same
values as a minimal GCC version required for building LLVM/Clang [1].
Now it's 5.1.0.

Is there any rationale to continue declare compatibility with old GCC 4.2.1?

[1] https://llvm.org/docs/GettingStarted.html#software

--
Simon Atanasyan
_______________________________________________
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: What's the rationale to continue declare compatibility with GCC 4.2.1?

Gavin Cui via cfe-dev
Sounds reasonable. Thanks.

On Wed, Jul 17, 2019 at 3:13 PM James Y Knight <[hidden email]> wrote:

>
> The reason has always been that changing it would undoubtedly break some software which uses features of newer GCCs that aren't implemented in Clang. And there are indeed some of those features, even if they are weird edge cases.
>
> Also, by this point, Clang is a widely-enough used compiler, that I'd expect most maintained software to be attempting to support it explicitly -- best via __has_builtin/__has_feature/__has_attribute/etc tests as applicable, falling back to the GCC version check if those macros don't exist.
>
> On Wed, Jul 17, 2019 at 7:22 AM Simon Atanasyan via cfe-dev <[hidden email]> wrote:
>>
>> Hi,
>>
>> Recently I get a request to implement in Clang a MIPS-related feature
>> which exists in GCC pre 4.4 and removed in later versions. There is a
>> rationale behind such strange request -- third-party software checks a
>> compiler's compatibility using __GNUC__,__GNUC_MINOR__ macros and
>> selects code dedicated for obsoleted version of GCC.
>>
>> As to me I would use for __GNUC__,__GNUC_MINOR__,__GNUC_PATCHLEVEL__
>> macros defined in the InitializePredefinedMacros function the same
>> values as a minimal GCC version required for building LLVM/Clang [1].
>> Now it's 5.1.0.
>>
>> Is there any rationale to continue declare compatibility with old GCC 4.2.1?
>>
>> [1] https://llvm.org/docs/GettingStarted.html#software

--
Simon Atanasyan
_______________________________________________
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: What's the rationale to continue declare compatibility with GCC 4.2.1?

Gavin Cui via cfe-dev
In reply to this post by Gavin Cui via cfe-dev

On Jul 17, 2019, at 2:13 PM, James Y Knight via cfe-dev <[hidden email]> wrote:

The reason has always been that changing it would undoubtedly break some software which uses features of newer GCCs that aren't implemented in Clang. And there are indeed some of those features, even if they are weird edge cases.

What you’re saying leads me to believe that https://reviews.llvm.org/rL365962 shouldn’t have been committed. Unless we now decide it’s OK to break code which check GCC quirks?


Also, by this point, Clang is a widely-enough used compiler, that I'd expect most maintained software to be attempting to support it explicitly -- best via __has_builtin/__has_feature/__has_attribute/etc tests as applicable, falling back to the GCC version check if those macros don't exist.

On Wed, Jul 17, 2019 at 7:22 AM Simon Atanasyan via cfe-dev <[hidden email]> wrote:
Hi,

Recently I get a request to implement in Clang a MIPS-related feature
which exists in GCC pre 4.4 and removed in later versions. There is a
rationale behind such strange request -- third-party software checks a
compiler's compatibility using __GNUC__,__GNUC_MINOR__ macros and
selects code dedicated for obsoleted version of GCC.

As to me I would use for __GNUC__,__GNUC_MINOR__,__GNUC_PATCHLEVEL__
macros defined in the InitializePredefinedMacros function the same
values as a minimal GCC version required for building LLVM/Clang [1].
Now it's 5.1.0.

Is there any rationale to continue declare compatibility with old GCC 4.2.1?

[1] https://llvm.org/docs/GettingStarted.html#software

--
Simon Atanasyan
_______________________________________________
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: What's the rationale to continue declare compatibility with GCC 4.2.1?

Gavin Cui via cfe-dev


On Jul 19, 2019, at 1:50 PM, JF Bastien via cfe-dev <[hidden email]> wrote:


On Jul 17, 2019, at 2:13 PM, James Y Knight via cfe-dev <[hidden email]> wrote:

The reason has always been that changing it would undoubtedly break some software which uses features of newer GCCs that aren't implemented in Clang. And there are indeed some of those features, even if they are weird edge cases.

What you’re saying leads me to believe that https://reviews.llvm.org/rL365962 shouldn’t have been committed. Unless we now decide it’s OK to break code which check GCC quirks?

To be clear, it was reverted, but we don’t really seem to have a standing policy. It was more “Python broke” that caused a revert.


Also, by this point, Clang is a widely-enough used compiler, that I'd expect most maintained software to be attempting to support it explicitly -- best via __has_builtin/__has_feature/__has_attribute/etc tests as applicable, falling back to the GCC version check if those macros don't exist.

On Wed, Jul 17, 2019 at 7:22 AM Simon Atanasyan via cfe-dev <[hidden email]> wrote:
Hi,

Recently I get a request to implement in Clang a MIPS-related feature
which exists in GCC pre 4.4 and removed in later versions. There is a
rationale behind such strange request -- third-party software checks a
compiler's compatibility using __GNUC__,__GNUC_MINOR__ macros and
selects code dedicated for obsoleted version of GCC.

As to me I would use for __GNUC__,__GNUC_MINOR__,__GNUC_PATCHLEVEL__
macros defined in the InitializePredefinedMacros function the same
values as a minimal GCC version required for building LLVM/Clang [1].
Now it's 5.1.0.

Is there any rationale to continue declare compatibility with old GCC 4.2.1?

[1] https://llvm.org/docs/GettingStarted.html#software

--
Simon Atanasyan
_______________________________________________
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: What's the rationale to continue declare compatibility with GCC 4.2.1?

Gavin Cui via cfe-dev
I think it was not a good idea to remove __VERSION__, but only because it actually breaks software (and not just Python). I don't think it's terribly important to preserve theoretically-pure compatibility at this point, but it is rather useful to keep practical compatibility.

I note a couple other changes in this area which might also be problematic.
- "4.2.1 Compatible" was removed from the beginning of __VERSION__.
- clang -dumpversion reports clang's version (e.g. "9.0.0", rather than always saying "4.2.1")

My inclination is that the former is very unlikely to break something (why would anyone use that string for anything other than human readable output, for which the new value is better?).

The latter, though, seems more risky, and I'm not sure there's much value to that change. Possibly it should be put back.


On Fri, Jul 19, 2019 at 7:53 AM JF Bastien <[hidden email]> wrote:


On Jul 19, 2019, at 1:50 PM, JF Bastien via cfe-dev <[hidden email]> wrote:


On Jul 17, 2019, at 2:13 PM, James Y Knight via cfe-dev <[hidden email]> wrote:

The reason has always been that changing it would undoubtedly break some software which uses features of newer GCCs that aren't implemented in Clang. And there are indeed some of those features, even if they are weird edge cases.

What you’re saying leads me to believe that https://reviews.llvm.org/rL365962 shouldn’t have been committed. Unless we now decide it’s OK to break code which check GCC quirks?

To be clear, it was reverted, but we don’t really seem to have a standing policy. It was more “Python broke” that caused a revert.


Also, by this point, Clang is a widely-enough used compiler, that I'd expect most maintained software to be attempting to support it explicitly -- best via __has_builtin/__has_feature/__has_attribute/etc tests as applicable, falling back to the GCC version check if those macros don't exist.

On Wed, Jul 17, 2019 at 7:22 AM Simon Atanasyan via cfe-dev <[hidden email]> wrote:
Hi,

Recently I get a request to implement in Clang a MIPS-related feature
which exists in GCC pre 4.4 and removed in later versions. There is a
rationale behind such strange request -- third-party software checks a
compiler's compatibility using __GNUC__,__GNUC_MINOR__ macros and
selects code dedicated for obsoleted version of GCC.

As to me I would use for __GNUC__,__GNUC_MINOR__,__GNUC_PATCHLEVEL__
macros defined in the InitializePredefinedMacros function the same
values as a minimal GCC version required for building LLVM/Clang [1].
Now it's 5.1.0.

Is there any rationale to continue declare compatibility with old GCC 4.2.1?

[1] https://llvm.org/docs/GettingStarted.html#software

--
Simon Atanasyan
_______________________________________________
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: What's the rationale to continue declare compatibility with GCC 4.2.1?

Gavin Cui via cfe-dev


On Jul 19, 2019, at 8:04 PM, James Y Knight <[hidden email]> wrote:

I think it was not a good idea to remove __VERSION__, but only because it actually breaks software (and not just Python). I don't think it's terribly important to preserve theoretically-pure compatibility at this point, but it is rather useful to keep practical compatibility.

All I’m saying is that the motivation didn’t contain a section on “we checked and nobody seems to use it”.


I note a couple other changes in this area which might also be problematic.
- "4.2.1 Compatible" was removed from the beginning of __VERSION__.
- clang -dumpversion reports clang's version (e.g. "9.0.0", rather than always saying "4.2.1")

My inclination is that the former is very unlikely to break something (why would anyone use that string for anything other than human readable output, for which the new value is better?).

It has broken non-humans in the past.


The latter, though, seems more risky, and I'm not sure there's much value to that change. Possibly it should be put back.


On Fri, Jul 19, 2019 at 7:53 AM JF Bastien <[hidden email]> wrote:


On Jul 19, 2019, at 1:50 PM, JF Bastien via cfe-dev <[hidden email]> wrote:


On Jul 17, 2019, at 2:13 PM, James Y Knight via cfe-dev <[hidden email]> wrote:

The reason has always been that changing it would undoubtedly break some software which uses features of newer GCCs that aren't implemented in Clang. And there are indeed some of those features, even if they are weird edge cases.

What you’re saying leads me to believe that https://reviews.llvm.org/rL365962 shouldn’t have been committed. Unless we now decide it’s OK to break code which check GCC quirks?

To be clear, it was reverted, but we don’t really seem to have a standing policy. It was more “Python broke” that caused a revert.


Also, by this point, Clang is a widely-enough used compiler, that I'd expect most maintained software to be attempting to support it explicitly -- best via __has_builtin/__has_feature/__has_attribute/etc tests as applicable, falling back to the GCC version check if those macros don't exist.

On Wed, Jul 17, 2019 at 7:22 AM Simon Atanasyan via cfe-dev <[hidden email]> wrote:
Hi,

Recently I get a request to implement in Clang a MIPS-related feature
which exists in GCC pre 4.4 and removed in later versions. There is a
rationale behind such strange request -- third-party software checks a
compiler's compatibility using __GNUC__,__GNUC_MINOR__ macros and
selects code dedicated for obsoleted version of GCC.

As to me I would use for __GNUC__,__GNUC_MINOR__,__GNUC_PATCHLEVEL__
macros defined in the InitializePredefinedMacros function the same
values as a minimal GCC version required for building LLVM/Clang [1].
Now it's 5.1.0.

Is there any rationale to continue declare compatibility with old GCC 4.2.1?

[1] https://llvm.org/docs/GettingStarted.html#software

--
Simon Atanasyan
_______________________________________________
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: What's the rationale to continue declare compatibility with GCC 4.2.1?

Gavin Cui via cfe-dev
On Fri, Jul 19, 2019 at 11:09 AM JF Bastien via cfe-dev <[hidden email]> wrote:
On Jul 19, 2019, at 8:04 PM, James Y Knight <[hidden email]> wrote:

I think it was not a good idea to remove __VERSION__, but only because it actually breaks software (and not just Python). I don't think it's terribly important to preserve theoretically-pure compatibility at this point, but it is rather useful to keep practical compatibility.

All I’m saying is that the motivation didn’t contain a section on “we checked and nobody seems to use it”.

I think between the folks involved (Duncan, myself, and Sylvestre) the idea was more like, "Can we do this? I don't know, let's try it and see if people complain." Sylvestre did searches on github that suggested that it would, in fact, break code. And, people complained, so it looks like we have to define __VERSION__.

On some level, users can always solve their own build issues with -D__VERSION__=whatever, so I'm kind of inclined to try again some day.

I note a couple other changes in this area which might also be problematic.
- "4.2.1 Compatible" was removed from the beginning of __VERSION__.
- clang -dumpversion reports clang's version (e.g. "9.0.0", rather than always saying "4.2.1")

My inclination is that the former is very unlikely to break something (why would anyone use that string for anything other than human readable output, for which the new value is better?).

It has broken non-humans in the past.

The latter, though, seems more risky, and I'm not sure there's much value to that change. Possibly it should be put back.

No actual user has reported problems with the new -dumpversion behavior yet, but users have complained about it reporting a GCC version in the past.

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