[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2017-06-27 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

--- Comment #11 from Uroš Bizjak  ---
(In reply to Andy Lutomirski from comment #9)
> I'm a bit late to the party, but this patch seems dubious to me. 
> __get_cpuid_max() fails to distinguish between CPUs that have max level 0
> (although I doubt that any such CPUs exist) and CPUs that don't have CPUID
> at all.

No, cpuid leaf 0 will never return zero [1].

[1] https://en.wikipedia.org/wiki/CPUID#EAX.3D0:_Highest_Function_Parameter

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2017-06-27 Thread christos at zoulas dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

--- Comment #10 from Christos Zoulas  ---
On Jun 27,  4:26pm, gcc-bugzi...@gcc.gnu.org ("luto at kernel dot org") wrote:
-- Subject: [Bug target/68491] libgcc calls __get_cpuid with 0 level breaks o

| I'm a bit late to the party, but this patch seems dubious to me.=20
| __get_cpuid_max() fails to distinguish between CPUs that have max level 0
| (although I doubt that any such CPUs exist) and CPUs that don't have CPUID =
| at
| all.
| 
| Shouldn't __get_cpuid_max return -1 if CPUID isn't there or, alternatively,=
| 
| just generally return the last level + 1 (and 0 if CPUID isn't there)?
| 

Yes, it should. That would be cleaner, but my goal was minimal change
not refactoring :-)

christos

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2017-06-27 Thread luto at kernel dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

Andy Lutomirski  changed:

   What|Removed |Added

 CC||luto at kernel dot org

--- Comment #9 from Andy Lutomirski  ---
I'm a bit late to the party, but this patch seems dubious to me. 
__get_cpuid_max() fails to distinguish between CPUs that have max level 0
(although I doubt that any such CPUs exist) and CPUs that don't have CPUID at
all.

Shouldn't __get_cpuid_max return -1 if CPUID isn't there or, alternatively,
just generally return the last level + 1 (and 0 if CPUID isn't there)?

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2017-06-26 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

Uroš Bizjak  changed:

   What|Removed |Added

 CC||tedheadster at gmail dot com

--- Comment #8 from Uroš Bizjak  ---
*** Bug 81218 has been marked as a duplicate of this bug. ***

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2017-05-03 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Uroš Bizjak  ---
Fixed everywhere.


[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2017-05-03 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May  3 20:00:50 2017
New Revision: 247566

URL: https://gcc.gnu.org/viewcvs?rev=247566=gcc=rev
Log:
Backport from mainline
2017-05-01  Uros Bizjak  

PR target/68491
* config/i386/cpuid.h (__get_cpuid): Always return 0 when
__get_cpuid_max returns 0.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/cpuid.h

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2017-05-03 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May  3 18:19:28 2017
New Revision: 247561

URL: https://gcc.gnu.org/viewcvs?rev=247561=gcc=rev
Log:
Backport from mainline
2017-05-01  Uros Bizjak  

PR target/68491
* config/i386/cpuid.h (__get_cpuid): Always return 0 when
__get_cpuid_max returns 0.
(__get_cpuid_count): Ditto.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/cpuid.h

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2017-05-02 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue May  2 20:36:26 2017
New Revision: 247523

URL: https://gcc.gnu.org/viewcvs?rev=247523=gcc=rev
Log:
Backport from mainline
2017-05-01  Uros Bizjak  

PR target/68491
* config/i386/cpuid.h (__get_cpuid): Always return 0 when
__get_cpuid_max returns 0.
(__get_cpuid_count): Ditto.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/cpuid.h

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2017-05-01 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

Uroš Bizjak  changed:

   What|Removed |Added

 Target|i?86-*-*|x86
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-01
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2017-05-01 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon May  1 15:38:14 2017
New Revision: 247439

URL: https://gcc.gnu.org/viewcvs?rev=247439=gcc=rev
Log:
PR target/68491
* config/i386/cpuid.h (__get_cpuid): Always return 0 when
__get_cpuid_max returns 0.
(__get_cpuid_count): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/cpuid.h

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2017-04-28 Thread christos at zoulas dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

--- Comment #2 from Christos Zoulas  ---
Created attachment 41284
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41284=edit
Amended cpuid patch.

Here's an amended patch against the trunk. Also sent mail to gcc-patches@

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

2016-01-23 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491

--- Comment #1 from Andrew Pinski  ---
Patches should goto gcc-patches@ and should be based off the trunk of GCC.