Re: Remove RMS from the GCC Steering Committee

2021-03-30 Thread Andrew Haley via Gcc 
On 3/30/21 11:34 AM, Jonathan Wakely wrote:
> On Tue, 30 Mar 2021 at 11:14, Andrew Haley wrote:

>> We could just rename it to "GCC", in much the same way that Acorn Risc
>> Machine became Advanced Risc Machines, then just "Arm". But I'd much
>> prefer that the FSF got its house in order.
> 
> whynotboth.jpg

I dunno, I don't want to see the FSF become the Parler of free software
foundations.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Remove RMS from the GCC Steering Committee

2021-03-30 Thread Andrew Haley via Gcc 
On 3/30/21 10:47 AM, Didier Kryn wrote:
> Le 30/03/2021 à 10:25, Jonathan Wakely via Gcc a écrit :
>> I've been asking myself what benefit GCC gets from being linked to GNU and
>> all I can think of is the DNS records for gcc.gnu.org.
> 
>     Can you remind the meaning of GCC. Isn't it "*GNU* Compiler
> Collection" ?

It's been renamed at least once already, from "GNU C Compiler."

>     If this is still true, it doesn't seem appropriate to "break the
> communication channel" as you said in a previous mail. Or maybe you
> might suggest a new name for the project (~:

We could just rename it to "GCC", in much the same way that Acorn Risc
Machine became Advanced Risc Machines, then just "Arm". But I'd much
prefer that the FSF got its house in order.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Integer division on x86 -m32

2020-12-11 Thread Andrew Haley via Gcc 
On 11/12/2020 07:12, Marc Glisse wrote:
> On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
> 
>> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
>> __divdi3 is always output, even though it seems the use of the idiv
>> instruction could be faster.
> 
> IIRC, idiv requires that the quotient fit in 32 bits, while your C code 
> doesn't. (1LL << 60) / 3 would cause an error with idiv.

Isn't that an integer overflow, which is undefined behaviour?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Should ARMv8-A generic tuning default to -moutline-atomics

2020-04-29 Thread Andrew Haley via Gcc 
On 4/29/20 1:54 PM, Florian Weimer via Gcc wrote:
> * Kyrylo Tkachov:
>
>> Hi Florian,
>>>
>>> Distributions are receiving requests to build things with
>>> -moutline-atomics:
>>>
>>>   
>>>
>>> Should this be reflected in the GCC upstream defaults for ARMv8-A
>>> generic tuning?  It does not make much sense to me if every distribution
>>> has to overide these flags, either in their build system or by patching
>>> GCC.
>>
>> I don't think this is a "tuning" decision as such, it is a useful
>> feature for deploying LSE in a backwards-compatible manner.
>
> To me, the Debian bug report suggests that it's closer to a workaround
> for a silicon quirk on some platforms.  The performance impact of not
> using LSE on these platforms seems that severe unfortuantely.  That's
> why I thought it might be appropriate for generic tuning.

Yeah, it's gotta be a quirk of some kind. In Java we prefer LSE if
it's there, but there's no way that LDX/STX should be far more
expensive than atomic CAS.  It may well be that on N1 an LDX
followed quickly by an STX fails frequently under high contention,
which it really should not do.

It looks like the sample code provided is fantastically highly-
contended, which is IMVHO a perverse thing to optimize for.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671